Whole post from Patently Defined is here.
Example 1 - An Improper Taking of Official Notice
Applicant respectfully traverses the rejection of independent claim 1 at least because the Office has failed to establish a prima facie case of obviousness.
In rejecting independent claim 1 under 35 U.S.C § 103, the Office Action contends:
It would have been obvious to one having ordinary skill in the art at the time the invention was made to replace the printer of Smith with the plotter of Jones since the Examiner takes Official Notice of the equivalent use in the art and the selection of any of these known equivalents to write information on a plastic card would be within the level of ordinary skill in the art.
Applicant respectfully traverses this attempted use of Official Notice as improper. Consequently, a necessary element of a prima facie case is absent.
Firstly, it is to be appreciated that the Office Action attempts to officially notice legal conclusions, –namely “the equivalent use in the art and the selection of any of these known equivalents to write information on a plastic card would be within the level of ordinary skill in the art.” Official Notice, however, is only proper for facts. (MPEP § 2144.03). Indeed, Official Notice is only permissible for those few facts that are of a “notorious character” and that are “capable of instant and unquestionable demonstration”. (MPEP § 2144.03(A)). It is improper to use Official Notice for conclusions of law.
Secondly, the Office Action relies on Official Notice as the “principal evidence” upon which the rejection of claim 1 is based. Official Notice cannot be used in this manner. As Section 2144.03(A) of the MPEP expressly warns, it is never appropriate to rely solely on Official Notice as the principal evidence upon which a rejection was based. Instead, Official Notice is only appropriate for facts and that serve to “fill in the gaps” in a rejection. (MPEP § 2144.03(A)). This is why official notice is to be judicially applied. (MPEP § 2144.03). It is unreasonable to conclude that the Office has used Official Notice to “fill in” a gap in this rejection.
Thirdly, the Office attempts to take Official Notice of matter that is not “capable of instant and unquestionable demonstration”, as expressly required by section 2144.03(A) of the MPEP. Indeed, even assuming arguendo that the equivalence of the subject printer and plotter is a fact, this fact would be neither of notorious character nor instantly and unquestionably demonstrable. Moreover, courts have long rejected the notion that official notice can be taken on the state of the art. (See Memorandum to Patent Examining Corps from the Deputy Commissioner for Patent Examining Policy regarding Procedures for Relying on Facts Which are Not of Record as Common Sense or for Taking Official Notice, n.6, citing In re Eynde, 480 F.2d 1364, 1370, 178 USPQ 470, 474 (CCPA 1973)). Thus, the Office’s attempt to officially notice the level of ordinary skill in the art is improper as a matter of law.
In sum, the Office’s attempts at Official Notice are improper and traversed. Consequently, there are evidentiary gaps in the rejection of independent claim 1 that are fatal to a prima facie case of obviousness.
Example 2 - An Ambiguous Taking of Official Notice --e.g., Well Known or the like.
Lastly, Applicant notes, at page 4 of the Office Action, an apparent attempt to officially notice a fact. If the Office has intended to take Official Notice, such an attempt is traversed, at least because it is not in compliance with the Office’s own procedures.
Proper use of Official Notice requires compliance with several obligations expressly set forth in the Manual of Patent Examining Procedure. The Office has failed to meet these obligations. Specifically, the Office has failed to satisfy its obligations under MPEP § 2144.03. MPEP § 2144.03 (B), for example, expressly requires the Office to provide specific factual findings predicated on sound technical and scientific reasoning to support taking Official Notice. The MPEP goes on to explain that this means that the Office should present an Applicant with the explicit basis on which Official Notice is based so that the Applicant is able to challenge the assertion in the next reply after the Office action. (MPEP §2144.03(B)). Naked assertions about what is allegedly known in the art, like those made at page 4 of the Office Action, cannot satisfy these requirements.
In the event that the Office is not attempting to take Official Notice, Applicant respectfully requests confirmation of this fact.
Also:• Rule 1.104(d)(2)
– Allows applicant to request affidavit from Examiner in support of
statements made based on personal knowledge
– Often forces Examiner to find additional prior art and issue new,
non-final office action
Wednesday, April 1, 2009
Factors in determining enablement--the Wands factors
Copied from Patently Defined
The Basis for the Enablement Requirement
The enablement requirement arises from the first paragraph of 35 U.S.C. § 112, which states in relevant part:
[t]he specification shall contain a written description of the invention, and the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same . . .
The purpose of the enablement requirement is to ensure that patented inventions are communicated to the public in a meaningful way.
Fundamentals of the Enablement Requirement
1. The USPTO’s guidelines for examination of patent applications for compliance with the enablement requirement are found in Section 2164 of the MPEP. This should be an Applicant’s primary resource for authority when articulating responses to enablement rejections.
2. All questions of enablement are evaluated against claimed subject matter. (MPEP 2164.08).
3. The test for enablement is whether one of ordinary skill would need to engage in undue experimentation to practice the claimed invention. (MPEP 2164.01).
4. Whether experimentation is “undue” is determined based on the following eight Wands factors:
1. Breadth of the claims;
2. Nature of the invention;
3. State of the prior art;
4. Level of ordinary skill in the art;
5. Predictability of the art;
6. Amount of direction provided in the specification;
7. Any working examples; and
8. Quantity of experimentation needed relative to the disclosure.
(MPEP 2164.01(a), citing In re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988)).
5. A proper analysis of whether any experimentation is undue requires an analysis of all of the Wands factors. (MPEP 2164.01(a)). It is improper to conclude that a disclosure is not enabling based on an analysis of only one of the above factors while ignoring one or more of the others. (Id.).
6. The amount of guidance or direction needed to satisfy the enablement requirement is inversely related to the amount of knowledge in the state of the art as well as the predictability in the art. (MPEP 2164.03). Thus, the question of enablement is one of predictability in view of what is known in the art.
Additional Points
1. The fact that experimentation may be complex does not necessarily make it undue, if the art typically engages in such experimentation. (MPEP 2164.01).
2. A patent need not teach, and preferably omits, what is well known in the art. (MPEP 2164.01). Further, an Applicant need not “enable one of ordinary skill in the art to make and use a perfected, commercially viable embodiment absent a claim limitation to that effect.” (MPEP 2164).
3. Any part of the specification can support an enabling disclosure, even a background section that discusses, or even disparages, the subject matter disclosed therein. (MPEP 2164.01, citing Callicrate v. Wadsworth Mfg., Inc., 427 F.3d 1361, 77 USPQ2d 1041 (Fed. Cir. 2005)(discussion of problems with a prior art feature does not mean that one of ordinary skill in the art would not know how to make and use this feature)).
4. The specification need not contain an example if the invention is otherwise disclosed in such manner that one skilled in the art will be able to practice it without undue experimentation. (MPEP 2164.02).
5. As long as the specification discloses at least one method for making and using the claimed invention that bears a reasonable correlation to the entire scope of the claim, then the enablement requirement of 35 U.S.C. 112 is satisfied. (MPEP 2164.01(b)).
6. Claims must be enabled as of their filing date. (MPEP 2164.05(a)).
7. Enablement is judged from the perspective of an ordinarily skilled artisan. (MPEP 2164.05(b)).
The Office’s Burden
1. It is always incumbent on an Examiner to fully develop the reasons for a technical rejection (enablement, written description, etc.).
Section 706.03 of the MPEP warns Examiners that “[w]here a major technical rejection is proper (e.g., lack of proper disclosure, undue breadth, utility, etc.) such rejection should be stated with a full development of the reasons rather than by a mere conclusion coupled with some stereotyped expression.” Thus, mere conclusory statements are insufficient to support a rejection under Section 112. Consequently, the Office must arguably provide a reasonable basis to reject a claim for failing to satisfy the enablement requirement, and this requires “a full development” of the reasons for the rejection.
This obligation to establish a prima facie case is affirmed by the MPEP in its discussions of each requirement of the first paragraph of 35 U.S.C. § 112. (See, e.g., MPEP § 2163 (III)(A) (written description); MPEP § 2164.04 (enablement)). A prima facie case requires a reasonable basis to challenge the adequacy of the written description. (MPEP § 2164.04).
In accordance with the principles of compact prosecution, if an enablement rejection is appropriate, the first Office action on the merits should present the best case with all the relevant reasons, issues, and evidence so that all such rejections can be withdrawn if applicant provides appropriate convincing arguments and/or evidence in rebuttal. The principles of compact prosecution also dictate that if an enablement rejection is appropriate and the examiner recognizes limitations that would render the claims enabled, the examiner should note such limitations to applicant as early in the prosecution as possible. (MPEP 2164.04).
2. An Examiner should always look for enabled, allowable subject matter and communicate to applicant what that subject matter is at the earliest point possible in the prosecution of the application. (MPEP 2164.04). Thus, if a rejection is made based on the view that the enablement is not commensurate in scope with the claim, the examiner should identify the subject matter that is considered to be enabled. (MPEP 2164.08).
3. The Examiner’s analysis must consider all the evidence related to each of these factors, and any conclusion of nonenablement must be based on the evidence as a whole. (MPEP 2164.01(a)).
4. Only after the Examiner has weighed all the evidence and established a reasonable basis to question the enablement provided for the claimed invention, does the burden fall on applicant to present persuasive arguments, supported by suitable proofs where necessary, that one skilled in the art would be able to make and use the claimed invention using the application as a guide. (MPEP 2164.05). The evidence provided by applicant need not be conclusive but merely convincing to one skilled in the art. (Id.).
5. The MPEP instructs Examiners that they must assume compliance with the enablement requirement when an application includes a teaching of how to make and use invention “in terms which correspond in scope to the claims.” This mandate may be only ignored when there is a basis to doubt the objective truth of the teaching. (MPEP 2164.04).
So, unless a rejection articulates “evidence or some technical reasoning” that either (i) an enabling teaching does not correspond to the claims or (ii) a reason to doubt the objective truth of such a teaching, the mere presence of a teaching requires that the Office assume that this requirement is satisfied.
The Basis for the Enablement Requirement
The enablement requirement arises from the first paragraph of 35 U.S.C. § 112, which states in relevant part:
[t]he specification shall contain a written description of the invention, and the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same . . .
The purpose of the enablement requirement is to ensure that patented inventions are communicated to the public in a meaningful way.
Fundamentals of the Enablement Requirement
1. The USPTO’s guidelines for examination of patent applications for compliance with the enablement requirement are found in Section 2164 of the MPEP. This should be an Applicant’s primary resource for authority when articulating responses to enablement rejections.
2. All questions of enablement are evaluated against claimed subject matter. (MPEP 2164.08).
3. The test for enablement is whether one of ordinary skill would need to engage in undue experimentation to practice the claimed invention. (MPEP 2164.01).
4. Whether experimentation is “undue” is determined based on the following eight Wands factors:
1. Breadth of the claims;
2. Nature of the invention;
3. State of the prior art;
4. Level of ordinary skill in the art;
5. Predictability of the art;
6. Amount of direction provided in the specification;
7. Any working examples; and
8. Quantity of experimentation needed relative to the disclosure.
(MPEP 2164.01(a), citing In re Wands, 858 F.2d 731, 737, 8 USPQ2d 1400, 1404 (Fed. Cir. 1988)).
5. A proper analysis of whether any experimentation is undue requires an analysis of all of the Wands factors. (MPEP 2164.01(a)). It is improper to conclude that a disclosure is not enabling based on an analysis of only one of the above factors while ignoring one or more of the others. (Id.).
6. The amount of guidance or direction needed to satisfy the enablement requirement is inversely related to the amount of knowledge in the state of the art as well as the predictability in the art. (MPEP 2164.03). Thus, the question of enablement is one of predictability in view of what is known in the art.
Additional Points
1. The fact that experimentation may be complex does not necessarily make it undue, if the art typically engages in such experimentation. (MPEP 2164.01).
2. A patent need not teach, and preferably omits, what is well known in the art. (MPEP 2164.01). Further, an Applicant need not “enable one of ordinary skill in the art to make and use a perfected, commercially viable embodiment absent a claim limitation to that effect.” (MPEP 2164).
3. Any part of the specification can support an enabling disclosure, even a background section that discusses, or even disparages, the subject matter disclosed therein. (MPEP 2164.01, citing Callicrate v. Wadsworth Mfg., Inc., 427 F.3d 1361, 77 USPQ2d 1041 (Fed. Cir. 2005)(discussion of problems with a prior art feature does not mean that one of ordinary skill in the art would not know how to make and use this feature)).
4. The specification need not contain an example if the invention is otherwise disclosed in such manner that one skilled in the art will be able to practice it without undue experimentation. (MPEP 2164.02).
5. As long as the specification discloses at least one method for making and using the claimed invention that bears a reasonable correlation to the entire scope of the claim, then the enablement requirement of 35 U.S.C. 112 is satisfied. (MPEP 2164.01(b)).
6. Claims must be enabled as of their filing date. (MPEP 2164.05(a)).
7. Enablement is judged from the perspective of an ordinarily skilled artisan. (MPEP 2164.05(b)).
The Office’s Burden
1. It is always incumbent on an Examiner to fully develop the reasons for a technical rejection (enablement, written description, etc.).
Section 706.03 of the MPEP warns Examiners that “[w]here a major technical rejection is proper (e.g., lack of proper disclosure, undue breadth, utility, etc.) such rejection should be stated with a full development of the reasons rather than by a mere conclusion coupled with some stereotyped expression.” Thus, mere conclusory statements are insufficient to support a rejection under Section 112. Consequently, the Office must arguably provide a reasonable basis to reject a claim for failing to satisfy the enablement requirement, and this requires “a full development” of the reasons for the rejection.
This obligation to establish a prima facie case is affirmed by the MPEP in its discussions of each requirement of the first paragraph of 35 U.S.C. § 112. (See, e.g., MPEP § 2163 (III)(A) (written description); MPEP § 2164.04 (enablement)). A prima facie case requires a reasonable basis to challenge the adequacy of the written description. (MPEP § 2164.04).
In accordance with the principles of compact prosecution, if an enablement rejection is appropriate, the first Office action on the merits should present the best case with all the relevant reasons, issues, and evidence so that all such rejections can be withdrawn if applicant provides appropriate convincing arguments and/or evidence in rebuttal. The principles of compact prosecution also dictate that if an enablement rejection is appropriate and the examiner recognizes limitations that would render the claims enabled, the examiner should note such limitations to applicant as early in the prosecution as possible. (MPEP 2164.04).
2. An Examiner should always look for enabled, allowable subject matter and communicate to applicant what that subject matter is at the earliest point possible in the prosecution of the application. (MPEP 2164.04). Thus, if a rejection is made based on the view that the enablement is not commensurate in scope with the claim, the examiner should identify the subject matter that is considered to be enabled. (MPEP 2164.08).
3. The Examiner’s analysis must consider all the evidence related to each of these factors, and any conclusion of nonenablement must be based on the evidence as a whole. (MPEP 2164.01(a)).
4. Only after the Examiner has weighed all the evidence and established a reasonable basis to question the enablement provided for the claimed invention, does the burden fall on applicant to present persuasive arguments, supported by suitable proofs where necessary, that one skilled in the art would be able to make and use the claimed invention using the application as a guide. (MPEP 2164.05). The evidence provided by applicant need not be conclusive but merely convincing to one skilled in the art. (Id.).
5. The MPEP instructs Examiners that they must assume compliance with the enablement requirement when an application includes a teaching of how to make and use invention “in terms which correspond in scope to the claims.” This mandate may be only ignored when there is a basis to doubt the objective truth of the teaching. (MPEP 2164.04).
So, unless a rejection articulates “evidence or some technical reasoning” that either (i) an enabling teaching does not correspond to the claims or (ii) a reason to doubt the objective truth of such a teaching, the mere presence of a teaching requires that the Office assume that this requirement is satisfied.
Bilski Transformation, claims that didn't make it
Claim 16 and Claim 18 were the focus of the Appeal and stated, respectively:
16. An additional information embedding method, for adding additional information to digital content to determine whether said digital content has been processed, comprising the steps of:
generating multiple sets of additional information that are correlated with each other and that correspond to the data form of predetermined digital content; and
synthesizing said additional information and content data for said digital content; and
wherein the additional information are correlated with each other by a mapping relationship defined by a predetermined function, said predetermined function dependent on a data string, the data string forming a predetermined message.
18. An additional content detection method, for detecting additional information added to a digital content in order to determine whether said digital content has been processed, comprising the steps of:
detecting, from content data for digital content, multiple sets of additional information that are correlated with each other, but that in robustness differ from each other;
evaluating relationships dependent on a data string, the data string forming a predetermined message, existing between said multiple sets of additional information; and
determining, based on said detected additional information and the evaluation of said relationships, whether said content data has been processed, and determining the type of processing performed when said content data has been processed.
In explaining their Bilski analysis, the BPAI said that the method steps of claims 16 and 18 can reasonably be interpreted to encompass a human being performing these steps. Thus, the claims fail the "particular machine requirement."
The BPAI's discussion of the "transformation requirement" is more interesting. They said that:
[h]ere we do not have a transformation of subject matter but merely an abstract expression that is created from synthesizing two types of digital content. However, such synthesizing does not require any tangible output into the real world. These steps describe nothing more than the manipulation of basic mathematical constructs, the paradigmatic "abstract idea." See In re Warmerdam, 33 F.3d 1354, 1360 (Fed. Cir. 1994). As a whole, the claim involves no more than the manipulation of abstract ideas. See id.
The BPAI went on to say in other words that the claims were directed to merely looking at transforming one digital representation into another digital representation. As such, they are not within the scope of 101.
Copied from BPAI Watchdog.
16. An additional information embedding method, for adding additional information to digital content to determine whether said digital content has been processed, comprising the steps of:
generating multiple sets of additional information that are correlated with each other and that correspond to the data form of predetermined digital content; and
synthesizing said additional information and content data for said digital content; and
wherein the additional information are correlated with each other by a mapping relationship defined by a predetermined function, said predetermined function dependent on a data string, the data string forming a predetermined message.
18. An additional content detection method, for detecting additional information added to a digital content in order to determine whether said digital content has been processed, comprising the steps of:
detecting, from content data for digital content, multiple sets of additional information that are correlated with each other, but that in robustness differ from each other;
evaluating relationships dependent on a data string, the data string forming a predetermined message, existing between said multiple sets of additional information; and
determining, based on said detected additional information and the evaluation of said relationships, whether said content data has been processed, and determining the type of processing performed when said content data has been processed.
In explaining their Bilski analysis, the BPAI said that the method steps of claims 16 and 18 can reasonably be interpreted to encompass a human being performing these steps. Thus, the claims fail the "particular machine requirement."
The BPAI's discussion of the "transformation requirement" is more interesting. They said that:
[h]ere we do not have a transformation of subject matter but merely an abstract expression that is created from synthesizing two types of digital content. However, such synthesizing does not require any tangible output into the real world. These steps describe nothing more than the manipulation of basic mathematical constructs, the paradigmatic "abstract idea." See In re Warmerdam, 33 F.3d 1354, 1360 (Fed. Cir. 1994). As a whole, the claim involves no more than the manipulation of abstract ideas. See id.
The BPAI went on to say in other words that the claims were directed to merely looking at transforming one digital representation into another digital representation. As such, they are not within the scope of 101.
Copied from BPAI Watchdog.
Appeal grounds, ideas
Successful appellants have proven factual errors including claim and reference interpretation errors. Similarly, successful appellants have proven legal errors including (a) non-analogous art cited by the patent examiner, (b) impermissible hindsight by the patent examiner, (c) inoperable combination of references, and (d) references cited by the patent examiner that taught way from the patent application. Finally, successful appellants included (a) thoughtful definitions of a person having ordinary skill in the art (PHOSITA) and (b) records having evidence of secondary indicia of non-obviousness. However, even if successful in overcoming the patent examiner’s rejection, appellants must consider the chance the Board will assert sua sponte rejections for claims that (i) do not recite patentable subject matter, (ii) are indefinite Hybrid claims reciting two statutory classes, (ii) lack enablement, and (iii) lack written description even for patentable claim features added in amendments during prosecution.
An applicant should appeal when properly interpreted claim language recites features that distinguish over properly applied references. In the heat of prosecution, Applicants sometimes lose sight that the pending claims need to clearly recite what is argued. If the pending claims can be amended to better support the arguments, a request for continued examination should be filed with claim amendments instead of an appeal. However, if the applicant believes that the invention has been optimally claimed and that the claims are distinguishable over the applied references, continuing prosecution is usually an inefficient use of resources. Rather, appealing the application is necessary.
Take Aways
Appeal to the Board is worthwhile since after successful appeal to the Board 80% of applications issue as patents.
Factual errors include claim and reference misinterpretations by the patent examiner.
Legal errors include (a) non-analogous art cited by the patent examiner, (b) impermissible hindsight by the patent examiner, (c) inoperable combination of references, and (d) references cited by the patent examiner that taught way from the patent application.
Success on appeals can increase when appellants include (a) definitions of a person having ordinary skill in the art (PHOSITA) and (b) records having evidence of secondary indicia of non-obviousness.
Appellants must balance success on appeal with the risk of narrow claim interpretations and sue sponte rejections for claiming non-patentable subject matter or amended claims that, although allowable over art, fail written description requirements.
In the end, Appealing final rejections from "hard-line" patent examiners may be an applicant’s only chance for reversing improper obviousness rejections to obtain an allowance for their application.
Copied from BPAI Watchdog, here. http://bpaiwatchdog.blogspot.com/
An applicant should appeal when properly interpreted claim language recites features that distinguish over properly applied references. In the heat of prosecution, Applicants sometimes lose sight that the pending claims need to clearly recite what is argued. If the pending claims can be amended to better support the arguments, a request for continued examination should be filed with claim amendments instead of an appeal. However, if the applicant believes that the invention has been optimally claimed and that the claims are distinguishable over the applied references, continuing prosecution is usually an inefficient use of resources. Rather, appealing the application is necessary.
Take Aways
Appeal to the Board is worthwhile since after successful appeal to the Board 80% of applications issue as patents.
Factual errors include claim and reference misinterpretations by the patent examiner.
Legal errors include (a) non-analogous art cited by the patent examiner, (b) impermissible hindsight by the patent examiner, (c) inoperable combination of references, and (d) references cited by the patent examiner that taught way from the patent application.
Success on appeals can increase when appellants include (a) definitions of a person having ordinary skill in the art (PHOSITA) and (b) records having evidence of secondary indicia of non-obviousness.
Appellants must balance success on appeal with the risk of narrow claim interpretations and sue sponte rejections for claiming non-patentable subject matter or amended claims that, although allowable over art, fail written description requirements.
In the end, Appealing final rejections from "hard-line" patent examiners may be an applicant’s only chance for reversing improper obviousness rejections to obtain an allowance for their application.
Copied from BPAI Watchdog, here. http://bpaiwatchdog.blogspot.com/
Software per se--arguing against 101
http://des.uspto.gov/Foia/ReterivePdf?system=BPAI&flNm=fd20082854-02-27-2009-1
Above is aBPAI decision stating that "a component executing on a computer" in the body of the claim means that the claim is not software per se.
"Regarding the non-statutory test, while the storage of information in independent claim 1 could arguably be done as a mental process, the recitation of a structured relationship between multiple stores that requires 'path information' inherently implies that this information must be stored on a computer or database. This 'particular' computer or database is sufficient structure to meet the machine prong of the machine-or-transformation test of In re Bilski."
http://des.uspto.gov/Foia/ReterivePdf?system=BPAI&flNm=fd20083475-03-28-2009-1
Ex parte Borenstein.
Above is aBPAI decision stating that "a component executing on a computer" in the body of the claim means that the claim is not software per se.
"Regarding the non-statutory test, while the storage of information in independent claim 1 could arguably be done as a mental process, the recitation of a structured relationship between multiple stores that requires 'path information' inherently implies that this information must be stored on a computer or database. This 'particular' computer or database is sufficient structure to meet the machine prong of the machine-or-transformation test of In re Bilski."
http://des.uspto.gov/Foia/ReterivePdf?system=BPAI&flNm=fd20083475-03-28-2009-1
Ex parte Borenstein.
Friday, March 13, 2009
Functional language not improper -- MPEP cites
The method steps merely describe the "functionality" imparted by the computer readable medium to the computer. As discussed in MPEP 2173.05(g):
"There is nothing inherently wrong with defining some part of an invention in functional terms. Functional language does not, in and of itself, render a claim improper."
"There is nothing inherently wrong with defining some part of an invention in functional terms. Functional language does not, in and of itself, render a claim improper."
Claim must be considered as a whole, refs
Flook, 437 U.S. at 594 ("Our approach to respondent's application is, however, not at all inconsistent with the view that a patent claim must be considered as a whole."); Diehr, 450 U.S. at 188 ("It is inappropriate to dissect the claims into old and new elements and then to ignore the presence of the old elements in the analysis.").
As such, if you claim a DVD (an example of a computer readable medium), when the "claim as a whole" is considered, the DVD is patentable subject matter because you cannot ignore that a DVD is neither a law of nature, natural phenomena, nor abstract idea.
"If the only difference between the alleged invention and the prior art is based on content or information, then the alleged invention isn't really tied to a particular machine."
If you ask one having ordinary skill in the art, they will say that a "general purpose computer" with the DVD (or other computer readable medium) encoded with the instructions for perform a method (i.e., the typical Beauregard language) is measurably different than an identical general purpose computer in which the DVD (or other computer readable medium) does not include the encoded instructions.
There may be a difference "based on content or information," as you allege, but that difference is measurable.
FYI your statement that "the alleged invention isn't really tied to a particular machine" ignores that Beauregard claims are product claims, not method claims. Just because you burn instructions on a DVD doesn't magically convert the DVD from a product into some "abstract method."
From MPEP 2141.02:
In determining the differences between the prior art and the claims, the question under 35 U.S.C. 103 is not whether the differences themselves would have been obvious, but whether the claimed invention as a whole would have been obvious. (underlining under "as a whole" omitted."
Under 35 USC 102, you have to establish that the prior art teaches ALL of the claimed limitations.
Thus, you have to look at the claimed invention AS A WHOLE, which includes ALL of the limitations. A blank DVD is not 102/103 art for the average Beauregard claim for those reasons.
The method steps merely describe the "functionality" imparted by the computer readable medium to the computer. As discussed in MPEP 2173.05(g):
"There is nothing inherently wrong with defining some part of an invention in functional terms. Functional language does not, in and of itself, render a claim improper."
Commenter at Patentlyo.com
As such, if you claim a DVD (an example of a computer readable medium), when the "claim as a whole" is considered, the DVD is patentable subject matter because you cannot ignore that a DVD is neither a law of nature, natural phenomena, nor abstract idea.
"If the only difference between the alleged invention and the prior art is based on content or information, then the alleged invention isn't really tied to a particular machine."
If you ask one having ordinary skill in the art, they will say that a "general purpose computer" with the DVD (or other computer readable medium) encoded with the instructions for perform a method (i.e., the typical Beauregard language) is measurably different than an identical general purpose computer in which the DVD (or other computer readable medium) does not include the encoded instructions.
There may be a difference "based on content or information," as you allege, but that difference is measurable.
FYI your statement that "the alleged invention isn't really tied to a particular machine" ignores that Beauregard claims are product claims, not method claims. Just because you burn instructions on a DVD doesn't magically convert the DVD from a product into some "abstract method."
From MPEP 2141.02:
In determining the differences between the prior art and the claims, the question under 35 U.S.C. 103 is not whether the differences themselves would have been obvious, but whether the claimed invention as a whole would have been obvious. (underlining under "as a whole" omitted."
Under 35 USC 102, you have to establish that the prior art teaches ALL of the claimed limitations.
Thus, you have to look at the claimed invention AS A WHOLE, which includes ALL of the limitations. A blank DVD is not 102/103 art for the average Beauregard claim for those reasons.
The method steps merely describe the "functionality" imparted by the computer readable medium to the computer. As discussed in MPEP 2173.05(g):
"There is nothing inherently wrong with defining some part of an invention in functional terms. Functional language does not, in and of itself, render a claim improper."
Commenter at Patentlyo.com
Saturday, January 3, 2009
Kyle Rules
Don't delete dependent claims, just add new dependent claims.
If dependent claims are allowed, add them separately to independent claims, pay for the extra independent claims, if necessary.
If dependent claims are allowed, add them separately to independent claims, pay for the extra independent claims, if necessary.
Kyle's preferred format
Claims 1-4, 6-10, and 28-33.
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Kyle's preferred format
Claims 1-4, 6-10, and 28-33.
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Neither Rojewski nor Schumacher, either separately or in combination teach or suggest, e.g., the amended claim 1 language
…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application; …
wherein the one or more opaque recorded step tokens comprise discrete chunks of data opaque to the external UI recorder that are not interpreted by the external UI recorder but are recognizable in the graphical user interface-based application. [Emphasis added.]
Tokenization is described, e.g., in the Specification as follows:
The application 240 converts each discrete recorded step into a token, or the application 240 groups multiple recorded steps as a single token. As for the mechanics of the tokenization, the application 240 may group recorded step data into one or more fields of a data structure for a token, which is then passed by copy or reference to the tool 220. Or, the application 240 may pass recorded step data as parameters of a method call, which the tool 220 receives and handles as opaque data. The application 240 may use an XML rules sheet (which defines a set of rules for tokenizing recorded step data) to reformat or reorganize the recorded step data into tokens. Or, the application 240 uses some other mechanism for tokenization. Conceptually, the tokenization may be viewed as placing the recorded step data in a token data structure, or wrapping the recorded step data with token information. This “hides” the macro language instructions from the tool, creating a token that is macro language independent but whose contents are recognizable in the appropriate native recording environment.
Specification p. 17, lines 7-19.
Rojewski discusses processing a user interaction with a browser-based application. [Rojewski, Abstract.] Instructions are passed from a user application to a “web recording service” where they are then packaged into macros. [Rojewski, Fig. 4, ¶¶ 0044-0047.]
A number of paragraphs are used by the Action to allegedly teach or suggest the above unamended claim 1 language. [Action, page 4.] Each will be discussed in turn.
To teach or suggest the unamended claim 1 language that currently reads “…receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens from the graphical user interface-based application across a native recording interface to the external UI recorder, the internal macro actions recorded in native format for the graphical user interface-based application….” [emphasis added], the action cites to Rojewski, ¶ 0047, reproduced below:
[0047] In one implementation, a user could employ a "web-recording service" to record a macro for the user's interaction with one or more applications, that could later be accessed by the user from the web-recording service. In this implementation, data items representing the user's interaction with the browser-based applications are sent by the one or more software frameworks executing with the browser-based applications to the web-recording service for storage. The web-recording service can then package the data items into a macro for subsequent use by the user, which macro can be made available to the user, for example, by way of the web-recording service's website, or by e-mail.
When the web recording service of Rojewski collects “data items representing the user's interaction with the browser-based applications” [id.], it then “package(s) the data into a macro for subsequent use by the user….” [id.]. Assuming, for argument’s sake only, that the data items of Rojewski are equivalent to the “internal macro actions” of claim 1, and the web recording service of Rojewsk is equivalent to the “external UI recorder” of claim 1, the data items cannot be opaque to the web recording service, because if the data items were truly opaque to the web recording service, the web recording service would not understand how to package the opaque data items into a macro. Thus, Rojewski does not teach or suggest receiving “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens” as found in claim 1.
Further, Rojewski teaches away from the above-quoted language from claim 1. In Rojewski, a customer support person can “listen” to the user’s interaction with the browser, which includes “relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525).” [Rojewski, 0054] None of these actions could take place if the data items were opaque, as, shown by Rojewski ¶ 0054, quoted below:
[0054] The listening mode can be used for customer support of the browser-based application 110. Referring to FIGS. 3 and 5, a user of the browser-based application 110, executing in the first browser 120 who is experiencing difficulty contacts customer support for the browser-based application, for example, by email or telephone (Step 505). A customer support worker instructs the user to enter recording mode (Step 510). At the same time, the customer support worker enters listening mode, with respect to the browser-based application 110 executing at the first browser 120 (Step 515). The user then interacts with the browser-based application 110 (Step 520), while the customer support worker "listens" to the interactions, by retrieving data items from the data store, representing the user's actions, relaying the data items to the software framework 150 at the second browser 145, and processing the data items in the software framework 150 (Step 525). The customer support worker can therefore see how the user is interacting with the browser-based application 110, and how the application 110 is behaving in response to the user input. The customer support worker can use this information to isolate and solve the user's problem (Step 530).
The requirement in Rojewski that a “customer support worker” listen in on the interactions between the user and the other components, such as the browser, requires that the data elements passed to the browser be understandable at all steps, directly teaching away from any opaque actions. Thus, Rojewski not only does not teach or show, but explicitly teaches away from the claim 1 language, e.g., “receiving a plurality of internal macro actions passed as one or more opaque recorded step tokens….” For at least this reason, claim 1 is in condition for allowance.
From 3382-67840-01, 19-23-2008
Subscribe to:
Posts (Atom)