Response to Amendment
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 .
This action is responsive amendment filed on 12/11/25. Claims 1, 2, 4-9, 11-16 and 18-20 are pending.
Independent claims 1, 8 and 15 have been evaluated for statutory subject matter. A received event as part of a stream is analyzed and associated with an entity. A set of nodes are associated with the entity. The system/method routes the event to appropriate nodes, wherein at each node state information of an entity is updated and event is updated with the updated state information of the entity.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 4-9, 11-16 and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Oscherov et al USPN. 2021/0240712 in view of Sethi et al (USPN. 2025/0023918).
8. Oscherov teaches a system comprising: a memory and a processing device operatively coupled to the memory, the processing device to (figs. 5 and 8A-B, memory and devices):
receive an event that is part of a stream of events (fig. 4, item 401, pars. 36 and 46, receive an event);
identify an entity referenced by the event (items 403 and 405, pars. 36 and 46, tenant based on topic);
determine a set of nodes associated with the entity (item 407, par. 47, determine a cluster node);
route the event to each of the set of nodes associated with the entity (item 411, par. 47, dispatch to cluster node); and
at each of the set of nodes associated with the entity (fig. 2, pars. 42, 43, 45, items 205 and 207, cluster monitor and payload router:
update state information of the entity maintained by the node based on the event (par. 49 and 51, “the cluster nodes can store the state of each tenant to a shared storage area” and rebalance distribution and updated configurator “redefines the tenants and/or topics serviced” note, that the rebalancing uses the stored shared state of each tenant), wherein the state information of the entity maintained by the node comprises a current state of the entity (par. 38, “online state”), each previous state of the entity (par. 38 “state of inactive tenants can be stored in the shared storage” and par. 39, the information is used to restore the current states stored in the shared storage), and metadata associated with the current state of the entity (par. 67, metadata that describes user access privileges and tenant specific constructs such as interfaces).
but Osherov does not explicitly teach “metadata associated with each of the previous states of the enity”.
However, having detailed information about the state of devices and objects is well known in distributed systems. One such system, Sethi, teaches state information of an entity maintained by the node comprises states of entities and metadata associated with each of the previous states of the entity (figs. 1 and 5.1, pars. 72, 103 and 136, “monitoring of the operational states of the edge devices results in information regarding the scenes that accurately reflects the states of the scenes”, “store/log… information regarding the sender (e.g. a malicious user), “metadata regarding obtained and/or derived data” and “history of user”, Sethi). It would have been obvious to one of ordinary skill in the field at the effective filing date of the application to integrate history and workload monitored Sethi data in Osherow system (par. 103, “store/log/record… data”, Sethi). One would have been motivated to rebalance all the devices and workload running on the client and system devices to avoid malicious activity (fig. 1, par. 103, workload balance edge device and information about a malicious user, Sethi).
Osherow and Sethi combined teach,
wherein to update the state information of the entity, the processing device is to save, as part of the metadata associated with the current state of the entity (fig. 8A, par. 67, metadata that is tenant specific data and describes tenant specific constructs is stored in multi tenant database, Osherov), a time stamp associated with the event as an indication of a time when the entity was last active (pars. 23 and 28, number of logins on a particular client including device logs are tracked, note that number of logins and device logs includes use of timestamps, Osherov);
update the event with the updated state information of the entity maintained by the node (fig. 6, pars. 51-52, the configurator redefines the tenants and topics serviced, cluster node restarts processing which causes the cluster nodes to identify and load a tenant, and then executes the processing of updated/reassigned events for the reassigned tenant/node, note that redefining the tenants and topics uses updated state information of the entity such as what events have occurred, Osherow, and par. 115, child nodes and parent nodes keep all data updated and transparent, Sethi).
9. Osherow and Sethi combined teach,
system of claim 8, wherein to identify the entity, the processing device is to: use a configuration to identify the entity, wherein the configuration comprises entity identification information indicating when the entity is referenced by a particular event (par. 33 implementations based on tenant/entity configuration that enables events to be routed and processed to each appropriate cluster nodes, in addition, please refer to par. 67 for explanation of rules using metadata, Osherow).
11. Osherov and Sethi combined teach,
system of claim 10, wherein to update the state information of the entity maintained by the node, the processing device is to (figs 2 and 5, Osherov):
update the current state of the entity to indicate an active state (fig. 5, item 511 and par. 49 and 51, rebalance distribution and updated configurator updates the cluster node);
and
save as part of the metadata associated with the current state of the entity, an event type of the event as an indication of a last activity of the entity ( par. 30 and 51 state of the event is executed/completed, and event type comprises information such as event topic, Osherow).
12. Osherov and Sethi combined teach,
system of claim 11, wherein the entity identification information comprises a key and a corresponding value for the key, and wherein the configuration further comprises a set of states each of the set of nodes is to maintain for the entity and rules to determine the current state of the entity (par. 39, restoring state of nodes and tenant/entities requires mapping relevant data keys, Osherov).
13. Osherov and Sethi combined teach,
system of claim 12, wherein the processing device is further to: determine, based on the configuration and the metadata associated with the current state of the entity, whether the current state of the entity should be changed (fig. 6, pars. 30 and 67 disclosing tenant and event specific schemas and applications, and par. 38, whether to transition states, Osherow).
14. Osherov and Sethi combined teach,
system of claim 12, wherein the processing device is further to: maintain a mapping of the corresponding value for the key to the set of nodes, and wherein the processing device determines the set of nodes using the mapping (fig. 7, par. 52, configuration file specifies and manages the routing of the events and nodes by payload router 713, Osherov).
Method claims 1, 2, 4-7 and medium claims 15, 16, 18-20 comprise substantially the same subject matter as system claims 8, 9, 11-14 rejected above, and are therefore rejected on the basis.
Response to Arguments
Applicant's arguments filed 12/11/25 have been fully considered but they are not persuasive. See remarks below.
Applicant alleges updating the event with the updated state information is not taught.
Examiner disagrees. The relevant portion of the updated office action reads,
“update the event with the updated state information of the entity maintained by the node (fig. 6, pars. 51-52, the configurator redefines the tenants and topics serviced, cluster node restarts processing which causes the cluster nodes to identify and load a tenant, and then executes the processing of updated/reassigned events for the reassigned tenant/node, note that redefining the tenants and topics uses updated state information of the entity such as what events have occurred, Osherov, and par. 115, child nodes and parent nodes keep all data updated and transparent, Sethi)”.
Redefining by the configurator based on updated information the tenants and topics serviced and executing the updated/reassigned events clearly comprises updating the previous event with updated state information relevant to the event.
Applicant alleges the newly amended limitation of claim 1 is not taught.
Examiner disagrees. The new cited portions of Osherov below teach the following limitation:
“wherein to update the state information of the entity, the processing device is to save, as part of the metadata associated with the current state of the entity (fig. 8A, par. 67, metadata that is tenant specific data and describes tenant specific constructs is stored in multi tenant database, Osherov), a time stamp associated with the event as an indication of a time when the entity was last active (pars. 23 and 28, number of logins on a particular client including device logs are tracked, note that number of logins and device logs includes use of timestamps, Osherov);
As detailed above, the tracking of number of user logins/client includes sessions and timestamps of the sessions to differentiate between the sessions. As such, the limitation is believed moot.
Previous relevant allegations and remarks filed 8/11/25:
Applicant alleges Osherov does not teach “updating… state information of the entity maintained by the node” “Osherov refers to reassigning” and not “updating… state information (pages 2-4).
Examiner disagrees. The updated Office Action reads,
“update state information of the entity maintained by the node based on the event (par. 49 and 51, “the cluster nodes can store the state of each tenant to a shared storage area” and rebalance distribution and updated configurator “redefines the tenants and/or topics serviced” note, that the rebalancing uses the stored shared state of each tenant), wherein the state information of the entity maintained by the node comprises a current state of the entity (par. 38, “online state”), each previous state of the entity (par. 38 “state of inactive tenants can be stored in the shared storage” and par. 39, the information is used to restore the current states stored in the shared storage), and metadata associated with the current state of the entity (par. 67, metadata that describes user access privileges and tenant specific constructs such as interfaces).
but Osherov does not explicitly teach “metadata associated with each of the previous states of the enity”.
However, having detailed information about the state of devices and objects is well known in distributed systems. One such system, Sethi, teaches state information of an entity maintained by the node comprises states of entities and metadata associated with each of the previous states of the entity (figs. 1 and 5.1, pars. 72, 103 and 136, “monitoring of the operational states of the edge devices results in information regarding the scenes that accurately reflects the states of the scenes”, “store/log… information regarding the sender (e.g. a malicious user), “metadata regarding obtained and/or derived data” and “history of user”, Sethi). It would have been obvious to one of ordinary skill in the field at the effective filing date of the application to integrate history and workload monitored Sethi data in Osherow system (par. 103, “store/log/record… data”, Sethi). One would have been motivated to rebalance all the devices and workload running on the client and system devices to avoid malicious activity (fig. 1, par. 103, workload balance edge device and information about a malicious user, Sethi)”.
Osherov clearly stores a plurality of states of the tenant and uses the stored information to restore current states in the shared nodes (see above). In addition Osherov in view of Sethi teach storing and using history/log of data and metadata data to avoid malicious activity. As such, in view of the updated Office action, Applicant arguments are believed moot.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
USPN. 20240323202 pars. 131-133 (processing of events and nodes)
USPN. 20200356442 par. 125
USPN. 20200174665 par. 67, nodes with states of entities.
USPN. 2024/0202363, Abstract, events.
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 MARCIN R FILIPCZYK whose telephone number is (571)272-4019. The examiner can normally be reached M-F 7-4 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, Kavita Stanley can be reached at 571-272-8352. 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.
March 13, 2026
/MARCIN R FILIPCZYK/Primary Examiner, Art Unit 2153