DETAILED ACTION
Claims 1-10 are pending.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner’s Notes
Examiner has cited particular columns and line numbers, paragraph numbers, or figures in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Claim Objections
Claims 1-10 are objected to because of the following informalities: Claim 1 and 10 recites the abbreviation “OT network” which has no generally recognized meaning and therefore it is unclear. Applicant’s specification page 2, line 3, provides a clear basis for clarifying the first occurrence of said abbreviation in the claim phrase as an “operational technology network.” Appropriate correction is required.
Claim 7 is objected to because of the following informalities: Claim 1 and 10 recites the abbreviation “OPC UA, SNMP or DCP” which has no generally recognized meaning and therefore it is unclear. Applicant’s specification page 24, lines 18-23, provides a clear basis for clarifying the first occurrence of said abbreviation in the claim phrase as an “Open Platform Communication Unified Architecture,” “Simple Network Management Protocol,” and “Dynamic Code Programming,” respectfully. Appropriate correction is required.
Claim Rejections - 35 USC § 101
Claim 10 recites a “a data storage medium” having a “program code”. Examiner is to apply the term “data storage medium” to its broadest reasonable interpretation which would be any medium usable by a computer which would include carrier waves and signals see specification "data storage medium" page 24, lines 5-13. Thus, the claim is directed to non-statutory matter. See MPEP § 2106. To overcome this type of rejection applicant may amend claims to include “non-transitory data storage medium.”
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-3, 6-8 and 10 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Van Camp (US-PGPUB-NO: 2010/0131084 A1).
As per claim 1, Van Camp teaches a management and updating system for automation devices connected to an OT network of an automation plant, comprising: a device management and update user unit connected to an OT network to which a plurality of automation devices of an automation plant are further connected (see Van Camp paragraph [0026], “Certain examples described herein can be used to deploy routine updates to a control system, such as a DeltaV.TM. digital automation system provided by Emerson Process Management. Additionally or alternatively, certain examples described herein can be used to update a flash version of a controller or Input/Output ("I/O") card and/or to distribute a new version of digital automation software to the rest of a running system”), wherein the device management and update user unit is further set up by programming to provide: an interface selection and connection service set up to select and set up a communication interface for establishing a communication link to an automation device of the plurality of connected automation devices (see Van Camp paragraph [0059], “The example implementation of FIG. 2 also includes the pen tablet computer 242, the handheld computer 244, and the laptop computer 246, all of which may be communicatively coupled to the Internet 216 and/or the LAN 234 to communicate with the example online maintenance system 202, the process control systems 218 and 220, and the messenger server 236. Users may use one or more of the pen tablet computer 242, the handheld computer 244, the laptop computer 246, or any other computer (e.g., a desktop computer) coupled to the Internet 216 or the LAN 234 and remotely located from the site 210 to access maintenance information associated with the site 210 in a manner substantially similar to that described above in connection with the workstation terminals 230 and 232”), a read-out service, set up for activating a read-out from each automation device to which the communication link is established, of device type information stored in the automation device, and for saving the device type information read out in each case (see Van Camp paragraph [0044], “In the illustrated example, the SMS server 208 is configured to store and process the registration/configuration information corresponding to each process control system monitored by the example online maintenance system 202. For example, the SMS server 208 may include and/or be communicatively coupled to one or more data structures (e.g., databases) that store the registration/configuration information. The SMS server 208 may also be configured to store knowledge base articles ("KBA's") (e.g., maintenance database entries or other database entries that include maintenance information or other information about process systems and/or parts thereof) that describe issues (e.g., software bugs, equipment failures, operating anomalies, etc.) associated with different components or devices of process control systems”, an update planning service set up to plan update requests for each automation device of the plurality of automation devices for which read-out device type information is saved (see Van Camp paragraph [0080], “A deployment group setup view may be an optional view provided for more experienced users. System hardware may be grouped to assign different schedules and degrees of update/upgrade automation. Groups may also be formed to implement update/upgrade deployment strategies where some parts of the system are updated/upgraded first to confirm results in less sensitive process areas. Groups may also be formed where some parts of the system are managed by different people, for example”), an update file retrieval service set up to establish a communication link to at least one storage device and to retrieve update files saved in the storage device (see Van Camp paragraph [0062], “The SMS 310 provides a software update delivery service such that, with no effort required on their part, users receive software files and supporting information to manage and install system software updates and/or upgrades. Software updates/upgrades are automatically electronically delivered to the user's specified destination, such as a computer 340, 350 and/or to a process or automation control system 350. Software updates/upgrades may be first delivered to the portable media 330 and/or the workstation 340 connected to but not a part of the process control system, which then deploy the updates/upgrades to the process control system 350, for example. Updates/upgrades can include process control system software, operating system software, anti-virus software, security software, etc. A software deployment manager 360 facilitates download, installation, configuration, and management of software deployment for the process control system 350”), a check and allocation service, set up to check each retrieved update file for its release with respect to the plurality of automation devices in functional dependence on the saved device type information and, if the check of one of the retrieved update files results in a release for an automation device, to allocate this update file to the device type information saved for this automation device (see Van Camp paragraph [0106], “At 1004, a repository (e.g., the update files 312, metadata 314, and KBA documents 316 of FIG. 3) is checked for an update and/or upgrade. The deployment manager (e.g., the software deployment manager 360 of FIG. 3) understands the configuration of the control system and checks for updates and/or upgrades applicable to that system configuration. The deployment manager can identify one or more updates and/or upgrades applicable to a configuration of nodes of the process control system”), and an update service, set up for transmitting to each automation device the update file allocated to it in each case, including an update command, in accordance with saved device type information, in each case as a functional function of the update requests planned for each automation device (see Van Camp paragraph [0107], “At 1006, update(s) and/or upgrade(s) applicable to the system configuration are selected. Selection may be automated and/or manual by a user as specified in the system configuration (e.g., using the software deployment manager 360 of FIG. 3 in conjunction with the deployment interface 500 of FIG. 5 and/or the deployment group setting interface 600 of FIG. 6). For example, the deployment manager understands the configuration of the control system and only selects the updates and upgrades for that system configuration. Selected update(s) and/or upgrade(s) can be provided for download to the process control system. Software representing an update and/or upgrade can be provided along with metadata for the software indicating applicability of the software to one or more nodes of the process control system”).
As per claim 2, Van Camp teaches wherein the device management and update user unit is further set up by programming: to save the allocate update files (see Van Camp paragraph [0064], “The SMS 310 provides one or more tables and related stored procedures to match process control system hot fixes to system nodes. Table(s) relate the KBAs 316, hot fixes, and control system software versions, for example. The SMS 310 stores the update and/or upgrade files 312, packages the files, creates help files, and transmits the files to a requesting applet at a customer site (e.g., the computer 340)”), and/or to log the respective update status with respect to each automation device for which read- out device type information is saved (see Van Camp paragraph [0038], “The example online maintenance system may also be implemented to provide a plurality of other features. For example, the example online maintenance system may be configured to send alerts via e-mail, pager, mobile phone, landline phone, really simple syndication ("RSS"), etc. to users (e.g., system operators, system engineers, maintenance engineers, etc.) if one or more particular conditions are met (e.g., a failure condition, a change in software or hardware, availability of firmware updates or software upgrades, etc.). The example online maintenance system may also generate various maintenance reports, monitor the lifecycle status of portions of the process control systems, organize and track information (e.g., expiration dates) associated with product warranty and support services, store and display status of open maintenance tickets or maintenance calls, and other features described below”).
As per claim 3, Van Camp teaches wherein the device management and updating user unit is furthermore set up by programming: for saving the read-out device type information each associated with an asset specified thereby and comprised by the automation device, comprising firmware, application or configuration of the automation device, for planning the update requests each for the assets specified by the saved device type information (see Van Camp paragraph [0040], “In the illustrated example, the main server 204 is configured to receive registration and/or configuration information associated with process control systems (e.g., example process control systems 218 and 220) monitored by the example online maintenance system 202. The registration and/or configuration information may include field device information, software information, firmware information, operational status information, maintenance information, lifecycle information, etc. associated with hardware, software, and/or firmware used to implement the components and devices of monitored process control systems 218 and 220. The main server 204 may receive the registration and/or configuration information during an enrollment process of a process control system (e.g., when a process control system is brought online for the first time to be monitored by the example online maintenance system 202). In addition, the main server 204 may receive new and/or updated registration and/or configuration information periodically and/or a periodically after an enrollment process to ensure that the example online maintenance system 202 has the latest and up-to-date information corresponding to monitored process control system”), for checking the retrieved update file each with respect to the assets specified by the saved device type information, and for allocating the released update files to the respective assets (see Van Camp paragraph [0045], “In the illustrated example, the SMS server 208 is configured to perform a KBA matching process. In general, the KBA matching process compares information stored in a KBA (e.g., identification information, device type information, or other criteria) to the registration/configuration information to determine which KBA's are applicable or relevant to which monitored process control systems”).
As per claim 6, Van Camp teaches wherein the device management and updating user unit is set up by programming on an edge PC, on one of the plurality of automation devices itself or on a central server instance of the user (see Van Camp paragraph [0035], “For example, the example online maintenance system may be implemented using one or more maintenance servers at a central facility executing machine accessible instructions (e.g., computer code, software, etc.) that cause the maintenance servers to communicate via the Internet and/or other communication network(s) (e.g., a local area network ("LAN"), a wireless LAN ("WLAN"), a wide area network ("WAN"), etc.) with one or more remotely located process control system servers and that cause the maintenance servers to obtain process control system information (e.g., performance information, operating information, etc.) from the process control system servers”).
As per claim 7, Van Camp teaches wherein the device management and update user unit is further set up to use different protocols from a plurality of data exchange protocols, in particular comprising standardized protocols, such as OPC UA, SNMP or DCP, and/or open source protocols, depending on the automation devices and/or for operating the update file retrieval service (see Van Camp paragraph [0123], “Examples may be practiced in a networked environment using logical connections to one or more remote computers having processors. Logical connections may include a local area network (LAN) and a wide area network (WAN) that are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets and the Internet and may use a wide variety of different communication protocols. Those skilled in the art will appreciate that such network computing environments will typically encompass many types of computer system configurations, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Examples may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices”).
As per claim 8, Van Camp teaches further comprising a management platform hierarchically superimposed on a plurality of device management and updating user units according to any one of the preceding claims and set up to provide update files stored in a storage device for retrieval by the plurality of device management and updating user units (see Van Camp paragraph [0082], “As illustrated, for example, in FIG. 5, an update deployment interface 500 of the software deployment manager described herein (e.g., the deployment manager 360 of FIG. 3) provides a list of hardware with pending updates 505. The deployment interface 500 provides an explorer-based display and hierarchy that allow taking action or dismissing action against a deployment group, individual nodes, and/or individual queued updates (and/or upgrades) for a node”).
As per claim 10, Van Camp teaches a data storage medium having a program code stored thereon, the program code being such that a data processing device connectable to an OT network, when programmed with the program code, provides a device management and updating user unit set up in accordance with claim 1 (see Van Camp paragraph [0121], “Certain examples include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media that may be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such computer-readable media may comprise RAM, ROM, PROM, EPROM, EEPROM, Flash, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions”).
Claim Rejections - 35 USC § 103
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.
Claim(s) 4 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Van Camp (US-PGPUB-NO: 2010/0131084 A1), in further view of Malaspina et al. (US-PGPUB-NO: 2018/0359144 A1) hereinafter Malaspina.
As per claim 4, Van Camp teaches wherein the update files for checking each retrieved update file are each retrieved together with description files associated with the stored update files, comprising information on the file type, the update file, manufacturer information, version information, type information, dependencies on existing previous versions and/or hardware versions, a unique ID, checksum, release status, and/or information on further accompanying documents (see Van Camp paragraph [0071], “The sidebar 420 may be part of an interface or other display for user review and interaction with the control system, for example. The sidebar 420 lists one or more update or upgrade types 425 and a number of nodes 427 in the system affected by the update/upgrade. For example, software update/upgrade types 425 may include firmware updates/upgrades, system version upgrades, system software updates/upgrades, Microsoft.RTM. software updates/upgrades, anti-virus software update/upgrades, etc”).
Van Camp does not explicitly teach comprising license information and/or change notes. However, Malaspina teaches comprising license information and/or change notes (see Malaspina paragraph [0042], “The invention may include a web service or interface for allowing client applications connection to an external database for real-time access to industrial automation products lifecycle data. The client application may use the data to provide system compatibility verification. The client application can initiate artifacts (firmware, release notes, etc.) downloads through the web service. The application can acquire products' lifecycle status”).
Van Camp and Malaspina are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the claimed invention effective date to modify Van Camp’s teaching of software deployment manager integration within a process control system with Malaspina’s teaching of launching multiple device firmware update operations from another application with device list context to incorporate release notes in order to gather as much information as possible when making the updates to the devices.
As per claim 9, Van Camp modified with Malaspina teaches wherein further the management platform is arranged in an IT network, comprising a cloud-based platform (see Malaspina paragraph [0031], “The invention provides the ability to make devices' firmware updates from a mobile application and cloud application, the ability to stream firmware updates from a central repository on the cloud, the ability to be notified of updates inline from the mobile application and cloud application, and the ability to integrate the mobile application and cloud application with a download center”).
Claim(s) 5 is rejected under 35 U.S.C. 103 as being unpatentable over Van Camp (US-PGPUB-NO: 2010/0131084 A1), in further view of Holtzman et al. (US-PGPUB-NO: 2008/0010449 A1) hereinafter Holtzman.
As per claim 5, Van Camp does not explicitly teach wherein a number of public keys is storable in a memory of the device management and updating user unit, and the verification and allocation service is set up, using the number of public keys, to verify signatures created with a private key contained in the retrieved update files, respectively. However, Holtzman teaches wherein a number of public keys is storable in a memory of the device management and updating user unit (see Holtzman paragraph [0249], “The asymmetric authentication protocols of the SSA preferably uses Public Key Infrastructure (PKI) and RSA algorithms. As defined by these algorithms, each party in the authentication process is allowed to create its own RSA key pair. Each pair consists of public and private keys. Since the keys are anonymous they cannot provide proof of identity. The PKI layer calls for a third, trusted, party which signs each one of the public keys. The public key of the trusted party is pre-shared between the parties which are to authenticate each other and is being used to verify the public keys of the parties. Once trust is established (both parties determined that the public key provided by the other party can be trusted) the protocol continues to authentication (verifying that each party holds the matching private key) and key exchange. This can be done through the challenge response mechanism illustrated in FIGS. 22 and 23 described below”), and the verification and allocation service is set up, using the number of public keys, to verify signatures created with a private key contained in the retrieved update files, respectively (see Holtzman paragraph [0253], “The certificate is considered public information (as the public key inside) and therefore is not encrypted. However, it includes an RSA signature which verifies that the public key, as well as, all other information fields were not tempered with”).
Van Camp and Holtzman are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the claimed invention effective date to modify Van Camp’s teaching of software deployment manager integration within a process control system with Holtzman’s teaching of content control system using certificate chain to incorporate the use of public keys in order to secure the content being used and make sure the update files aren’t tampered with.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mitra (US-PGPUB-NO: 2020/0356354 A1) teaches automated application updates during operating system upgrades.
Malaspina et al. (US-PGPUB-NO: 2018/0357058 A1) teaches devices and revisions templates for managing firmware standards.
Kacin (US-PGPUB-NO: 2008/0109396 A1) teaches IT automation application and user portal.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/LENIN PAULINO/Examiner, Art Unit 2197
Prosecution Insights