DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. Claims 1–20 are pending for examination in the reply filed on 02/10/2026.
(Claims 11–20 are NEW).
Examiner’s Remarks
3. Examiner refers to and explicitly cites particular pages, sections, figures, paragraphs or columns and lines in the references as applied to Applicant’s claims to the extent practicable to streamline prosecution.
Although the cited portions of the references are representative of the best teachings in the art and are applied to meet the specific limitations of the claims, other uncited but related teachings of the references may be equally applicable as well. It is respectfully requested that, in preparing responses to the rejections, the Applicant fully considers not only the cited portions of the references, but also the references in their entirety, as potentially teaching, suggesting or rendering obvious all or one or more aspects of the claimed invention.
Abbreviations
4. Where appropriate, the following abbreviations will be used when referencing Applicant’s submissions and specific teachings of the reference(s):
i. figure / figures: Fig. / Figs.
ii. column / columns: Col. / Cols.
iii. page / pages: p. / pp.
References Cited
5. (A) Bian et al., US 2020/0159195 A1 (“Bian”).
(B) Neiman et al., US 2003/0237084 A1 (“Neiman”).
(C) Feldpusch et al., US 2019/0036733 A1 (“Feldpusch”).
(D) Maturana et al., US 2014/0047107 A1 (“Maturana”).
Bian and Feldpusch were cited in the previous Office action.
Notice re prior art available under both pre-AIA and AIA
6. 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.
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 of this title, 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.
A.
7. Claims 1–12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Bian in view of (B) Neiman and (C) Feldpusch.
See “References Cited” section, above, for full citations of references.
8. Regarding claim 1, (A) Bian teaches/suggests the invention substantially as claimed, including:
“An information management apparatus comprising: a communication apparatus, a memory and a processor, wherein the processor is configured to:”
(Fig. 5 and ¶¶ 57–59: a network interface 510, a processor 520, an output 530, and a storage device 540 such as a memory);
“receiving measurement data that is collected by a device”
(¶ 22: An IIoT may connect assets, such as turbines, jet engines, locomotives, elevators, healthcare devices, mining equipment, oil and gas refineries, and the like, to the Internet or cloud, or to each other in some meaningful way such as through one or more networks. The cloud can be used to receive, relay, transmit, store, analyze, or otherwise process information for or about assets and manufacturing sites;
¶ 23: Assets may be outfitted with one or more sensors (e.g., physical sensors, virtual sensors, etc.) configured to monitor respective operations or conditions of the asset and the environment in which the asset operates. Data from the sensors can be recorded or transmitted to a cloud-based or other remote computing environment;
¶ 24: The edge-cloud system may be used in conjunction with applications and systems for managing machine and equipment assets and can be hosted within an IIoT;
Fig. 1 and ¶ 29: illustrates a cloud computing system 100 for industrial software and hardware in accordance with an example embodiment. Referring to FIG. 1, the system 100 includes a plurality of assets 110 which may be included within an edge of an IIoT and which may transmit raw data to a source such as cloud computing platform 120 where it may be stored and processed;
¶ 40: the sensors can include various types of industrial devices such as imaging, proximity, temperature, switch, chemical, IR, pressure, counter, vibration, etc.);
Bian teaches “calculated data that is generated from the measurement data” (¶¶ 22 and 25: cloud can be used to receive, relay, transmit, store, analyze, or otherwise process information for or about assets and manufacturing sites) but does not teach:
“when a calculation apparatus that performs a predetermined calculation receives the measurement data and when acquiring first calculated data that is generated from the measurement data.”
(B) Neiman (teaching distributing tasks to computing workers and receiving processed results), however teaches or suggests:
“when a calculation apparatus that performs a predetermined calculation receives the measurement data and when acquiring first calculated data that is generated from the measurement data, corresponding to the first calculated data”
(¶ 111: Once a job 182 is created, a calling application 180 may proceed to schedule computations, with the compute backbone 300, in units called tasks 186. According to one embodiment, a task 186 includes a task input 187 (e.g., an object or structured message) that is accessed by the worker 155 to create a task output 189 (e.g., another object or structured message). The task output 189 may be returned upon successful completion of the computation;
¶ 112: In a synchronous computation mode, a thread in a calling application 180 may first submit to the compute backbone 300 a job 182 containing one or more task 186-1 to 186-N, and then wait for the results of each successive computation;
Fig. 2 and ¶ 59: According to one embodiment, the compute backbone 300 and a corresponding API 190 enables a number of users 20-1 to 20-N each running, for example, a number of different and completely independent calling applications to be processed dynamically on a single pool of distributed processing resources. Such an embodiment of the compute backbone 300 may collect computation requests from calling applications 180-1 to 180-N, invoke those requests on appropriate compute functions or engines (i.e., workers 155-1 to 155-N), assemble results, and return those results to the invoking calling applications 180-1 to 180-N);
“wherein the information management apparatus is capable of transmitting the measurement data to the calculation apparatus by using a common API that performs transmission and reception of data without a need for a dedicated port between the information management apparatus and the calculation apparatus”
(¶ 45: a portion of the API 190 may communicate with both the calling application 180 and the compute backbone 300 in the following manner. First, a calling application 180 may send a request, in C language, for something to be done by the compute backbone 300 (e.g., a request for a computation to be performed or for a result to be retrieved). The API may translate the C language request... send it to the compute backbone 300, which in turn processes the request from the calling application 180;
¶ 47: an object oriented API 190 residing on a local computer 100 provides an interface between a calling application 180 and the compute backbone 300. Such an API 190 may use a transparent communication protocol (e.g., SOAP, XML/HTTP or its variants) to provide communication between calling applications 180-1 to 180-N and the compute backbone 300 infrastructure;
¶ 48: Each API 190 contains a minimal but complete set of operations (to be performed by the compute backbone 300) that supports the job logic of the particular calling application 180, as well as the communication patterns of the local computer 100 on which the calling application 180 is running, such that the API 190 can send computation inputs and retrieve results).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (B) Neiman with those of (A) Bian to distribute processing (computation) tasks to different cloud servers/workers for processing. The motivation or advantage to do so is to allow for the parallel computing/processing of tasks to maximize computing efficiency and resources.
Bian and Neiman do not teach “setting a first virtual device corresponding to the measurement data; and
setting a second virtual device where-in the second virtual device is set, when a calculation apparatus that performs a predetermined calculation receives the measurement data and when acquiring first calculated data that is generated from the measurement data”
(C) Feldpusch, in the context of Bian and Neiman’s teachings, however teaches or suggests implementing:
“setting a first virtual device corresponding to the measurement data; and
setting a second virtual device where-in the second virtual device is set, when a calculation apparatus that performs a predetermined calculation receives the measurement data and when acquiring first calculated data that is generated from the measurement data”
(¶¶ 5–6: receiving a request to connect a first autonomous system (AS) instance with a second AS instance, the first AS instance having a first AS number (ASN) and the second AS instance having a second ASN. A bridge including virtual routers is instantiated within the telecommunications network to facilitate communication between the first AS instance and the second AS instance. In one implementation, the bridge includes each of a first virtual router and a second virtual router that are communicatively coupled …
transmitting traffic between AS instances is provided. The method includes receiving traffic from a first AS instance connected to a first virtual router of a bridge by each of a first Layer 2 connection and a first Layer 3 connection. The traffic is routed within the bridge from the first virtual router to a second virtual router of the bridge, the second virtual router being connected to a second AS instance by each of a second Layer 2 connection and a second Layer 3 connection;
¶ 30: In one implementation, the process of instantiating the bridge 220 and the virtual routers 222, 224 may be facilitated, at least in part, by a controller 280. For example, the controller 280 may receive a request from the customer 206 or other computing device in communication with the controller 280 to connect two or more AS instances, such as region A 210 and region B 212. In response, the controller 280 may execute one or more routines that spin up the bridge 220 (if the bridge 220 does not currently exist), populate the bridge 220 with the appropriate virtual routers, and initialize connection of the virtual routers with themselves and the cloud provider routers 240, 242).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further combine the teachings of (C) Feldpusch with those of (A) Bian and (B) Neiman to deploy virtual routers and bridges to communicate between different cloud hosts, data centers, and/or systems. The motivation or advantage to do so is to provide for the secure connection and transfer/communications of data between cloud computing devices/environments.
9. Regarding claim 2, Neiman and Feldpusch, in combination, teach or suggest:
“when acquiring second calculated data that is generated from the measurement data by the calculation apparatus, SETTING A THIRD VIRTUAL DEVICE corresponding to the second calculated data, and when acquiring third calculated data that is generated from the measurement data by the calculation apparatus, SETTING A FOURTH VIRTUAL DEVICE corresponding to the third calculated data”
(Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.)
10. Regarding claim 3, Feldpusch teaches or suggests:
“generating the first virtual device on a cloud system by using a resource included in the cloud system,
generating the second virtual device on the cloud system by using a resource included in the cloud system”
(¶ 3: purchase resources from a public cloud service to virtualize one or more of their processes and connect to such resources through a telecommunications network;
¶ 29: connections between regions 210, 212 and the virtual bridge 220 may be established on a dynamic, on demand basis).
11. Regarding claim 4, Bian, Neiman, and Feldpusch, in combination, teach or suggest:
“transmitting the measurement data that is associated with the first virtual device to the calculation apparatus by using a common API that is shared between the information management apparatus and the calculation apparatus; and
acquiring calculated data generated by the calculation apparatus by using the common API”
(Neiman — ¶ 22: An IIoT may connect assets, such as turbines, jet engines, locomotives, elevators, healthcare devices, mining equipment, oil and gas refineries, and the like, to the Internet or cloud, or to each other in some meaningful way such as through one or more networks. The cloud can be used to receive, relay, transmit, store, analyze, or otherwise process information for or about assets and manufacturing sites;
¶ 23: Assets may be outfitted with one or more sensors (e.g., physical sensors, virtual sensors, etc.) configured to monitor respective operations or conditions of the asset and the environment in which the asset operates. Data from the sensors can be recorded or transmitted to a cloud-based or other remote computing environment;
¶ 24: The edge-cloud system may be used in conjunction with applications and systems for managing machine and equipment assets and can be hosted within an IIoT;
Fig. 1 and ¶ 29: illustrates a cloud computing system 100 for industrial software and hardware in accordance with an example embodiment. Referring to FIG. 1, the system 100 includes a plurality of assets 110 which may be included within an edge of an IIoT and which may transmit raw data to a source such as cloud computing platform 120 where it may be stored and processed;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.)
12. Regarding claim 5, Bian, Neiman, and Feldpusch, in combination, teach or suggest:
“displaying the first virtual device corresponding to the measurement data and a second virtual device corresponding to the first calculated data, and displaying data that is associated with a virtual device that is selected from the first virtual device and the second virtual device that are displayed”
(Bian — ¶ 32: receive views of data or other information about the asset as the data is processed via one or more applications hosted by the cloud platform 120. For example, the user device 130 may receive graph-based results, diagrams, charts, warnings, measurements, power levels, and the like … the user device 130 may display a graphical user interface that allows a user thereof to input commands to an asset via one or more applications hosted by the cloud platform;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
¶ 96: The administrative GUI 1000 of one embodiment may also enable a user 20 to monitor the status of jobs 182-1 to 182-N deployed and/or running on the node computers 800-1 to 800-N, including the progress of each job 182 and its resource utilization ... authenticated user 20 may be able to cancel or suspend a job 182 through the administrative GUI 1000, as well as change the priority of jobs;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.)
the Examiner notes: it would have been obvious to an ordinary artisan to enable a user to select/filter and display any type of data or information in the cloud computing system to provide greater user control and customization)
13. Regarding claim 6 (independent, similar to claim 1), Bian teaches or suggests:
“an information management apparatus (sending) measurement data … that is collected by a plant apparatus”
(¶ 22: An IIoT may connect assets, such as turbines, jet engines, locomotives, elevators, healthcare devices, mining equipment, oil and gas refineries, and the like, to the Internet or cloud, or to each other in some meaningful way such as through one or more networks. The cloud can be used to receive, relay, transmit, store, analyze, or otherwise process information for or about assets and manufacturing sites;
¶ 23: Assets may be outfitted with one or more sensors (e.g., physical sensors, virtual sensors, etc.) configured to monitor respective operations or conditions of the asset and the environment in which the asset operates. Data from the sensors can be recorded or transmitted to a cloud-based or other remote computing environment;
¶ 24: The edge-cloud system may be used in conjunction with applications and systems for managing machine and equipment assets and can be hosted within an IIoT;
Fig. 1 and ¶ 29: illustrates a cloud computing system 100 for industrial software and hardware in accordance with an example embodiment. Referring to FIG. 1, the system 100 includes a plurality of assets 110 which may be included within an edge of an IIoT and which may transmit raw data to a source such as cloud computing platform 120 where it may be stored and processed;
¶ 40: the sensors can include various types of industrial devices such as imaging, proximity, temperature, switch, chemical, IR, pressure, counter, vibration, etc.);
Bian does not teach “receiving, from an information management apparatus, measurement data … generating first calculated data by performing a predetermined calculation on the measurement data; and transmitting the first calculated data ….
wherein the calculation apparatus is capable of transmitting the first calculated data to the information management apparatus by using a common API that performs transmission and reception of data without a need for a dedicated port between the calculation apparatus and the information management apparatus.”
(B) Neiman (teaching distributing tasks to computing workers and receiving processed results), however teaches or suggests:
“receiving, from an information management apparatus, measurement data …
generating first calculated data by performing a predetermined calculation on the measurement data; and
transmitting the first calculated data … to the information management apparatus”
(¶ 111: Once a job 182 is created, a calling application 180 may proceed to schedule computations, with the compute backbone 300, in units called tasks 186. According to one embodiment, a task 186 includes a task input 187 (e.g., an object or structured message) that is accessed by the worker 155 to create a task output 189 (e.g., another object or structured message). The task output 189 may be returned upon successful completion of the computation;
¶ 112: In a synchronous computation mode, a thread in a calling application 180 may first submit to the compute backbone 300 a job 182 containing one or more task 186-1 to 186-N, and then wait for the results of each successive computation;
Fig. 2 and ¶ 59: According to one embodiment, the compute backbone 300 and a corresponding API 190 enables a number of users 20-1 to 20-N each running, for example, a number of different and completely independent calling applications to be processed dynamically on a single pool of distributed processing resources. Such an embodiment of the compute backbone 300 may collect computation requests from calling applications 180-1 to 180-N, invoke those requests on appropriate compute functions or engines (i.e., workers 155-1 to 155-N), assemble results, and return those results to the invoking calling applications 180-1 to 180-N);
“wherein the calculation apparatus is capable of transmitting the first calculated data to the information management apparatus by using a common API that performs transmission and reception of data without a need for a dedicated port between the calculation apparatus and the information management apparatus”
(¶ 45: a portion of the API 190 may communicate with both the calling application 180 and the compute backbone 300 in the following manner. First, a calling application 180 may send a request, in C language, for something to be done by the compute backbone 300 (e.g., a request for a computation to be performed or for a result to be retrieved). The API may translate the C language request... send it to the compute backbone 300, which in turn processes the request from the calling application 180;
¶ 47: an object oriented API 190 residing on a local computer 100 provides an interface between a calling application 180 and the compute backbone 300. Such an API 190 may use a transparent communication protocol (e.g., SOAP, XML/HTTP or its variants) to provide communication between calling applications 180-1 to 180-N and the compute backbone 300 infrastructure;
¶ 48: Each API 190 contains a minimal but complete set of operations (to be performed by the compute backbone 300) that supports the job logic of the particular calling application 180, as well as the communication patterns of the local computer 100 on which the calling application 180 is running, such that the API 190 can send computation inputs and retrieve results).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of (B) Neiman with those of (A) Bian to distribute processing (computation) tasks to different cloud servers/workers for processing. The motivation or advantage to do so is to allow for the parallel computing/processing of tasks to maximize computing efficiency and resources.
Bian and Neiman do not teach “measurement data that is associated with a first virtual device set by the information management apparatus” and “first calculated data as data that is associated with a second virtual device set by the information management apparatus”
(C) Feldpusch, in the context of Bian and Neiman’s teachings, however teaches or suggests implementing:
“measurement data that is associated with a first virtual device set by the information management apparatus” and
“first calculated data as data that is associated with a second virtual device set by the information management apparatus”
(¶¶ 5–6: receiving a request to connect a first autonomous system (AS) instance with a second AS instance, the first AS instance having a first AS number (ASN) and the second AS instance having a second ASN. A bridge including virtual routers is instantiated within the telecommunications network to facilitate communication between the first AS instance and the second AS instance. In one implementation, the bridge includes each of a first virtual router and a second virtual router that are communicatively coupled …
transmitting traffic between AS instances is provided. The method includes receiving traffic from a first AS instance connected to a first virtual router of a bridge by each of a first Layer 2 connection and a first Layer 3 connection. The traffic is routed within the bridge from the first virtual router to a second virtual router of the bridge, the second virtual router being connected to a second AS instance by each of a second Layer 2 connection and a second Layer 3 connection;
¶ 30: In one implementation, the process of instantiating the bridge 220 and the virtual routers 222, 224 may be facilitated, at least in part, by a controller 280. For example, the controller 280 may receive a request from the customer 206 or other computing device in communication with the controller 280 to connect two or more AS instances, such as region A 210 and region B 212. In response, the controller 280 may execute one or more routines that spin up the bridge 220 (if the bridge 220 does not currently exist), populate the bridge 220 with the appropriate virtual routers, and initialize connection of the virtual routers with themselves and the cloud provider routers 240, 242).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further combine the teachings of (C) Feldpusch with those of (A) Bian and (B) Neiman to deploy virtual routers and bridges to communicate between different cloud hosts, data centers, and/or systems. The motivation or advantage to do so is to provide for the secure connection and transfer/communications of data between cloud computing devices/environments.
14. Regarding claim 7, it is the corresponding computer program product claim reciting similar limitations of commensurate scope as the system of claim 1. Therefore, it is rejected on the same basis as claim 1 above.
15. Regarding claim 8, it is the corresponding computer program product claim reciting similar limitations of commensurate scope as the system of claim 6. Therefore, it is rejected on the same basis as claim 6 above.
16. Regarding claim 9, it is a system claim reciting similar limitations of commensurate scope as the system of claim 1 and 6, in combination. Therefore, it is rejected on the same basis as claims 1 and 6 above, including the following rationale or explanations:
Claim 9 is directed to an “information processing system comprising: an information management apparatus; and a calculation apparatus” elements of which are entirely encompassed in claims 1 and 6, respectively.
17. Regarding claim 10, it is a method reciting similar limitations of commensurate scope as the system of claim 1 and 6, in combination. Therefore, it is rejected on the same basis as claims 1 and 6 above, including the following rationale or explanations:
Claim 10 is directed to a method, steps of which are entirely encompassed in claims 1 and 6, respectively.
Claims 11–20
18. Regarding claim 11, Bian and Feldpusch teach or suggest:
“wherein the second virtual device, the third virtual device and the third virtual device are set each corresponding to different artificial intelligence functions”
(Bian — ¶¶ 17 and 19: Within the system, edge devices and the cloud platform may use machine learning (ML) models (also referred to as artificial intelligence models) to monitor and predict attributes associated with the industrial asset. Often, these models are processed on the cloud based on data that is fed back from edge devices which collect data from sensors on or about the industrial asset. For example, sensors may capture time-series data (temperature, pressure, vibration, etc.) about an industrial asset which can be processed using ML models to identify operating characteristics of the industrial asset that need to be changed. As another example, images may be captured of an industrial asset which can be processed using ML models to identify various image features or regions of interest;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.)
19. Regarding claim 12, Bian and Neiman teach or suggest:
“wherein the calculation apparatus comprises a machine learning model, wherein the machine learning model outputs the first calculated data in response to an input of the measurement data”
(Bian — ¶¶ 17 and 19, as applied in rejecting claim 11 above;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above).
20. Regarding claim 14, Bian teaches or suggests:
“wherein the plant apparatus comprises one of a sensor apparatus, a gateway apparatus, or a control apparatus”
(¶ 18: An industrial site may include multiple sensors and other acquiring systems that capture data of an industrial asset being operated).
B.
21. Claims 13, and 15–20 are rejected under 35 U.S.C. 103 as being unpatentable over (A) Bian in view of (B) Neiman and (C) Feldpusch, as applied to claim 1 above, and further in view of (D) Maturana.
22. Regarding claim 13, Bian, Neiman and Feldpusch do not teach: wherein the plant apparatus is identified among a plurality of plant apparatus by apparatus identification information.
(D) Maturana however teaches or suggests:
“wherein the plant apparatus is identified among a plurality of plant apparatus by APPARATUS IDENTIFICATION INFORMATION”
(¶ 58: header 504 can include a unique customer ID, a site ID representing a particular plant facility, a virtual support engineer ID, a data priority for the data in the compressed data file, a message type, and a process ID;
¶ 59: Message queuing database 420 can include site-specific information regarding what tag data are to be collected ( e.g., data tag identifiers, etc.);
Figs. 6A and 6B and ¶ 21: cloud-based remote monitoring system for displaying tag names and associated values).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to further combine the teachings of (D) Maturana with those of (A) Bian, (B) Neiman, and (C) Feldpusch to incorporate identifying name/tag and metadata to collected plant data. The motivation or advantage to do so is to allow for the collective packaging, storage, processing and visualization of different information across plants.
23. Regarding claim 15, Bian, Neiman, and Maturana teach or suggest:
“wherein the first calculated data is identified by apparatus identification information of the plant apparatus and calculated at a time”
(Bian — ¶ 22, ¶ 23, ¶ 24, see claim 1 above;
Fig. 1 and ¶ 29: illustrates a cloud computing system 100 for industrial software and hardware in accordance with an example embodiment. Referring to FIG. 1, the system 100 includes a plurality of assets 110 which may be included within an edge of an IIoT and which may transmit raw data to a source such as cloud computing platform 120 where it may be stored and processed;
¶ 40: the sensors can include various types of industrial devices such as imaging, proximity, temperature, switch, chemical, IR, pressure, counter, vibration, etc.;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
Maturana — ¶ 58: header 504 can include a unique customer ID, a site ID representing a particular plant facility, a virtual support engineer ID, a data priority for the data in the compressed data file, a message type, and a process ID;
¶ 59: Message queuing database 420 can include site-specific information regarding what tag data are to be collected ( e.g., data tag identifiers, etc.);
Figs. 6A and 6B and ¶ 21: cloud-based remote monitoring system for displaying tag names and associated values;
¶ 62: cloud agent 306 can tag selected subsets of the data with a time indicator specifying a time at which the data was generated).
24. Regarding claim 16, Maturana teaches or suggests:
“indicating a time at which the measurement data is acquired by the plant apparatus”
(¶ 57: intelligent sorting and organizing based on defined criteria, including but not limited to time of occurrence;
¶ 62: cloud agent 306 can tag selected subsets of the data with a time indicator specifying a time at which the data was generated,
Fig. 9 and ¶ 74: FIG. 9 illustrates an exemplary interface display 900 that can be provided by reporting services 318 and that lists tag history by machine section).
25. Regarding claim 17, Bian, Neiman, Feldpusch, and Maturana teach or suggest:
“displaying the measurement data corresponding to the first virtual device and the first calculated data corresponding to the second virtual device, in response to a selected display condition, comprising an APPARATUS IDENTIFICATION NUMBER of the plant apparatus”
(Bian — ¶ 32: receive views of data or other information about the asset as the data is processed via one or more applications hosted by the cloud platform 120. For example, the user device 130 may receive graph-based results, diagrams, charts, warnings, measurements, power levels, and the like … the user device 130 may display a graphical user interface that allows a user thereof to input commands to an asset via one or more applications hosted by the cloud platform;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
¶ 96: The administrative GUI 1000 of one embodiment may also enable a user 20 to monitor the status of jobs 182-1 to 182-N deployed and/or running on the node computers 800-1 to 800-N, including the progress of each job 182 and its resource utilization ... authenticated user 20 may be able to cancel or suspend a job 182 through the administrative GUI 1000, as well as change the priority of jobs;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.;
Maturana — ¶ 58: header 504 can include a unique customer ID, a site ID representing a particular plant facility, a virtual support engineer ID, a data priority for the data in the compressed data file, a message type, and a process ID;
¶ 59: Message queuing database 420 can include site-specific information regarding what tag data are to be collected ( e.g., data tag identifiers, etc.);
Figs. 6A and 6B and ¶ 21: cloud-based remote monitoring system for displaying tag names and associated values;
Figs. 6 to 10 and ¶¶ 72–76, generally teaching an exemplary interface displays that can be provided by reporting services to display an animated graphical representation of a section of an industrial system including collected real-time data, timestamps, and tag name/value).
26. Regarding claim 18, Bian, Neiman, Feldpusch, and Maturana teach or suggest:
“displaying the measurement data corresponding to the first virtual device and the first calculated data corresponding to the second virtual device comprising at least one of the following: presenting the measurement data with its temporal change and presenting the first calculated data with its temporal change.”
(Bian — ¶ 32: receive views of data or other information about the asset as the data is processed via one or more applications hosted by the cloud platform 120. For example, the user device 130 may receive graph-based results, diagrams, charts, warnings, measurements, power levels, and the like … the user device 130 may display a graphical user interface that allows a user thereof to input commands to an asset via one or more applications hosted by the cloud platform;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
¶ 96: The administrative GUI 1000 of one embodiment may also enable a user 20 to monitor the status of jobs 182-1 to 182-N deployed and/or running on the node computers 800-1 to 800-N, including the progress of each job 182 and its resource utilization ... authenticated user 20 may be able to cancel or suspend a job 182 through the administrative GUI 1000, as well as change the priority of jobs;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.;
Maturana — Figs. 6 to 10 and ¶¶ 72–76, generally teaching an exemplary interface displays that can be provided by reporting services to display an animated graphical representation of a section of an industrial system including collected real-time data, timestamps, and tag name/value).
27. Regarding claim 19, Bian, Neiman, Feldpusch, and Maturana teach or suggest:
“displaying the measurement data corresponding to the first virtual device and the first calculated data corresponding to the second virtual device comprising, displaying one of the measurement data corresponding to the first virtual device and the first calculated data corresponding to the second virtual device in a predetermined graph.”
(Bian — ¶ 32: receive views of data or other information about the asset as the data is processed via one or more applications hosted by the cloud platform 120. For example, the user device 130 may receive graph-based results, diagrams, charts, warnings, measurements, power levels, and the like … the user device 130 may display a graphical user interface that allows a user thereof to input commands to an asset via one or more applications hosted by the cloud platform;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
¶ 96: The administrative GUI 1000 of one embodiment may also enable a user 20 to monitor the status of jobs 182-1 to 182-N deployed and/or running on the node computers 800-1 to 800-N, including the progress of each job 182 and its resource utilization ... authenticated user 20 may be able to cancel or suspend a job 182 through the administrative GUI 1000, as well as change the priority of jobs;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.;
Maturana — Figs. 6 to 10 and ¶¶ 72–76, generally teaching an exemplary interface displays that can be provided by reporting services to display an animated graphical representation of a section of an industrial system including collected real-time data, timestamps, and tag name/value).
28. Regarding claim 20, Bian, Neiman, Feldpusch, and Maturana teach or suggest:
“wherein the measurement data corresponding to the first virtual device and the first calculated data corresponding to the second virtual device as displayed, is utilized for at least one of factory production remote monitoring or environmental measurement remote monitoring”
(Bian — ¶ 22: receive, relay, transmit, store, analyze, or otherwise process information for or about assets and manufacturing sites;
¶ 23: Assets may be outfitted with one or more sensors (e.g., physical sensors, virtual sensors, etc.) configured to monitor respective operations or conditions of the asset and the environment in which the asset operates;
¶ 29: Assets 110 may include hardware/structural assets such as machine and equipment used in industry, healthcare, manufacturing;
¶ 32: receive views of data or other information about the asset as the data is processed via one or more applications hosted by the cloud platform 120. For example, the user device 130 may receive graph-based results, diagrams, charts, warnings, measurements, power levels, and the like … the user device 130 may display a graphical user interface that allows a user thereof to input commands to an asset via one or more applications hosted by the cloud platform;
Neiman — ¶ 111, ¶ 112, Fig. 2 and ¶ 59, teaching distributed computation processing using a pool of workers or compute engines, as applied in rejecting claim 1 above;
¶ 45, ¶ 47, and ¶ 48, teaching API requests and communications;
¶ 96: The administrative GUI 1000 of one embodiment may also enable a user 20 to monitor the status of jobs 182-1 to 182-N deployed and/or running on the node computers 800-1 to 800-N, including the progress of each job 182 and its resource utilization ... authenticated user 20 may be able to cancel or suspend a job 182 through the administrative GUI 1000, as well as change the priority of jobs;
Feldpusch — ¶¶ 5–6 and ¶ 30, as applied in rejecting claim 1 above, teaching deploying virtual devices for connecting and exchanging data/communications between cloud providers, regions, devices, etc.;
Maturana — Figs. 6 to 10 and ¶¶ 72–76, generally teaching an exemplary interface displays that can be provided by reporting services to display an animated graphical representation of a section of an industrial system including collected real-time data, timestamps, and tag name/value).
Response to Arguments
29. Applicant’s arguments with respect to the claims have been considered but are moot because the arguments do not apply to any of the newly applied teachings or references being used in the current rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
(a) Alam et al., US 2020/0278666 A1, teaching cloud-based method for optimizing tuning of an industrial plant.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN C WU whose telephone number is (571)270-5906. The examiner can normally be reached Monday through Friday, 8:30 A.M. to 5:00 P.M..
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, Aimee J. Li can be reached on (571)272-4169. 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.
/BENJAMIN C WU/Primary Examiner, Art Unit 2195
June 4, 2026
Prosecution Insights