Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This communication is a First Office Action on the merits in reply to application number 18/917,178 filed on 10/16/2024.
Claims 1-14 are currently pending and have been examined.
Priority
Applicant’s claim for priority under 35 U.S.C. 119 and/or 35 U.S.C. 120 is acknowledged.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
From claim 1: “wherein the operating system comprises at least one transport medium and a ticket server communicating with the transport medium…”, “…wherein the transport medium transmits the tickets to the recipient(s)…”, and “generating registration data for the field device on the basis of the order by a manufacturer's server”.
From claim 2: “…wherein the registration module registers the field device as an existing field device on the ticket server.”.
From claim 4: “The method according to claim 3, wherein a software module or a hardware module is used as the registration module.”.
From claim 10: “wherein an optical detection unit is assigned to the registration module, and wherein the registration module reads the code via an optical detection unit.”.
From claim 13: “wherein an operating unit for operating existing field devices…”.
Claims 2 and 4 invoke §112(f) because they recite the nonce terms “transport medium”, “ticket server”, “manufacturer's server”, “registration module”, “software module”, “hardware module”, “optical detection unit”, and “operating unit” followed by functional language, without being modified by sufficient structure to perform the actions/steps of the recited limitations.
When looking to the specification, the following is disclosed:
With respect to the “transport medium”, par. [0050] discloses: “For this purpose, the ticket server TS transmits a ticket to the field device FG. In this case, the transport medium TM is an operating unit, in particular a laptop or a mobile device in the form of a smartphone or a tablet.”. This is to be the interpretation given to “transport medium”.
With respect to the optical detection unit”, par [0028] discloses: “The optical detection unit is, for example, a photodiode or a camera.”. This is to be the interpretation given to “optical detection unit”.
With respect to the “operating unit”, par. [0027] discloses: “Alternatively, an operating unit, for example a mobile device…”. This is to be the interpretation given to “operating unit”.
However, the specification and drawings are silent regarding the structure associated with the “ticket server”, “manufacturer's server”, “registration module”, “software module”, and “hardware module”.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 2, and 4 are rejected under 35 USC 112(b) because the bounds of the claimed invention are unclear. In particular, the claims recite:
From claim 1: “…a ticket server communicating with the transport medium…”, and “generating registration data for the field device on the basis of the order by a manufacturer's server”.
From claim 2: “…wherein the registration module registers the field device as an existing field device on the ticket server.”.
From claim 4: “The method according to claim 3, wherein a software module or a hardware module is used as the registration module.”.
It is unclear what the following are: “ticket server”, “manufacturer’s server”, “registration module”, “software module”, and “hardware module”. The drafting of the claim is not clear, such that the introduction of these claim elements is supported by what they actually are. A person having ordinary skill in the art at the time of the invention’s filing would not readily recognize the meaning of claim limitations “registration module”, “software module”, and “hardware module”. Therefore, the bounds of the claim are unclear. For the purpose of compact prosecution, Examiner is interpreting, under BRI, the “ticket server”, the “manufacturer’s server”, the “registration module”, “software module”, and “hardware module” as computer hardware and/or software (i.e., generic computing elements).
In this instance, Specification is silent regarding any specific structure by which the profile is embodied. Therefore, the claims are indefinite and rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claims 2-14 depend from claim 1 and fail to cure the issues noted above. Claims 3-12 depend from claim 2 and fail to cure the issues noted above. Claim 11 depend from claim 4 and fails to cure the issues noted above. Therefore, claims 2-14 are indefinite based on their inheritance of the deficiencies of their respective parent claim.
Claims 13 is rejected under 35 USC 112(b) because the claim limitations lack antecedent basis. In particular, the claim recites “wherein an operating unit for operating existing field devices located in the installations…”. However, there is a lack of antecedent basis for “the installations”. Parent claim 1 indicates that the field devices are located in the system (i.e., “…existing field devices located in the system…”). It’s not clear if the system is being equated with “the installations”, or if the system is located within some types of installations, which would as a corollary, place the field devices in “the installations”. The antecedent basis deficiency goes beyond a mere typographical error and instead causes ambiguity as to claim scope. For the purpose of compact prosecution, Examiner is interpreting “existing field devices located in the installations” as equivalent to “existing field devices located in the system”.
Accordingly, claims 1-14 are rejected under 35 USC 112(b).
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of 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, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of 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, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1, 2, and 4, as stated above, the claim limitations invoke 35 USC 112(f) or pre-AIA 35 USC 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. In particular, the specification does not adequately disclose how the “registration module”, “software module”, or “hardware module” perform the entire claimed function.
The first paragraph of 35 U.S.C. 112 requires that the “specification shall contain a written description of the invention.” This requirement is separate and distinct from the enablement requirement. See, e.g., Vas-Cath, Inc. v. Mahurkar, 935 F.2d 1555, 1560, 19 USPQ2d 1111, 1114 (Fed. Cir. 1991). See also Univ. of Rochester v. G.D. Searle & Co., 358 F.3d 916, 920-23, 69 USPQ2d 1886, 1890-93 (Fed. Cir. 2004) (discussing history and purpose of the written description requirement). To satisfy the written description requirement, a patent specification must describe the claimed invention in sufficient detail that one skilled in the art can reasonably conclude that the inventor had possession of the claimed invention. See, e.g., Moba, B.V. v. Diamond Automation, Inc., 325 F.3d 1306, 1319, 66 USPQ2d 1429, 1438 (Fed. Cir. 2003); Vas-Cath, Inc. v. Mahurkar, 935 F.2d at 1563, 19 USPQ2d at 1116. However, a showing of possession alone does not cure the lack of a written description. Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 969-70, 63 USPQ2d 1609, 1617 (Fed. Cir. 2002).
Claim 1 recites the limitations of: “…a ticket server communicating with the transport medium…”, and “generating registration data for the field device on the basis of the order by a manufacturer's server”.
Claim 1 fails to satisfy the written description requirement of §112(a) because there is no evidence of a complete specific application or embodiment to satisfy the requirement that the description is set forth “in such full, clear, concise, and exact terms” to show possession of the claimed invention. See Fields v. Conover, 443 F.2d 1386, 1392, 170 USPQ 276, 280 (CCPA 1971).
Claim 2 recites the limitation of: “…wherein the registration module registers the field device as an existing field device on the ticket server.”.
Claim 2 fails to satisfy the written description requirement of §112(a) because there is no evidence of a complete specific application or embodiment to satisfy the requirement that the description is set forth “in such full, clear, concise, and exact terms” to show possession of the claimed invention. See Fields v. Conover, 443 F.2d 1386, 1392, 170 USPQ 276, 280 (CCPA 1971).
Claim 4 recites the limitation of: “The method according to claim 3, wherein a software module or a hardware module is used as the registration module.”.
Claim 4 fails to satisfy the written description requirement of §112(a) because there is no evidence of a complete specific application or embodiment to satisfy the requirement that the description is set forth “in such full, clear, concise, and exact terms” to show possession of the claimed invention. See Fields v. Conover, 443 F.2d 1386, 1392, 170 USPQ 276, 280 (CCPA 1971).
Claims 2-14 depend from claim 1 and inherit the deficiency noted above. Claims 3-12 depend from claim 2 and inherit the deficiency noted above. Claim 11 depends from claim 4 and inherits the deficiency noted above.
Accordingly, claims 1-14 are rejected under 35 USC 112(a).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claims are directed to an abstract idea without significantly more. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception as further set forth in MPEP 2106.
Step 1: The claimed invention is analyzed to determine if it falls outside one of the four statutory categories of invention. See MPEP 2106.03
Claims 1-14 are directed to a method (i.e., Process). Therefore, claims 1-14 are directed to patent eligible categories of invention. Accordingly, claims 1-14 satisfy Step 1 of the eligibility inquiry.
Step 2A, Prong 1: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether they recite a judicial exception. See MPEP 2106.04
Independent claim 1 recites a computing system, a method, and a machine-readable medium for enterprise resource planning. As drafted, the limitations recited by the independent claims fall under the “Mental Processes” abstract idea group by setting forth activities that could be performed mentally by a human (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).
wherein the operating system comprises at least one transport medium and a ticket server communicating with the transport medium, wherein the ticket server and existing field devices located in the system are designed to create and/or process tickets, which tickets in each case contains at least one cryptographically secured item of information and in which in each case one or more recipients from the group of the ticket server and the existing field devices are defined, wherein the ticket server and the existing field devices are designed to transmit the created tickets to the transport medium, wherein the transport medium transmits the tickets to the recipient(s), and wherein the recipient(s) check(s) the authenticity and integrity of the tickets, comprising: (But for the recitation of additional elements (underlined), the steps for communicating, create and/or process tickets, transmit the created tickets, transmit the tickets, and check the authenticity and integrity of the tickets could be accomplished mentally, such as by human observation, evaluation, judgement, or with the help of pen and paper. Additionally, even if considered as additional elements, the steps to transmit the created tickets, transmit the tickets, and check the authenticity and integrity of the tickets amount to insignificant extra-solution activity as mere data gathering, mere data gathering, and insignificant application, respectively.);
placing an order for the field device by a customer; (But for the recitation of additional elements (underlined), the steps for placing an order could be accomplished mentally, such as by human observation, evaluation, judgement, or with the help of pen and paper.);
generating registration data for the field device on the basis of the order by a manufacturer's server, wherein the registration data comprise identification information of the field device and a first cryptographically relevant item of information; (But for the recitation of additional elements (underlined), the steps for generating registration data could be accomplished mentally, such as by human observation, evaluation, judgement, or with the help of pen and paper.);
and registering the field device as an existing field device on the ticket server, wherein in the course of registration the registration data are transmitted to the ticket server and a second cryptographically relevant item of information of the ticket server is stored in the field device. (But for the recitation of additional elements (underlined), the steps for registering the field device data, data are transmitted, and information is stored could be accomplished mentally, such as by human observation, evaluation, judgement, or with the help of pen and paper. Additionally, even if considered as additional elements, the steps for data are transmitted, and information is stored amount to insignificant extra-solution activity as mere data gathering and insignificant application.).
The additional elements beyond the abstract ideas for consideration under Step 2A, Prong 2, and Step 2B recited by independent claim 1 are: transport medium, ticket server, field device(s), and manufacturer’s server.
The dependent claims further narrow the abstract ideas and introduce the following additional elements for consideration:
From claim 2: registration module.
From claim 4: software module, hardware module.
From claim 5: digital image of the field device.
From claim 7: REST API.
From claim 9: graphical user interface.
From claim 10: optical detection unit.
From claim 11: data carrier.
From claim 13: operating unit.
Dependent claims 2-8, 12-19, and 21-23 further narrow the abstract idea and do not introduce any additional elements for consideration.
Step 2A, Prong 2: An evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the judicial exception into a practical application of the exception. See MPEP 2106.04(d).
Regarding the computing additional elements, namely transport medium, ticket server, field device(s), manufacturer’s server, registration module, software module, hardware module, digital image of the field device, graphical user interface, data carrier, and operating unit, these additional elements have been evaluated but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (generic computing environment). See MPEP 2106.05(f) and 2106.05(h). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment (generic computing environment).
With respect to the limitation for wherein the manufacturer's server accesses the registration module via a REST API of the registration module for the purpose of mutual data or information transfer, this limitation fails to integrate the abstract idea into a practical application because it provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception.
With respect to the optical detection unit, the optical detection unit has been considered under Step 2A Prong Two, however the optical detection unit is recited at a high level of generality and fails to provide a technical improvement or otherwise integrate the abstract idea into a practical application. This is supported by Applicant’s own specification, where in [0028], Applicant discloses: “The optical detection unit is, for example, a photodiode or a camera.”.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
Step 2B: The claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for "inventive concept." See MPEP 2106.05.
Regarding the computing additional elements, namely transport medium, ticket server, field device(s), manufacturer’s server, registration module, software module, hardware module, digital image of the field device, graphical user interface, data carrier, and operating unit, these additional element(s) has/have been evaluated, but fail to add significantly more to the claims because they amount to using generic computing elements (computer hardware) or instructions/software (engine) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (network computing environment, the internet, online) and does not amount to significantly more than the abstract idea itself. Applicant’s specification recites the computing additional elements at a high level of generality. Therefore, the additional elements merely describe generic computing elements or computer-executable instructions (software) merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
With respect to the limitations for wherein the manufacturer's server accesses the registration module via a REST API of the registration module for the purpose of mutual data or information transfer, this limitation fails to add significantly more to the abstract idea because it provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, the additional elements merely describe generic computing elements or computer-executable instructions (software) merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015). Additionally, the REST API additional element has been recognized as well-understood, routine, and conventional by prior art, such as in Brousseau et al. (Doc. ID: US 20150088981 A1 | Published on 03/26/2015), which in at least par. [0043] discloses: “Backend systems may use an API such as a REST API to tag specific posts with a work identifier that associate the posts with a specific work item or case. REST APIs are known to those skilled in the art and thus are not further described herein.”. Therefore, the REST API additional element is also considered well-understood, routine, and conventional, which does not amount to significantly more than the abstract idea itself.
With respect to the optical detection unit, the optical detection unit has been considered under Step 2A Prong Two, however the optical detection unit is recited at a high level of generality and fails to provide a technical improvement or otherwise add significantly more to the abstract idea. This is supported by Applicant’s own specification, where in [0028], Applicant discloses: “The optical detection unit is, for example, a photodiode or a camera.”.
Furthermore, even if the transmit the created tickets, transmit the tickets, check the authenticity and integrity of the tickets, data are transmitted, and information is stored are interpreted as additional elements, these activities at most amount to insignificant extra-solution activity (insignificant application), which does not add significantly more to the abstract idea, as noted in MPEP 2106.05(g). Additionally, the transmit the created tickets, transmit the tickets, and data are transmitted extra-solution activity have been recognized as well-understood, routine, and conventional, and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d) - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network).
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to amount to significantly more than the abstract idea itself.
The ordered combination of elements in the claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea itself.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Harrison (US 20210217001 A1, hereinafter “Harrison”, in view of Harding et al. (US 20200082065 A1, hereinafter “Harding”),
Regarding claim 1: Harrison teaches a method for integrating a field device into an operating system of an automation system ([Abstract] Disclosed embodiments are related to blockchain asset token management systems, and in particular, to Multiple Decentralized Tokenization with Personal Control (MDTPC).; [0017] Examples of systems, apparatus, computer-readable storage media, and methods according to the disclosed implementations are described in this section.) with the following limitations:
wherein the operating system comprises at least one transport medium and a ticket server communicating with the transport medium, ([0022] The system 16 may be a DB system and/or a cloud computing service comprising a network or other interconnection of computing systems (e.g., servers, storage devices, applications, etc., such as those discussed with regard to FIGS. 1A-1B infra) that provides access to a pool of physical and/or virtual resources. In some implementations, the system 16 is a multi-tenant DB system and/or a multi-tenant cloud computing platform. In some implementations, the system 16 provides a Communications as a Service (CaaS), Compute as a Service (CompaaS), Database as a Service (DaaS), Data Storage as a Service (DSaaS), Firewall as a Service (FaaS), Infrastructure as a Service (IaaS), Network as a Service (NaaS), Platform as a Service (PaaS), Security as a Service, Software as a Service (SaaS), and/or other like cloud services.; [0032] The user systems 12 can be implemented as any computing device(s) or other data processing apparatus or systems usable by users to access the system 16. For example, any of user systems 12 can be a desktop computer, a work station, a laptop computer, a tablet computer, a handheld computing device (e.g., Personal Data Assistants (PDAs), pagers, portable media player, etc.), a mobile cellular phone (e.g., a “smartphone”), a Head-Up Display (HUD) device/system, a an Extended Reality (XR) device (e.g., Virtual Reality (VR), Augmented Reality (AR), and/or Mixed Reality (MR) device), or any other WiFi-enabled device, WAP-enabled device, or other computing device capable of interfacing directly or indirectly to the Internet or other network (e.g., network 14). The terms “user system”, “computing device”, “computer system”, or the like may be used interchangeably herein with one another and with the term “computer.”);
wherein the ticket server and existing field devices located in the system are designed to create and/or process tickets, ([0049] In FIG. 1B, the network interface 20 and/or processor system 17 is/are implemented as a set of application servers 100.sub.1-100.sub.X (where X is a number). Each application server 100 (also referred to herein as an “app server”, an “API server”, an “HTTP application server,” a “worker node”, and/or the like) is configured to communicate with tenant DB 22 and the tenant data 23 therein, as well as system DB 24 and the system data 25 therein, to serve requests received from the user systems 12.)
wherein the transport medium transmits the tickets to the recipient(s), and wherein the recipient(s) check(s) the authenticity and integrity of the tickets, ([0012] In embodiments, an individual who is interested in buying an asset, or verifying the provenance of an asset, posts the request to investigate ownership of a particular asset rather than transfer of the asset. Asset verification for conventional blockchain transactions takes place by reading the data on the blockchain. By contrast, embodiments involve requesting the token service (blockchain) for ownership information of an asset, and the token service digitally signs the request. Posting the request in the wallet initiates the request securely but does not guarantee the owner's information will be exposed. The cryptographically signed request is then posted to the token service (blockchain) when the ownership of the asset is verified. The specific token service(s) (blockchain(s)) that the signed request is to be posted may be identified by the token itself. Alternatively, requesting wallet may query the registry service with various fields to identify which specific token service(s) (blockchain(s)) that the signed request is to be posted. The requesting wallet may post the request to each of the personally identified token service and the registry service identified token service. After the request is posted to each of the identified token services, each of the token services are queried for the subject of the request, and return a confirmation, identifier, and/or block data to the registry service if the subject of the request is found in their respective blockchains. In some embodiments, the token services notify the subject(s) of the request (e.g., the wallet of the owner of the asset), and the owner wallet can determine whether to provide the confirmation/identifier to the requesting wallet. If the owner does not want to share their details and/or does not expect a request for proof of ownership, the owner can indicate that they have the asset and deny access to any additional information. The response from the owner wallet would allow the requesting wallet to have concurrence between the physical asset and the known token services. Once the Token Services have confirmation from the owning wallet on the level of detail to provide, they each send their data back to the requesting wallet, either directly or through the registry service.);
comprising: placing an order for the field device by a customer; ([0012] In embodiments, an individual who is interested in buying an asset, or verifying the provenance of an asset, posts the request to investigate ownership of a particular asset rather than transfer of the asset. Asset verification for conventional blockchain transactions takes place by reading the data on the blockchain.);
generating registration data for the field device on the basis of the order by a manufacturer's server, wherein the registration data comprise identification information of the field device and a first cryptographically relevant item of information; ([0085] , the owner wallet 208 is depicted as an individual client application, however, in other embodiments, the owner wallet 206 could be operated by a regulatory agency system (e.g., a Department of Motor Vehicles (DMV) when the asset is a vehicle, a state/provincial licensing authority, or the like), a device or product manufacturer and/or service provider (e.g., mobile network operator when the asset is a smartphone or tablet computer device), a collectors registry, an insurance company, and/or the like.; [Fig. 5] [0104] Referring now to FIG. 5, which shows a lookup process 500a and a registration process 500b that may be performed by registry 210.; [0098] The token service 206 blockchain details (e.g., directory) includes, for example, access (resource) location such as a URI, URL, IP address, domain name, and/or other like identifiers/addresses; a service provider or platform identifier such as a name, pointer, registration number, or other unique identifier; and security controls which may include, for example, access tokens, encryption requirements, digital certificates, public key infrastructure (PKI), and/or the like. The asset class(es) (e.g., a catalog of each token service 206) comprises the asset classes and/or asset categories of each type and/or kind of asset tokens managed by the token service with appropriate sub-classifications, if necessary. The term “class” in “asset class” refers to a collection of objects that can be unambiguously defined by a property that all its members share. The term “asset kind” or “kind of asset” refers to a final or intended usage of a particular asset, for example, a smartphone, smartwatch, painting, baseball card, vehicle, sensor, pharmaceutical/medicine, and/or the like. The term “asset type” or “type of asset” refers to a specific series of asset of a given asset kind and/or with a given configuration (e.g., a specific smartphone such as Apple® iPhone® 7, Samsung® S6, etc.).);
and registering the field device as an existing field device on the ticket server, wherein in the course of registration the registration data are transmitted to the ticket server and a second cryptographically relevant item of information of the ticket server is stored in the field device. ([0032] The user systems 12 can be implemented as any computing device(s) or other data processing apparatus or systems usable by users to access the system 16. For example, any of user systems 12 can be a desktop computer, a work station, a laptop computer, a tablet computer, a handheld computing device (e.g., Personal Data Assistants (PDAs), pagers, portable media player, etc.), a mobile cellular phone (e.g., a “smartphone”), a Head-Up Display (HUD) device/system, a an Extended Reality (XR) device (e.g., Virtual Reality (VR), Augmented Reality (AR), and/or Mixed Reality (MR) device), or any other WiFi-enabled device, WAP-enabled device, or other computing device capable of interfacing directly or indirectly to the Internet or other network (e.g., network 14). The terms “user system”, “computing device”, “computer system”, or the like may be used interchangeably herein with one another and with the term “computer.”; [0035] The application(s) 12y (also referred to as “app 12y” or “apps 12y”) is/are a software application designed to run on the user system 12 and is used to access data stored by the system 16. The apps 12y may be platform-specific, such as when the user system 12 is implemented in a mobile device, such as a smartphone, tablet computer, and the like. The apps 12y may be a native application, a web application, or a hybrid application (or variants thereof).; [0037] In another example, the app 12y may be a blockchain app or service that enables a user of the user system 12 to interact with a blockchain or other decentralized ledger or database. The blockchain app 12y may store public and/or private keys, hash generators, encryption/decryption algorithms, and/or other like elements that can be used to generate blocks to be added to one or more blockchains.).
Harrison doesn’t explicitly teach:
which tickets in each case contains at least one cryptographically secured item of information
and in which in each case one or more recipients from the group of the ticket server and the existing field devices are defined,
wherein the ticket server and the existing field devices are designed to transmit the created tickets to the transport medium,
Harding teaches:
which tickets in each case contains at least one cryptographically secured item of information ([0002] Credentials used to authenticate a client can include a username and password, biometric information, or a cryptographic signature that is included with the request.; [0052] A swim diagram 500 shows a process that begins at block 502 where the client generates and signs a request with a cryptographic key accessible to the client.);
and in which in each case one or more recipients from the group of the ticket server and the existing field devices are defined, ([0002] Credentials used to authenticate a client can include a username and password, biometric information, or a cryptographic signature that is included with the request.; [0052] FIG. 5 shows an illustrative example of a process that, when performed by a service, a client of the service, and a context management service, authorizes a request based at least in part on a context, in accordance with an embodiment.);
wherein the ticket server and the existing field devices are designed to transmit the created tickets to the transport medium, ([0052] FIG. 5 shows an illustrative example of a process that, when performed by a service, a client of the service, and a context management service, authorizes a request based at least in part on a context, in accordance with an embodiment. A swim diagram 500 shows a process that begins at block 502 where the client generates and signs a request with a cryptographic key accessible to the client. The client transmits the request to the service, and at block 504, the service authenticates the request by validating a digital signature of the client. In some examples, the request can be authenticated using a username and a password. The passwords can be stored using a list of one-way hashes that represent the values of the permitted usernames and passwords. If the service determines that the username and password are present in the list of authorized username-password combinations, the service authenticates the identity of the client as being associated with an authorized user that is associated with the provided username.; [0071] Further, operations described herein as being performed by a single device may, unless otherwise clear from context, be performed collectively by multiple devices, which may form a distributed and/or virtual system.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine Harrison with Harding’s feature(s) listed above. One would’ve been motivated to do so in order to determine an allowable scope of operations that may be necessary to fulfill the ticket (Harding; [0068]). By incorporating the teachings of Harding, one would’ve been able to create and process tickets using a server and a field device for the registration of other field devices into the system.
Regarding claim 2: Harrison teaches:
wherein the ticket server is assigned a registration module, ([0011] Additionally, a Registry Service is used to ensure visibility of tokens across multiple blockchains, which increases the likelihood of identifying the rightful owner of an asset.);
wherein the registration data are transferred from the manufacturer's server to the registration module, [Fig. 6] Operation 645; [0108] At operation 645 the token service 206 generates a validation response including an amount of data about the token 202, owning wallet 208, and/or the user of the owning wallet 208 based on the indicated privacy level. In some embodiments, a single validation response may be generated and sent, which includes information about all discovered asset tokens 202 and/or owners.);
and wherein the registration module registers the field device as an existing field device on the ticket server. (Fig. 5] Operation 550; [0105] At operation 550, the registry 210 generates and sends an acknowledgement message to the individual token service 206 indicating registration with the registry service.).
Harrison doesn’t teach:
wherein the second cryptographically relevant item of information is transferred from the registration module to the manufacturer's server,
Harding teaches:
wherein the second cryptographically relevant item of information is transferred from the registration module to the manufacturer's server, ([0018] In various examples, a requester sends a request to a service. The service authenticates the requester by confirming an identity that is associated with the requester using a username and password, digital signature, biometric response, physical key, or other method. Using the confirmed identity, the service identifies a set of access rights and privileges that have been granted to the requester. If the access rights privileges are sufficient to perform the request, the service determines that the request is authorized. Before the request is performed, information related to the context of the request is assembled and validated against the request and the identity of the requester. If the context of the request is not in accordance with the request itself, t