DETAILED ACTION
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 .
Claims 1-19 are pending.
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 12 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because it directed to a computer program per se (often referred to as "software per se") that represent non-statutory subject matter.
Claim 13 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claim 13 recites “computer program product comprising a data carrier”. However, the specification does not limit which forms the above term would take. Therefore, the broadest reasonable interpretation to the above term would cover forms of non-transitory tangible media and transitory propagating signals per se, and the signal per se represent non-statutory subject matter. Applicant is encouraged to amend it with “non-transitory computer-readable storage media”.
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.
Claims 1-19 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, 6, 8, 12-14 each recites the limitation "real functions". It is unclear what kind of function is considering as “real”, appropriate clarification is required.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-19 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by STUMP et al. (hereinafter “STUMP”) (US 20220269493 A1).
As to claims 1, 8, 12-14, STUMP teaches the invention comprising an engineering server of an engineering system of a process control system for providing configurations for real functions of a runtime system of the process control system (see par. [0082] "An example private cloud platform can comprise a set of servers hosting the IDE services 802", par. [0053] "Automation objects 222 can be created and augmented during design, integrated into larger data models, and consumed during runtime... Automation objects 222 can represent elements at substantially any level of an industrial enterprise, including individual devices, machines made up of many industrial devices and components (some of which may be associated with their own automation objects 222), and entire production lines or process control systems" and par. [0050] "the IDE system 202 can support... device/system configuration"), said engineering server comprising:
at least one processor operable to provide a group of engineering services of an engineering services platform (see par. [0082] "An example private cloud platform can comprise a set of servers hosting the IDE services 802" and fig. 2), said group of engineering services including, at least one engineering directory service and at least one group of model services, where each group of model services is associated with a corresponding engineering directory service (see par. [0053] "The object library can store predefined automation objects 222 representing various classifications of real-world industrial assets 402, including but not limited to pumps, tanks, values, motors, motor drives (e.g., variable frequency drives), industrial robots, actuators (e.g., pneumatic or hydraulic actuators)", par. [0073] "Each automation object 222 has associated therewith object properties or attributes specific to its corresponding industrial asset..., including executable control programming for controlling the asset (or for coordinating the actions of the asset with other industrial assets)" and par. [0074] "Other properties can be modified or added by the developer as needed (via design input 512) to customize the automation object 222 for the particular asset and/or industrial application for which the system projects 302 is being developed. This can include, for example, associating customized control code, HMI screens, AR presentations, or help files associated with selected automation objects 222"; in a service-oriented architecture as described in the reference, storing and providing automation objects as well as associating and customizing control code is performed via services; thus, the "engineering directory service" corresponds to the service storing and providing automation objects, the "model services" to services for associating and customizing control code; as predefined automation objects can be customized via associating specific control code per automation-object instance, each group of control code is associated with a corresponding automation object),
where each engineering directory service, provides at least one object of a type corresponding to a type of process control equipment and each model service provides a function operating on an object provided by the corresponding engineering directory service and allowing a user to configure the corresponding function (see par. [0053] "The object library can store predefined automation objects 222 representing various classifications of real-world industrial assets 402, including but not limited to pumps, tanks, values, motors, motor drives (e.g., variable frequency drives), industrial robots, actuators (e.g., pneumatic or hydraulic actuators)", par. [0073] "Each automation object 222 has associated therewith object properties or attributes specific to its corresponding industrial asset..., including executable control programming for controlling the asset (or for coordinating the actions of the asset with other industrial assets)" and par. [0074] "Other properties can be modified or added by the developer as needed (via design input 512) to customize the automation object 222 for the particular asset and/or industrial application for which the system projects 302 is being developed. This can include, for example, associating customized control code, HMI screens, AR presentations, or help files associated with selected automation objects 222"),
wherein the model services and the engineering directory service are realized as microservices and each model service is operative to communicate with the corresponding engineering directory service via a corresponding point-to-point connection and to store configurations made by the user in a source file store for being implemented as configurations of real functions in the runtime system operating on process control equipment (see par. [0135] "operating system 1630 can support containers, and application programs 1632 can be in the form of containers, which are lightweight, standalone, executable packages of software that include, e.g., code, runtime, system tools, system libraries and settings for an application"; using lightweight container deployment is considered an example of a "microservice"-based architecture); see par. [0044] "project generation component 206, project deployment component 208, project testing component 210, collaboration management component 212, the one or more processors 218, and memory 220 can be electrically and/or communicatively coupled to one another to perform one or more of the functions of the IDE system 202" par. [0100] "Embodiments of the IDE system 202 can support a development architecture whereby changes made to an automation object 222 stored in the automation object library 502 are propagated to instances of that automation object 222 that are used in a system project 302…automation objects 222 are maintained in an automation object library 502 (which may be part of memory 220). Via interaction with user interface component 204 and the associated IDE editor 224, developers can add selected automation objects 222 from the library 502 to a system project 302 as instances of these automation objects 222…. " par. [0052] "The system project 302 encodes one or more of control programming... device or sub-system configuration data (e.g., drive parameters, vision system configurations, telemetry device parameters, safety zone definitions, etc.)... of an industrial automation system being designed", par. [0104-0105] "FIG. 12 depicts an example scenario in which the system project 302 is stored on the IDE system 202 itself (e.g., on cloud-based storage if the IDE system 202 is implemented as a cloud service, as depicted in FIG. 8)" and par. [0075] "Project deployment component 208 can compile or otherwise translate a completed system project 302 into one or more executable files or configuration files that can be stored and executed on respective target industrial devices of the automation system (e.g., industrial controllers 118, HMI terminals 114 or other types of visualization systems, motor drives 710, telemetry devices, vision systems, safety relays, etc.)" as well as fig. 8 and 12).
As to claim 2, STUMP teaches a deploy service configured to deploy the configurations of the functions in the runtime system (par. [0047, 0052-0054, 0059, 0066]).
As to claim 3, STUMP teaches each model service has a local store and is operative to, upon starting of a function configuration session for a user, receive data from the source file store and store said data in the local store, store configurations made by the user during the function configuration session in the local store and transfer the content of the local store to the source file store at the end of the function configuration session (par. [0104-0111]).
As to claim 4, STUMP teaches a model service in said group is operative to poll the engineering directory service for changes made from other model services, receive such changes from the engineering directory service and integrate them in the local store (par. [0047, 0052-0054, 0059, 0066, 0100-0101, 0104-0111]).
As to claim 5, STUMP teaches there are several users and each user is provided with an own engineering directory service and associated own group of model services (par. [0053, 0062-0066, 0096, 0104-0111]).
As to claim 6, STUMP teaches a global repository and wherein there is one source file store provided for each user and an engineering directory service is operative to store the configurations of the corresponding group of model services in the associated source file store and the configurations of the different users are merged into the global repository before being implemented as configurations of real functions in the runtime system (par. [0047, 0052-0054, 0059, 0062-0066, 0096-0101, 0104-0111]).
As to claim 7, STUMP teaches the engineering directory service is available during updates of model services in the corresponding group (par. [0047, 0052-0054, 0059, 0066, 0100-0101, 0104-0111]).
As to claim 9, STUMP teaches providing a deploy service operable to deploy the configurations of the functions in the runtime system (par. [0047, 0052-0054, 0059, 0066]).
As to claim 10, STUMP teaches each model service has a local store and receives, upon starting of a function configuration session for a user, data from the source file store and stores said data in the local store, stores configurations made by the user during the function configuration session in the local store and transfers the content of the local store to the source file store at the end of the function configuration session (par. [0104-0111]).
As to claim 11, STUMP teaches polling by a model service in said group the engineering directory service for changes made from other model services, receiving such changes from the engineering directory service and integrating them in the local store (par. [0047, 0052-0054, 0059, 0066, 0100-0101, 0104-0111]).
As to claim 15, STUMP teaches the engineering system comprises an engineering terminal providing a number of engineering tools, each operative to cooperate with a corresponding engineering service of the engineering server (par. [0066, 0073, 0084-0087]).
As to claim 16, STUMP teaches each model service has a local store and is operative to, upon starting of a function configuration session for a user, receive data from the source file store and store said data in the local store, store configurations made by the user during the function configuration session in the local store and transfer the content of the local store to the source file store at the end of the function configuration session (par. [0104-0111]).
As to claim 17, STUMP teaches a model service in said group is operative to poll the engineering directory service for changes made from other model services, receive such changes from the engineering directory service and integrate them in the local store (par. [0047, 0052-0054, 0059, 0066, 0100-0101, 0104-0111]).
As to claim 18, STUMP teaches there are several users and each user is provided with an own engineering directory service and associated own group of model services (par. [0053, 0062-0066, 0096, 0104-0111]).
As to claim 19, STUMP teaches the engineering directory service is available during updates of model services in the corresponding group (par. [0047, 0052-0054, 0059, 0066, 0100-0101, 0104-0111]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHIPENG WANG whose telephone number is (571)272-5437. The examiner can normally be reached Monday-Friday 10-7.
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, Kamini Shah can be reached at 5712722279. 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.
/ZHIPENG WANG/Primary Examiner, Art Unit 2115