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 .
Drawings
The drawing FIG.2 is objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “50” has been used to designate both “DEVICES” and “control/monitoring system”.
The drawing FIG. 2 is objected to as failing to comply with 37 CFR 1.84(p)(5) because it does not include the following reference sign(s) mentioned in the description:
“mobile computing device 66” is recited in [0040], but is not included in FIG. 2.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Claim Rejections - 35 USC § 112(b)
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.
Claim 6 is 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 pre-AIA the applicant regards as the invention.
Claim 6 recites a term “device twin” which causes ambiguity. The recited term is unclear since there is no description about it in the specification. Since Applicant discloses “a digital twin” in the specification, for continuing examination purpose, the term has been construed as “digital twin”.
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 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.
(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 1, 2, 4, 10, 11, 16 and 20 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable over Amaro (US 20220404808 A1, hereinafter as “Amaro”).
Regarding claim 1, Amaro teaches:
A human-interface module (HIM) (SDCS 100 and I/O 40 in FIG. 1 and [0076-0077]) for an industrial automation system comprising:
processing circuitry ([Abstract]); and
a memory ([Abstract]), accessible by the processing circuitry, the memory storing instructions that, when executed by the processing circuitry, cause the processing circuitry to perform operations comprising:
receiving instructions to control one or more industrial automation devices of the industrial automation system ([0381]: laptop enable a user to send instructions to control field devices via HIM) via a cloud-based computing system or a mobile computing device (laptop 20c in FIG.1 and [0076]) communicatively coupled to the HIM;
generating one or more control signals based on the instructions (FIG. 2 and [0104]);
transmitting the one or more control signals to the one or more industrial automation devices ([Abstract]) via an Ethernet connection (FIG. 1 and [0082]);
receiving process data associated with the one or more industrial automation devices ([Abstract]); and
transmitting the process data to the mobile computing device ([0381]: process data are sent to laptop to be displayed).
Amaro teaches specifically (underlines are added by Examiner for emphasis):
PNG
media_image1.png
600
886
media_image1.png
Greyscale
PNG
media_image2.png
712
520
media_image2.png
Greyscale
[Abstract] A process control system includes a plurality of field devices operating to control a process in a process plant. A communication infrastructure couples the plurality of field devices to a software-defined control system (SDCS) that receives data from the field devices and transmits instructions to the field devices. A data cluster, executing the SDCS, includes a plurality of compute nodes, each of which includes a processor executing an operating system, a memory, and a communication resource coupled to one or more other compute nodes in the data cluster. A plurality of instantiated containers, each of which is an isolated execution environment within the operating system of the compute node on which the container is instantiated, cooperate to facilitate execution of a control strategy in the SDCS. At least one of the containers in the SDCS is pinned to a component in the SDCS.
[0076] FIG. 1 depicts a block diagram of an example physical industrial process plant 10 including an example software defined control system (SDCS) 100. The process plant 10 includes a field environment 12 (e.g., the process plant floor) communicatively connected to a back-end environment 15. The back-end environment 15 of the plant 10 is typically shielded from the harsh conditions and materials of the field environment 12, and may include, for example, a separate room, building, or location on site proximate to the field environment 12, any number of devices which are located remotely from the plant site, and/or any number of applications which execute remotely on devices or systems which are located remotely from the plant site. The back-end environment 15 includes the SDCS 100 and typically also includes one or more physical work stations and/or user interfaces 20a-20e which are communicatively connected to the SDCS 100. For example, one or more operator and/or configuration workstations 20a may be located on-site at the plant 10 in a shielded room and communicatively connected with the SDCS 100 via a wired data or communication link 22 (e.g., Ethernet or other suitable wired link), and one or more operator tablets 20b utilized by on-site personnel may be communicatively connected to the SDCS 100 via a wireless link 25 (e.g., Wi-Fi, WirelessHART, cellular communication system link such as 4G LTE, 5G, or 6G, or some other type of suitable wireless link) and wired link 22. Other user interfaces 20c-20e associated with the process plant 10 may be disposed externally to the plant 10 and may communicatively connect to the SDCS 100 via last mile links 30 and/or wireless 32 links, and/or via one or more networks private and/or public networks 35. For example, laptops 20c, mobile devices 20d, and/or process plant-related applications executing in laptops 20c, mobile devices 20d, and/or vehicle systems 20e may be communicatively connected to SDCS 100 via respective wireless links 32, one or more public and/or private data or communication networks 35, and a direct or last-mile link 30 to the SDCS 100 (which typically, but not necessarily, is a wired link). The remote user interfaces and devices 20c-20e may be utilized, for example, by plant operators, configuration engineers, and/or other personnel associated with the industrial process plant 10 and components thereof.
[0077] As shown in FIG. 1, the SDCS 100 communicatively connects to components of the field environment 12 via an I/O (input/output) interface system or gateway 40. Generally speaking, the field-facing portion of the I/O interface system 40 includes a set of physical ports or physical hardware interfaces via which various types of I/O data are delivered to/from components disposed in the field environment, and which connect with and/or support various types of process plant communication links or data links 42-58 via which the I/O data is delivered. The I/O interface system 40 converts and/or routes physical I/O received via links 42-58 from components of the field environment 12 to recipient components of the SDCS 100 (not shown in FIG. 1), and conversely the I/O interface system 40 converts communications generated by the SDCS 100 into corresponding physical I/O and routes the physical I/O to respective recipient components disposed within the field environment 12, e.g., via corresponding links 42-58. As such, the I/O interface system 40 is interchangeably referred to herein as an “I/O gateway” 40. In the embodiment illustrated in FIG. 1, the SDCS 100 and at least a portion of the I/O gateway 40 are implemented using a common set of hardware and software computing resources, e.g., a same computing platform. That is, in the embodiment illustrated in FIG. 1, the SDCS 100 and at least a portion of the I/O gateway 40 (e.g., the portions of the I/O gateway 40 which perform converting, routing, switching, etc.) share at least some computing hardware and software resources; however, the I/O gateway 40 further includes the physical I/O ports or I/O hardware interfaces to the data or communication links 42-58. In other embodiments, though, the SDCS 100 and the I/O gateway 40 may be implemented on separate, communicatively connected computing platforms, each of which utilizes a separate set of hardware and software computing resources, e.g., as is depicted in FIG. 2.
[0082] In some implementations, the process plant 10 includes a set of wired and/or wireless field devices 80 which communicatively connect to the I/O gateway 40 via an APL (Advanced Physical Layer) switch 82. Generally speaking, the APL switch 82 and its links 85 provide power to field devices 80 and in some cases to other devices such as wireless router 88, e.g., in a manner which meets the jurisdictional power safety requirements of the hazardous field environment 12. Typically, the APL-compatible links 85 provide data transport to/from field devices 80 and wireless router 88 via high bandwidth transport media and packet protocols, such as Ethernet and IP protocols, or other suitable high bandwidth transport media and packet protocols. Some of the field devices 80 may be next-generation or APL-compatible field devices, and some of the field devices 80 may be standard field devices which are connected to the links 85 via respective APL adaptors. Similar to the links 85, the links 55 communicatively connecting the APL switch 82 and the I/O gateway 40 may also utilize APL-compatible transport media and/or packet protocols, such as high-bandwidth Ethernet and IP protocols, and thus the links 55 may support an APL I/O type. Consequently, the I/O gateway 40 may include respective I/O cards or devices to service the communications delivered via the links 55.
[0104] Now turning to the application layer 212 of the SDCS 200, the set of SD process control services 235 provide the process control business logic of the logical process control system 245. Each different control service 235 may be configured with desired parameters, values, etc. and optionally other control services 235; each instance of a configured control service 235 may execute in a respective container; and each container may be assigned (or pinned) to execute on a respective node or cluster. As such, each configured control service 235 may be a logical or software defined control entity which functionally may be configured and may perform in a manner similar to that of a traditional, hardware-implemented process controller device, process control module, process control function block, etc. However, unlike traditional, hardware-implemented process controller devices, traditional control modules, and traditional control function blocks, and advantageously, the SDCS 200 may easily replicate multiple instances of a same configured control service 235 for various purposes, such as performance, fault tolerance, recovery, and the like. For example, a controller service (which executes in its own container) may be configured to execute a control module service (which executes in its own container), and the control module service may be configured to execute a set of control function block services (each of which executes in its own container, and each of which may be configured with respective parameters, values, etc.). As such, the set of containers corresponding to the set of configured control function block services may be nested in the control module service container, and the control module service container may be nested in the controller service container. The set of containers corresponding to the set of configured function block services may be assigned to execute on different cores of a physical layer processor 208, e.g., for performance load-balancing purposes. When loads change, one or more of the function block service containers may be moved to execute on different processor cores, different processors, or even different nodes in attempt to re-balance loads; however, the moved function block service containers would still be nested under the control module service container, and would execute accordingly.
[0381] FIG. 42 depicts the visualization service or utility 3202 (that executes on a computer processor) as communicating with the orchestrator 222 of FIG. 1 as well as, if necessary, the configuration database 3203, to discover configuration and runtime information for the various logical and physical elements. The visualization service 3202 may subscribe to information from the orchestrator 222 for active visualizations, and/or may send one or more queries to the orchestrator 222 (and the configuration database 3203) when generating a visualization for a user via a user interface 3204. In any event, the visualization service 3202 executes to display both logical and physical information about the control system to a user via the user interface device 3204 (which may be any type of user interface, such as a laptop, a wireless device, a phone application, a workstation, etc.) and may display control system information in an interactive manner, so as to enable the user to view configured, as well as the current run-time operation of the various logical elements within the plant, and of the physical elements to which these logical elements are currently assigned. In particular, the visualization service 3202 may present one or more screens to a user via the user interface device 3204 displaying one or more logical and/or physical elements of the control system and may enable the user to select any of various logical and/or physical elements of the control system, as currently being implemented, to indicate more detail about the configuration and/or runtime information the user wishes to see. The visualization service 3202 then obtains, from the orchestrator 222, runtime information for the selected logical and/or physical elements including, for example, the manner in which the logical elements (e.g., containers, such as control containers) are nested within or pinned to one another, the manner in which the logical elements are being executed in or on various physical elements, and/or one or more performance indicators that indicates the operational health or performance of the logical and/or physical elements as currently operating. The visualization service 3202 presents this information to the user in one or more screen displays and may, in some cases, enable the user to interact via a screen display to view other information, and to dynamically change the operation of the control system in terms of how one or more of the logical elements are assigned to other logical elements or to physical elements.
Regarding claim 2, Amaro teach(es) all the limitations of its base claim from which the claim depends.
Amaro further teaches:
the one or more industrial automation devices are communicatively coupled to the HIM in parallel via an Ethernet switch (FIG. 1 and [0082]: field devices 80 are coupled to the HIM in parallel via APL switch 82).
Regarding claim 4, Amaro teach(es) all the limitations of its base claim from which the claim depends.
Amaro further teaches:
receiving the process data from the one or more industrial automation devices comprises receiving first process data from a first industrial automation device and receiving second process data from a second industrial automation device concurrently via the Ethernet connection (FIG. 1 and [0082 and 0381]: “so as to enable the user to view configured, as well as the current run-time operation of the various logical elements within the plant, and of the physical elements to which these logical elements are currently assigned”).
Regarding claim 10, Amaro teach(es) all the limitations of its base claim from which the claim depends.
Amaro further teaches:
the instructions comprise instructions to execute one or more containerized applications on a compute surface of the HIM ([0016-0020]).
Regarding claim 11, Amaro teach(es) all the limitations of its base claim from which the claim depends.
Amaro further teaches:
the one or more containerized applications (FIG. 2 and [0095]: “Within the architecture of the SDCS 200, the application layer software components 235-248 may execute in containers”) are associated with the control ([0104]: “each instance of a configured control service 235 may execute in a respective container;…. As such, each configured control service 235 may be a logical or software defined control entity …”), monitoring, or authentication of the one or more industrial automation devices.
Claim 16, in its broadest reasonable interpretations, is construed as “transmit the process data to a mobile computing device communicatively coupled to the HIM”. Claim 16 recites an industrial automation system comprising a HIM of claim 2 with similar limitations. Therefore, claim 16 is rejected for the same reasons recited in the rejections of claim 1 and claim 2.
Regarding claim 20, Amaro teach(es) all the limitations of its base claim from which the claim depends.
Amaro further teaches:
the HIM comprises a display, and wherein the HIM is configured to display the received process data via the display (FIG. 1 and [0027]: “to assist a user in visualizing the run-time operation of the SDCS, a visualization service interfaces with the orchestrator and a configuration database to obtain configuration data and current run-time operational data defining the currently established or operating interrelationships between various logical elements of the control system, such as control and subsystem containers, both with each other and with physical elements in the system. The visualization service may create any number of different user displays that illustrate these relationships (as currently configured and operating in the SDCS) and that also provide key performance or health parameters for one or more of the displayed logical and/or physical elements”).
Claim Rejections - 35 USC § 103
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 3 is rejected under 35 U.S.C. 103 as being unpatentable over Amaro in view of Ritchie (US 20240118798 A1, hereinafter as “Ritchie”).
Regarding claim 3, Amaro teach(es) all the limitations of its base claim from which the claim depends, but does not teach the one or more control signals comprise instructions to implement a firmware update on the one or more industrial automation devices.
However, Ritchie teaches in an analogous art:
instructions to implement a firmware update on the one or more industrial automation devices (FIG. 3 and [0080]: “The networked computer system(s) also can update a configuration, including software/firmware update, of the field devices/instruments 370A and 370B through the bridge device 350”. This teaches a remote computer device sends instructions to update firmware of field devices 370A/B).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro based on the teaching of Ritchie, to make the HIM wherein the one or more control signals comprise instructions to implement a firmware update on the one or more industrial automation devices. One of ordinary skill in the art would have been motivated to do this modification since it enables to update a field device from a networked computer, as Ritchie suggests in [Abstract].
Claims 5, 12 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Amaro in view of Ritchie (US 20240118798 A1, hereinafter as “Ritchie”).
Regarding claim 5, Amaro teach(es) all the limitations of its base claim from which the claim depends, but does not teach transmitting the process data to the mobile computing device is via the cloud-based computing system.
However, Vasko teaches in an analogous art:
transmitting data to the mobile computing device is via the cloud-based computing system (FIG. 2 and [0030-0031]: “the cloud-based computing system 28 may be capable of communicating with the industrial automation equipment 16 and the computing device 26. As such, the cloud-based computing system 28 may be capable of wired or wireless communication between the industrial automation equipment 16 and the computing device 26”. This teach data can be transmitted from equipment 16 to a cloud-based computing system 28 and be transmitted to laptop 26 via the cloud-based computing system).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro based on the teaching of Vasko, to make the HIM wherein transmitting the process data to the mobile computing device is via the cloud-based computing system. One of ordinary skill in the art would have been motivated to do this modification in order to “share information with each other and thus perform their respective operations more efficiently”, as Vasko suggests in [0002].
Claim 12 recites a method comprising operational step conducted by the HIM in claims 1 and 5 with similar limitations. Therefore, claim 12 is unpatentable over Amaro in view of Vasko, for the reasons recited in the rejections of claims 1 and 5.
Claim 17 recites an industrial automation system comprising a HIM as claim 5 with similar limitations. Therefore, claim 17 is rejected fort the similar reason recited in the rejection of claim 5.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Amaro in view of Harvey (US 20250139314 A1, hereinafter as “Harvey”).
Regarding claim 6, Amaro teach(es) all the limitations of its base claim from which the claim depends, but does not teach generating a digital twin for a device of the one or more devices, wherein the digital twin comprises an interface by which one or more applications interact with the device.
However, Harvey teaches in an analogous art:
generating a digital twin for a device of the one or more devices ([0048-0049]: “the digital twin 220 includes an environment twin 222 that models the environment whose state is being controlled (e.g., a building) and a controlled system twin 224 that models the system that the controller controls (e.g., an HVAC equipment system). A digital twin 220 may be any data structure that models a real-life object, device, system, or other entity. …. The digital twin creator 218 may provide a toolkit for the user to create digital twins 220 or portions thereof”), wherein the digital twin comprises an interface by which one or more applications interact with the device ([0063]: “The commissioning application 234 has access to the digital twin 220, such that the digital twin may pass information to the commissioning application 234, and receive information from the commissioning application”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro based on the teaching of Harvey, to make the HIM wherein the operations comprise generating a digital twin for a device of the one or more devices, wherein the digital twin comprises an interface by which one or more applications interact with the device. One of ordinary skill in the art would have been motivated to do this modification since it can help with “equipment utilization”, as Harvey suggests in [0040].
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Amaro in view of Soo (US 20230051907 A1, hereinafter as “Soo”).
Regarding claim 19, Amaro teach(es) all the limitations of its base claim from which the claim depends, but does not teach each industrial automation device of the one or more industrial automation devices is configured to perform a control function for one or more additional industrial automation devices based on the one or more control signals.
However, Soo teaches in an analogous art:
each industrial automation device of the one or more industrial automation devices is configured to perform a control function for one or more additional industrial automation devices based on the one or more control signals (FIG. 1 and [0048]: “some operations may be performed at a field device 122, 126 that is controlled by another field device 120, 124 that includes the event enrollment object”. This teaches field devices 120 and 124 control operations for field devices 122 and 126).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro based on the teaching of Soo, to make the industrial automation system wherein each industrial automation device of the one or more industrial automation devices is configured to perform a control function for one or more additional industrial automation devices based on the one or more control signals. One of ordinary skill in the art would have been motivated to do this modification in order to help “management of field devices”, as Soo suggests in [0002].
Claims 7 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Amaro in view of Fries (US 20240236671 A1, hereinafter as “Fries”), and in further view of Vasko.
Regarding claim 7, Amaro teach(es) all the limitations of its base claim from which the claim depends, but does not teach detecting a connection attempt from the mobile computing device via the cloud-based computing system; determining whether the mobile computing device is a trusted device; and allowing access from the mobile computing device to the one or more industrial automation devices in response to determining that the mobile computing device is a trusted device.
However, Fries teaches in an analogous art:
detecting a connection attempt from the mobile computing device (step 210 in FIG. 2 and [0020]: a connection/registration request from mobile user device 143 is received by industrial edge server 110);
determining whether the mobile computing device is a trusted device (step 220 in FIG. 2 and [0022] and [0028]: “… and to evaluate if the device 143 is to be trusted or not, based on the contained parameter”); and
allowing access from the mobile computing device to the one or more industrial automation devices in response to determining that the mobile computing device is a trusted device ([0017-0019]: after the user device is authenticated, the user device can access industrial automation devices through industrial network).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro based on the teaching of Fries, to make the HIM wherein the operations comprise detecting a connection attempt from the mobile computing device; determining whether the mobile computing device is a trusted device; and allowing access from the mobile computing device to the one or more industrial automation devices in response to determining that the mobile computing device is a trusted device. One of ordinary skill in the art would have been motivated to do this modification since it can help improve “overall security”, as Fries suggests in [Abstract].
Amaro-Fries teaches all the limitations except the connection attempt from the mobile computing device is received via the cloud-based computing system.
However, Vasko teaches in an analogous art:
Detecting communication from the mobile computing device via the cloud-based computing system (FIG. 2 and [0030-0031]: “the cloud-based computing system 28 may be capable of communicating with the industrial automation equipment 16 and the computing device 26. As such, the cloud-based computing system 28 may be capable of wired or wireless communication between the industrial automation equipment 16 and the computing device 26”. This teach that communication can be transmitted from equipment 16 to a cloud-based computing system 28 and be transmitted to laptop 26 via the cloud-based computing system).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro-Fries based on the teaching of Vasko, to make the HIM wherein the operations comprise detecting a connection attempt from the mobile computing device via the cloud-based computing system. One of ordinary skill in the art would have been motivated to do this modification in order to “share information with each other and thus perform their respective operations more efficiently”, as Vasko suggests in [0002].
Claim 13 recites a method comprising operational steps conducted by the HIM of claim 7 with similar limitations. Therefore, claim 13 is rejected for the similar reason recited in the rejection of claim 7.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Amaro in view of Vasko, and in further view of Oba (US 20100186063 A1, hereinafter as “Oba”).
Regarding claim 18, Amaro-Vasko teach(es) all the limitations of its base claim from which the claim depends, but do not teach to receive, from the cloud-based computing system, additional instructions to change one or more security configurations of the HIM; and to generate the one or more control signals based on the changed one or more security configurations.
However, Oba teaches in an analogous art:
Receive additional instructions to change one or more security configurations of a device (FIG. 1 and step 112 in FIG. 4 and [0038 and 0041]: “the IFA 20 is accessed by the MD 10 for updating an original security configuration of the IFA 20 with a new security configuration using security information which is transmitted from the MD 10 to the IFA 20 via the Internet 16”. These teach that a device IFA 20 receives instruction to change/update security configuration); and
generate signals based on the changed one or more security configurations (FIG. 5 and [0041]: the IFA 20 generates command/signals based on updated security configurations).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro-Vasko based on the teaching of Oba, to make the industrial automation system wherein the HIM is configured to receive, from the cloud-based computing system, additional instructions to change one or more security configurations of the HIM; and generate the one or more control signals based on the changed one or more security configurations. One of ordinary skill in the art would have been motivated to do this modification in order to change/update the security configuration when needed.
Allowable Subject Matter
Claims 8-9 and 14-15 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Mazur (US 20210216061 A1): teaches, in FIG. 1, a computing device connects and controls industrial devices.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES CAI whose telephone number is (571)272-7192. The examiner can normally be reached on M-F 8-5 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, Kamini Shah can be reached on 571-272-2279. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES CAI/Primary Patent Examiner, Art Unit 2115
Prosecution Insights