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 Final Office Action in response to Applicant’s amendment for application number 18/917,178 received on 04/13/2026.
In accordance with Applicant’s amendment, claims 1-14 are amended, 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.
Response to Amendment
The amendment filed on 04/13/2026 has been entered.
Applicant’s amendment necessitated the new ground(s) of rejection set forth in this Office Action.
With respect to the 112 rejections previously applied, upon review of Applicant’s amendments and arguments, the rejections are withdrawn.
Response to Arguments
Response to §112(f) arguments – With respect to the claim interpretation previously applied to the claims, upon further review of Applicant’s claims and arguments, the claim interpretation for “ticket server” and “manufacturer’s server” are withdrawn.
Response to §101 arguments – Applicant’s arguments with respect to the §101 rejections previously applied to the claims have been considered and are unpersuasive.
Applicant argues (Remarks at pg. 9): “The Examiner rejects Applicant's claims as being directed to a "mental processes." The mental process abstract idea group includes activities that could be performed mentally by a human. Applicant respectfully disagrees but asserts that even if Applicant's claims were directed to a mental process, they amount to significantly more than the abstract idea.”. In response, Examiner respectfully disagrees and notes that, as currently recited, Applicant’s claims fail to add significantly more to the abstract idea for the following reasons:
The computing additional elements 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.
The claims add insignificant extra-solution activity (e.g., mere data gathering) to the judicial exception, which is nothing significantly more.
The claims recite additional elements at a high level of generality, which fails to provide a technical improvement or otherwise add significantly more to the abstract idea.
Applicant argues (Remarks at pg. 9): “This method provides for a novel approach to introducing new field devices at a customer installation. The approach solves problems of delays between receiving a new field device and when the new field device is ready for use. Applicant has improved this commissioning strategy, while maintaining data security. This is a practical application in the field of process automation, which does not preempt all strategies for introducing new field devices at a customer installation.”. In response, Examiner respectfully disagrees and reminds Applicant that the inquiry under 35 U.S.C. 101 is related to patent subject matter eligibility of the claimed invention, not novelty of the claimed invention. See MPEP 2106 Patent Subject Matter Eligibility.
Response to §103 arguments – Applicant’s arguments with respect to the §103 rejections previously applied to the claims are moot given the new grounds of rejections set forth in the updated 103 rejections section below, as necessitated by Applicant’s amendments.
Claim Interpretation
With respect to the preamble of independent claim 1, Examiner notes that the preamble is not given patentable weight because it is not ‘necessary to give life, meaning, and vitality’ to the claim. See MPEP 2111.02. See also Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165-66 (Fed. Cir. 1999). See also Jansen v. Rexall Sundown, Inc., 342 F.3d 1329, 1333, 68 USPQ2d 1154, 1158 (Fed. Cir. 2003) (In considering the effect of the preamble in a claim directed to a method of treating or preventing pernicious anemia in humans by administering a certain vitamin preparation to "a human in need thereof," the court held that the claims’ recitation of a patient or a human "in need" gives life and meaning to the preamble’s statement of purpose.).
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 transport medium transmits the tickets to the recipient(s)…”
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…”.
The claims invoke §112(f) because they recite the nonce terms “transport medium”, “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”.
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). Independent claim 1 recites a method with the following abstract limitations: “placing an order for the field device by a customer; generating registration data for the field device on the basis of the order, wherein the registration data comprise identification information of the field device and a first cryptographically relevant item of information; registering the field device as an existing field device; and installing the field device at an installation of the customer after the registering step.”. But for the recitation of additional elements recited by the claim, the steps in the claim could be accomplished mentally, such as by human observation, evaluation, judgement, opinion, or with the help of pen and paper.
Dependent claims 2, 4, 5, 7, 9-11, and 13 further narrow the abstract ideas and introduce further additional elements for consideration.
Dependent claims 3, 6, 8, 12, and 14 further narrow the abstract ideas and do not introduce further 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 including the customer entering details of the field device to be ordered and an identification of the ticket server of the customer into a manufacturer's server, by the manufacturer's server, establishing a communication connection via a communication network between the manufacturer's server and the ticket server, and on the ticket server, wherein in the course of registration a second cryptographically relevant item of information of the ticket server is stored in the field device from independent claim 1, registration module from claim 2, software module, hardware module from claim 4, digital image of the field device from claim 5, graphical user interface from claim 9, data carrier from claim 11, and operating unit from claim 13, 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 transmitting the registration data from the manufacturer's server to the ticket server via the communication connection from independent claim 1, this limitation does not integrate the judicial exception into a practical application because it adds insignificant extra-solution activity to the judicial exception. This limitation merely recites receiving and/or sending data over a network, which is extra-solution activity. See MPEP 2106.05(g).
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 from claim 7, 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 from claim 10, 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 including the customer entering details of the field device to be ordered and an identification of the ticket server of the customer into a manufacturer's server, by the manufacturer's server, establishing a communication connection via a communication network between the manufacturer's server and the ticket server, and on the ticket server, wherein in the course of registration a second cryptographically relevant item of information of the ticket server is stored in the field device from independent claim 1, registration module from claim 2, software module, hardware module from claim 4, digital image of the field device from claim 5, graphical user interface from claim 9, data carrier from claim 11, and operating unit from claim 13, 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 transmitting the registration data from the manufacturer's server to the ticket server via the communication connection from independent claim 1, this limitation fails to add significantly more to the claims because it adds insignificant extra-solution activity (e.g., mere data gathering) to the judicial exception. This limitation merely recites receiving and/or sending data over a network, which is extra-solution activity. See MPEP 2106.05(g). Additionally, the mere data gathering extra-solution activity has 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)).
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.”.
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-6, 8-9, 11, 12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Cruikshank et al. (US 20240013109 A1, hereinafter “Cruikshank”), in view of Johnson et al. (US 20210120316 A1, hereinafter “Johnson”).
Regarding claim 1: Cruikshank teaches a method for integrating a field device into an operating system of an automation system ([Abstract] A method for facilitating automated system onboarding is disclosed. The method includes receiving, via a graphical user interface, onboarding requests from a user, the onboarding requests including system parameters that correspond to user systems) with the following limitations:
placing an order for the field device by a customer, ([0006] The method may include receiving, via a graphical user interface, at least one onboarding request from a user, the at least one onboarding request may include at least one system parameter that corresponds to at least one user system; [0009] In accordance with an exemplary embodiment, the at least one onboarding request may correspond to a request to onboard the at least one user system, the onboarding may relate to an integration of the at least one user system with a plurality of services in an enterprise network environment.; [0085] the communication interface may correspond to an interface and/or a protocol that enables a computing device to communicate with another computing device. The automatically generated communication interface may enable communication between the user system and the enterprise network environment.);
including the customer entering details of the field device to be ordered and an identification of the ticket server of the customer into a manufacturer's server; ([0024] receive, via a graphical user interface, at least one onboarding request from a user, the at least one onboarding request may include at least one system parameter that corresponds to at least one user system);
generating registration data for the field device on the basis of the order by the manufacturer's server, ([0092] At step S412, a log may be generated to provide documentation for the automated onboarding process. The log may include information that relates to the automatic validating, the automatic generating, and the automatic testing. In an exemplary embodiment, the log may correspond to a record of events that occurred during the automated onboarding process. The record of events may be associated with the user as well as the corresponding communication interface and persisted in a networked repository.);
wherein the registration data comprise identification information of the field device and a first cryptographically relevant item of information; ([0024] receive, via a graphical user interface, at least one onboarding request from a user, the at least one onboarding request may include at least one system parameter that corresponds to at least one user system; automatically validate the at least one onboarding request and the at least one system parameter; automatically generate, based on a result of the validating, at least one communication interface in response to the at least one onboarding request; automatically test the at least one communication interface; implement the at least one communication interface based on a result of the testing; and generate at least one log, the at least one log may include information that relates to the automatic validating, the automatic generating, and the automatic testing.);
establishing a communication connection via a communication network between the manufacturer's server and the ticket server; ([0021] the at least one application programming interface may link the at least one user system with a plurality of services in an enterprise network environment.; [0046] Each of the components of the computer system 102 may be interconnected and communicate via a bus 118 or other communication link.; [0047] The computer system 102 may be in communication with one or more additional computer devices 120 via a network 122.; [0085] the communication interface may correspond to an interface and/or a protocol that enables a computing device to communicate with another computing device. The automatically generated communication interface may enable communication between the user system and the enterprise network environment.);
transmitting the registration data from the manufacturer's server to the ticket server via the communication connection; ([0096] As illustrated in FIG. 5, a user and/or requestor may interact with the disclosed invention to facilitate automated onboarding with existing services. The user and/or requestor may interact with a front-end single-page application (SPA) to provide input, validate user data, and access saved data. The SPA may relate to a web application that interacts with the user by dynamically rewriting the current page with new data from a web server. The SPA may provide information to the user based on user input consistent with disclosures in the present application. A backend server may then receive API requests from the front-end SPA and send back responses from existing services and data storage devices. Consistent with present disclosures, the backend server may perform automation actions.);
wherein in the course of registration a second cryptographically relevant item of information of the ticket server is stored in the field device; ([0087] In another exemplary embodiment, cryptographic keys for the user system may also be automatically generated. The cryptographic keys may facilitate authentication and enable communication via the API. In another exemplary embodiment, the cryptographic keys may correspond to a piece of information that enables the encoding and/or decoding of cryptographic data. The piece of information may correspond to strings of numbers and/or letters that are usable to encrypt and decrypt the cryptographic data. In another exemplary embodiment, the cryptographic keys may be automatically generated according to a task list. Consistent with present disclosures, the task list may indicate that cryptographic keys are required and a sequence for generating the cryptographic keys.).
Cruikshank doesn’t explicitly teach:
registering the field device as an existing field device on the ticket server,
and installing the field device at an installation of the customer after the registering step.
Johnson teaches:
registering the field device as an existing field device on the ticket server ([0053] FIG. 4B also depicts a device token 430, which uniquely identifies the device to the consent management platform as having been authenticated by the platform. More specifically, the device token 430 is generated and cryptographically-signed by the consent management platform when a device first registers, and then provided to the device for expediting future secure communications between the device and the platform. Other elements of the device records in FIG. 4B are describe below in connection with example operation.);
and installing the field device at an installation of the customer after the registering step. ([0025] The client device 106 is a user device that may implement operational features and/or services that require prior user consent in order to be activated for execution on the client device.; [0078] After the consent-choice selection is a process has completed, the secure web session may be removed. The now-updated device-based activation whitelist will include identifiers (e.g., names and/or links) of functions that carry out various aspects of consent features to which the user consented (i.e., selected acceptance of consent). Inclusion in the activation whitelist gives permission for the functions in the list to execute as necessary on the device when the associated consent features are invoked. The now-updated server-based activation whitelist may include identifiers of the device-based functions, as well as information about cloud-side operations associated with the consent-to features. This information may be used to give permission for these operations to be carried out as necessary for delivery of the associated service(s) to the particular content-presentation device. The term “whitelist” as used herein should be understood to describe or specify a list, table, or the like, that associates some form of permission with items in the list. For example embodiments of consent management, the list items identify functions associated with consent features. Other terms for “whitelist” may be used as well, such as “allowlist.”).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine Cruikshank with Johnson‘s feature(s) listed above. One would’ve been motivated to do so in order to implement operational features and/or services that require prior user consent in order to be activated for execution on the client device (Johnson; [0025]). By incorporating the teachings of Johnson, one would’ve been able to register and install a field device.
Regarding claim 2: Cruikshank teaches:
wherein the ticket server includes a registration module, ([0068] The ASOM device 202 is described and shown in FIG. 3 as including an automated system onboarding management module 302, although it may include other rules, policies, modules, databases, or applications, for example.);
wherein the registration data are transferred from the manufacturer's server to the registration module, ([0015] The computing device including a processor; a memory; and a data transmission interface coupled to each of the processor and the memory, wherein the processor may be configured to receive, via a graphical user interface, at least one onboarding request from a user, the at least one onboarding request may include at least one system parameter that corresponds to at least one user system; automatically validate the at least one onboarding request and the at least one system parameter; automatically generate, based on a result of the validating, at least one communication interface in response to the at least one onboarding request; automatically test the at least one communication interface; implement the at least one communication interface based on a result of the testing; and generate at least one log, the at least one log may include information that relates to the automatic validating, the automatic generating, and the automatic testing.; [0085] The communication interface may be automatically generated based on a result of the validating without additional input from the user. In an exemplary embodiment, the communication interface may correspond to an interface and/or a protocol that enables a computing device to communicate with another computing device. The automatically generated communication interface may enable communication between the user system and the enterprise network environment.; [0092] At step S412, a log may be generated to provide documentation for the automated onboarding process. The log may include information that relates to the automatic validating, the automatic generating, and the automatic testing. In an exemplary embodiment, the log may correspond to a record of events that occurred during the automated onboarding process. The record of events may be associated with the user as well as the corresponding communication interface and persisted in a networked repository.);
wherein the second cryptographically relevant item of information is transferred from the registration module to the manufacturer's server, ([0087] In another exemplary embodiment, cryptographic keys for the user system may also be automatically generated. The cryptographic keys may facilitate authentication and enable communication via the API. In another exemplary embodiment, the cryptographic keys may correspond to a piece of information that enables the encoding and/or decoding of cryptographic data. The piece of information may correspond to strings of numbers and/or letters that are usable to encrypt and decrypt the cryptographic data. In another exemplary embodiment, the cryptographic keys may be automatically generated according to a task list. Consistent with present disclosures, the task list may indicate that cryptographic keys are required and a sequence for generating the cryptographic keys.).
Cruikshank doesn’t teach:
and wherein the registration module registers the field device as an existing field device on the ticket server.
Johnson teaches:
and wherein the registration module registers the field device as an existing field device on the ticket server. ([0078] After the consent-choice selection is a process has completed, the secure web session may be removed. The now-updated device-based activation whitelist will include identifiers (e.g., names and/or links) of functions that carry out various aspects of consent features to which the user consented (i.e., selected acceptance of consent). Inclusion in the activation whitelist gives permission for the functions in the list to execute as necessary on the device when the associated consent features are invoked. The now-updated server-based activation whitelist may include identifiers of the device-based functions, as well as information about cloud-side operations associated with the consent-to features. This information may be used to give permission for these operations to be carried out as necessary for delivery of the associated service(s) to the particular content-presentation device. The term “whitelist” as used herein should be understood to describe or specify a list, table, or the like, that associates some form of permission with items in the list. For example embodiments of consent management, the list items identify functions associated with consent features. Other terms for “whitelist” may be used as well, such as “allowlist.”).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Cruikshank with Johnson‘s feature(s) listed above. One would’ve been motivated to do so in order to implement operational features and/or services that require prior user consent in order to identify the device and determine the platform and the device are synchronized or out of synchronization (Johnson; [0079]). By incorporating the teachings of Johnson, one would’ve been able to complete a registration of a field device by adding the field device as an existing field device on the server.
Regarding claim 3: Cruikshank teaches:
wherein the registration data are transferred to the registration module in the form of a first digital exchange ticket, which is created by the manufacturer's server, ([Fig. 5] Front End Spa; [Fig. 4] S402; [0074] In the process 400 of FIG. 4, at step S402, onboarding requests may be received from a user. The onboarding requests may be received via a graphical user interface. In an exemplary embodiment, the onboarding requests may include system parameters that correspond to a user system such as, for example, a client system. The onboarding requests may correspond to a request to onboard the user system. The onboarding process may relate to an integration of the user system with a plurality of services in an enterprise network environment.; [0096] As illustrated in FIG. 5, a user and/or requestor may interact with the disclosed invention to facilitate automated onboarding with existing services. The user and/or requestor may interact with a front-end single-page application (SPA) to provide input, validate user data, and access saved data. The SPA may relate to a web application that interacts with the user by dynamically rewriting the current page with new data from a web server. The SPA may provide information to the user based on user input consistent with disclosures in the present application. A backend server may then receive API requests from the front-end SPA and send back responses from existing services and data storage devices. Consistent with present disclosures, the backend server may perform automation actions.);
and wherein the second cryptographically relevant item of information is transferred to the manufacturer's server in the form of a second digital exchange ticket, which is created by the registration module or the ticket server. ([Fig. 4] S412; [0092] At step S412, a log may be generated to provide documentation for the automated onboarding process. The log may include information that relates to the automatic validating, the automatic generating, and the automatic testing. In an exemplary embodiment, the log may correspond to a record of events that occurred during the automated onboarding process. The record of events may be associated with the user as well as the corresponding communication interface and persisted in a networked repository; [0087] In another exemplary embodiment, cryptographic keys for the user system may also be automatically generated. The cryptographic keys may facilitate authentication and enable communication via the API. In another exemplary embodiment, the cryptographic keys may correspond to a piece of information that enables the encoding and/or decoding of cryptographic data. The piece of information may correspond to strings of numbers and/or letters that are usable to encrypt and decrypt the cryptographic data. In another exemplary embodiment, the cryptographic keys may be automatically generated according to a task list. Consistent with present disclosures, the task list may indicate that cryptographic keys are required and a sequence for generating the cryptographic keys.).
Regarding claim 4: Cruikshank teaches:
wherein a software module or a hardware module is used as the registration module. ([0060] The server devices 204(1)-204(n) may be hardware or software or may represent a system with multiple servers in a pool, which may include internal or external networks. The server devices 204(1)-204(n) hosts the databases 206(1)-206(n) that are configured to store data that relates to onboarding requests, system parameters, user systems, communication interfaces, tests, and logs.; [0096] A backend server may then receive API requests from the front-end SPA and send back responses from existing services and data storage devices. Consistent with present disclosures, the backend server may perform automation actions.).
Regarding claim 5: Cruikshank doesn’t teach:
wherein a digital image of the field device is generated in the course of ordering, wherein the registration data are transferred from the manufacturer's server to the digital image of the field device, wherein the second cryptographically relevant item of information is transferred from the registration module to the digital image of the field device, wherein in the course of registration the registration data are transferred from the digital image of the field device to the registration module.
Johnson teaches:
wherein a digital image of the field device is generated in the course of ordering, wherein the registration data are transferred from the manufacturer's server to the digital image of the field device, wherein the second cryptographically relevant item of information is transferred from the registration module to the digital image of the field device, wherein in the course of registration the registration data are transferred from the digital image of the field device to the registration module. ([0052] FIG. 4B illustrates example device records configured for storage on devices and in the cloud. For any specific individual device, these records are arranged to contain actual consent choices made by a user, and which, for the specific device on which the device record is stored, apply to activating or not activating functions that make up particular services. In some examples, the functions may be pre-installed on a device in an initially disabled and/or deactivate state by the device manufacturer, and only enabled and/or activated by a user's explicit choice to do so via a procedure described below. By maintaining a device-based device record 432 on the device and a corresponding server-based device record 452 in the cloud, and periodically checking and, if necessary, updating synchronization of the records, the consent status of a device may be kept up to date with potential changes to consent campaigns, features, agreements, and functions, for example.; [0053] FIG. 4B also depicts a device token 430, which uniquely identifies the device to the consent management platform as having been authenticated by the platform. More specifically, the device token 430 is generated and cryptographically-signed by the consent management platform when a device first registers, and then provided to the device for expediting future secure communications between the device and the platform. Other elements of the device records in FIG. 4B are describe below in connection with example operation.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Cruikshank with Johnson‘s feature(s) listed above. One would’ve been motivated to do so in order to implement operational features and/or services that require prior user consent in order to support efficient and comprehensive operations for obtaining user consent choices and maintaining synchronization (Johnson; [0052]). By incorporating the teachings of Johnson, one would’ve been able to use digital images to store field device information.
Regarding claim 6: Cruikshank teaches:
wherein the manufacturer's server and the registration module are in communication connection, ([0085] The communication interface may be automatically generated based on a result of the validating without additional input from the user. In an exemplary embodiment, the communication interface may correspond to an interface and/or a protocol that enables a computing device to communicate with another computing device. The automatically generated communication interface may enable communication between the user system and the enterprise network environment. As will be appreciated by a person of ordinary skill in the art, computing components within the user system may utilize the communication interface to communicate with computing components within the enterprise network environment to facilitate system integration consistent with present disclosures.);
wherein the registration data are transferred from the manufacturer's server via the communication connection to the registration module, ([0096] As illustrated in FIG. 5, a user and/or requestor may interact with the disclosed invention to facilitate automated onboarding with existing services. The user and/or requestor may interact with a front-end single-page application (SPA) to provide input, validate user data, and access saved data. The SPA may relate to a web application that interacts with the user by dynamically rewriting the current page with new data from a web server. The SPA may provide information to the user based on user input consistent with disclosures in the present application. A backend server may then receive API requests from the front-end SPA and send back responses from existing services and data storage devices. Consistent with present disclosures, the backend server may perform automation actions.; [Fig. 8]; [0101] FIG. 8 is a component backend diagram 800 of an exemplary process for implementing a method for facilitating automated onboarding of client systems based on validated system parameter inputs. In FIG. 8, the container diagram illustrates different ecosystems and interactions between various services within each of the different ecosystems.; [0102] As illustrated in FIG. 8, the backend server may receive API requests from the front-end SPA and send back responses from existing services and data storage devices. Consistent with present disclosures, the backend server may perform automation actions.
and wherein the second cryptographically relevant item of information is transferred from the registration module to the manufacturer's server via the communication connection. ([0087] In another exemplary embodiment, cryptographic keys for the user system may also be automatically generated. The cryptographic keys may facilitate authentication and enable communication via the API. In another exemplary embodiment, the cryptographic keys may correspond to a piece of information that enables the encoding and/or decoding of cryptographic data. The piece of information may correspond to strings of numbers and/or letters that are usable to encrypt and decrypt the cryptographic data. In another exemplary embodiment, the cryptographic keys may be automatically generated according to a task list. Consistent with present disclosures, the task list may indicate that cryptographic keys are required and a sequence for generating the cryptographic keys.).
Regarding claim 8: Cruikshank teaches:
wherein the manufacturer's server and the registration module are not in communication connection. ([0006] automatically generating, based on a result of the validating, at least one communication interface in response to the at least one onboarding request. Examiner notes that one of ordinary skill in the art would reasonably interpret the communication interface being generated as a result of an onboarding request, as equivalent to the registration module and the manufacturer’s server not being in communication connection until after a request is made by a user.).
Regarding claim 9: Cruikshank teaches:
wherein the registration data are entered into the registration module by a user via a graphical user interface. ([0006] include receiving, via a graphical user interface, at least one onboarding request from a user, the at least one onboarding request may include at least one system parameter that corresponds to at least one user system).
Regarding claim 11: Cruikshank teaches:
wherein the first digital exchange ticket is transferred from the manufacturer's server to a data carrier and wherein the first digital exchange ticket is transferred from the data carrier to the registration module. ([0008] In accordance with an exemplary embodiment, the at least one resolution action may include at least one from among a first action to generate a service ticket in an issue tracking platform, a second action to track a status of the generated service ticket, a third action to notify at least one responsible party, and a fourth action to persist information that relates to the at least one error in the at least one log.).
Regarding claim 12: Cruikshank 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. ([0087] In another exemplary embodiment, cryptographic keys for the user system may also be automatically generated. The cryptographic keys may facilitate authentication and enable communication via the API. In another exemplary embodiment, the cryptographic keys may correspond to a piece of information that enables the encoding and/or decoding of cryptographic data. The piece of information may correspond to strings of numbers and/or letters that are usable to encrypt and decrypt the cryptographic data. In another exemplary embodiment, the cryptographic keys may be automatically generated according to a task list. Consistent with present disclosures, the task list may indicate that cryptographic keys are required and a sequence for generating the cryptographic keys.).
Regarding claim 14: Cruikshank teaches:
wherein the operating unit authenticates itself to the existing field devices defined in the corresponding digital tickets. ([0087] The cryptographic keys may facilitate authentication and enable communication via the API.).
Claims 7, 10, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Cruikshank et al. (US 20240013109 A1, hereinafter “Cruikshank”), in view of Johnson et al. (US 20210120316 A1, hereinafter “Johnson”), as applied to claims 1 and 6 above, in further view of Harrison (US 20210217001 A1, hereinafter “Harrison”).
Regarding claim 7: Cruikshank doesn’t teach:
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.
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, Simple Object Access Protocol (SOAP) API, salesforce.com Apex API, and/or some other like API. The API 32 may be implemented as a web service including, for example, Apache® Axi2.4 or Axi3, Apache® CXF, a JSON-Remote Procedure Call (RPC) API (e.g., Ethereum JSON-RPC API implemented by a public or enterprise Ethereum® blockchain platform), JSON-Web Service Protocol (WSP), Web Services Description Language (WSDL), XML Interface for Network Services (XINS), Web Services Conversation Language (WSCL), Web Services Flow Language (WSFL), RESTful web services, and/or the like.
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Cruikshank with Harrison‘s feature(s) listed above. One would’ve been motivated to do so in order to include one or more public APIs and one or more private APIs (Harrison; [0064]). By incorporating the teachings of Harrison, one would’ve been able to access the registration module using a REST API.
Regarding claim 10: Cruikshank doesn’t teach:
wherein the registration data or the first digital exchange ticket containing the registration data are present as an optically detectable code, in particular as a barcode or as a QR code,
wherein an optical detection unit is assigned to the registration module, and wherein the registration module reads the code via an optical detection unit.
Harrison teaches:
wherein the registration data or the first digital 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.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Cruikshank with Harrison‘s feature(s) listed above. One would’ve been motivated to do so in order to validate the asset token (Harrison; [0064]). By incorporating the teachings of Harrison, one would’ve been able to present registration data using a QR code and read the code with an optical detection unit.
Regarding claim 13: Cruikshank doesn’t teach:
wherein an operating unit for operating existing field devices located in the system is provided as a transport medium,
wherein the digital tickets contain data that authorize the operating unit to carry out a defined work order on a defined existing field device.
Johnson teaches:
wherein an operating unit for operating existing field devices located in the system 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 digital tickets contain data that authorize the operating unit to carry out a defined work order on a defined existing field device. ([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.; [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.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Cruikshank with Harrison‘s feature(s) listed above. One would’ve been motivated to do so in order to access and modify application and DB information, depending on the users' respective security or permission levels (also referred to as “authorizations”). (Harrison; [0043]). By incorporating the teachings of Harrison, one would’ve been able to authorize the operating unit to carry out a defined work order on a defined existing field device.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
/BRIAN M EPSTEIN/Supervisory Patent Examiner, Art Unit 3625
Prosecution Insights