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 .
Remarks
2. This Office action is responsive to the Request for Continued Examination (RCE) filed under 37 CFR §1.53(d) for the instant application on October 8, 2025. Applicants have properly set forth the RCE, which has been entered into the application, and an examination on the merits follows herewith.
Claims 1-3, 5-9, and 11-13 have been examined and rejected. This Office action is responsive to the amendment filed on October 8, 2025, which has been entered in the above identified application.
Drawings
3. The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description:
a. Reference characters ‘323’ in figure 3A].
b. Reference characters ‘321’ and ‘322’ in figure 3B].
4. The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference character “324” in [figure 3B] appears to be used to designate different items, one being on the top part of memory 302 and the other being on the bottom part of memory 312. Applicant’s specification [page 16, lines 9-11] refers to reference character ‘324’ as an external buffer. However, it is unclear whether reference character ‘324’ shown on the top part of memory 302 in [figure 3B] also refers to an external buffer Do(ext) given the location of the reference character.
5. Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
6. Based on the recitation of “Symbolic links i.e. symlinks” on [page 5, line 11] of Applicant’s specification, the objection to the specification is withdrawn.
7. The disclosure is objected to because of the following informalities:
a. On [page 13, lines 13-14], Examiner suggests changing “310, 320” to --300, 310--.
b. On [page 14, lines 30-31], Examiner suggests changing “This achieved which is achieved by” to --This is achieved by--.
c. [Page 16, lines 9-10] recites, “Next, within the Data Transfer List for the respective output event the associated array objects are identified and the source pointer src, destination pointer dst and function pointer fnc are retrieved 502 in order to copy the output variables from the internal buffer to the external buffer 324.” It is unclear whether the external buffer 324 refers to the external buffer of memory instance 302 or the external buffer of memory instance 312 in [figure 3B].
d. [Page 16, lines 10-11] recites, “For a composite function block this is representing the copy of the external buffer Do(ext) of the connected member function block to the external buffer Do(ext) of composite.” This sentence appears to be incomplete. Further, it is unclear which of the function blocks 300, 310 in [figure 3A] represents the member function block and which represents the composite.
e. On [page 16, line 15], Examiner suggests changing “event queue 503” to --event queue 321--.
f. On [page 17, line 6], Examiner suggests changing “an type cast” to --a type cast--.
g. On [page 18, line 12], Examiner suggests changing “executed Accordingly” to --executed. Accordingly--.
h. [Page 18, lines 26-28] recites, “Executing 803 the function block algorithm according to the definition of the ECC, it's current ECC state and the Input Event being triggered and filling the timestamp into the event datastructure header when the event is being executed”. This does not correspond to what is shown in step 803 of [figure 8], which is represented by the text “Copy data variable values from the event Data structure.”
Appropriate correction is required.
Claim Objections
8. The correction to claim 12 has been approved, and the objection to the claim is withdrawn.
Claim Rejections - 35 USC § 103
9. 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.
10. Claims 1-3 and 5-7 are rejected under 35 U.S.C. 103 as being unpatentable over Vyatkin et al (Pub. No. US 2014/0143419) in view of Nishi et al (U.S. Patent No. 6,434,737).
10-1. Regarding claim 1, Vyatkin teaches the claim of a runtime environment including hardware resources with processing circuitry for execution of an event driven control program for a distributed control system comprising at least one computing resource, wherein the control program comprises at least two function blocks: wherein the runtime environment is configured to execute each function block event driven when any of the each respectively function block associated trigger events occur, by disclosing a set of logical nodes that each encapsulate data [paragraph 166] and that each contain a logical node module that communicates and responds to other logical node modules using a set of standardized data objects and events to perform functions, dependent on receiving events and data in the form of objects [paragraph 168, lines 4-10].
Vyatkin teaches wherein the runtime environment comprises at least one computing resource, and for each computing resource, an event executor which is configured for execution of sets of events with respective associated data on the respective computing resource, by disclosing that the logical node module comprises a service-interface module that performs functions representing the function encapsulated with the data [paragraph 168].
Vyatkin teaches wherein the runtime environment comprises for each function block, an instance memory configured to: store a set of events and associated data for each function block upon determining the data is produced by the function block in a current trigger event; and store a reference to the set of events and the associated data for each function block upon determining the data is consumed by the function block in the current event trigger, by disclosing that the logical module for a logical node represents a data and function capsule which stores data representing the state of the logical node [paragraph 168, lines 1-4]. The logical node module performs functions, dependent on receiving events and data in the form of objects, wherein such functions are manifest as updating data or generating data objects to be communicated to another logical node module [paragraph 168, lines 9-13]. Events in the form of requests for services or service requests may be accompanied by corresponding data objects [paragraph 168, lines 15-17]. The service-interface module receives or exchanges events and data objects defined by the standard and stores data in the standardized data types [paragraph 169]. Thus, based on receiving an event (i.e. an event trigger), the logical node module of a logical node may generate (i.e. produce) data objects, and such data objects will be stored. Vyatkin further discloses that a service interpreter of the service-interface module receives service requests and corresponding data from other logical nodes, wherein the corresponding data are data references, data and a requested service [paragraph 181, lines 6-9]. Thus, based on an event (i.e. an event trigger) that indicates data is being received from another logical node and used (i.e. consumed) by the logical node, the service-module of the logical node module performs a function of updating data, where such data comprise data references, data and a requested service.
Vyatkin teaches wherein said reference corresponds to a data structure, the data structure being held by the runtime environment for each event, the data structure for each event representing the event and data connections between the at least two function blocks, by disclosing that the logical module for a logical node represents a data and function capsule which stores data representing the state of the logical node [paragraph 168, lines 1-4]. The service-interface module receives or exchanges events and data objects defined by the standard and stores data in the standardized data types [paragraph 169]. A service interpreter of the service-interface module receives service requests and corresponding data from other logical nodes, wherein the corresponding data are data references, data and a requested service [paragraph 181, lines 6-9]. An intelligence module of the service-interface module has algorithms to perform logic, calculations, and other algorithms as required for influencing control or event controlling the logical nodes [paragraph 186] and can receive and send events, request standard services from a database module, allow logic data to be sent to and received from other intelligence modules, and receive and exchange data with the database module [paragraph 188].
Vyatkin does not expressly teach wherein the data structure for each event contains a Data Transfer To Queue (DTTQ) variable and a Data Transfer From Queue (DTFQ) variable, the DTTQ variable having DTTQ objects therein, each DTTQ object describing what data is associated with an event that is to be put on a data transfer queue, and the DTFQ variable having DTFQ objects therein, each DTFQ object describing what data should be copied to where for an event that is to be executed. Nishi discloses a function block (FB) processing apparatus which generates an application function through establishment of connections between a plurality of event-driven-type function blocks each composed of a data processing block and an event processing block, and which executes the application function [column 5, lines 4-11]. A FB execution section executes the application function by starting the event-driven function blocks in accordance with information with regard to the application function stored in a FB connection information section [column 5, lines 25-30]. When a signal line is set in order to establish a connection between event-driven function blocks, for the thru-set connection, a setting section sets a variable area (which may be of an FIFO type) for data transfer between the data processing blocks [column 5, lines 33-36, 47-55]. For each of the event-driven function blocks, an allocation section allocates a pointer which points to the variable area so that each of the function blocks input data from or output data to the variable area [column 5, lines 36-40]. This would reduce memory capacity by allowing event driven function blocks to be connected directly without use of an event-drive function block having a selection function [column 6, lines 45-48]. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide a variable area for each input event, as taught by Nishi. This would reduce memory capacity.
10-2. Regarding claim 2, Vyatkin-Nishi teach all the limitations of claim 1, wherein any of the at least two function blocks is a composite function block comprising multiple function blocks, by disclosing that the logical nodes may be composite blocks [Vyatkin, paragraphs 14, 203].
10-3. Regarding claim 3, Vyatkin-Nishi teach all the limitations of claim 1, wherein the set of events and associated data is stored with a function block state in an instance memory, by disclosing that the logical module for a logical node represents a data and function capsule which stores data representing the state of the logical node [Vyatkin, paragraph 168, lines 1-4]. The service-interface module receives or exchanges events and data objects defined by the standard and stores data in the standardized data types [Vyatkin, paragraph 169].
10-4. Regarding claim 5, Vyatkin-Nishi teach all the limitations of claim 1, wherein the at least one computing resource contains a function block network composed of function blocks instances represented by instance memories, and event and data connections represented by data structures inside the runtime environment, by disclosing that the logical nodes may be composite blocks [Vyatkin, paragraphs 14, 203], where each block comprises a logical node module that represents a data and function capsule which stores data representing the state of the block [Vyatkin, paragraph 168, lines 1-4]. An intelligence module of the service-interface module within the logical node module has algorithms to perform logic, calculations, and other algorithms as required for influencing control or event controlling the logical nodes [Vyatkin, paragraph 186] and can receive and send events, request standard services from a database module, allow logic data to be sent to and received from other intelligence modules, and receive and exchange data with the database module [Vyatkin, paragraph 188]. Further, both the service-interpreter and the database module may be implemented with multiple functional blocks [Vyatkin, paragraphs 182, 184].
10-5. Regarding claim 6, Vyatkin-Nishi teach all the limitations of claim 3, wherein while executing, the corresponding instance memory for each function block holds and keeps a complete state of a function block over the whole lifetime of the function block, by disclosing that the logical module for a logical node represents a data and function capsule which stores data representing the state of the logical node [Vyatkin, paragraph 168, lines 1-4]. The service-interface module receives or exchanges events and data objects defined by the standard and stores data in the standardized data types [Vyatkin, paragraph 169]. A database of the service-interface module operates as a container for all mandatory and optional data objects defined for the particular logical node [Vyatkin, paragraphs 174, 183].
10-6. Regarding claim 7, Vyatkin-Nishi teach all the limitations of claim 3, wherein an instance memory is defined at least by all current values of input data, output data and internal variables, by disclosing that the logical module for a logical node represents a data and function capsule which stores data representing the state of the logical node [Vyatkin, paragraph 168, lines 1-4]. The service-interface module receives or exchanges events and data objects defined by the standard and stores data in the standardized data types [Vyatkin, paragraph 169]. A database of the service-interface module operates as a container for all mandatory and optional data objects defined for the particular logical node [Vyatkin, paragraphs 174, 183].
11. Claims 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Vyatkin et al (Pub. No. US 2014/0143419), in view of Nishi et al (U.S. Patent No. 6,434,737), and further in view of Apel et al (U.S. Patent No. 6,760,687).
11-1. Regarding claim 8, Vyatkin-Nishi teach all the limitations of claim 3. Vyatkin-Nishi do not expressly teach wherein when one trigger event occurs for a function block, the runtime environment is configured to set binary values representing the event as well as the corresponding input data in the instance memory of the function block, and to execute an algorithm of the function block producing new output data in an internal buffer for the output data and marking new output events to be fired by setting the binary values representing the output event in the instance memory. Apel discloses that it was well known in process control systems to use function blocks located in different field devices to receive inputs from and/or provide outputs to other function blocks, and perform control operations [column 1, line 54 to column 2, line 6] where binary on-off type signals associated with significant events are monitored to detect changes in these signals and thereby detect “events” within the process plant [column 2, lines 7-16]. Being able to detect such types of events would expand the types of devices that could be included for control and/or monitoring. Since Vyatkin discloses a set of processors operable to control and/or monitor the operation of a set of devices by executing code defining a data-model for a network, the data-model comprising a set of logical-nodes encapsulating network functions and/or network devices [Vyatkin, paragraph 17], it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide, for receipt as input events by the logical nodes of Vyatkin-Nishi, binary type signals, as taught by Apel. This would expand the types of devices that could be included for control and/or monitoring. Since the logical node receives service requests and corresponding data from other logical nodes [Vyatkin, paragraph 181], performs algorithms or operations in response to service request-events [Vyatkin, paragraph 184], and provides output events and data generated in response to the service requests [Vyatkin, paragraph 185], receipt of a binary type signal as a trigger event would cause the logical node to obtain binary values for the event as well as corresponding data for the performance of algorithms or operations to produce output data that will be used by other logical nodes.
11-2. Regarding claim 9, Vyatkin-Nish-Apel teach all the limitations of claim 8, wherein the algorithm of the function block writes a value to an internal buffer of a respective output variable and when an output event associated with said value is fired, said value is copied from the internal buffer to an external buffer after the execution of the algorithm of the function block, by disclosing that the logical module for a logical node represents a data and function capsule which stores data representing the state of the logical node [Vyatkin, paragraph 168, lines 1-4]. A database module performs algorithms or operations in response to service request-events [Vyatkin, paragraph 184], provides output events and data generated in response to the service requests [Vyatkin, paragraph 185], and operates as a container for all mandatory and optional data objects defined for the particular logical node [Vyatkin, paragraph 183]. An intelligence module of the service-interface module has algorithms to perform logic, calculations, and other algorithms as required for influencing control or event controlling the logical nodes [Vyatkin, paragraph 186] and can receive and send events, request standard services from a database module, allow logic data to be sent to and received from other intelligence modules, and receive and exchange data with the database module [Vyatkin, paragraph 188]. Thus, the intelligence module may receive stored data of an output from the database module and perform an algorithm that sends such stored data to another logical node. An auxiliary FB may serve a buffer role [Vyatkin, paragraph 211].
12. Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Vyatkin et al (Pub. No. US 2014/0143419), in view of Nishi et al (U.S. Patent No. 6,434,737), and further in view of Sawahara (U.S. Patent No. 11,215,960).
12-1. Regarding claim 11, Vyatkin-Nishi teach all the limitations of claim 1, wherein the variable DTTQ and DTFQ objects consist of a source or destination pointer,… and a function pointer to a cast and/or copy function, by disclosing that when a signal line is set in order to establish a connection between event-driven function blocks, for the thru-set connection, a setting section sets a variable area (which may be of an FIFO type) for data transfer between the data processing blocks [Nishi, column 5, lines 33-36, 47-55]. For each of the event-driven function blocks, an allocation section allocates a pointer which points to the variable area so that each of the function blocks input data from or output data to the variable area [Nishi, column 5, lines 36-40].
Vyatkin-Nishi do not expressly teach wherein the variable DTTQ and DTFQ consist of an offset in the data structure of the event. Sawahara discloses that it was well known to use an offset to point to data in a data structure [column 4, lines 17-31]. This would provide more efficient data retrieval by allowing particular sections of a data structure to be quickly located without having to read the entire data structure from start to finish. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to provide an offset in the event data structure, as taught by Sawahara. This would provide more efficient data retrieval by allowing particular sections of a data structure to be quickly located.
13. Claims 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Vyatkin et al (Pub. No. US 2014/0143419), in view of Nishi et al (U.S. Patent No. 6,434,737), and further in view of Wuerr et al (11,947,329).
13-1. Regarding claim 12, Vyatkin-Nishi teach all the limitations of claim 1. Vyatkin-Nishi do not expressly teach wherein the runtime environment uses an event queue, which may be a ring buffer and stores data structures for the set of events scheduled for execution. Wuerr discloses an execution module that manages event queues in which activation events still to be executed are stored [column 3, line 61 to column 4, line 7]. This would improve the real-time capability of the process. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use a queue in which activation events still to be executed are stored, as taught by Vyatkin. This would improve the real-time capability of the process.
13-2. Regarding claim 13, Vyatkin-Nishi-Wuerr teach all the limitations of claim 12, wherein a data structure for an event contains a timestamp when the event is being queued and also a placeholder for a timestamp when the event is being executed, by disclosing that event chains of functional modules to be successively executed are in each case formed and the time required for the execution of the individual event chains is monitored such that on an exceeding of the predefined time duration, a predefined response can take place [Wuerr, column 2, lines 44-58]. A time stamp can, for example, indicate the point in time at which the execution of the initial module of the event chain is started, and additionally, the time stamp can also indicate the point in time at which the initial event is created [Wuerr, column 7, lines 28-32].
Response to Arguments
14. The Examiner acknowledges the Applicant’s amendments to claims 1, 6, 8, 11, and 12.
Regarding independent claim 1, Applicant alleges that Vyatkin et al (Pub. No. US 2014/0143419) does not teach storing “a set of events and associated data for each function block upon determining the data is produced by the function block in a current trigger event" and storing "a reference to the set of events and the associated data for each function block upon determining the data is consumed by the function block in the current trigger event," as has been amended to the claim, because at most, Vyatkin teaches the service-interpreter-module 14 in the logical node 8 can receive data references, data, and a requested service from other logical nodes.
Contrary to Applicant’s arguments, Vyatkin discloses that the logical module for a logical node represents a data and function capsule which stores data representing the state of the logical node [paragraph 168, lines 1-4]. The logical node module performs functions, dependent on receiving events and data in the form of objects, wherein such functions are manifest as updating data or generating data objects to be communicated to another logical node module [paragraph 168, lines 9-13]. Events in the form of requests for services or service requests may be accompanied by corresponding data objects [paragraph 168, lines 15-17]. The service-interface module receives or exchanges events and data objects defined by the standard and stores data in the standardized data types [paragraph 169]. Thus, based on receiving an event (i.e. an event trigger), the logical node module of a logical node may generate (i.e. produce) data objects, and such data objects will be stored. Vyatkin further discloses that a service interpreter of the service-interface module receives service requests and corresponding data from other logical nodes, wherein the corresponding data are data references, data and a requested service [paragraph 181, lines 6-9]. Thus, based on an event (i.e. an event trigger) that indicates data is being received from another logical node and used (i.e. consumed) by the logical node, the service-module of the logical node module performs a function of updating data, where such data comprise data references, data and a requested service.
Applicant states that dependent claims 2-3, 5-9, and 11-13 recite all the limitations of the independent claims, and thus, are allowable in view of the remarks set forth regarding independent claim 1. However, as discussed above, Vyatkin in view of Nishi are considered to teach claim 1, and consequently, claims 2-3, 5-9, and 11-13 are rejected.
To distinguish over the cited references, Examiner suggests amending claim 1 to include aspects regarding the creation of an event data structure on an event queue comprising various information as described in Applicant’s specification [page 17, line 21 to page 18, line 8; figure 7, ‘702’-‘704’] and using the created event data structure to execute an input event for a target function block, as described in Applicant’s specification [page 18, lines 10-15].
Conclusion
15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALVIN H TAN whose telephone number is (571)272-8595. The examiner can normally be reached M-F 10AM-6PM.
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, Scott Baderman can be reached at 571-272-3644. 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.
/ALVIN H TAN/Primary Examiner, Art Unit 2118