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 .
DETAILED ACTION
This action is in response to the application filed on 01/22/2026.
Claims 1-3 and 5-8 are pending.
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, 3, 5-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jose et al. (US 2018/0234523 A1) hereinafter Jose in view of Ekambaram et al. (US 2019/0188760 A1) hereinafter Ekambaram and further in view of Eksten et al. (US 9,043,747 B2) hereinafter Eksten and further in view of Ha et al. (US 2020/0389528 A1) hereinafter Ha.
Regarding claim 1, Jose discloses
A microservice orchestration method comprising:
establishing, for each of a plurality of microservices, a first node in a first runtime (Jose [0026] and Fig. 2 illustrates Node 210 coupled to Microservice 218, Node 230 coupled to Microservice 238, Node 220 couple to Microservice 228 in a runtime environment), wherein the first node is configured to control execution of the microservice (Jose [0030] discloses node 210 executing first section of APP CODE 207 and invoking microservice 218 with data 203 delivered within payload 208 thus, node 210 controlling execution of microservice 218);
wherein the behavior tree comprises a leaf node representing the microservice (Jose Fig. 2 illustrates leaf nodes 218, 228, and 238 which represent different microservices);
and mapping the leaf node to the first node (Jose Fig. 2 illustrates the leaf nodes 218, 228, 238 coupled to Nodes 210, 220, 238 respectively thus, mapped to corresponding node); and
Jose lacks explicitly
receiving construction performed by a user on a behavior tree,
parsing the behavior tree by transmitting a control logic in the behavior tree to the first runtime;
connecting at least one behavior sub-tree to the behavior tree;
performing distributed deployment on a second runtime connected to the at least one behavior sub-tree and the first runtime connected to the behavior tree;
connecting the first runtime to the second runtime so that the first runtime controls execution of the second runtime;
establishing, for each of all behavior nodes in a behavior sub-tree of the at least one behavior sub-tree, a corresponding second node in the second runtime, wherein a respective behavior node defines an operation of an operational technology (OT) device, so that a corresponding OT device is controlled through the second node when the respective behavior node in the behavior sub-tree is ticked
generating an instance of the behavior tree.
Ekambaram teaches
parsing the behavior tree by transmitting a control logic in the behavior tree to the first runtime (Ekambaram [0032] teaches “The machine learning API service will execute a fork function Fork ( ) (block 310) to duplicate a decision tree classifier (block 306) on the customer computing device which performs client-side processing of the sampled dataset 304 to detect one or more data categories (block 308) of the sampled dataset 304.” Where the forking and duplicating of the decision tree is similar to transmitting control logic to the first runtime. The customer computing device being the first runtime),
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jose to incorporate the teachings of Ekambaram to “parsing the behavior tree by transmitting a control logic in the behavior tree to the first runtime” in order to improve modularity and reusability, enhance clarity, along with increase scalability and flexibility.
Eksten teaches
receiving construction performed by a user on a behavior tree (Eksten [col. 18, lines 41-42] teaches the visual design tool for creating and saving workflows such as graph 28 illustrated in Fig. 5),
connecting at least one behavior sub-tree to the behavior tree (Eksten [col. 22, lines 55-60] and Fig. 5 teach and illustrate blueprint 28a which contains an outer graph 28 and a video processing sub-graph 28 connected to the outer graph 28);
performing distributed deployment on a second runtime connected to the at least one behavior sub-tree and the first runtime connected to the behavior tree (Eksten [col. 22, lines 5-21] teaches a blueprint 28a may be final embodiment of a graph 28 which may reference a solution set of components. The blueprint 28a may be used to instantiate a graph 28 at application runtime and connect the functionality of a graph to a running environment. Blueprints may be viewed as a business level container of graphs 28. A blueprint 28a may include one or more graphs which may be executed in multiple graph 28 stages and executed in serial form, one after the other. A blueprint 28a may be a container of one or more graphs 28. Where graphs 28 contained at the blueprint 28a level may run simultaneously, or sequentially);
connecting the first runtime to the second runtime so that the first runtime controls execution of the second runtime (Eksten [col. 22, lines 5-21] A blueprint 28a may include one or more graphs which may be executed in multiple graph 28 stages and executed in serial form, one after the other. A blueprint 28a may be a container of one or more graphs 28. Where graphs 28 contained at the blueprint 28a level may run simultaneously, or sequentially. Eksten [col. 37, lines 13-18] teach “whereas the graphs 28 contained at the blueprint 28a level may run simultaneously, or sequentially. Cloud agents 34 and cloud engines 36 may be operable to receive a blueprint 28a and use it to instantiate a graph 28 of components 24, compound components 26, and data containers 56.” And [col. 33, lines 45-50] teaches “The cloud agents 34 may interact with cloud engines 36 to execute graphs 28 and blueprints 28a thereof in order to run media applications, or other computing applications. At application runtime, a pool of one or more cloud agents 34 can access a shared repository 32 of components 24 and graphs 28 to construct the application.” Thus, the blueprint connects different runtimes with multiple graphs in a blueprint connecting the sub-graphs and each running on a different cloud agent/first and second runtime. Further, by constructing the application the sequential graphs executing would have one graph running on runtime/cloud agent to control executing of the second graph running on a different runtime/cloud agent. The graph running on a cloud agent would control executing the sub-graph executing on a separate cloud agent through the blueprint workflow illustrated in Fig. 5. Thus, the first runtime being the graph on cloud agent would control the second runtime being the sub-graph on a second cloud agent);
establishing, for each of all behavior nodes in a behavior sub-tree of the at least one behavior sub-tree, a corresponding second node in the second runtime (Eksten [col. 22, lines 5-21] A blueprint 28a may include one or more graphs which may be executed in multiple graph 28 stages and executed in serial form, one after the other. A blueprint 28a may be a container of one or more graphs 28. Where graphs 28 contained at the blueprint 28a level may run simultaneously, or sequentially. Eksten [col. 37, lines 13-18] teach “whereas the graphs 28 contained at the blueprint 28a level may run simultaneously, or sequentially. Cloud agents 34 and cloud engines 36 may be operable to receive a blueprint 28a and use it to instantiate a graph 28 of components 24, compound components 26, and data containers 56.” And [col. 6, lines 35-37] teaches “The cloud engine may provide a running environment for graphs and executes graphs at application runtime to instantiate computing applications.” Where the sub-graphs being executed sequentially on a different cloud engine within a blueprint would be established as a corresponding node illustrated in Fig. 5),
generating an instance of the behavior tree (Eksten [col. 22, lines 22-27] teaches “A graph 28 can be represented as a file (e.g. XML file) in its blueprint 28a form or as dynamically instantiated object code at runtime. Graphs 28 may be viewed as having two lives, as a running live instance and as a description of how that instance is saved for communication, transportation, distribution or storage needs.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Jose to incorporate the teachings of Eksten to “receiving construction performed by a user on a behavior tree, connecting at least one behavior sub-tree to the behavior tree; performing distributed deployment on a second runtime connected to the at least one behavior sub-tree and the first runtime connected to the behavior tree; connecting the first runtime to the second runtime so that the first runtime controls execution of the second runtime; establishing, for each of all behavior nodes in a behavior sub-tree of the at least one behavior sub-tree, a corresponding second node in the second runtime; generating an instance of the behavior tree” in order to improve performance, portability and control of the overall system which permits improved configurations regarding execution timings of the different graphs/subgraphs.
Ha teaches
wherein a respective behavior node defines an operation of an operational technology (OT) device, so that a corresponding OT device is controlled through the second node when the respective behavior node in the behavior sub-tree is ticked (Ha [0021] teaches controlling the IoT device to include execution of a sub-graph to a loop, an iterative period of a loop, and a condition for remaining in a loop); and
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination to incorporate the teachings of Ha to “wherein the behavior node defines an operation of an operational technology (OT) device, so that a corresponding OT device is controlled through the second node when the behavior node in the behavior sub- tree is ticked” in order to improve when a user can actively intervene in an IoT environment to add a new service and actively reconfigure the IoT environment, and thus it is possible to increase the degree of freedom of controlling the user's IoT device, and it is also possible to allow the user to take the initiative in the IoT environment (Ha [0026]).
Regarding claim 3, Jose in view of Ekambaram and further in view of Eksten combination teach
The method according to claim 1, further comprising, after receiving construction performed by the user on the behavior tree,
configuring the leaf node so that the execution of the corresponding microservice is controlled through the first node according to the configuration when the leaf node is ticked (Jose [0030] teaches node 210 invokes the microservice 218 with user name data 203 delivered within payload 208. Where the combination of Jose in view of Eksten teach that after the graph is built based on user input, the microservice leaf node coupled to the node is configured to executed the microservice. Where a configuration may be coupling the microservice 218 to node 210).
Regarding claim 5, The method according to claim 1,
Jose further discloses
further comprising, after establishing a corresponding second node in the second runtime, connecting at least one second node to the microservice in the second runtime so the second node controls execution of the microservice (Jose [0027]-[0028] and Fig. 2 illustrate Network packet node 204 which may send packet to node 210 which may then invoke microservice 218 based on payload).
Regarding claim 6, Jose in view of Ekambaram and further in view of Eksten and further in view of Ha combination lacks explicitly
The method according to claim 1, wherein connecting the at least one behavior sub-tree to the behavior tree comprises:
determining a leaf node from the behavior tree, wherein the leaf node is configured to control execution of a behavior sub-tree; and
connecting a root node of each of the at least one behavior sub-tree to a corresponding leaf node in the behavior tree.
Eksten further teaches
determining a leaf node from the behavior tree, wherein the leaf node is configured to control execution of a behavior sub-tree (Eksten Fig. 5 illustrates 24f which may be determined to be a leaf node of the outer graph 28 which may control execution of the Video Processing Sub-graph 28 when 24f is done processing); and
connecting a root node of each of the at least one behavior sub-tree to a corresponding leaf node in the behavior tree (Eksten Fig. 5 illustrates root node 24g of the sub-graph 28 connected to leaf node 24f of the outer graph 28).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination to incorporate the teachings of Eksten to “determining a leaf node from the behavior tree, wherein the leaf node is configured to control execution of a behavior sub-tree; and connecting a root node of each of the at least one behavior sub-tree to a corresponding leaf node in the behavior tree.” in order to improve development and prevent wasted time when different sections of the graph need to be updated.
Regarding claim 7, it’s directed to a method having similar limitations cited in claim 2. Thus claim 7 is also rejected under the same rationale as cited in the rejection of claim 2 above.
Regarding claim 8, it’s directed to an electronic device having similar limitations 2cited in claim 1. Thus claim 8 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Claims 2 is/are rejected under 35 U.S.C. 103 as being unpatentable overJose et al. (US 2018/0234523 A1) hereinafter Jose in view of Ekambaram et al. (US 2019/0188760 A1) hereinafter Ekambaram and further in view of Eksten et al. (US 9,043,747 B2) hereinafter Eksten and further in view of Ha et al. (US 2020/0389528 A1) hereinafter Ha and further in view of Bothwell et al. (US 2023/0198860 A1) hereinafter Bothwell.
Regarding claim 2, Jose in view of Ekambaram and further in view of Eksten and further in view of Ha combination teach
The method according to claim 1,
the combination lacks explicitly
wherein the first node communicates with the corresponding microservice through a RESTful application programming interface (API) or a remote procedure call (RPC) API.
Bothwell teaches
wherein the first node communicates with the corresponding microservice through a RESTful application programming interface (API) (Bothwell [0148] teaches a Node Communication Service 35 that handles bidirectional communication between nodes and various services via RESTful services API) or a remote procedure call (RPC) API (no rejection required due to “or” language).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination to incorporate the teachings of Bothwell to “wherein the first node communicates with the corresponding microservice through a RESTful application programming interface (API)” in order to efficiently ease development, increase scalability and flexibility, improve cost, and support various data formats.
Response to Arguments
Applicant's arguments filed 01/22/2026 have been fully considered but they are not persuasive.
Regarding the remark the cited portions of Eksten, do not include a first runtime controlling the second runtime as required, instead each cloud agent runs a separate runtime without controlling the others since each cloud agent would serve as a different second runtime without a first runtime as required, the examiner respectively disagrees and would like to point out that the graph running on a cloud agent would control executing the sub-graph executing on a separate cloud agent through the blueprint workflow illustrated in Fig. 5. Thus, the first runtime being the graph on cloud agent would control the second runtime being the sub-graph on a second cloud agent.
For the above reasons, the rejection is maintained.
Conclusion
THIS ACTION IS MADE FINAL. 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 Noor Alkhateeb whose telephone number is (313)446-4909. The examiner can normally be reached Monday-Friday from 9:00AM ET to 5:00PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat do, can be reached at telephone number (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/NOOR ALKHATEEB/Primary Examiner, Art Unit 2193