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, the request is denied despite being authorized by an authentic requester.; [0053] In one example, the request is a request to retrieve a portion of the log file. The service examines the log file to determine the creation and modification date of the requested log file information, and includes this context information when requesting context validation of the request.]; [0054] At block 512, the service provides the information regarding the request, and the request context to the context management service.; [0082] In various embodiments, data objects such as digital signatures may be cryptographically verifiable. In one example, cryptographically verifiable data objects are created to be cryptographically verifiable by the system to which the data object is to be provided or another system that operates in conjunction with the system to which the data object is to be provided. For example, the data object may be encrypted so as to be decryptable by the system that will cryptographically verify the data object, where the ability to decrypt the data object serves as cryptographic verification of the data object. As another example, the data object may be digitally signed (thereby producing a digital signature of the data object) such that the digital signature is verifiable by the system that will cryptographically verify the data object. In other examples, both encryption and digital signatures are used for cryptographic verifiability and/or security. The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair. Using the public key to encrypt the data object may include generating a symmetric key, using the symmetric key to encrypt the data object, and encrypting the symmetric key using the public key, where the encrypted symmetric key is provided to a system with the encrypted data object to enable the system to use the corresponding private key to decrypt the symmetric key and use the decrypted symmetric key to decrypt the data object. Further, in some embodiments, the data object is digitally signed using a private key of a public/private key pair corresponding to the computer system that encrypts and/or digitally signs the data object (e.g., a user device).).
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 additional feature(s) listed above. One would’ve been motivated to do so, so that an application may be provisioned with the private key and the data object may include a certificate for the private key for use by a system for verification of the digital signature of the data object (Harding; [0082]). By incorporating the teachings of Harding, one would’ve been able to transmit encrypted information to clients, including a manufacturer’s server.).
Regarding claim 3: Harrison doesn’t teach:
wherein the registration data are transferred to the registration module in the form of a first exchange ticket, which is created by the manufacturer's server, and wherein the second cryptographically relevant item of information is transferred to the manufacturer's server in the form of a second exchange ticket, which is created by the registration module or the ticket server.
Harding teaches:
wherein the registration data are transferred to the registration module in the form of a first exchange ticket, which is created by the manufacturer's server, and wherein the second cryptographically relevant item of information is transferred to the manufacturer's server in the form of a second exchange ticket, which is created by the registration module or the ticket 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, the request is denied despite being authorized by an authentic requester.; [0053] In one example, the request is a request to retrieve a portion of the log file. The service examines the log file to determine the creation and modification date of the requested log file information, and includes this context information when requesting context validation of the request.; [0054] At block 512, the service provides the information regarding the request, and the request context to the context management service.; [0082] In various embodiments, data objects such as digital signatures may be cryptographically verifiable. In one example, cryptographically verifiable data objects are created to be cryptographically verifiable by the system to which the data object is to be provided or another system that operates in conjunction with the system to which the data object is to be provided. For example, the data object may be encrypted so as to be decryptable by the system that will cryptographically verify the data object, where the ability to decrypt the data object serves as cryptographic verification of the data object. As another example, the data object may be digitally signed (thereby producing a digital signature of the data object) such that the digital signature is verifiable by the system that will cryptographically verify the data object. In other examples, both encryption and digital signatures are used for cryptographic verifiability and/or security. The key used to encrypt and/or digitally sign the data object may vary in accordance with various embodiments and the same key is not necessarily used for both encryption and digital signing, where applicable. In some embodiments, a key used to encrypt the data object is a public key of a public/private key pair where the private key of the key pair is maintained securely by the system to which the data object is to be provided, thereby enabling the system to decrypt the data object using the private key of the key pair. Using the public key to encrypt the data object may include generating a symmetric key, using the symmetric key to encrypt the data object, and encrypting the symmetric key using the public key, where the encrypted symmetric key is provided to a system with the encrypted data object to enable the system to use the corresponding private key to decrypt the symmetric key and use the decrypted symmetric key to decrypt the data object. Further, in some embodiments, the data object is digitally signed using a private key of a public/private key pair corresponding to the computer system that encrypts and/or digitally signs the data object (e.g., a user device).).
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 additional feature(s) listed above. One would’ve been motivated to do so, so that an application may be provisioned with the private key and the data object may include a certificate for the private key for use by a system for verification of the digital signature of the data object (Harding; [0082]). By incorporating the teachings of Harding, one would’ve been able to transmit encrypted information to clients, including a manufacturer’s server.).
Regarding claim 4: Harrison teaches:
wherein a software module or a hardware module is used as the registration module. ([0074] In another example, the cloud system 150 may provide token registry services (see e.g., asset token registry service 210 of FIG. 2) according to the embodiments discussed herein, such as those disused with respect to FIGS. 2-7.; [0039] A TEE is a hardware-based technology that executes only validated tasks, produces attested results, provides protection from malicious host software, and ensures confidentiality of shared encrypted data.).
Regarding claim 5: Harrison teaches:
wherein a digital image of the field device is generated in the course of ordering, ([0008] In the context of asset management, the tokenization process converts rights to an asset into a digital token. The “rights” to an asset may be in the form of a physical ownership, title, deed, share or stock certificate, authenticity certificate, or the like. Asset tokens represent assets such as total or partial participation in ownership of real physical objects, companies, earnings streams, an entitlement to dividends or interest payments, virtualized objects in games or simulated environments, and even the rights to a specific action. In terms of their economic function, asset tokens are sometimes considered analogous to equities, bonds, or derivatives. Additionally, asset tokens are sometime regarded or considered to be a form of securities, which means that the trade of asset tokens may have to conform to securities law requirements. Nevertheless, asset tokens can be stored and managed in a blockchain.; [0015] In some embodiments, the registry service stores information about each token service (e.g., resource locations (URLs), token service owner/operator, security controls, etc.) and information about the asset classes stored by each token service (e.g., by asset classes, UPC, EPC, etc.).; [0077] The asset token 202 may represent any type of asset, such as total or partial ownership of a physical object (or a portion thereof), a company, an earnings streams, an entitlement to dividends or interest payments, a virtualized object or virtual property (e.g., in video games or simulated environments), rights to specific performance (e.g., the performance of a contractual duty), and/or the like. Typically, asset tokens 202 are used to prove ownership of an asset in a similar manner as a paper documentation of ownership (e.g., title, deed, certificate of authenticity, registration certificate, Document of Conformity (DoC), Conformité Européenne (CE) marking, etc.), authentication certificate, or other like documentation. The asset or rights to the asset is/are converted into the asset token 202 via a tokenization process.);
wherein the registration data are transferred from the manufacturer's server to the digital image of the field device, ([0076] FIGS. 2-4 shows an example Multiple Decentralized Tokenization with Personal Control (MDTPC) architecture 200 according to various embodiments. As shown by FIGS. 2-4, the MDTPC architecture 200 includes an asset token 202, a digital wallet 204 (also referred to as a “requesting wallet 204”), an asset token registry service 210 (also referred to as “registry 210”), tokenization services 206-1 to 206-Z where Z is a number (collectively referred to as “token services 206” or token service 206″), and digital wallet 208 (also referred to as a “owner wallet 208”).; [0085] In the example of FIGS. 2-4, the owner (represented by wallet 208) has registered the asset token with two of the token services 206 (e.g., token services 206-2 and 206-Z) and the owner wallet 208 receives a notification from the two token services 206 (e.g., nodes E in FIG. 2). In the example depicted by FIG. 2, 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. The user of the owning wallet 208 can evaluate the fee structures for providing the tokenization services, and determine if any information should be shared. In some embodiments, the notification to the owner wallet 208 could include a description of the asset, a name or other identifier of the requesting wallet 204, a name or identifier of the registry service 210, and/or any other type of information. Usually, the notification may include the content of the validation request, and in some embodiments (such as when the registry service 210 is queried by the requesting wallet 204), each notification may include a list of all token services 206 to which the validation request was posted and/or each token service 206 where a search has been performed (e.g., the notification from token service 206-2 may list each of token services 206-1, 206-2, and 206-Z, and the notification from token service 206-Z may list each of token services 206-1, 206-2, and 206-Z).; [Fig. 5] operation 535);
wherein the second cryptographically relevant item of information is transferred from the registration module to the digital image of the field device, ([Fig. 5] Operation 540, Operation 545; [0105] At operation 540, the registry 210 determines a reliability score for the individual asset token service 206 based on data items included in the registration request.; At operation 545, the registry 210 stores the determined reliability score and the data items in association with an identifier of the individual asset token service 206 in the database of registered token services 206.);
wherein in the course of registration the registration data are transferred from the digital image of the field device to the registration module. ([0105] The registration process 500b begins at operation 535 where the registry 210 receives a registration request from an individual token service 206 for registering one or more asset classes, types, etc., with the registry 210.).
Regarding claim 6: Harrison teaches:
wherein the manufacturer's server and the registration module are in communication connection, ([0030] The network 14 may comprise one or more network elements, each of which may include one or more processors, communications systems (e.g., including network interface controllers, one or more transmitters/receivers connected to one or more antennas, etc.), and computer readable media. Examples of such network elements may include wireless APs (WAPs), a home/business server (with or without radio frequency (RF) communications circuitry), routers, switches, hubs, radio beacons, (macro or small-cell) base stations, servers (e.g., stand-alone, rack-mounted, blade, etc.), and/or any other like devices/systems.);
wherein the registration data are transferred from the manufacturer's server via the communication connection to the registration module, ([0067] In some implementations, each application server 100 is configured to handle requests for any user associated with any organization that is a tenant of the system 16. In this regard, each application server 100 may be configured to perform various DB functions (e.g., indexing, querying, etc.) as well as formatting obtained data (e.g., ELT data, ETL data, etc.) for various user interfaces to be rendered by the user systems 12. Because it can be desirable to be able to add and remove application servers 100 from the server pool at any time and for various reasons, in some implementations there is no server affinity for a user or organization to a specific application server 100. In some such implementations, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers 100 and the user systems 12 to distribute requests to the application servers 100. In one implementation, the load balancer uses a least-connections algorithm to route user requests to the app servers 100 (see e.g., load balancer 228 of FIGS. 2A-2B discussed infra). Other examples of load balancing algorithms, such as round robin and observed-response-time, also can be used. For example, in some instances, three consecutive requests from the same user could hit three different application servers 100, and three requests from different users could hit the same application server 100. In this manner, by way of example, system 16 can be a multi-tenant system in which system 16 handles storage of, and access to, different objects, data and applications across disparate users and organizations.; [0105] The registration process 500b begins at operation 535 where the registry 210 receives a registration request from an individual token service 206 for registering one or more asset classes, types, etc., with the registry 210. At operation 540, the registry 210 determines a reliability score for the individual asset token service 206 based on data items included in the registration request.);
and wherein the second cryptographically relevant item of information is transferred from the registration module to the manufacturer's server via the communication connection. ([0070] In some implementations, the user systems 12 (which also can be client systems) communicate with the application servers 100 to request and update system-level and tenant-level data from the system 16. Such requests and updates can involve sending one or more queries to tenant DB 22 or system DB 24. The system 16 (e.g., an application server 100 in the system 16) can automatically generate one or more native queries (e.g., SQL statements or SQL queries or the like) designed to access the desired information from a suitable DB. To do so, the system 16 (e.g., an application server 100 in the system 16) may include one or more query engines 103, which is/are a software engine, SDK, object(s), program code and/or software modules, or other like logical unit that takes a description of a search request (e.g., a user query), processes/evaluates the search request, executes the search request, and returns the results back to the calling party.; [0012] 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.; [0013] When the owning wallet is notified of the request, the owning wallet will receive the list of token services.);
Regarding claim 7: Harrison teaches:
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. ([0063] The API(s) 32 may be implemented as a remote API or a web API, such as a Representational State Transfer (REST or RESTful) API; [0064] The async public API may be implemented as a REST or RESTful API, SOAP API, Apex API, and/or some other like API, such as those discussed herein.; [0065] The private APIs may be implemented as a REST or RESTful API, SOAP API, Apex API, a proprietary API, and/or some other like API.);
Regarding claim 8: Harrison teaches:
wherein the manufacturer's server and the registration module are not in communication connection. ([0083] At node C, the validation request is posted to the blockchain(s) operated by a token service 206 (e.g., token service 206-2). In some cases, the owner of the asset token 202 may indicate which token service 206 has the asset token 202 registered (e.g., token service 206-2), for example, by communicating offline.)
Regarding claim 9: Harrison teaches:
wherein the registration data are entered into the registration module by a user via a graphical user interface. ([0041] The input system 12C can include any suitable combination of input devices, such as touchscreen interfaces, touchpad interfaces, keyboards, mice, trackballs, scanners, cameras, a pen or stylus or the like, or interfaces to networks. The input devices of input system 12C may be used for interacting with a GUI provided by the browser/application container on a display of output system 12D (e.g., a monitor screen, liquid crystal display (LCD), light-emitting diode (LED) display, among other possibilities) of the user system 12 in conjunction with pages, forms, applications and other information provided by the system 16 or other systems or servers. For example, the user interface device can be used to access data and applications hosted by system 16, and to perform searches on stored data, and otherwise allow a user to interact with various GUI pages that may be presented to a user.; [0105] The registration process 500b begins at operation 535 where the registry 210 receives a registration request from an individual token service 206 for registering one or more asset classes, types, etc., with the registry 210. At operation 540, the registry 210 determines a reliability score for the individual asset token service 206 based on data items included in the registration request. In various embodiments, the data items included in the registration request indicate and/or include data of one or more of asset token classes, subclasses, kinds, types, or categories managed by the individual token service 206, validation procedures performed by individual token service 206 to validate asset ownership, one or more regulatory regimes, standards organizations, geographic or jurisdictional regions/areas, etc., supported by the individual token service 206, human languages supported by the individual token service 206, programming languages supported by the individual token service 206, and/or other token service related information. In these embodiments, the various data items may be the “value” of the token service 206 as discussed previously. At operation 545, the registry 210 stores the determined reliability score and the data items in association with an identifier of the individual asset token service 206 in the database of registered token services 206. At operation 550, the registry 210 generates and sends an acknowledgement message to the individual token service 206 indicating registration with the registry service. If the registration fails or is not permitted for some reason, at operation 550 the registry 210 may generate and send a negative acknowledgement message to the individual token service 206 to indicate error(s) and/or failure(s) in the registration process, and/or reasons why the registration was not possible. At operation 555 process 500b ends or repeats as necessary.).
Regarding claim 10: Harrison teaches:
wherein the registration data or the first exchange ticket containing the registration data are present as an optically detectable code, in particular as a barcode or as a QR code, ([0080] Referring now to FIG. 2, an asset token 202 is first identified by a unique identifier associated with the asset token 202. As examples, the asset identifier may be a vehicle identification number (VIN), a bar code, a quick response (QR) code, an Electronic Product Code (EPC), a product serial number (which may be extracted from a bar code, QR code, and/or EPC), an RFID tag (which could include an EPC), a Bluetooth/BLE® or iBeacon tag, legal instrument (e.g., real estate deed or the like) record index, Universal Property ID, or any other identifier. Where virtual assets are used, the asset identifier may be a credit score, a social security number (SSN), an International Securities Identification Number (ISIN), a Valor or Valorem Code, Wertpapierkennnummer (WKN), Asia Pacific Investment Register (APIR) code, Legal Entity Identifier (LEI), National Securities Identifying Number (NSIN), Market Identifier Code (MIC), Reuters Instrument Code (RIC), Stock Exchange Daily Official List (SEDOL) code, Classification of Financial Instruments (CFI) code, Financial Instrument Short Name (FISN), ticker symbol, Employer Identification Numbers (EIN), Tax Identification Number (TIN), cryptocurrency wallet ID, and/or combinations thereof.);
wherein an optical detection unit is assigned to the registration module, and wherein the registration module reads the code via an optical detection unit. ([0041] The input system 12C can include any suitable combination of input devices, such as touchscreen interfaces, touchpad interfaces, keyboards, mice, trackballs, scanners, cameras, a pen or stylus or the like, or interfaces to networks. The input devices of input system 12C may be used for interacting with a GUI provided by the browser/application container on a display of output system 12D (e.g., a monitor screen, liquid crystal display (LCD), light-emitting diode (LED) display, among other possibilities) of the user system 12 in conjunction with pages, forms, applications and other information provided by the system 16 or other systems or servers. For example, the user interface device can be used to access data and applications hosted by system 16, and to perform searches on stored data, and otherwise allow a user to interact with various GUI pages that may be presented to a user. The output system 12D can include any suitable combination of output devices, such as one or more display devices, printers, or interfaces to networks. The output system 12D is used to display visual representations and/or GUIs 12v based on various user interactions. As discussed above, implementations are suitable for use with the Internet, although other networks can be used instead of or in addition to the Internet, such as an intranet, an extranet, a virtual private network (VPN), a non-TCP/IP based network, any LAN or WAN or the like.).
Regarding claim 11: Harrison teaches:
wherein the first exchange ticket is transferred from the manufacturer's server to a data carrier ([0019] Example embodiments of the present disclosure may be described in terms of a multitenant and/or cloud computing architecture or platform. Cloud computing refers to a paradigm for enabling network access to a scalable and elastic pool of shareable computing resources with self-service provisioning and administration on-demand and without active management by users. Computing resources (or simply “resources”) are any physical or virtual component, or usage of such components, of limited availability within a computer system or network. Examples of resources include usage/access to, for a period of time, servers, processor(s), storage equipment, memory devices, memory areas, networks, electrical power, input/output (peripheral) devices, mechanical devices, network connections (e.g., channels/links, ports, network sockets, etc.), operating systems, virtual machines (VMs), software/applications, computer files, and/or the like. Cloud computing provides cloud computing services (or cloud services), which are one or more capabilities offered via cloud computing that are invoked using a defined interface (e.g., an API or the like). Multi-tenancy is a feature of cloud computing where physical or virtual resources are allocated in such a way that multiple tenants and their computations and data are isolated from and inaccessible to one another. As used herein, the term “tenant” refers to a group of users (e.g., cloud service users) who share common access with specific privileges to a software instance and/or a set of computing resources. Tenants may be individuals, organizations, or enterprises that are customers or users of a cloud computing service or platform. However, a given cloud service customer organization could have many different tenancies with a single cloud service provider representing different groups within the organization. A multi-tenant platform or architecture, such as those discussed herein, may provide a tenant with a dedicated share of a software instance typically including one or more of tenant specific data, user management, tenant-specific functionality, configuration, customizations, non-functional properties, associated applications, etc. Multi-tenancy contrasts with multi-instance architectures, where separate software instances operate on behalf of different tenants.; [0105] The registration process 500b begins at operation 535 where the registry 210 receives a registration request from an individual token service 206 for registering one or more asset classes, types, etc., with the registry 210… At operation 545, the registry 210 stores the determined reliability score and the data items in association with an identifier of the individual asset token service 206 in the database of registered token services 206.);
and wherein the first exchange ticket is transferred from the data carrier to the registration module. ([0021] FIG. 1A shows an example of an environment 10 in which on-demand services (e.g., cloud computing services and/or database services) can be used in accordance with various embodiments. The environment 10 includes user systems 12, a network 14, system 16 (also referred to herein as a “cloud-based system,” “database system,” “cloud computing service,” or the like), and one or more customer platforms (CPs) 50. The cloud system 16 includes a processor system 17, an application platform 18, a network interface 20, tenant database (DB) 22 for storing tenant data 23 (see e.g., FIG. 1B), system DB 24 for storing system data 25 (see FIG. 1B), program code 26 for implementing various functions of the system 16, and process space 28 for executing DB system processes and tenant-specific processes, such as running applications as part of an application hosting service. In some other implementations, environment 10 may not have all of these components or systems, or may have other components or systems instead of, or in addition to, those listed above.; [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.).
Regarding claim 12: Harrison teaches:
wherein the second cryptographically relevant item of information is communicated to the manufacturer's server in the course of the placing of the order by the user. ([0109] Referring now to FIG. 7, which shows a registration process 700 performed by a token service 206. In embodiments, process 700 may be run before, after, simultaneously or concurrently with process 600 of FIG. 6. Process 700 begins at operation 705 where the token service 206 determines whether to register one or more asset classes, asset types, etc., with the registry 210. In some embodiments, the decision to register with the registry 210 may be based on content included in one or more received validation requests, such as the asset classes, types, etc., of the asset token 202 indicated by the request, a list of all token services 206 to which the validation request was posted, each token service 206 where an ownership search has been or is scheduled to be performed, and/or other token service-related information. Other parameters, conditions, policies, etc., may be used to determine whether to register with a particular registry 210. Additionally or alternatively, any suitable ML/AI approach could be used to decide when to register with one or more registries 210 and what asset classes, types, etc., to register with a particular registry 210. For example, clustering, deep learning, decision trees, support vector machines, genetic algorithms, federated learning, and/or other ML/AI techniques may be used to determine specific asset classes, types, etc., and/or specific registries 210 to register the token service 206. In another example, linear matrix factorization model, non-negative matrix factorization, or the like may be used to recommend registries 210 to register with based on the unique characteristics, patterns, features, etc., of the validation requests supplied by various wallets 204.).
Regarding claim 13: Harrison teaches:
wherein an operating unit for operating existing field devices located in the installations is provided as a transport medium, ([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 tickets contain data that authorize the operating unit to carry out a defined work order on a defined existing field device. ([0105] The registration process 500b begins at operation 535 where the registry 210 receives a registration request from an individual token service 206 for registering one or more asset classes, types, etc., with the registry 210. At operation 540, the registry 210 determines a reliability score for the individual asset token service 206 based on data items included in the registration request. In various embodiments, the data items included in the registration request indicate and/or include data of one or more of asset token classes, subclasses, kinds, types, or categories managed by the individual token service 206, validation procedures performed by individual token service 206 to validate asset ownership, one or more regulatory regimes, standards organizations, geographic or jurisdictional regions/areas, etc., supported by the individual token service 206, human languages supported by the individual token service 206, programming languages supported by the individual token service 206, and/or other token service related information. In these embodiments, the various data items may be the “value” of the token service 206 as discussed previously. At operation 545, the registry 210 stores the determined reliability score and the data items in association with an identifier of the individual asset token service 206 in the database of registered token services 206. At operation 550, the registry 210 generates and sends an acknowledgement message to the individual token service 206 indicating registration with the registry service.).
Regarding claim 14: Harrison teaches:
wherein the operating unit authenticates itself to the existing field devices defined in the corresponding tickets. ([0036] the various application(s) discussed herein may also enable the user system 12 to provide authentication credentials (e.g., user identifier (user id), password, personal identification number (PIN), digital certificates, etc.) to the system 16 so that the system 16 may authenticate the identity of a user of the user system 12.).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Gourisetti et al. (WO 2021138591 A1 | Published on: 07/08/2021), which discloses technology related to blockchain cybersecurity solutions and a blockchain applicability framework is disclosed. In one example of the disclosed technology, a system is configured to store, in a database, a plurality of cryptographically-signed records of data transmitted between an asset and a utility historian, and store, in a distributed ledger, a respective hash value corresponding to each record of the database.
V. T. Truong and L. Bao Le, "A Blockchain-Based Framework for Secure Digital Asset Management," ICC 2023 - IEEE International Conference on Communications, Rome, Italy, 2023, pp. 1911-1916.
S. Varakliotis, P. T. Kirstein and G. Deiana, "The use of Handle to aid IoT security," 2015 IEEE International Conference on Communications (ICC), London, UK, 2015, pp. 542-548.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GABRIEL J TORRES CHANZA whose telephone number is (571)272-3701. The examiner can normally be reached Monday thru Friday 8am - 5pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached on (571)270-5389. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/G.J.T./Examiner, Art Unit 3625
/TIMOTHY PADOT/Primary Examiner, Art Unit 3625
Prosecution Insights