Office Action Predictor
Last updated: April 16, 2026
Application No. 17/956,929

System and Method for Aggregating Data in a Remote Address Space

Final Rejection §103
Filed
Sep 30, 2022
Examiner
ELFERVIG, TAYLOR A
Art Unit
2445
Tech Center
2400 — Computer Networks
Assignee
Abb Schweiz AG
OA Round
3 (Final)
62%
Grant Probability
Moderate
4-5
OA Rounds
4y 0m
To Grant
99%
With Interview

Examiner Intelligence

Grants 62% of resolved cases
62%
Career Allow Rate
253 granted / 409 resolved
+3.9% vs TC avg
Strong +38% interview lift
Without
With
+38.5%
Interview Lift
resolved cases with interview
Typical timeline
4y 0m
Avg Prosecution
31 currently pending
Career history
440
Total Applications
across all art units

Statute-Specific Performance

§101
8.4%
-31.6% vs TC avg
§103
57.0%
+17.0% vs TC avg
§102
16.3%
-23.7% vs TC avg
§112
12.2%
-27.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 409 resolved cases

Office Action

§103
DETAILED ACTION 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 . General Remarks This communication is considered fully responsive to Applicant’s application filed 11/24/2025. Application filed: 09/30/2022 Applicant’s PgPUB: 2023/0027121 Claims: Claims 1-15 and 17-22 is pending. Claims 1, 18 and 22 are independent. Claims 1, 2, 4, 9, 17, 18 and 22 are amended. Claim 16 is canceled. IDS: Previous IDS: IDS filed 04/09/2024 has been considered. IDS filed 12/04/2023 has been considered. IDS filed 09/30/2022 has been considered. Continuity/Priority Data: This Application claims priority to European Application EP2016724.6 filed 03/31/2020. This Application is Continuation of International Patent Application PCT/EP2021/058152 filed 03/29/2021. Response to Arguments Applicant’s arguments, see Applicant’s arguments, filed 11/24/2025, with respect to the rejection(s) of claim(s) 1-15 and 17-22 under 35 U.S.C. 103 have been fully considered and are persuasive to overcome the prior rejection. However, upon further consideration, a new ground(s) of rejection is made in view of U.S. Patent Application Publication No. 2015/0012141 A1 to Schultz et al. (“Schultz”). 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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. Claims 1-20 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Printed Publication, “Aggregating OPC UA Server for Flexible Manufacturing Systems” to Tuomi (”Tuomi”) in view of U.S. Patent Application No. 2019/0107827 A1 to Dhakshinamoorthy et al. (“Dhakshinamoorthy”) in further view of U.S. Patent Application Publication No. 2015/0012141 A1 to Schultz et al. (“Schultz”). As to claim 1, Tuomi discloses: An Open Platform Communications Unified Architecture (OPC UA) aggregation server configured to: aggregate at least one OPC UA server in a remote address space (ch. 3.5.1, pg. 18, para. 1-2 – Tuomi teaches that the amount of network traffic can significantly reduced (i.e., data reduction)); wherein the at least one OPC UA server is configured for supporting data reduction and/or redundancy mechanisms (ch. 3.5.1, pg. 18, para. 1-2 – Tuomi teaches that the amount of network traffic can significantly reduced (i.e., data reduction)); Dhakshinamoorthy discloses what Tuomi does not expressly disclose. Dhakshinamoorthy discloses: wherein the OPC UA aggregation server is configured to store remote address space information of a current session (Fig. 3A, Address Space (Nodes), 332; Views, 334, Information Repository, 336; ¶0068, ¶0069, ¶0085 – Dhakshinamoorthy teaches that for each new session that is created by the session generator 350, the cached views 370 caches the views 372a-372n of the user who initiated the new session. In certain embodiments, the cached views 370 caches the views 372a-372n of the user for each new query of the user. Caching the views for each new query can provide real time data for the user; ¶0071 – Query server is a part of the OPC UA Server); wherein the session is related to an application and/or a OPC UA client (¶0079 – Dhakshinamoorthy teaches based on the identity of the user, the particular views 334 available to the user can be identified. Examiner Note: views 334 and 372 are similar, see ¶0082); and wherein the OPC UA aggregation server is configured to use the remote address space information in a next session for aggregating data (¶0079 – Dhakshinamoorthy teaches each session, such as session 352a that connects to the client session 354a allows the query engine 395 to identify the particular user of the computing device 310. Based on the identity of the user, the particular views 334 available to the user can be identified.). Tuomi and Dhakshinamoorthy are analogous arts because they are from the same field of endeavor with respect to networked data tranmissions. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to incorporate accessing stored address space information within a session as discussed in Dhakshinamoorthy with the OPC UA environment as discussed in Tuomi by adding the functionality of Dhakshinamoorthy to the system/method of Tuomi in order to track the status of the controllers and field devices and to decide whether changes to the control and automation systems or the underlying processes should be made. (Dhakshinamoorthy, ¶0004). Schultz discloses what Tuomi and Dhakshinamoorthy do not expressly disclose. However, Tuomi does teach the use of filters (sec. 3.3 – Tuomi teaches use of filters) Schultz discloses: filtering data to be aggregated via a configurable traffic using self-tuning traffic optimization logic (¶0120, ¶0137 - Schultz teaches workflow items because the workflow items can be sorted, filtered, or aggregated according to the context (i.e., self-tuning), wherein the OPC UA aggregation server is configured to aggregate the filtered data (¶0087, ¶0137 - Schultz teaches that a filter dialog may be opened and all field device components may be selected which are temperature transmitters (i.e., filtered). The aggregating workflow item can now change to show such field device components needing parameterization. (i.e., aggregate)). Tuomi, Dhakshinamoorthy and Schultz are analogous arts because they are from the same field of endeavor with respect to networked data tranmissions. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to incorporate filtering input data as discussed in Schultz with accessing stored address space information within a session as discussed in Dhakshinamoorthy with the OPC UA environment as discussed in Tuomi by adding the functionality of Schultz to the system/method of Tuomi and Dhakshinamoorthy in order to assist with workflow within a system (Schultz, ¶0008). As to claim 2, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 1, and Tuomi discloses: wherein the OPC UA aggregation server is configured to aggregate the data from the remote address space on demand at a time when requested (sec. 1.1, pg. 1 – Tuomi teaches Reacting to expected and unexpected changes requires making real-time decisions concerning manufacture in the FMS itself, and delivering these instructions to each device taking part in the process.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 3, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 1, and Tuomi discloses: wherein the OPC UA aggregation server obtains partial remote address space information from a configuration file (sec. 3.5.1, pg. 18 – Tuomi teaches the nodes in the aggregating address space can be connected to underlying devices with a mapping. The mapping is configured according to a configuration which specifies the aggregated servers and how their address spaces are mapped into the aggregating address space.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 4, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 2, and Tuomi discloses: Wang discloses what Tuomi does not expressly disclose. Wang discloses: wherein the OPC UA aggregation server is configured to store the data aggregated on demand in a cache (Abstract – Wang teaches an OPC UA multi-server aggregation method supporting cache management.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 5, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 1, and Tuomi discloses: wherein the OPC UA aggregation server is configured to use information based on configuration data of an application (sec. 3.5.1, pg. 18 – Tuomi teaches the nodes in the aggregating address space can be connected to underlying devices with a mapping. The mapping is configured according to a configuration which specifies the aggregated servers and how their address spaces are mapped into the aggregating address space.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 6, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 5, and Tuomi discloses: wherein the information based on configuration data of an application is a subset of nodes of the remote address space, and wherein the subset of nodes is identified through a NodeId (ch. 5.2.3 – Tuomi teaches mapping defines the connection between a node in the aggregating address space and its sources. It is created according to a configuration and used during runtime to retrieve and compute requested values. The mapping itself is a data structure enabling efficient addition and lookup of the source of a given node. Since services are used frequently, the performance of searching for a NodeId in a mapping is an important consideration. Hash maps were selected as the data structure for their constant-time performance on lookup and insertion operations. Each hash map maps a NodeId in the aggregating server’s local address space into a data source.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 7, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 6, and Tuomi discloses: wherein the NodeId used by the OPC UA aggregation server is composed such that a URL of the aggregated OPC UA server and the NodeId of a node in the remote address space of an aggregated OPC UA server are extractable (Fig. 5.4, sec. 5.2.4, pg. 32 para. 2 – Tuomi teaches Nodes are identified in the database by their NodeId and the ServerURI of the server containing them – the same values used to identify nodes in configuration.) The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 8, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 1, and Tuomi discloses: wherein the OPC UA aggregation server additionally aggregates node-context from the remote address space (sec. 3.3 of Tuomi). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 9, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 2, and Tuomi discloses: wherein the aggregated data comprises object data and type data (Fig. 5.4, sec. 5.2.4, pg. 32 para. 1 – Tuomi teaches the requirements specify the aggregating server is able to consistently identify nodes, save, persist and retrieve their values, and to present them in the aggregating address space according to OPC UA Historical Data Access … The schema is amended with information on NodeId types and DataTypes to aid node identification and deserialization of stored values into their proper OPC UA DataTypes on the aggregating server.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 10, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 1, and Tuomi discloses: wherein the OPC UA aggregation server is configured to aggregate source names for events (sec. 33, pg. 13-14 – Tuomi teaches events have an EventType, which can be used to categorize and filter them); and wherein the OPC UA aggregation server is configured to import event override data, the override data defining an override of at least one property (Fig. 6.1; sec. 6.1, pg. 40, para. 1 – Tuomi teaches most functionality is implemented by overriding OPC UA service implementations in the SDK class NodeManager to alter the default behaviour. The overridden functions are supported by utility classes providing database connectivity, data structures for mappings, and run-time monitoring.), and to transform the at least one property by using the imported event override data (Fig. 6.1; sec. 6.1, pg. 40, para. 1 – Tuomi teaches most functionality is implemented by overriding OPC UA service implementations in the SDK class NodeManager to alter the default behaviour. The overridden functions are supported by utility classes providing database connectivity, data structures for mappings, and run-time monitoring.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 11, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 10, and Tuomi discloses: wherein the property is a source name (sec. 3.3, pg. 14 – Tuomi teaches use of data sources). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 12, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 10, and Tuomi discloses: wherein the aggregating OPC UA server is configured to: receive a client event subscription (Fig. 3.1, Subscription, sec. 3.3, pg. 14, para 1 of Tuomi); upon receiving the client event subscription, check, whether an operand of the event refers to an event-property for which an override rule is defined (Fig. 6.1; sec. 6.1, pg. 40, para. 1 – Tuomi teaches most functionality is implemented by overriding OPC UA service implementations in the SDK class NodeManager to alter the default behaviour. The overridden functions are supported by utility classes providing database connectivity, data structures for mappings, and run-time monitoring.) add an override rule to the operand (pg. 38-39 – Tuomi teaches that functionality can be overwritten in the SDK class NodeManager to alter behavior); when the OPC UA aggregation server receives an event, check the operand whether there is an override configured inside (pg. 13-15 – Tuomi teaches events, alarms and conditions; sec. 5.3.2, pg. 35 – Tuomi teaches the aggregating server monitoring event notifications; pg. 41, sec 6.1.3 – Tuomi teaches the that a node manager maps processes by reading the URI of devices from the configuration and creates clients to connect to them); and transform a value of the operand referred event-property according to the override rule before forwarding the event with an overridden property to an OPC UA client (pg. 38-39 – Tuomi teaches that functionality can be overwritten in the SDK class NodeManager to alter behavior). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 13, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 1, and Tuomi discloses: wherein the OPC UA aggregation server is configured to support redundancy types implementing an address space representation for redundant devices (Fig. 3.1, sec. 3.1 of Tuomi). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 14, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 13, and Tuomi discloses: wherein the OPC UA aggregation server is configured to support redundancy for identical devices and/or for different devices (Fig. 3.1, sec. 3.1 of Tuomi). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 15, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 13, and Tuomi discloses: wherein the OPC UA aggregation server is configured to support redundancy for at least one node of the redundant devices (Fig. 3.1, sec. 3.1 of Tuomi) The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 17, Tuomi, Dhakshinamoorthy and Schultz discloses: OPC UA aggregation server according to claim 1, and Tuomi discloses: wherein the OPC UA aggregation server is configured to filter data to aggregate only values of variables, method calls and events (sec. 3.3 – Tuomi teaches use of filters). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 18, Tuomi discloses: an Open Platform Communications Unified Architecture (OPC UA) aggregation system (Fig. 5.1, ch. 5, System Architecture), comprising: an OPC UA client configured to send a data request to an OPC UA aggregation server (Fig. 5.1, ch. 5.2.1-5.2.3 – Tuomi teaches the address space of the aggregating OPC UA server is the interface external clients connect to, this denotes the OPC UA server offers an I/F via which clients request remote address space and in which allocates the address space); an OPC UA aggregation server configured to aggregate at least one OPC UA server and provide OPC UA aggregated server data to the OPC UA client (ch. 3.5.1, pg. 18, para. 1-2 – Tuomi teaches that the amount of network traffic can significantly reduced (i.e., data reduction)); and an OPC UA aggregated server configured to provide the requested data to the OPC UA aggregation server; wherein the OPC US aggregation server is configured to: aggregate at least one OPC UA server in a remote address space (ch. 3.5.1, pg. 18, para. 1-2 – Tuomi teaches that the amount of network traffic can significantly reduced (i.e., data reduction)); wherein the at least one OPC UA server is configured for supporting data reduction and/or redundancy mechanisms (ch. 3.5.1, pg. 18, para. 1-2 – Tuomi teaches that the amount of network traffic can significantly reduced (i.e., data reduction)); Dhakshinamoorthy discloses what Tuomi does not expressly disclose. Dhakshinamoorthy discloses: wherein the OPC UA aggregation server is configured to store remote address space information of a current session (Fig. 3A, Address Space (Nodes), 332; Views, 334, Information Repository, 336; ¶0068, ¶0069, ¶0085 – Dhakshinamoorthy teaches that for each new session that is created by the session generator 350, the cached views 370 caches the views 372a-372n of the user who initiated the new session. In certain embodiments, the cached views 370 caches the views 372a-372n of the user for each new query of the user. Caching the views for each new query can provide real time data for the user; ¶0071 – Query server is a part of the OPC UA Server); wherein the session is related to an application and/or a OPC UA client (¶0079 – Dhakshinamoorthy teaches based on the identity of the user, the particular views 334 available to the user can be identified. Examiner Note: views 334 and 372 are similar, see ¶0082); and wherein the OPC UA aggregation server is configured to use the remote address space information in a next session for aggregating data (¶0079 – Dhakshinamoorthy teaches each session, such as session 352a that connects to the client session 354a allows the query engine 395 to identify the particular user of the computing device 310. Based on the identity of the user, the particular views 334 available to the user can be identified.). The suggestion/motivation and obviousness rejection is the same as in claim 1. Schultz discloses what Tuomi and Dhakshinamoorthy do not expressly disclose. Schultz discloses: wherein the data is filtered prior to being aggregating the data via a configurable traffic filter using self-tuning traffic optimization logic (¶0120, ¶0137 - Schultz teaches workflow items because the workflow items can be sorted, filtered, or aggregated according to the context (i.e., self-tuning); ¶0087, ¶0137 - Schultz teaches that a filter dialog may be opened and all field device components may be selected which are temperature transmitters (i.e., filtered). The aggregating workflow item can now change to show such field device components needing parameterization. (i.e., aggregate)). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 19, Tuomi and Dhakshinamoorthy discloses: OPC UA aggregation system according to claim 18, and Tuomi discloses: wherein the request of the OPC UA client comprises remote address space information for a requested subset of the aggregated address space (Fig. 5.1, ch. 5.2.1-5.2.3 – Tuomi teaches the address space of the aggregating OPC UA server is the interface external clients connect to, this denotes the OPC UA server offers an I/F via which clients request remote address space and in which allocates the address space); , and information supporting the OPC UA aggregation server to aggregate the data from the OPC UA aggregated server (ch. 3.5.1, pg. 18, para. 1-2 – Tuomi teaches that the amount of network traffic can significantly reduced (i.e., data reduction)). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 20, Tuomi and Dhakshinamoorthy discloses: OPC UA aggregation system according to claim 18, and Tuomi discloses: wherein the OPC UA aggregated server is configured to determine type data related to an object comprising object data (Fig. 5.4, sec. 5.2.4, pg. 32 para. 1 – Tuomi teaches the requirements specify the aggregating server is able to consistently identify nodes, save, persist and retrieve their values, and to present them in the aggregating address space according to OPC UA Historical Data Access … The schema is amended with information on NodeId types and DataTypes to aid node identification and deserialization of stored values into their proper OPC UA DataTypes on the aggregating server.). The suggestion/motivation and obviousness rejection is the same as in claim 1. As to claim 22, Tuomi discloses: a method for aggregating remote address space data in an Open Platform Communications Unified Architecture (OPC UA) system (Fig. 5.1, ch. 5, System Architecture), comprising: requesting, by an OPC UA client, remote address space data from an OPC UA aggregation server (Fig. 5.1, ch. 5.2.1-5.2.3 – Tuomi teaches the address space of the aggregating OPC UA server is the interface external clients connect to, this denotes the OPC UA server offers an I/F via which clients request remote address space and in which allocates the address space); aggregating, by an OPC UA aggregation server, remote address space data using data reduction and/or redundancy mechanisms (ch. 3.5.1, pg. 18, para. 1-2 – Tuomi teaches that the amount of network traffic can significantly reduced (i.e., data reduction)); providing, by an OPC UA aggregation server, the requested remote address space data to the OPC UA client (ch. 5.2.3 – Tuomi teaches mapping defines the connection between a node in the aggregating address space and its sources. It is created according to a configuration and used during runtime to retrieve and compute requested values. The mapping itself is a data structure enabling efficient addition and lookup of the source of a given node. Since services are used frequently, the performance of searching for a NodeId in a mapping is an important consideration. Hash maps were selected as the data structure for their constant-time performance on lookup and insertion operations. Each hash map maps a NodeId in the aggregating server’s local address space into a data source.); and presenting, by the OPC UA client, the requested remote address space data (sec. 4.2, pg. 22, para. 3 – Tuomi teaches a OPC UA client reading values which the OPC UA server interprets according to which node the client accesses in its address space; ch. 5.1, pg. 26, para. 1 – Tuomi teaches the aggregating server contains OPC UA clients able to connect to the OPC UA server of each aggregated device and access their address space.); Dhakshinamoorthy discloses what Tuomi does not expressly disclose. Dhakshinamoorthy discloses: wherein the OPC UA aggregation server is configured to store remote address space information of a current session (Fig. 3A, Address Space (Nodes), 332; Views, 334, Information Repository, 336; ¶0068, ¶0069, ¶0085 – Dhakshinamoorthy teaches that for each new session that is created by the session generator 350, the cached views 370 caches the views 372a-372n of the user who initiated the new session. In certain embodiments, the cached views 370 caches the views 372a-372n of the user for each new query of the user. Caching the views for each new query can provide real time data for the user; ¶0071 – Query server is a part of the OPC UA Server); wherein the session is related to an application and/or a OPC UA client (¶0079 – Dhakshinamoorthy teaches based on the identity of the user, the particular views 334 available to the user can be identified. Examiner Note: views 334 and 372 are similar, see ¶0082); and wherein the OPC UA aggregation server is configured to use the remote address space information in a next session for aggregating data (¶0079 – Dhakshinamoorthy teaches each session, such as session 352a that connects to the client session 354a allows the query engine 395 to identify the particular user of the computing device 310. Based on the identity of the user, the particular views 334 available to the user can be identified.). The suggestion/motivation and obviousness rejection is the same as in claim 1. Schultz discloses what Tuomi and Dhakshinamoorthy do not expressly disclose. Schultz discloses: wherein prior to aggregating the data, OPC UA aggregation server filters the data to be aggregated via a configurable traffic filter using self-tuning traffic optimization logic (¶0120, ¶0137 - Schultz teaches workflow items because the workflow items can be sorted, filtered, or aggregated according to the context (i.e., self-tuning); ¶0087, ¶0137 - Schultz teaches that a filter dialog may be opened and all field device components may be selected which are temperature transmitters (i.e., filtered). The aggregating workflow item can now change to show such field device components needing parameterization. (i.e., aggregate)); The suggestion/motivation and obviousness rejection is the same as in claim 1. Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Printed Publication, “Aggregating OPC UA Server for Flexible Manufacturing Systems” to Tuomi (”Tuomi”) in view of U.S. Patent Application No. 2019/0107827 A1 to Dhakshinamoorthy et al. (“Dhakshinamoorthy”) in further view of U.S. Patent Application No. 2020/0296632 A1 to Pudukoli et al. (“Pudukoli”). As to claim 21, Tuomi and Dhakshinamoorthy discloses: OPC UA aggregation system according to claim 18, Pudukoli discloses what Tuomi and Dhakshinamoorthy does not expressly disclose. Pudukoli discloses: wherein the OPC UA aggregated server comprises a software OPC UA server and a hardware accelerated OPC UA server, and wherein the hardware accelerated OPC UA server is configured to check upon a data request if hardware accelerated data is available; if yes the storage of the hardware accelerated OPC UA server is accessed for retrieving the requested data; if no, the storage of software OPC UA server is accessed for retrieving the requested data. (Fig. 5, ¶0055 – Pudukoli teaches that transmission queues in the control plane are presented as software as hardware accelerators present in the data plane may be unavailable. This denotes that hardware options will be considered first and if unavailable, the software version will be used) Tuomi, Dhakshinamoorthy and Pudukoli are analogous arts because they are from the same field of endeavor with respect to networked data transmissions. Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to incorporate physical and virtual assets as discussed in Pudukoli with the accessing stored address space information within a session as discussed in Dhakshinamoorthy with the OPC UA environment as discussed in Tuomi by adding the functionality of Pudukoli to the system/method of Tuomi and Dhakshinamoorthy in order to demonstrate that resources can be provided in both hardware and software forms and the priority of their access (Pudukoli, ¶0055). Conclusion 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 TAYLOR A ELFERVIG whose telephone number is (571)270-5687. The examiner can normally be reached Monday (10:00 AM CST) - Friday (4:00 PM CST). 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, Oscar Louie can be reached at (571) 270-1684. 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. /TAYLOR A ELFERVIG/Primary Examiner, Art Unit 2445
Read full office action

Prosecution Timeline

Sep 30, 2022
Application Filed
Feb 22, 2025
Non-Final Rejection — §103
May 27, 2025
Response Filed
Aug 29, 2025
Non-Final Rejection — §103
Nov 24, 2025
Response Filed
Jan 07, 2026
Final Rejection — §103
Mar 20, 2026
Request for Continued Examination
Apr 06, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12598146
SYSTEMS, METHODS, AND APPARATUSES FOR PREDICTING RESOURCE SHORTAGES USING MACHINE LEARNING
2y 5m to grant Granted Apr 07, 2026
Patent 12592902
CONTEXT-BASED SENSITIVE MESSAGE DETECTION
2y 5m to grant Granted Mar 31, 2026
Patent 12587495
Electronic Message Generation
2y 5m to grant Granted Mar 24, 2026
Patent 12568128
SYSTEM CONFIGURATION AND COMMUNICATION METHOD TO ENABLE POST ACQUIRED ABILITY TO CONTROL AND COMMUNICATE WITH AD-HOC DEVICES
2y 5m to grant Granted Mar 03, 2026
Patent 12556539
DETECTING MISCONFIGURATION OF GUEST ACCOUNT SECURITY PERMISSIONS
2y 5m to grant Granted Feb 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

4-5
Expected OA Rounds
62%
Grant Probability
99%
With Interview (+38.5%)
4y 0m
Median Time to Grant
High
PTA Risk
Based on 409 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in for Full Analysis

Enter your email to receive a magic link. No password needed.

Free tier: 3 strategy analyses per month