Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in response to the amendments filed 02/25/2026. Claims 16-20 have been added. Claims 1-20 are currently pending.
Response to Arguments
Applicant’s arguments regarding the prior art rejection have been fully considered but they are not persuasive. Applicant argues on page 8 that the Zornio reference fails to teach providing an environment with a graphical user interface and to execute a control software. Examiner respectfully disagrees and reminds Applicant that the prior art references must be considered in their entireties, i.e., as a whole (see MPEP 2141.02 (VI)), and that the paragraphs cited in the rejection are merely pointed to in order to make clear the most how the reference teaches the corresponding claim limitations. Examiner notes that at least paragraph [0012] of Zornio teaches a computing system, or environment, in which control operations associated with physical processes of a plane or process control system are performed. At least figure 8 and paragraph [0168] of Zornio teach wherein the computing environment also includes a graphical user interface. Examiner notes that paragraph [0167] of Zornio teaches that figure 8 represents an embodiment wherein the data studio is coupled to the process plant network; therefore the graphical user interface is part of the same computing environment as the control operation system. Applicant has not pointed to any particular definitions of an “environment”, a “graphical user interface”, or a “control software” in Applicant’s original disclosure such that the broadest reasonable interpretation of these claim terms would exclude the computing system containing control software and a graphical user interface from Zornio. Therefore, this argument is considered unpersuasive.
Applicant further argues on page 8-9 that Zornio does not teach wherein the control software controls a plurality of physical processes decomposable into physical sub-processes such that the physical sub-processes are combinable into a nonempty set. Examiner respectfully disagrees and notes that at least paragraph [0012] of Zornio teaches that the data being monitored by the computing system is related to physical parameters as well as “any other value that is generated based on the process being controlled in the control plant”. Examiner further notes that at least paragraph [0099] of Zornio is cited in order to show wherein the process plant can control the kind of physical actions taught in at least paragraph [0012] that can subdivided across different regions of the plant to decompose that action into a nonempty set of physical sub-processes. Applicant has not pointed to any particular definitions of an “physical processes” or “sub-processes” in Applicant’s original disclosure such that the broadest reasonable interpretation of these claim terms would exclude the actions associated with physical parameters of actions taken in the control plant from Zornio. Therefore, this argument is considered unpersuasive.
Applicant further argues on pages 9-10 that Zornio does not teach wherein control of the physical processes proceeds indirectly through external software programs through an interface or wherein the control software calls an external software program to control the execution of a physical process. Examiner respectfully disagrees and notes at least paragraph [0015] of Zornio teaches separate control and communication networks associated with physical processes performed by the control plant. At least paragraph [0186] of Zornio teaches wherein programs that are external from the monitoring and analytics functions can be used to implement the controlled physical processes associated with the process control plant. Therefore, this argument is considered unpersuasive.
Applicant further argues on pages 10-11 that Zornio does not teach an environment in which debug points can be placed on actions to defined which physical sub-processes are to be monitored, or wherein a debug point associated with a monitoring function does not stop execution of a controlled physical process. Examiner respectfully disagrees and reminds Applicant of the broadest reasonable interpretation of “physical sub-processes” as explained on page 3 of these remarks. Examiner notes that Applicant has not pointed to any particular definition of a “debug point” such that the broadest reasonable interpretation would exclude the set points from Zornio, which are described in at least paragraph [0096] as “data specifying changes in a process operation, data specifying changes in operating parameters such as setpoints, or records of process”. Examiner notes that paragraph [0007] teaches where these set points can be enabled by an operator in order to display relevant data regarding a monitored physical process. Paragraph [0012] of Zornio is cited to show that monitoring data can occur without performing control operations to show that these set points can be used without stopping execution of their associated controlled physical processes. Therefore, this argument is considered unpersuasive.
Applicant further argues on page 11 that Zornio does not teach wherein sensor data recording observables are stored in memory, or that the sensor data is related to the debug point. Examiner respectfully disagrees and reminds Applicant of the broadest reasonable interpretation of “physical sub-processes” as explained on page 3 of these remarks. Examiner notes that Applicant has not pointed to any particular definitions of “observables” in Applicant’s original disclosure such that the broadest reasonable interpretation of these claim terms would exclude the sensor data related to observed data “that has been directed utilized in or generated from controlling or monitoring a process with the plant” as taught by at least paragraph [0082] of Zornio. At least paragraph [0083] of Zornio teaches where this data can be cached, or stored in memory, and that this data also corresponds to the setpoints, or debug points, utilized by the monitoring system. Therefore, this argument is considered unpersuasive.
Applicant further argues on pages 11-12 that Zornio does not teach wherein each monitoring function is provided by a trained model having access to memory associated with sensor data related to a given debug point, or wherein monitoring functions provide indications in the graphical user interface about the physical state of the monitored physical sub-processes. Examiner respectfully disagrees and reminds Applicant of the broadest reasonable interpretation of “physical sub-processes” as explained on page 3 of these remarks. Examiner notes that claim 1 does not require any particular kind of “trained model” that would exclude the analytic functions taught by Zornio. At least paragraphs [0052] and [0054] of Zornio show that the analytic functions have access to memory and the sensor data “for the equipment they are monitoring”. At least paragraph [0122] of Zornio shows the connection between the monitoring functions and the user interface “to enable the one or more processes to be controlled or monitored in real-time in the process plant”. Applicant has not pointed to any particular definitions of “indications in the graphical user interface” related to the physical state of monitored sub-processes in Applicant’s original disclosure such that the broadest reasonable interpretation of these claim terms would exclude the ability from Zornio to enable process monitoring using a user interface. Therefore, this argument is considered unpersuasive.
Applicant further argues on page 12 that Zornio does not teach wherein a monitoring function associated with a placed debug point monitors sensor data of associated physical sub-processes. Examiner respectfully disagrees and reminds Applicant of the broadest reasonable interpretation of “physical sub-processes” as explained on page 3 of these remarks. Given this interpretation, at least paragraph [0083] of Zornio, combined with the earlier teachings of Zornio, shows that sensor data associated with measurements from physical processes and associated sub-processes can be monitored and that and setpoints, or debug points, can be monitored. Therefore, this argument is considered unpersuasive.
Applicant further argues on page 13 that the Larson reference does not teach wherein control software is determined by a number and type of actions and associations between actions, each action being an elementary building block. Examiner respectfully disagrees and notes that Applicant has not pointed to any particular definition of “actions” or “elementary building blocks” that would exclude the function blocks from Larson, which are used to perform control functions, or actions, as taught by at least columns 6-7.
Examiner notes that Applicant’s arguments on pages 14-15 appear to recite multiple alleged claim elements that are not recited in claim 1, including at least the arguments alleged that the cited references to not disclose or suggest “implementing monitoring functions as trained machine learning models”, “pairing trained models with debug points placed on software actions”, “training models to detect physical state or anomalies”. Applicant alleges that the claimed system provides “a pre-configured mapping architecture”, “sensor data are automatically stored with metadata linking the data to the specific debug point”, “automatic provision of debug-point-specific sensor data to trained models”. These elements are not recited in claim 1 and Applicant has not shown if these elements are meant to reference any particular dependent claims. Therefore, these arguments are considered unpersuasive.
Lastly, Applicant alleges on pages 15-16 that “there is no apparent motivation in the cited references to make such a combination, nor any teaching or suggestion that would lead a person of ordinary skill in the art to arrive at the claimed invention. Examiner notes that Applicant merely points to allegedly novel elements not clearly recited in the claims and states that these elements are not taught by the cited prior art, but does not address the combination as provided on page 12 of the office action dated 12/23/2025. Therefore, this argument is considered unpersuasive.
Examiner notes the new grounds of rejection required by Applicant’s amendments. Newly amended claim 17 is rejected under Zornio in view of Larson in further view of Pokrajac, and newly amended claim 18 is rejected under Zornio in view of Larson in further view of Bodik. The prior art rejections have been updated to include the amended limitations and to clarify the reasoning given for the limitations that were not amended.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 20 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 20 recites the limitation “wherein the subset of physical sub-processes to be monitored is automatically determined from the pre-stored associations when the debug point is placed on the action”. Examiner notes that while page 7 of Applicant’s specification recites “If a set of pre-defined actions are available to a user, the association of which physical sub-processes 5a, 5b are influenced by which action may be pre-stored on the computing unit on which the control software is executed”, Applicant’s original disclosure does not support automatically determining a subset of physical sub-processes to be monitored when placing a debug point on an action. For purposes of examination, Examiner is interpreting that a pre-defined action and associated physical sub-processes can be pre-stored on a computing unit as described on page 7 of Applicant’s specification.
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.
Claims 1-6, 9-10, and 12-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Zornio et al (US 20160098037 A1, herein Zornio) in view of Larson et al (US 6044305 A, herein Larson).
Regarding claim 1, Zornio teaches a computer program product on a non-transitory medium comprising instructions, which, when the program is executed by a computing unit, cause the computing unit to provide an environment with a graphical user interface to a user and to execute a control software in the environment (para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant includes forming and installing one or more data pipelines within various interconnected devices of the process plant or process control system, wherein the data pipelines automatically collect and process data in predetermined manners to perform partial or complete data analysis” (i.e., executing control software in environment)). Fig. 8 and para. [0168] recite “the configuration engine 523 includes an interface routine 525 to generate elements of a graphic user interface for the structured environment, a plurality of templates 529 that serve as the building blocks of the data pipelines and a compiler 527 that converts the model into a data format executable by the run-time engine 524” (i.e., a graphical user interface)), wherein the control software controls a plurality of physical processes, wherein each controlled physical process is decomposable into at least one physical sub-process, the physical sub-processes of the controlled physical processes combinable into a nonempty set of physical sub-processes (para. [0012] recites “The data on which signal processing is performed by the data pipeline architecture may be, for example, indicative of a value over time of an output signal of a process control device, a process variable, a measurement of a physical parameter such as temperature, pressure, flow rate, etc., a balance of energy, a balance of mass, a performance parameter, an output of an analytics function, and/or any other value that is generated based on the process being controlled in the process plant” (i.e., physical processes which can be controllable). Para. [0099] recites “a process plant may have a first region that receives raw materials and produces a first intermediate product, a second region that receives other raw materials and produces a second intermediate product, and a third region that receives the first and second intermediate products to produce an output product. Each of these three different example regions may be serviced by a respective "regional" big data node 106a, 106b, 106m to operate on big data produced by its respective region” (i.e., physical processes associated with a plant can be decomposable into sub-processes)),
the control of the physical processes by the control software proceeds indirectly through external software programs, each external software program providing an interface through which at least one of the actions of the control software may communicate with the respective external software, wherein the control software calls at least a first external software program to control execution of a first physical process (para. [0015] recites “a data pipeline runs or extends through various (e.g., two or more) communication networks within or associated with a process plant including a process control network and a further communication network. More particularly, a plant communication system for use within a process plant environment that implements a process includes a process control network including a multiplicity of process control devices disposed within the process plant to control the process and a process control communication network communicatively coupled to the multiplicity of process control devices, wherein one or more of the multiplicity of process control devices collects or generates process control data”. Para. [0124] recites “a user interface device 130 may have one or more built-in analytic capabilities (denoted in FIG. 4 by the encircled Az) In other words, a user interface device 130 may communicate with any number of big data nodes and/or big data appliances to download and/or receive data and perform local analysis Az, on the downloaded/received data to discover or learn knowledge and may do so a part of a data pipeline or by connecting to a data pipeline”. Para. [0186] recites “the monitoring and analytics engines, algorithms, and data pipelines described herein can be run external to the distributed control systems (DCSs), asset management systems, and existing machine health systems of a typical process control plant or network” (i.e., control devices may interface for communication with outside, or external systems to control physical processes))
the environment enables the user to place a debug point [on each action] to which a nonempty subset of the set of physical sub-processes is associated to define which physical sub-processes from the set of physical sub-processes are to be monitored, wherein a monitoring function is associated to each debug point (para. [0007] recites “The configuration application may also allow a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality”. Para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., a set, or debug, point placed by a user is associated with a particular physical process or sub-process)),
and the debug point does not stop the execution of the controlled physical processes (para. [0012] recites “the data pipeline architecture may process other types of data than process control data, such as monitoring data (produced by a monitoring system that does not perform control), device data indicative of device operational parameters, maintenance data used by maintenance personnel to service, repair and replace devices within a network, communication data, etc.” Para. [0083] recites “real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected. Other examples of real-time data may include process models, statistics, status data, and network and plant management data” (i.e., set or debug points do not need to control, or stop the execution of a monitored process)),
and wherein sensor data recording observables are stored in a memory, which observables depend on a subset of the set of physical sub-processes associated to one of the debug points, wherein the sensor data are stored in such a way in the memory that the stored sensor data are relatable to the debug point (para. [0082] recites “process control big data that is generated, collected, observed, and/or forwarded by provider nodes may include data that has been directly utilized in or generated from controlling or monitoring a process within the plant, e.g., first-order real time and configuration data that is generated or used by process control devices such as controllers, input/output (I/O) devices, and field devices such as transmitters, sensors, etc.” (i.e., sensor data related to a specific sub-process). Para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected. Other examples of real-time data may include process models, statistics, status data, and network and plant management data” (i.e., sensor data and associated set point information can be stored in memory). Para. [0089] recites “Returning again to FIG. 4, the process control big data network 100 may include process control big data provider nodes 102-110 that operate at various levels, tiers, or orders with respect to first-order or primary process related data that is directly generated, routed, and/or used by process control devices such as controllers, I/O devices, field devices, etc. At the lowest order, tier, or level, "local" big data provider nodes or devices 102a-102n that operate nearest to the process to collect, generate, observe, and/or forward primary process big data related to the input, operation, and output of process devices and equipment in the process plant” (i.e., set points can be associated with and associated monitoring nodes, or functions which can be stored in and accessed via memory));
each monitoring function is provided by a trained model having access to those parts of the memory that comprise sensor data related to the debug point to which the respective monitoring function is associated (para. [0124] recites “a user interface device 130 may have one or more built-in analytic capabilities (denoted in FIG. 4 by the encircled Az) In other words, a user interface device 130 may communicate with any number of big data nodes and/or big data appliances to download and/or receive data and perform local analysis Az on the downloaded/received data to discover or learn knowledge and may do so a part of a data pipeline or by connecting to a data pipeline”. Para. [0052] recites “The embedded analytics engines 36a-36n cache the data and begin processing locally in real-time, and the embedded analytics engines 36a-36n may include both learning and runtime execution capability. Once trained, the embedded analytics modules 36a-36n could then be downloaded where they would then be used to monitor the process, assets, and equipment.” Para. [0054] recites “the embedded analytics could begin identifying leading indicators for the equipment they are monitoring and then work with other embedded analytics engines to identify the parameters that have the greatest impact on those leading indicators. Once trained, the embedded analytics modules 36a-36n could then be downloaded where they would then be used to monitor the process, assets, and equipment. A unique feature is that the analytics engines 36a-36n can continuously learn in a manner defined by a data pipeline, and such learning could be cached for consideration at a later date at any of the big data devices or nodes” (i.e., monitoring functions can be associated with trained analytics models that can access downloaded process sensor data, or data from memory, associated with a specified monitored process)),
wherein each monitoring function provides an indication in the graphical user interface about a physical state of the subset of the set of physical sub-processes associated to the debug point to which the monitoring function is associated (para. [0089] recites “"local big data provider nodes or devices" 102a-102n typically are nodes and/or devices that generate, route, and/or receive primary process control data or monitoring data (from a process monitoring system) to enable the one or more processes to be controlled or monitored in real-time in the process plant. Examples of local big data provider nodes 102a-102n include devices whose primary function is directed to generating and/or operating on process control data to control a process, e.g., wired and wireless field devices, controllers, and I/O devices” (i.e., the physical state of processes and subprocesses can be monitored by monitoring nodes, or functions). Para. [0122] recites “typically, big data nodes or devices 102-110 do not have an integral user interface, although some of the big data nodes or devices 102-110 may have the capability to be in communicative connection with one or more user interface devices 130, e.g., by communicating over a wired or wireless communication link, or by plugging a user interface device 130 into a port of the big data nodes or devices 102-110. In FIG. 4, the user interface device 130 is depicted a big data node that is wirelessly connected to the process control big data network 100 “ (i.e., monitoring functions and associated set points can be shown using a graphical user interface));
and the monitoring function associated to the placed debug point monitors the senor data provided by the sensors recording observables of the physical sub-processes associated to [the action on which] the debug point is placed (para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., monitoring nodes, or functions, can record, or store, raw sensor data associated with the physical processes associated with a set, or debug point)).
However, while Zornio teaches monitoring physical processes (see at least paragraph [0012]), Zornio does not explicitly teach wherein the controlled physical process comprises actions and is determined by a number and type of actions and associations between the actions, each action being an elementary building block.
Larson teaches wherein the controlled physical process comprises actions and is determined by a number and type of actions and associations between the actions, each action being an elementary building block (col. 6 line 66 – col. 7 lines 8 recite “Fieldbus devices are, therefore, capable of directly implementing portions of an overall control strategy which, in the past, were performed by a centralized digital controller of a DCS (i.e., distributed control system). To perform control functions, each Fieldbus device includes one or more standardized "blocks" which are implemented in a microprocessor within the device. In particular, each Fieldbus device includes one resource block, zero or more function blocks, and zero or more transducer blocks. These blocks are referred to as block objects” (i.e., the control software comprises blocks associated with actions and associations of the control software)),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine these teachings by using the software control blocks from Larson to implement the physical plant processes from Zornio. Zornio and Larson are both directed to methods of monitoring and debugging physical systems. One of ordinary skill in the art would understand that the known methods from Larson could be used to improve the similar method from Zornio, as Larson notes in col. 4 line 65 – col 5 line 1 “the debugging and tuning method and apparatus of the present invention can be used in any process control network that performs distributed control functions even if this process control network uses the HART, PROFIBUS, etc. communication protocols or any other communication protocols that now exist or that may be developed in the future”, and Zornio teaches in paragraph [0172] that its data templates “can implement or define any basic or unitary functionality to be performed on data”.
Regarding claim 2, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein a debug point on an action allows for monitoring the physical state of the subset of the set of physical sub-processes associated to the debug point (Zornio para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., monitoring the physical state of a physical process associated with a set, or debug, point)),
wherein the monitored sub-processes comprise sub-processes belonging to physically remote physical processes, wherein the monitoring provides information about the joint physical state of the monitored sub-processes (Larson col. 1 lines 35-44 recite “As is known, a DCS includes an analog or a digital computer, such as a programmable logic controller, connected to numerous electronic monitoring and control devices, such as electronic sensors, transmitters, current-to-pressure transducers, valve positioners, etc. located throughout a process. The DCS computer stores and implements a centralized and, frequently, complex control scheme to effect measurement and control of process parameters according to some overall control scheme” (i.e., the sub-processes are physically remote and can be monitored to determine a centralized or joint state of all sub-processes)).
Regarding claim 3, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein a monitoring function associated to at least one debug point is configured to provide anomaly detection on the stored data associated to the debug point, wherein anomalies in the stored data are identified by the monitoring function, the anomalies relating to physical changes in the subset of the set of physical sub-processes associated to the debug point (Zornio para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected”. Zornio para. [0047] recites “individual data pipelines may be wrapped in analytics modules which may be tagged, distributed, and used for generating predictions, specialized visualizations, alarms and alerts within a plant control or monitoring setting”. Para. [0054] recites “Each data pipeline may be hosted by a module that includes alarms/alerts and that may manually adjustable alarm limits, for example” (i.e., using a monitoring function to identify alerts, or anomalies, associated with set, or debug, points)).
Regarding claim 4, the combination of Zornio and Larson teaches the computer program product according to claim 3, wherein the monitoring function implements an online unsupervised anomaly detection algorithm (Zornio para. [0077] recites “Each process control big data node or device 102-110 is connected to a process control system big data network backbone (not shown), and may use the backbone to communicate with one or more other process control big data nodes. Accordingly, the process control big data network 100 comprises the process control system big data network backbone and the process control big data nodes 102-110 that are communicatively connected thereto. In an example, the process control big data network 100 includes a plurality of networked computing devices or switches that are configured to route packets to/from various other devices, switches or nodes of the network 100 via the backbone. As will be described in more detail, one or more data pipelines may be implemented within the various devices, nodes, etc. of the big data network 100 to perform data processing and supervised or unsupervised learning on data generated within, collected within or otherwise available at the various nodes 102-110 of the big data network 100” (i.e., a monitoring function that includes an online unsupervised anomaly detection algorithm)), wherein the monitoring function operates on the stream of sensor data recording observables which depend on the subset of the set of physical sub-processes associated to the debug point to which the monitoring function is associated (Zornio para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., monitoring sensor data associated with the physical process associated with the set, or debug, point)).
Regarding claim 5, the combination of Zornio and Larson teaches the computer program product according to claim 3, wherein the monitoring function implements a rule-based anomaly detection algorithm, wherein the monitoring function operates on the stream of sensor data recording observables which depend on the subset of the set of physical sub-processes associated to the debug point to which the monitoring function is associated, wherein the rules are adapted to the action on which the debug point is placed (Larson col. 15 lines 44-50 recite “breakpoints or single-step stopping points may be located at a device and occur when the device operates within the process control scheme, may be located between the different process control functions, such as between the function blocks, of a process control loop and/or may be located within an algorithm making up any particular process control function”. Larson col. 15 lines 60-67 recites “any of the breakpoints, single-step stopping points or tuning procedures may have one or more conditions associated therewith which, when met, cause the algorithm or the process control network to cease operation and, if not met, cause the process control scheme to continue without interruption. The condition may be associated with the value of some variable, a time, or any other desired condition” (i.e., a rule based anomaly detection algorithm which determines when a given physical sub-process reaches a state associated with a given condition or rule)).
Regarding claim 6, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein actions are associated to each other via a graph, wherein a debug point is represented by a pin placed on an action (Larson col. 17 lines 2-18 recite “A block 110, which may be implemented by software within a host device having a user interface, the location of and other data associated with each of the desired breakpoints is set using, for example, asynchronous communications over the bus 34. Breakpoints may be set at an instruction level (step 112), in which the execution of a particular instruction within a device or a function block of a device causes a break condition to be examined, at a function block level (step 114), in which data flow to or from a particular function block or the execution of a function block of a process control loop causes a break condition to be examined, and/or at a device level (step 116), in which data flow to or from a device or operation of a device causes a break condition to be examined. Of course, multiple breakpoints may be set and different breakpoints may be set at different instruction, function block and device levels.” (i.e., debug points can be indicated visually on a user interface)).
Regarding claim 9, the combination of Zornio and Larson teaches a method for monitoring the behavior of at least one physical sub-process using the computer program product according to claim 1,
further comprising placing a debug point with a paired monitoring function on an action to which is associated the at least one physical sub-process, and providing information about the behavior of the at least one physical sub-process with the monitoring function by analyzing the sensor data recording observables which are related to the at least one physical sub-process associated to the debug point (Zornio para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., monitoring event, or behavior, information via set, or debug, points related to physical processes which are associated with received sensor data)).
Regarding claim 10, the combination of Zornio and Larson teaches a computer program product according to claim 1, wherein assembling the control software comprises assembling actions via drag-and-drop operations from a list of available actions (Zornio fig. 8 and para. [0168] recite “the configuration engine 523 includes an interface routine 525 to generate elements of a graphic user interface for the structured environment, a plurality of templates 529 that serve as the building blocks of the data pipelines and a compiler 527 that converts the model into a data format executable by the run-time engine 524”. Zornio para. [0169] recites “The interface routine 525 includes a set of instructions stored in memory that when, executed by a processor, generates a set of user interface elements of a drag and drop graphical user interface to facilitate creation of the data pipeline including a library region 525a that displays the templates 529 and a canvas region 525b that serves as the main presentation window for creating models” (i.e., the user can graphically assemble software using drag and drop operations from a library, or list of options)).
Regarding claim 12, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein the control software calls at least a first external software program to control the execution of a first physical process and a second external software program to control the execution of a second physical process (Zornio para. [009] recites “While the analytic engines 36a-36n may be implemented in controllers, field devices, gateway devices, etc., these engines may also or instead be implemented in standalone processing devices that, for example, implement big data machines. The analytic engines 36a-36n may be connected together via a streaming protocol bus 37 and may be connected to various ones of the control devices 14, 16, 18, of the control system 12, to the monitoring devices 20, 24 or to other devices within the system, such as the spectrum analyzer 24 via various different buses or communication networks which may use the same or different communication protocols” (i.e., separate physical processes can be executed by the control software)).
Regarding claim 13, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein the monitoring is unsupervised monitoring, provided by a model configured to detect changes or outliers in the sensor data on which it operates (Zornio fig. 3 and para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant”. Zornio para. [0063] recites “Modules that may be included in the data pipeline include, for example, data selection and/or data cleaning modules, data alignment modules, sensitivity analysis modules, causality analysis modules, supervised learning modules and unsupervised learning modules” (i.e., using an unsupervised model to detect abnormalities, or outliers, in sensor data)).
Regarding claim 14, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein the monitoring is supervised monitoring, provided by a model that has been trained to detect abnormal behavior of the monitored physical sub-processes (Zornio fig. 3 and para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant”. Zornio para. [0063] recites “Modules that may be included in the data pipeline include, for example, data selection and/or data cleaning modules, data alignment modules, sensitivity analysis modules, causality analysis modules, supervised learning modules and unsupervised learning modules” (i.e., using a supervised model to detect abnormalities, or outliers, in monitored processes)).
Regarding claim 15, the combination of Zornio and Larson teaches the computer program product according to claim 14, wherein examples of typical failures and normal behavior of the physical sub-processes associated to a monitored action are gathered for the supervised monitoring (Zornio para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant”. Zornio para. [0013] recites “The data processing pipeline may perform data processing operations including, for example, data collection, data selection and cleaning, data alignment, sensitivity analysis, causality analysis, supervised learning, and/or unsupervised learning” (i.e., supervised monitoring can be used to determine normal behavior and typical failures of a given process)).
Regarding claim 16, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein the monitoring function is configured to provide anomaly detection on the stored data associated to the debug point by implementing an online unsupervised anomaly detection algorithm that operates on a stream of the sensor data recording observables which depend on the subset of the set of physical sub-processes associated to the debug point to which the monitoring function is associated (Zornio para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant”. Zornio para. [0077] recites “Each process control big data node or device 102-110 is connected to a process control system big data network backbone (not shown), and may use the backbone to communicate with one or more other process control big data nodes. Accordingly, the process control big data network 100 comprises the process control system big data network backbone and the process control big data nodes 102-110 that are communicatively connected thereto. In an example, the process control big data network 100 includes a plurality of networked computing devices or switches that are configured to route packets to/from various other devices, switches or nodes of the network 100 via the backbone. As will be described in more detail, one or more data pipelines may be implemented within the various devices, nodes, etc. of the big data network 100 to perform data processing and supervised or unsupervised learning on data generated within, collected within or otherwise available at the various nodes 102-110 of the big data network 100” (i.e., monitoring sensor data related to physical subprocesses using online unsupervised algorithm for detecting abnormal events, or anomalies). Zornio para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., the monitored sensor data is associated with a debug point)), wherein anomalies in the stored data are identified by the monitoring function, the anomalies relating to physical changes in the subset of the set of physical sub-processes associated to the debug point (Zornio para. [0008] recites “In a process plant or process control system or other monitoring system, when evidence of an abnormal condition or fault occurs (e.g., when an alarm is generated, or when a process measurement or actuator is found to have excessive variation), an operator, instrument technician or process engineer typically uses an analytics tool in combination with his or her knowledge of the process being controlled by the system and its flow path through the system to attempt to determine upstream measurements and process variables that may have contributed to the production of the evidence of the abnormal condition or fault”. Zornio para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant” (i.e., determined anomalies are related to physical changes, such as process measurements, in the processes monitored by debug points)).
Regarding claim 19, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein a set of pre-defined actions are available to the user for assembling the control software, wherein associations defining which physical sub-processes are influenced by which action are pre-stored on the computing unit on which the control software is executed (Zornio para. [0012] recites “wherein the data pipelines automatically collect and process data in predetermined manners to perform partial or complete data analysis” (i.e., pre-determined, or pre-defined actions). Zornio para. [0046] recites “data processing and knowledge learning techniques may be automatically or autonomously implemented within a plant network with the use of one or more data pipelines which, through their operation, implement specific actions on data that is collected, generated or measured within the plant to thereby enable perform specific types of higher level data processing and learning. Each data pipeline defines a series of operations or functions to be performed on a particular set of data or sets of data in a particular (e.g. , fixed) order to thereby perform some overall processing that leads to knowledge about the plant or learning within the plant. In other words, each data pipeline implements a series of predetermined data processing functions in a particular, predefined order, to perform or implement one or more data models and/or to implement data learning within the plant”. Zornio para. [0061] recites “cases, the data pipelines may themselves be analytic modules that are generally distributed in the plant 10 to process data streams in known or predetermined manners to make new data or new types of data available for use or processing by other analytic modules or for consumption by a user. A particular data pipeline, once installed in a plant, may be used by more than one analytic module to perform different types of analytics on the same data or using the same data” (i.e., actions and associated physical processes and sub-processes can be pre-stored and used repeatedly)).
Regarding claim 20, the combination of Zornio and Larson teaches the computer program product according to claim 19, wherein the subset of physical sub-processes to be monitored is automatically determined from the pre-stored associations when the debug point is placed on the action (Zornio para. [0012] recites “wherein the data pipelines automatically collect and process data in predetermined manners to perform partial or complete data analysis”. Zornio para. [0046] recites “data processing and knowledge learning techniques may be automatically or autonomously implemented within a plant network with the use of one or more data pipelines which, through their operation, implement specific actions on data that is collected, generated or measured within the plant to thereby enable perform specific types of higher level data processing and learning. Each data pipeline defines a series of operations or functions to be performed on a particular set of data or sets of data in a particular (e.g. , fixed) order to thereby perform some overall processing that leads to knowledge about the plant or learning within the plant. Zornio para. [0061] recites “cases, the data pipelines may themselves be analytic modules that are generally distributed in the plant 10 to process data streams in known or predetermined manners to make new data or new types of data available for use or processing by other analytic modules or for consumption by a user” (i.e., Examiner notes that this limitation is interpreted in light of the 112(a) rejection such that a pre-defined action and associated physical sub-processes can be pre-stored on a computing unit. Given this interpretation, Zornio teaches that a set of actions related to physical processes and associated sub-processes can be pre-determined and automatically monitored)).
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Zornio et al (US 20160098037 A1, herein Zornio) in view of Larson et al (US 6044305 A, herein Larson), in further view of Hoernicke et al (US 9471044 B2, herein Hoernicke).
Regarding claim 7, the combination of Zornio and Larson teaches the computer program product according to claim 6.
However, the combination of Zornio and Larson does not explicitly teach wherein upon the detection of an anomaly associated to a debug point, a visual change in the pin representing the debug point is displayed in the graphical user interface.
Hoernicke teaches wherein upon the detection of an anomaly associated to a debug point, a visual change in the pin representing the debug point is displayed in the graphical user interface (col. 5 lines 20-38 recite “herein changed signals, parameters, process parts, plant parts, domain parts or other related parts, and/or their impact are highlighted, whereas affected signals, parameters, process parts, plant parts, domain parts, states or other impacted parts are posted and highlighted to the user, e.g. in a display, and advantageously documenting the changes and the impact automatically by tracking online values and/or engineering changes. Likewise an exemplary embodiment of the present disclosure provides that dependencies and/or links between signals or parameters are automatically gathered and visualized to the user by means of a color scheme or filter functionality. Furthermore according to another exemplary embodiment of distributed control system architecture in accordance with disclosed herein separated plant parts as well as their dependencies and links and their application domains are visualized to the user whereas breakpoints are enabled according to the application domain conditions, which interrupt multiple applications domains together” (i.e., changes to a process associated with a breakpoint or debug point can be indicated by a visual change on the user interface)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine these teachings by the methods of modifying components of a user interface from Hoernicke to the user interface used to monitor physical processes from Zornio (as modified by Larson). Hoernicke and Zornio are both directed to data processing and analysis systems. One of ordinary skill in the art would be motivated to combine these methods as Hoernicke teaches in column 3 lines 62-65 that “The information can be retrieved by means of data interfaces to these control sub-systems” such as the data interface taught by Zornio, and Zornio teaches in paragraph [0172] that its data templates “can implement or define any basic or unitary functionality to be performed on data”.
Regarding claim 8, the combination of Zornio and Larson teaches the computer program product according to claims 6.
However, the combination of Zornio and Larson does not explicitly teach wherein different graphical forms of the pin representing the debug point are associated to different monitoring functions.
Hoernicke teaches (col. 6 lines 53-62 recites “FIG. 3 illustrates a plant wide signal tree across different control sub-systems in accordance with an exemplary embodiment of the present disclosure. Namely, FIG. 3 depicts the invented plant wide debugging system, presenting a signal tree across different control sub-systems in a hierarchical view on the plant solution. Each relevant signal is visible to the engineer and available for debugging. For each signal, a list of parameters with online values is shown. As presented, process signal of different domains (PLC, robot etc.) are shown” Hoernicke col. 7 lines 5-12 recite “the depicted signal tree allows determination of signals, which are part of the PWCBP: the signal of the safety door (door_open at the safety PLC) and the overall plant state (plant_running at the cell PLC) and the robot state (robot_inwork at the robot control). For each of these signals, the breakpoint conditions are defined (door_open=true AND plant_running=true AND robot_inwork=true )” (i.e., different debug points are visually associated with different monitoring functions on the user interface)).
See claim 7 for motivation to combine.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Zornio et al (US 20160098037 A1, herein Zornio) in view of Larson et al (US 6044305 A, herein Larson), in further view of Witkos et al (US 20160334201 A1, herein Witkos).
Regarding claim 11, the combination of Zornio and Larson teaches the computer program product according to claim 1.
However, the combination of Zornio and Larson does not explicitly teach wherein a subset of physical processes related to the movement of a coordinate measuring machine.
Witkos teaches a subset of physical processes related to the movement of a coordinate measuring machine (para. [0006]-[0007] recite “the sensing information includes information relating to at least one of temperature, vibration, humidity, pressure, light, and composition of fluid in vicinity of coordinate measuring machine. To that end, in various embodiments, the coordinate measuring machine includes at least one of a temperature sensor, inertial sensor, humidity sensor, pressure sensor, light sensor, and air sensor. In some embodiments, controlling the coordinate measuring machine includes measuring the object using the coordinate measuring machine, while in some embodiments controlling the coordinate measuring machine to measure the object a second time” (i.e., a subset of physical processes performed by coordinate measuring machine)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine these teachings by utilizing the monitoring and analytics system from Zornio (as modified by Larson) to monitor and analyze operations associated with the control system from Witkos used to operate a coordinate measuring machine. Zornio teaches in at least paragraph [0012] that its monitoring and analytics system can be applied to sensors related to physical parameters such as “temperature, pressure. . .or any other value that is generated based on the process being controlled”. Witkos teaches in at least paragraph [0006] that its coordinate measuring machine includes sensors such as “a temperature sensor, inertial sensor, humidity sensor, pressure sensor, light sensor, and air sensor”. Accordingly, one of ordinary skill would understand that the sensors from the coordinate measuring machine from Witkos could be monitored and analyzed using the system from Zornio.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Zornio et al (US 20160098037 A1, herein Zornio) in view of Larson et al (US 6044305 A, herein Larson), in further view of Pokrajac et al* (“Incremental Local Outlier Detection for Data Streams”, here Pokrajac).
*a copy of this document was provided with the IDS dated 01/20/2021
Regarding claim 17, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein the monitoring function is configured to provide anomaly detection on the stored data associated to the debug point by implementing an online unsupervised anomaly detection algorithm [comprising an incremental local outlier factor algorithm] that operates on a stream of the sensor data recording observables which depend on the subset of the set of physical sub-processes associated to the debug point to which the monitoring function is associated (Zornio para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant”. Zornio para. [0077] recites “Each process control big data node or device 102-110 is connected to a process control system big data network backbone (not shown), and may use the backbone to communicate with one or more other process control big data nodes. Accordingly, the process control big data network 100 comprises the process control system big data network backbone and the process control big data nodes 102-110 that are communicatively connected thereto. In an example, the process control big data network 100 includes a plurality of networked computing devices or switches that are configured to route packets to/from various other devices, switches or nodes of the network 100 via the backbone. As will be described in more detail, one or more data pipelines may be implemented within the various devices, nodes, etc. of the big data network 100 to perform data processing and supervised or unsupervised learning on data generated within, collected within or otherwise available at the various nodes 102-110 of the big data network 100” (i.e., monitoring sensor data related to physical subprocesses using online unsupervised algorithm for detecting abnormal events, or anomalies). Zornio para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., the monitored sensor data is associated with a debug point)), wherein anomalies in the stored data are identified by the monitoring function, the anomalies relating to physical changes in the subset of the set of physical sub-processes associated to the debug point (Zornio para. [0008] recites “In a process plant or process control system or other monitoring system, when evidence of an abnormal condition or fault occurs (e.g., when an alarm is generated, or when a process measurement or actuator is found to have excessive variation), an operator, instrument technician or process engineer typically uses an analytics tool in combination with his or her knowledge of the process being controlled by the system and its flow path through the system to attempt to determine upstream measurements and process variables that may have contributed to the production of the evidence of the abnormal condition or fault”. Zornio para. [0012] recites “A system and method for providing distributed signal processing-based data processing and analysis to determine, for example, potential sources of faults, abnormal operations, and/or variations in the behavior of signals generated by controlling a process in a process plant” (i.e., determined anomalies are related to physical changes, such as process measurements, in the processes monitored by debug points)).
However, while the combination of Zornio and Larson teaches unsupervised anomaly detection algorithm that operates on a stream of the sensor data (see at least paragraphs [0012], [0077], and [0083] of Zornio), the combination of Zornio and Larson does not explicitly teach an unsupervised anomaly detection algorithm comprising an incremental local outlier factor algorithm that operates on a stream of the sensor data.
Pokrajac teaches unsupervised anomaly detection algorithm comprising an incremental local outlier factor algorithm that operates on a stream of the sensor data (section I para. 4 recites “we propose a novel incremental LOF (i.e., local outlier factor) algorithm that is appropriate for detecting outliers in data streams” (i.e., a local outlier factor algorithm operating on a sensor data stream)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine these teachings by modifying or substituting the unsupervised learning method from Zornio (as modified by Larson) with the incremental local outlier factor algorithm from Pokrajac. Zornio and Pokrajac are both directed to methods of monitoring data streams related to physical processes. At least paragraph [0075] of Zornio states “block 92 may perform unsupervised learning by applying analytic modeling, such as PCA and SVD modeling, by performing data clustering, K-means, k-NN, decision trees, bagging, boosting, random forest, conditional Bayesian probability analyses, etc. Of course, these are just a few examples of the types of processing that can occur or that can be implemented in each of the blocks 87-92 in a data pipeline and many other types of data processing can be applied as well or instead”. One of ordinary skill in the art would recognize that the types of unsupervised learning in Zornio could also include the incremental local outlier factor algorithm from Pokrajac.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Zornio et al (US 20160098037 A1, herein Zornio) in view of Larson et al (US 6044305 A, herein Larson), in further view of Bodik et al (US 20130212277 A1, herein Bodik).
Regarding claim 18, the combination of Zornio and Larson teaches the computer program product according to claim 1, wherein memory can be used to store sensor data associated to the debug point (Zornio para. [0007] recites “The configuration application may also allow a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller and, in some cases, one or more field devices, stores and executes a respective controller application that runs the control modules assigned and downloaded thereto to implement actual process control functionality”. Zornio para. [0083] recites “A big data provider node may, in some embodiments, also include high-density memory for the caching of the real-time big data. Examples of real-time data that may be transmitted, received, streamed, cached, collected, and/or otherwise observed by big data provider nodes may include process control data such as measurement data, configuration data, batch data, event data, monitoring data, maintenance data (such as that collected by or generated by maintenance devices, algorithms, procedures, etc.) and/or continuous data. For instance, real-time data corresponding to configurations, batch recipes, setpoints, outputs, rates, control actions, diagnostics, alarms, events and/or changes thereto may be collected” (i.e., sensor data associated with a debug point can be stored in memory)).
However, the combination of Zornio and Larson does not explicitly teach wherein the computing unit dynamically allocates memory for storing data in an ongoing manner during execution of an action, wherein an amount of memory allocated depends on a length of execution time of the action.
Bodik teaches wherein the computing unit dynamically allocates memory for storing data in an ongoing manner during execution of an action, wherein an amount of memory allocated depends on a length of execution time of the action (para. [0027] recites “In the example of FIG. 1, resources are illustrated as computing resources, which may be provided by multiple processing nodes 150A, 150B . . . 150E. In this example, each of the processing nodes is illustrated as a physical computing device”. Para. [0028] recites “different or additional types of resources may be allocated to a job executed on a computing cluster. In some scenarios, for example, memory or I/O resources may be allocated to a job executed by a computing cluster”. Para. [0040] recites “Resource allocation control loop 260 may use such a model to determine at multiple points in time during execution of the job what resources to allocate to the job in order for the job to complete execution by a target completion time. Resource allocation control loop 260 may determine the target completion time in any suitable way” (i.e., dynamically allocating resources, including memory, based on a determined execution time of a job, or action)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine these teachings by utilizing the resource allocation control system from Bodik to manage the resources, including memory required during execution time of an action, from Zornio (as modified by Larson). Paragraph [0009] of Zornio states “the architecture of currently known process control plants and process control systems is strongly influenced by limited controller and device memory, communications bandwidth and controller and device processor capability. For example, in currently known process control system architectures, the use of dynamic and static non-volatile memory in the controller is usually minimized or, at the least, managed carefully. As a result, during system configuration ( e.g., a priori), a user typically must choose which data in the controller is to be archived or saved”. One of ordinary skill in the art would be motivated to manage the resources, including the memory, allocated to the monitoring actions from Zornio using the resource allocation control system from Bodik rather than requiring a user to perform resource allocation tasks.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
“A Comparative Study of Local Outlier Factor Algorithms for Outliers Detection in Data Streams” (Mishra et al) teaches an assessment of density-based outlier detection using local outlier factor algorithms for anomaly prediction.
“Dynamic process monitoring using adaptive local outlier factor” (Ma et al) teaches a method for monitoring industrial processes with time-varying and multimode characteristics utilizing a numerically efficient moving window local outlier factor (LOF) algorithm.
“A new memory monitoring scheme for memory-aware scheduling and partitioning” (Suh et al) teaches a memory monitoring scheme used to schedule jobs or to partition a cache and an analytical model of cache and memory behavior to produce a more accurate overall miss-rate for the collection of processes sharing a cache in both time and space.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LEAH M FEITL whose telephone number is (571) 272-8350. The examiner can normally be reached on M-F 0900-1700 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, Viker Lamardo can be reached on (571) 270-5871. 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.
/L.M.F./ Examiner, Art Unit 2147
/VIKER A LAMARDO/Supervisory Patent Examiner, Art Unit 2147
Prosecution Insights