Prosecution Insights
Last updated: July 17, 2026
Application No. 18/380,629

Network Device, Time-Sensitive Network System and Auto-configuration Method Thereof

Final Rejection §103
Filed
Oct 16, 2023
Priority
Nov 24, 2022 — provisional 63/427,840
Examiner
COONEY, ADAM A
Art Unit
2458
Tech Center
2400 — Computer Networks
Assignee
Moxa Inc.
OA Round
2 (Final)
57%
Grant Probability
Moderate
3-4
OA Rounds
1y 4m
Est. Remaining
69%
With Interview

Examiner Intelligence

Grants 57% of resolved cases
57%
Career Allowance Rate
220 granted / 384 resolved
-0.7% vs TC avg
Moderate +12% lift
Without
With
+11.8%
Interview Lift
resolved cases with interview
Typical timeline
4y 1m
Avg Prosecution
15 currently pending
Career history
410
Total Applications
across all art units

Statute-Specific Performance

§101
0.4%
-39.6% vs TC avg
§103
87.7%
+47.7% vs TC avg
§102
10.0%
-30.0% vs TC avg
§112
0.8%
-39.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 384 resolved cases

Office Action

§103
DETAILED ACTION This Action is in response to Applicant’s amendment filed on 03/16/26. Claims 1, 9, 11, 21 and 23 have been amended. Claims 1-30 are pending. 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 . Response to Arguments The objection to claims 1, 11 and 23 has been withdrawn in view of the applicant’s amendment. Argument A) – The applicant argues, in regards to the 103 rejection of claim 1, that Sachs does not disclose “obtaining, by a first (OPC UA) client module, a TSN configuration of a stream”. In particular, the applicant states that Sachs does not disclose that a client obtains a TSN configuration of a stream and how the configuration is performed (see applicant’s remarks; pages 12 and 13). Response to argument A) – The examiner respectfully disagrees. The examiner notes that Sachs clearly discloses that OPC-UA is used over TSN. Sachs discloses OPC-UA is used over TSN (emphasis added) (see Sachs; paragraph 0124 and Figure 105). For the use in TSN, the OPC-UA standard is adapted (emphasis added) to be more deterministic and support TSN features (see Sachs; paragraph 1212). OPC-UA is also assumed to be used as a configuration-protocol in TSN (emphasis added) (see Sachs; paragraph 1213). A TSN application or a client of the TSN application uses at least one established TSN stream (emphasis added) (see Sachs; paragraph 1392). In other words, the OPC-UA configuration used over the TSN would necessarily be obtained in order for the client to use the TSN stream. Therefore, in regards to the claimed limitation, Sachs does in fact discloses “obtaining, by a first (OPC UA) client module, a TSN configuration of a stream” by OPC-UA being used as a configuration protocol over the TSN and a client of a TSN application using at least one TSN stream. As such, the rejection has been maintained. Argument B) - The applicant argues, in regards to the 103 rejection of claim 1, that Mehmedagic does not disclose “transmitting, by the first OPC UA client module, the TSN configuration to an OPC UA server module of a centralized user configuration (CUC) in the TSN system”. In particular, the applicant states that Mehmedagic does not disclose that the CUC includes an OPC UA server module nor that the OPC UA client transmits the TSN configuration to the CUC (see applicant’s arguments; pages 13 and 14). Response to argument B) – The examiner respectfully disagrees. The examiner notes that Mehmedagic clearly discloses communicating configuration information between a OPCUA client and OPCUA server. Mehmedagic discloses an OPCUA server is configured to subscribe/receive OPCUA messages from an OPCUA client that publish/send OPCUA messages (emphasis added) (see Mehmedagic; paragraph 0043). A mapping between the OPCUA connection and a TSN stream for the OPCUA server and OPCUA client is provided (emphasis added) (see Mehmedagic; paragraph 0046). A CUC is present to provide OPCUA connection configuration that carries the parameters required to provision the TSN stream (emphasis added) (see Mehmedagic; paragraph 0051). In other words, there is a connection mapped between an OPCUA server and OPCUA client in which messages, such as, configuration for a TSN stream is provided. Therefore, in regards to the claimed limitation, Mehmedagic does in fact disclose “transmitting, by the first OPC UA client module, the TSN configuration to an OPC UA server module of a centralized user configuration (CUC) in the TSN system” by transmitting messages, including configuration for a TSN stream, from a OPCUA client to a OPCUA server. As such, the rejection has been maintained. Argument C) - The applicant argues, in regards to the 103 rejection of claim 1, that Sachs does not disclose “obtaining, by the CUC, a routing information and scheduling of the stream according to the TSN configuration and a network topology”. In particular, the applicant states that Sachs independently discovers the network topology, and in comparison, in the instant application, the network topology is generated by a topology generation entity tool and transmitted to an OPC UA server module of the CUC by a second OPC UA client module. The CUC then forwards the network topology to the CNC (see applicant’s remarks; pages 14 an 15). Response to argument C) – The examiner respectfully disagrees. The examiner notes that it appears the applicant is arguing limitations not recited in the claim. This is supported by the applicant stating “in the instant application” rather than pointing to the claim limitation. The claim limitation merely recites “…according to the TSN configuration and a network topology”. The claim language does not specify how the network topology is generated and transmitted. Sachs discloses path and schedule computation of streams is performed from checking the physical network topology and configuration and sent to the CUC (see Sachs; paragraphs 1235-1238 and 1449). In other words, a path and schedule computation for streams is performed based on the network topology and configuration and is sent to the CUC. Therefore, in regards to the claimed limitation, Sachs does in fact disclose “obtaining, by the CUC, a routing information and scheduling of the stream according to the TSN configuration and a network topology” by performing path and schedule computation based on configuration and physical network topology. As such, the rejection has been maintained. Argument D) - The applicant argues, in regards to the 103 rejection of claim 1, that Mehmedagic does not disclose “sending, by the first OPC UA client module, a request to the OPC UA server to obtain the routing information and scheduling of the stream”. In particular, the applicant states that Mehmedagic does not disclose that the CUC includes an OPC UA server module, nor disclose that an OPC UA client sends a request to the CUC to obtain routing information and scheduling results of a stream (see applicant’s remarks; pages 15 and 16). Response to argument D) – The examiner respectfully disagrees. The examiner notes that Mehmedagic clearly discloses receiving messages for a defined schedule and specific paths of a TSN stream. Mehmedagic discloses a CNC provides a way for messages to be routed. The CNC is an application that defines a schedule for transmission of TSN frames and calculates specific paths (emphasis added) (see Mehmedagic; paragraph 0041). An OPCUA server is configured to subscribe/receive OPCUA messages from an OPCUA client that publish/send OPCUA messages (emphasis added) (see Mehmedagic; paragraph 0043). A mapping between the OPCUA connection and a TSN stream for the OPCUA server and OPCUA client is provided (emphasis added) (see Mehmedagic; paragraph 0046). A CUC is present to provide OPCUA connection configuration that carries the parameters required to provision the TSN stream (emphasis added) (see Mehmedagic; paragraph 0051). In other words, the OPCUA server receives a message, e.g. a request, from the OPCUA client for the defined schedule and specific paths of the TSN frame. Therefore, in regards to the claimed limitation, Mehmedagic does in fact disclose “sending, by the first OPC UA client module, a request to the OPC UA server to obtain the routing information and scheduling of the stream” by a defined schedule and specific path for the TSN stream being sent by the OPCUA client to the OPCUA server. As such, the rejection has been maintained. The applicant states that same arguments for claims 11 and 23, as well as, the corresponding dependent claims (see applicant’s remarks; page 16). As such, the same rationale discussed above regarding claim 1 applies equally as well to claims 11, 23 and the corresponding dependent claims. Claim Interpretation Regarding claims 5, 6, 9, 16, 17, 21, 26 and 27, the claims recite alternative language, i.e. using the term “or”, and as such, the Examiner interprets certain features to not be required due to the claim language listing the features in the alternative. The rejection below specifies the particular limitations. 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. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1-30 are rejected under 35 U.S.C. 103 as being unpatentable over Sachs et al. (U.S. 2020/0259896 A1) (applicant submitted prior art; see IDS filed 10/29/24) in view of Mehmedagic (U.S. 2022/0377144 A1). Regarding claim 1, Sachs discloses an auto-configuration method, used in a time-sensitive networking (TSN) system, the auto-configuration method comprising: obtaining, by a first Open Platform Communications Unified Architecture (OPC UA) client module, a TSN configuration of a stream (see Sachs; paragraphs 0124, 1212, 1213 and 1392; Sachs discloses OPC-UA is used over TSN. For the use in TSN, the OPC-UA standard is adapted. Further, OPC-UA is used as a configuration protocol in TSN. A TSN application or a client, i.e. “a first OPC UA client module”, uses a TSN stream, i.e. “obtaining…a TSN configuration of a stream”. In other words, the OPC-UA configuration used over the TSN would necessarily be obtained in order for the client to use the TSN stream); obtaining, by the CUC, a routing information and scheduling of the stream according to the TSN configuration and a network topology (see Sachs; paragraphs 1235-1238 and 1449; Sachs discloses path and schedule, i.e. “routing information and scheduling”, computation of streams is performed from checking the physical network topology, i.e. “network topology”, and configuration and sent to the CUC, i.e. “obtaining, by the CUC…”); configuring the routing information and scheduling of the stream to a plurality of end stations in the TSN system (see Sachs; paragraphs 1235-1238; Sachs discloses the computed path and schedule, i.e. “routing information and scheduling”, is sent in which end stations are configured, i.e. “configuring …to a plurality of end stations”, to start the traffic exchange). While Sachs discloses “TSN configuration” and “routing information and scheduling of streams”, as discussed above, Sachs does not explicitly disclose transmitting, by the first OPC UA client module, the TSN configuration to an OPC UA server module of a centralized user configuration (CUC) in the TSN system; and sending, by the first OPC UA client module, a request to the OPC UA server to obtain the routing information and scheduling of the stream. In analogous art, Mehmedagic discloses transmitting, by the first OPC UA client module, the TSN configuration to an OPC UA server module of a centralized user configuration (CUC) in the TSN system (see Mehmedagic; paragraphs 0043, 0046, 0051 and Figure 1; Mehmedagic discloses an OPCUA client, i.e. “first OPC UA client module”, has a connection mapped with a OPCUA server via a CUC, i.e. “OPC UA server module of a CUC”, for communicating information, such as configuration, of a TSN stream, i.e. “transmitting…TSN configuration”. The OPCUA server receives the message from the OPCUA client via the connection and a TSN stream and the CUC provides OPCUA connection configuration. In other words, messages, including configuration for a TSN stream via the CUC, are transmitted from an OPCUA client to an OPCUA server); and sending, by the first OPC UA client module, a request to the OPC UA server to obtain the routing information and scheduling of the stream (see Mehmedagic; paragraphs 0041, 0043, 0046, 0051 and Figure 1; Mehmedagic discloses receiving messages, i.e. “a request”, for a defined schedule and specific paths of TSN frames for the stream, i.e. “routing information and scheduling of the stream”). One of ordinary skill in the art would have been motivated to combine Sachs and Mehmedagic because they both disclose features of TSN connection in an industrial network, and as such, are within the same environment. Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Mehmedagic’s management of an industrial network into the system of Sachs in order to provide the benefit of scalability by extending OPCUA to reduce system complexity and ease of system design and operations (see Mehmedagic; paragraph 0004). Regarding claim 2, Sachs and Mehmedagic disclose all the limitations of claim 1, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses being executed to obtain the routing information and scheduling of the stream off-line and configure the routing information and scheduling of the stream to the plurality of end stations after the plurality of end stations are online (see Sachs; paragraphs 1234-1238, 1407 and 1473; Sachs discloses performing path and schedule computation of streams and then configuring end stations when connected, i.e. “plurality of end stations are online”. The determination of the TSN features, e.g. path and scheduling, happens before a connected mode, i.e. “stream off-line”). Regarding claim 3, Sachs and Mehmedagic disclose all the limitations of claim 1, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses transmitting, by a second OPC UA client module, the network topology to the OPC UA server module of the CUC in the TSN system (see Sachs; paragraphs 1232, 1234, 1235-1238 and 1449; Sachs discloses sending the physical network topology, i.e. “network topology”, and configuration to the CUC, i.e. “the network topology to… the CUC”; Further, Mehmedagic discloses the “OPC UA server” with a CUC; see Mehmedagic; paragraph 0043 and Figures 1 and 4). The prior art used in the rejection of the current claim is combined using the same motivation as was applied in claim 1. Regarding claim 4, Sachs and Mehmedagic disclose all the limitations of claim 3, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses wherein the network topology is built by a topology generation entity tool (see Sachs; paragraph 1229, 1232 and 2273; Sachs discloses the use of an engineering tool, i.e. “generation entity tool”, to discover the physical network topology). Regarding claim 5, Sachs and Mehmedagic disclose all the limitations of claim 1, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses wherein the step of the first OPC UA client module obtaining the TSN configuration of the stream comprises: importing, by an engineering tool, a configuration data comprising an OPC UA configuration descriptor (see Sachs; paragraphs 1213 and 1229; Sachs discloses OPC UA configuration protocol, i.e. “OPC UA configuration descriptor”, and the engineering tool specifies to exchange time-sensitive streams) or an IEC/IEEE 60802 digital data sheet (see Sachs; paragraph 1214; Sachs discloses supporting the OPC UA including TSN down to field level initiative to work in IEC/IEEE 60802) (The claim list features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art. The Examiner has chosen both alternatives); and converting, by the engineering tool, the configuration data into the TSN configuration available for the first OPC UA client (see Sachs; paragraphs 1212, 1213 and 1229; Sachs discloses using OPC-UA as a configuration protocol in TSN and using the engineering tool). Regarding claim 6, Sachs and Mehmedagic disclose all the limitations of claim 5, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses wherein the step of configuring the routing information and scheduling of the stream to the plurality of end stations in the TSN system comprises: configuring, by the engineering tool, the routing information and scheduling of the stream to the plurality of end stations through respective protocols comprising PROFINET, EtherNet/IP, EtherCAT, CC-Link IE, PowerLink, Sercos or OPC UA (see Sachs; paragraph 1213 and 1235-1238; Sachs discloses OPC-UA used as a configuration protocol in TSN. And the computed path and schedule, i.e. “routing information and scheduling”, is sent in which end stations, i.e. “plurality of end stations”, are configured to start the traffic exchange) (The claim list features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art. The Examiner has chosen the “OPC UA” alternative). Regarding claim 7, Sachs and Mehmedagic disclose all the limitations of claim 1, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses wherein the step of the first OPC UA client module obtaining the TSN configuration of the stream comprises: obtaining, by a master controller belonging to the plurality of end stations, QoS information of other slave controllers through OPC UA connection manager (see Mehmedagic; paragraphs 0070, 0072 and 0073; Mehmedagic discloses a first controller, i.e. “master controller”, receiving QoS latency data from other controllers, i.e. “other slave controllers”, through an OPCUA connection); and converting, by the master controller, the QoS information into the TSN configuration available for the first OPC UA client (see Mehmedagic; paragraphs 0070, 0072, 0073 and 0075; Mehmedagic discloses the first controller converting the QoS latency data into TSN parameters, i.e. “TSN configuration”, for the OPCUA client). The prior art used in the rejection of the current claim is combined using the same motivation as was applied in claim 1. Regarding claim 8, Sachs and Mehmedagic disclose all the limitations of claim 7, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses wherein the step of configuring the routing information and scheduling of the stream to the plurality of end stations in the TSN system comprises: configuring, by the master controller, the routing information and scheduling of the stream to the plurality of end stations through OPC UA connection manager (see Mehmedagic; paragraphs 0041, 0043, 0070 and 0075; Mehmedagic discloses configuring a defined schedule and specific paths of the TSN frames, i.e. “routing information and scheduling of the stream” for a OPCUA connection). The prior art used in the rejection of the current claim is combined using the same motivation as was applied in claim 1. Regarding claim 9, Sachs and Mehmedagic disclose all the limitations of claim 1, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses wherein the step of the CUC obtaining the routing information and scheduling of the stream according to the TSN configuration and the network topology comprises: transmitting, by the CUC, the TSN configuration and the network topology to a centralized network configuration (CNC) in the TSN system according to IEEE 802.1Qdj (see Sachs; paragraphs 1233, 1235-1238 and 1449; Sachs discloses a CNC uses IEEE 802.1Q to send the physical network topology, i.e. “network topology”, and configuration for the TSN stream), representational state transfer (REST) (see Sachs; paragraph 2219; Sachs discloses using the REST protocol), or a vendor specific API (The claim list features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art. The Examiner has chosen the “IEE 802.1Qdj” and “REST” alternatives); and transmitting, by the CNC, the routing information and scheduling of the stream to the CUC according to IEEE 802.1Qdj (see Sachs; paragraphs 1233, 1235-1238 and 1449; Sachs discloses a CNC uses IEEE 802.1Q to send the path and schedule computation, i.e. “routing information and scheduling”, of the TSN stream), representational state transfer (REST) (see Sachs; paragraph 2219; Sachs discloses using the REST protocol) or the vendor specific API (The claim list features in the alternative. While the claim lists a number of optional limitations only one limitation from the list is required and needs to be met by the prior art. The Examiner has chosen the “IEE 802.1Qdj” and “REST” alternatives). Regarding claim 10, Sachs and Mehmedagic disclose all the limitations of claim 7, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses deploying, by the CNC, configurations relative to the routing information and scheduling of the stream to a plurality of TSN bridges in the TSN system after the plurality of TSN bridges are online (see Sachs; paragraphs 1235 and 1236; Sachs discloses the CNC performs path and schedule, i.e. “routing information and scheduling” computation of streams and configures TSN features in bridges, i.e. “TSN bridges are online”, along the computed path in the, e.g., configuration of the transmission schedule). Regarding claim 11, Sachs a time-sensitive networking (TSN) system for an auto-configuration method, comprising: a first OPC UA client module (see Sachs; paragraphs 1213 and 1392; Sachs discloses OPC-UA is used as a configuration protocol in TSN and a TSN application or a client, i.e. “a first OPC UA client module”); a plurality of end stations (see Sachs; paragraph 1238; Sachs discloses end stations); wherein the auto-configuration method comprises: obtaining, by the first OPC UA client module, a TSN configuration of a stream (see Sachs; paragraphs 1213 and 1392; Sachs discloses OPC-UA is used for the TSN application or a client, i.e. “a first OPC UA client module”, uses a TSN stream, i.e. “obtaining…a TSN configuration of a stream”); obtaining, by the CUC, a routing information and scheduling of the stream according to the TSN configuration and a network topology (see Sachs; paragraphs 1235-1238 and 1449; Sachs discloses path and schedule, i.e. “routing information and scheduling”, computation of streams is performed from checking the physical network topology, i.e. “network topology”, and configuration and sent to the CUC, i.e. “obtaining, by the CUC…”); configuring the routing information and scheduling of the stream to the plurality of end stations (see Sachs; paragraphs 1235-1238; Sachs discloses the computed path and schedule, i.e. “routing information and scheduling”, is sent in which end stations are configured, i.e. “configuring …to a plurality of end stations”, to start the traffic exchange). While Sachs discloses “TSN configuration” and “routing information and scheduling of streams”, as discussed above, Sachs does not explicitly disclose a centralized user configuration (CUC), comprising an OPC UA server module; transmitting, by the first OPC UA client module, the TSN configuration to an OPC UA server module of a centralized user configuration (CUC) in the TSN system; and sending, by the first OPC UA client module, a request to the OPC UA server to obtain the routing information and scheduling of the stream. In analogous art, Mehmedagic discloses a centralized user configuration (CUC), comprising an Open Platform Communications Unified Architecture (OPC UA) server module (see Mehmedagic; paragraphs 0043 and 0044; Mehmedagic discloses a CUC with a OPC UA server); transmitting, by the first OPC UA client module, the TSN configuration to the OPC UA server module of the CUC (see Mehmedagic; paragraphs 0043, 0046, 0051 and Figure 1; Mehmedagic discloses an OPCUA client, i.e. “first OPC UA client module”, has a connection with a OPCUA server via a CUC, i.e. “OPC UA server module of a CUC”, for communicating information, such as configuration, of a TSN stream, i.e. “transmitting…TSN configuration”); and sending, by the first OPC UA client module, a request to the OPC UA server to obtain the routing information and scheduling of the stream (see Mehmedagic; paragraphs 0041, 0043, 0046, 0051 and Figure 1; Mehmedagic discloses receiving messages, i.e. “a request”, for a defined schedule and specific paths of TSN frames for the stream, i.e. “routing information and scheduling of the stream”). One of ordinary skill in the art would have been motivated to combine Sachs and Mehmedagic because they both disclose features of TSN connection in an industrial network, and as such, are within the same environment. Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Mehmedagic’s management of an industrial network into the system of Sachs in order to provide the benefit of scalability by extending OPCUA to reduce system complexity and ease of system design and operations (see Mehmedagic; paragraph 0004). Regarding claim 12, the limitations recited are similar to the limitations recited in claim 2, as such, the same rationale used to reject claim 2 applies equally as well to claim 12. Regarding claim 13, the limitations recited are similar to the limitations recited in claim 3, as such, the same rationale used to reject claim 3 applies equally as well to claim 13. Regarding claim 14, the limitations recited are similar to the limitations recited in claim 4, as such, the same rationale used to reject claim 4 applies equally as well to claim 14. Regarding claim 15, Sachs and Mehmedagic disclose all the limitations of claim 7, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses a network device configured as an engineering tool (see Sachs; paragraphs 1213 and 1229; Sachs discloses OPC UA configuration protocol, i.e. “OPC UA configuration descriptor”, and an engineering tool used to specify to exchange time-sensitive streams). Regarding claim 16, the limitations recited are similar to the limitations recited in claim 5, as such, the same rationale used to reject claim 5 applies equally as well to claim 16. Regarding claim 17, the limitations recited are similar to the limitations recited in claim 6, as such, the same rationale used to reject claim 6 applies equally as well to claim 17. Regarding claim 18, Sachs and Mehmedagic disclose all the limitations of claim 7, as discussed above, and further the combination of Sachs and Mehmedagic clearly discloses wherein the first OPC UA client module is deployed in a master controller belonging to the plurality of end stations (see Mehmedagic; paragraphs 0070, 0072, 0073 and Figure 3; Mehmedagic discloses a first controller, i.e. “master controller” through an OPCUA connection). Regarding claim 19, the limitations recited are similar to the limitations recited in claim 7, as such, the same rationale used to reject claim 7 applies equally as well to claim 19. Regarding claim 20, the limitations recited are similar to the limitations recited in claim 8, as such, the same rationale used to reject claim 8 applies equally as well to claim 20. Regarding claim 21, the limitations recited are similar to the limitations recited in claim 9, as such, the same rationale used to reject claim 9 applies equally as well to claim 20. Regarding claim 22, the limitations recited are similar to the limitations recited in claim 10, as such, the same rationale used to reject claim 10 applies equally as well to claim 20. Regarding claim 23, Sachs discloses a network device in a time-sensitive networking (TSN) system, configured to have a first Open Platform Communications Unified Architecture (OPC UA) client module, the network device comprising: a processing unit, configured to execute a program code (see Sachs; paragraphs 1286 and 1288; Sachs discloses one or more processors to execute instructions); and a storage unit, coupled to the processing unit, configured to store the program code to instruct the processing unit to execute an auto-configuration method (see Sachs; paragraph 1286 and 1288; Sachs discloses memory with the one or more processor o store the instructions executed by the at least one processor), wherein the auto-configuration method comprises: obtaining, by the first OPC UA client module, a TSN configuration of a stream (see Sachs; paragraphs 1213 and 1392; Sachs discloses OPC-UA is used as a configuration protocol in TSN. A TSN application or a client, i.e. “a first OPC UA client module”, uses a TSN stream, i.e. “obtaining…a TSN configuration of a stream”); configuring the routing information and scheduling of the stream to a plurality of end stations in the TSN system (see Sachs; paragraphs 1235-1238; Sachs discloses the computed path and schedule, i.e. “routing information and scheduling”, is sent in which end stations are configured, i.e. “configuring …to a plurality of end stations”, to start the traffic exchange). While Sachs discloses “TSN configuration” and “routing information and scheduling of streams”, as discussed above, Sachs does not explicitly disclose transmitting, by the first OPC UA client module, the TSN configuration to an OPC UA server module of a centralized user configuration (CUC) in the TSN system; and sending, by the first OPC UA client module, a request to the OPC UA server to obtain the routing information and scheduling of the stream. transmitting, by the first OPC UA client module, the TSN configuration to an OPC UA server module of a centralized user configuration (CUC) in the TSN system (see Mehmedagic; paragraphs 0043, 0046, 0051 and Figure 1; Mehmedagic discloses an OPCUA client, i.e. “first OPC UA client module”, has a connection with a OPCUA server via a CUC, i.e. “OPC UA server module of a CUC”, for communicating information, such as configuration, of a TSN stream, i.e. “transmitting…TSN configuration”); sending, by the first OPC UA client module, a request to the OPC UA server to obtain routing information and scheduling of the stream (see Mehmedagic; paragraphs 0041, 0043, 0046, 0051 and Figure 1; Mehmedagic discloses receiving messages, i.e. “a request”, for a defined schedule and specific paths of TSN frames for the stream, i.e. “routing information and scheduling of the stream”). One of ordinary skill in the art would have been motivated to combine Sachs and Mehmedagic because they both disclose features of TSN connection in an industrial network, and as such, are within the same environment. Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate Mehmedagic’s management of an industrial network into the system of Sachs in order to provide the benefit of scalability by extending OPCUA to reduce system complexity and ease of system design and operations (see Mehmedagic; paragraph 0004). Regarding claim 24, the limitations recited are similar to the limitations recited in claims 2 and 12, as such, the same rationale used to reject claims 2 and 12 applies equally as well to claim 24. Regarding claim 25, the limitations recited are similar to the limitations recited in claim 15, as such, the same rationale used to reject claim 15 applies equally as well to claim 25. Regarding claim 26, the limitations recited are similar to the limitations recited in claims 5 and 16, as such, the same rationale used to reject claims 5 and 16 applies equally as well to claim 26. Regarding claim 27, the limitations recited are similar to the limitations recited in claims 6 and 17, as such, the same rationale used to reject claims 6 and 17 applies equally as well to claim 27. Regarding claim 28, the limitations recited are similar to the limitations recited in claim 18, as such, the same rationale used to reject claim 18 applies equally as well to claim 28. Regarding claim 29, the limitations recited are similar to the limitations recited in claims 7 and 19, as such, the same rationale used to reject claims 7 and 19 applies equally as well to claim 29. Regarding claim 30, the limitations recited are similar to the limitations recited in claims 8 and 20, as such, the same rationale used to reject claims 8 and 20 applies equally as well to claim 20. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Gotz et al. (U.S. 2020/0322461 A1) discloses industrial communication via a TSN and automatic configuration. Ha et al. (U.S. 2022/0095153 A1) discloses a QoS flow for a time sensitive communication. Mannweiler et al. (U.S. 2021/0306901 A1) discloses a TSN translator function for transparent usage of a wireless connection service and to hide specific behavior of the 3GPP network to the TSN network and vice versa. 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 ADAM A COONEY whose telephone number is (571)270-5653. The examiner can normally be reached M-F 7:30am-5:00pm (every other Fri off). 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, Umar Cheema can be reached at 571-270-3037. 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. /A.A.C/Examiner, Art Unit 2458 05/30/26 /UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458
Read full office action

Prosecution Timeline

Oct 16, 2023
Application Filed
Dec 18, 2025
Non-Final Rejection mailed — §103
Mar 16, 2026
Response Filed
Jun 04, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12675772
SCALABLE METHODS AND SYSTEMS FOR AI-FACILITATED VIDEO-CONFERENCING AMONG LARGE CONVERSATIONAL HUMAN GROUPS
1y 7m to grant Granted Jul 07, 2026
Patent 12652339
METHODS AND SYSTEMS FOR MANAGING MULTIPATH COMMUNICATION
2y 7m to grant Granted Jun 09, 2026
Patent 12652261
SYSTEM AND METHOD FOR AI-MEDIATED CONVERSATIONS AMONG LARGE NETWORKED POPULATIONS
1y 7m to grant Granted Jun 09, 2026
Patent 12647341
ROUTE GENERATION METHOD AND DEVICE
1y 11m to grant Granted Jun 02, 2026
Patent 12634250
METHOD AND SYSTEM FOR ENABLING REAL-TIME AI-FACILITATED CONVERSATION AMONG LARGE NETWORKED HUMAN GROUPS
1y 6m to grant Granted May 19, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
57%
Grant Probability
69%
With Interview (+11.8%)
4y 1m (~1y 4m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 384 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

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

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month