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 .
The office action is a response to Applicant’s Amendment filed January 14, 2026.
Claims 1, 8, 21 and 22 have been amended.
Claim 34 has been cancelled.
Claims 1, 6-9, 19-22, 26-33, 25 and 36 are now pending in the application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on November 14, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments with respect to claims have been considered but are moot because a new ground of rejection is appropriate, applying a new reference to teach the element that changes the scope of the previous claims, namely that the recited first message is now used by the target end to determine an optimal master clock, which had not particularly been required to determine in the prior claim version.
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, 6, 8, 21, 22, 26, 29, 33 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Sachs et al, U.S. Patent Application Publication No. 20200259896 A1 (hereinafter Sachs) in view of Chen et al, U.S. Patent Application Publication No. 20190173596 A1 (hereinafter Chen, related to International Patent Application Publication No. WO 2017198304 A1, previously included in Applicant’s Information Disclosure Statement).
Regarding Claim 1, Sachs discloses an information control method, performed by a first communications device being a device-side time-sensitive network translator (DS-TT) (e.g., FIG. 221, ¶ [2396], the method actions performed by the transmitting device, such as e.g. the UE 120… and/or the translator function, in a 3GPP wireless communication system 100, such as e.g. the 5G system, for handling gPTP signaling from the TSN [Sachs does not explicitly describe UE or translator as being device side translator function, DS-TT; but Examiner interprets that a translator (DS-TT) is integrated with the UE, as this scenario would have been obvious to one of ordinary skill, evidenced by examples of Lv et al, U.S. Patent Application Publication No. 20230091501 A1 (e.g., FIG. 2, ¶ [0069], DS-TT [may be] integrated into the UE]), and Minokuchi et al, U.S. Patent Application Publication No. 20220338142 A1 (e.g., FIGS. 2-4, ¶ [0083], DS-TT may be a function in the UE 10]), comprising: receiving a first message (e.g., FIG. 221, ¶ [2397] Action 1301: The transmitting device may receive, from the TSN network, a gPTP frame, such as e.g. an Announce message), wherein the first message is an announce message in a generalized precision time protocol (gPTP) or an announce message in a precision time protocol (PTP) (e.g., ¶ [2397] Action 1301: …a gPTP frame, such as e.g. an Announce message); performing a first operation, wherein the first operation comprises: sending the first message to a first target end (e.g., FIG. 221, ¶ [2398] Action 1302: The transmitting device may determine, based on the indication of the time domain and/or the MAC address, the receiving device which the gPTP frame relates to), wherein the first target end comprises at least one of a network-side time-sensitive network translator (NW-TT) or a user-plane function (UPF) (e.g., FIG. 221, ¶ [2402] Action 1304: The transmitting device may transmit, to the determined receiving device, such as e.g. the radio network node 110 or the UPF in UL… the gPTP frame in a PDU session related to the determined receiving device); the first message is used by the first target end to determine a second message (e.g., FIG. 222, ¶ [2403], FIG. 222 illustrates the method actions performed by the receiving device, such as…the radio network node 110, the UPF and/or the translator function, in the 3GPP wireless communication system 100 [Sachs does not explicitly describe translator as being network side translator function, NW-TT; but Examiner interprets that a translator (NW-TT) can be integrated with, e.g., UPF, as this scenario would have been obvious to one of ordinary skill, evidenced by examples of Lv, above (e.g., FIG. 2, ¶ [0069], NW-TT [may be] integrated into a UPF device), and Minokuchi, above (e.g., FIGS. 2-4, ¶ [0082], NW-TT may be a function in the UPF 50]; e.g., FIG. 222, ¶ [2405] Action 1402: The receiving device may determine, based on the indication of the time domain and/or the MAC address, one or more second end stations in the TSN network to transmit the received gPTP frame to; e.g., ¶ [2408] Action 1405: The receiving device may transmit, to the one or more second end stations in the TSN network, the gPTP frame); and receiving the second message sent by the first target end, wherein the second message is an announce message in a gPTP or an announce message in a PTP (e.g., FIG. 222, ¶ [2408] Action 1405: The receiving device may transmit, to the one or more second end stations in the TSN network, the gPTP frame [e.g., gPTP Announce message] [As established above, the end station, or device side, is UE, which may include the DS-TT function, and can be the device which transmitted gPTP frame to UPF or network side in FIG. 221]).
Sachs discloses that a PTP/gPTP Announce massage can be used to determine an optimal master clock(e.g., ¶ [2328] 5GS internal signaling is used to transport time information. In this case the 5GS may act as a gPTP time-aware device (which is defined to be compliant with an IEEE1588 boundary clock)—it may use ingress gPTP frames to get time aware itself or may have separate gPTP instances handling the 5G system clock and external TSN clocks. An internal signaling in the RAN and Core may be used to transport the relevant gPTP information internally and when received by the UE it may then act as a gPTP master at the UE egress. The 5GS in this case must support and participate in all Best Master Clock Algorithms (BMCAs) (one gPTP instance per gPTP domain must operate in this case) or being configured to its gPTP role by an external entity. A simplified option is possible where a static BMCA is implemented. The actual operation of the BMCA is out of the scope of this disclosure, but the solutions identified herein support the transfer of the related information received via Announce messages [i.e., BCMA related information may be sent via Announce in PTP (which is also explicitly described in other prior art examples, such as Wang et al, U.S. Patent Application Publication No. 20220216932 A1 (e.g., ¶ [0082] additional information provided by the Announce messages is also used to perform the Best Master Clock Algorithm (BMCA). BMCA is part of the (g)PTP standard (see, e.g., IEEE 1588, clause 6.6.2.3)]).
Sachs does not expressly disclose that the first message is used by the first target end to determine a second message, and the first message is used by the first target end to determine an optimal master clock; and receiving the second message sent by the first target end, wherein the second message is an announce message in a gPTP or an announce message in a PTP, and the second message is generated based on the first message.
Chen discloses the first message is used by the first target end to determine a second message (e.g., ¶ [0025] Upon receiving an Announce+ message [i.e., first message] with the teardown message, each clock must first of all carry out a cleansing action in the local database and must then select the best clock; e.g., ¶ [0027] confirm this receipt by transmitting an Announce+ message [i.e., second message]), and the first message is used by the first target end to determine an optimal master clock (e.g., ¶ [0027] In order to further increase the reliability, a clock which has received the new notification via one of its ports can confirm this receipt by transmitting an Announce+ message [i.e. second message] to the original transmitter containing the same announce message [i.e., generated based on the first message]); and receiving the second message sent by the first target end (i.e., reception of disclosed Announce+ by the end that had transmitted the first Announce+ message), wherein the second message is an announce message in a gPTP or an announce message in a PTP (In a PTP network, using the best master clock (BMC) algorithm (e.g., ¶ [0006]), BMCA+ is used to support the selection and maintenance of two best master clocks in a single gPTP domain. It uses so-called peer-to-peer Announce+ messages which contain the best master selection information for the best and second-best clocks (e.g., ¶ [0012])), and the second message is generated based on the first message (e.g., ¶ [0027] transmitting an Announce+ message [i.e. second message] to the original transmitter containing the same announce message [i.e., generated based on the first message]).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of receiving PTP based Announce message which enables calculation of best clock, as disclosed by Sachs, with the disclosure of receiving end responding with best clock information to the transmitting end with another PTP based Announce message, as disclosed by Chen. The motivation to combine would have been to support interchange and storage results of best clock information (Chen: e.g., ¶ [0013]).
Regarding Claim 6, Sachs in view of Chen discloses all the limitations of the method according to claim 1.
Sachs discloses wherein the first target end further comprises an access function (AF) (e.g., ¶ [2389] 3. The 5GS may receive, on the AF which may comprise the translator function).
Regarding Claim 8, Sachs discloses an information control method, performed by a second communications device being at least one of a network-side time-sensitive network translator (NW-TT) or a user-plane function (UPF) (e.g., FIG. 222, ¶ [2403], FIG. 222 illustrates the method actions performed by the receiving device, such as…the radio network node 110, the UPF and/or the translator function, in the 3GPP wireless communication system 100 [for reasons and examples given in examination of claim 1, the NW-TT function may be integrated into a UPF]), comprising: receiving a first message from at least one of a device-side time-sensitive network translator (DS-TT) port or a network-side time-sensitive network translator (NW-TT) port (e.g., FIG. 221, ¶ [2402] Action 1304: The transmitting device may transmit, to the determined receiving device, such as e.g. the radio network node 110 or the UPF in UL… the gPTP frame in a PDU session related to the determined receiving device); wherein the first message is an announce message in a generalized precision time protocol (gPTP) or an announce message in a precision time protocol (PTP) (e.g., ¶ [2397] Action 1301: …a gPTP frame, such as e.g. an Announce message); and performing a second operation based on the first message, wherein the second operation comprises: determining a second message (e.g., FIG. 222, ¶ [2405] Action 1402: The receiving device may determine, based on the indication of the time domain and/or the MAC address, one or more second end stations in the TSN network to transmit the received gPTP frame to…e.g., ¶ [2408] Action 1405: The receiving device may transmit, to the one or more second end stations in the TSN network, the gPTP frame); sending the second message to a second target end being at least one of a terminal, a UPF, a device-side time-sensitive network translator (DS-TT), or an AF (e.g., FIG. 222, ¶ [2408] Action 1405: The receiving device may transmit, to the one or more second end stations in the TSN network, the gPTP frame [e.g., gPTP Announce message] [As established above, the end station, or device side, is UE, which may include the DS-TT function, and can be the device which transmitted gPTP frame to UPF or network side in FIG. 221]); wherein the second message is an announce message in a gPTP or an announce message in a PTP (e.g., ¶ [2408] Action 1405: gPTP frame [e.g., gPTP Announce message]).
Sachs discloses that a PTP/gPTP Announce massage can be used to determine an optimal master clock(e.g., ¶ [2328] 5GS internal signaling is used to transport time information. In this case the 5GS may act as a gPTP time-aware device (which is defined to be compliant with an IEEE1588 boundary clock)—it may use ingress gPTP frames to get time aware itself or may have separate gPTP instances handling the 5G system clock and external TSN clocks. An internal signaling in the RAN and Core may be used to transport the relevant gPTP information internally and when received by the UE it may then act as a gPTP master at the UE egress. The 5GS in this case must support and participate in all Best Master Clock Algorithms (BMCAs) (one gPTP instance per gPTP domain must operate in this case) or being configured to its gPTP role by an external entity. A simplified option is possible where a static BMCA is implemented. The actual operation of the BMCA is out of the scope of this disclosure, but the solutions identified herein support the transfer of the related information received via Announce messages [i.e., BCMA related information may be sent via Announce in PTP (which is also explicitly described in other prior art examples, such as Wang et al, U.S. Patent Application Publication No. 20220216932 A1 (e.g., ¶ [0082] additional information provided by the Announce messages is also used to perform the Best Master Clock Algorithm (BMCA). BMCA is part of the (g)PTP standard (see, e.g., IEEE 1588, clause 6.6.2.3)]).
Sachs does not expressly disclose the second communication device performing a second operation comprising determining an optimal master clock..
Chen discloses performing a second operation based on the first message; wherein the second operation comprises: determining an optimal master clock (e.g., ¶ [0025] Upon receiving an Announce+ message [i.e., first message] with the teardown message, each clock must first of all carry out a cleansing action in the local database and must then select the best clock); e.g., ¶ [0027] confirm this receipt by transmitting an Announce+ message [i.e., second message]), determining a second message (e.g., ¶ [0027] a clock which has received the new notification via one of its ports can confirm this receipt by transmitting an Announce+ message [i.e. second message] to the original transmitter containing the same announce message [i.e., generated based on the first message]); sending the second message to a second target end (i.e., Transmission of disclosed Announce+ by the end that had received the first Announce+ message), wherein the second message is an announce message in a gPTP or an announce message in a PTP (i.e., in the PTP network, using the best master clock (BMC) algorithm (e.g., ¶ [0006]), BMCA+ is used to support the selection and maintenance of two best master clocks in a single gPTP domain. It uses so-called peer-to-peer Announce+ messages which contain the best master selection information for the best and second-best clocks (e.g., ¶ [0012])).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of receiving PTP based Announce message which enables calculation of best clock, as disclosed by Sachs, with the disclosure of receiving end responding with best clock information to the transmitting end with another PTP based Announce message, as disclosed by Chen. The motivation to combine would have been to support interchange and storage results of best clock information (Chen: e.g., ¶ [0013]).
Regarding Claim 21, Sachs in view of Chen discloses all the limitations of the method according to claim 8.
Sachs discloses wherein the second operation further comprises at least one of: generating a message priority vector based on a first message and/or a first port (Examiner interprets that message priority in time sensitive traffic – which may also be interpreted as meeting or achieving some QoS parameters -- would have been obvious to one of ordinary skill in the art at the time of the filing date. Sachs discloses that Time-Sensitive Networking provides guaranteed high-performance connectivity services for certain traffic flows (e.g., ¶ [0243]), ensures low latency without unforeseen queuing (e.g., ¶ [0726]), certain privileges are associated with TSN streams while frames not from prioritized TSN streams might be queued and delayed (e.g., ¶ [0746]), i.e., messages which support time sensitive traffic would be prioritized. As such, priority for received and transmitted PTP related messages are being interpreted as a message priority. Further, Examiner is relying on interpretation of a priority vector as information about a receiving port (which may indicate a port that receives a message) – which a priority vector described in Applicant’s detailed disclosure (e.g., ¶ [0226] of U.S. Patent Application Publication No. 20230164713 A1) may optionally include – to reason that Sachs discloses or fairly suggests a message priority vector generated by the recited second communications device, which receives the PTP Announce message and generates a second message (e.g., FIG. 222, ¶ [2404] Action 1401: The receiving device may receive, from a transmitting device,… gPTP frame (which had been reasoned in examination of claim 8 (e.g., ¶ [2397]) as Announce message); e.g., ¶ [2405] Action 1402: The receiving device may determine, based on the indication of the time domain and/or the MAC address, one or more second end stations in the TSN network to transmit the received gPTP frame to [i.e., Examiner reasons that determining the end station to receive the generated “second” message may be interpreted as determining the port that will receive the message]).
Regarding Claim 22, the claim is directed to a first communication device, as a DS-TT, that is configured for operations that are functionally similar to those performed by the first communication device, DS-TT, of claim 1. Therefore, the reasoning used in the examination of claim 1 shall be applied to claim 22. Sachs had disclosed a DS-TT with a processor, a memory, and a computer program stored on the memory and capable of running on the processor, the processor configured to read the computer program to perform recited operations (e.g., FIG. 124, ¶ [1290], FIG. 124 is a schematic block diagram of a UE 2500 according to some embodiments of the present disclosure. As illustrated, the UE 2500 includes one or more processors 2502 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 2504, and one or more transceivers 2506 each including one or more transmitters 2508 and one or more receivers 2510 coupled to one or more antennas 2512. In some embodiments, the functionality of the UE 2500 described above may be fully or partially implemented in software that is, e.g., stored in the memory 2504 and executed by the processor(s) 2502).
Regarding Claim 26, Sachs in view of Chen discloses all the limitations of the first communications device according to claim 22.
The functional limitations of Claim 26 are similar to claim 6. Therefore, the reasoning used in the examination of claim 6 shall be applied to claim 26.
Regarding Claim 29, Sachs in view of Chen discloses all the limitations of the method according to claim 1.
Sachs discloses wherein the first message comprises information about a first master clock (e.g., ¶ [1112], The UE acts as a master clock to the TSN end stations using the (g)PTP protocol and decides when working clock values need to be refreshed in the End Stations. The UE forwards all working clocks it receives to all end stations it manages (i.e. the end stations determine which working clocks they are interested in).
Sachs does not expressly disclose the second message comprises information about an optimal master clock.
Chen discloses the second message comprises information about an optimal master clock (e.g., ¶ [0025] Upon receiving an Announce+ message [i.e., first message] with the teardown message, each clock must first of all carry out a cleansing action in the local database and must then select the best clock); e.g., ¶ [0027] confirm this receipt by transmitting an Announce+ message [i.e., second message]).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of receiving PTP based Announce message which enables calculation of best clock, as disclosed by Sachs, with the disclosure of receiving end responding with best clock information to the transmitting end with another PTP based Announce message, as disclosed by Chen. The motivation to combine would have been to support interchange and storage results of best clock information (Chen: e.g., ¶ [0013]).
Regarding Claim 33, Sachs in view of Chen discloses all the limitations of the method according to claim 8.
The functional limitations of Claim 33 are similar to claim 29. Therefore, the reasoning used in the examination of claim 29 shall be applied to claim 33.
Regarding Claim 35, Sachs in view of Chen discloses all the limitations of the first communications device according to claim 22.
The functional limitations of Claim 35 are similar to claim 29. Therefore, the reasoning used in the examination of claim 29 shall be applied to claim 35.
Claims 7, 27, 30 and 36 are rejected under 35 U.S.C. 103 as being unpatentable over Sachs in view of Chen, in further view of Zhang et al, Chinese Patent Application Publication No. CN 103634208A (hereinafter Zhang, part of Applicant’s Information Disclosure Statement, using citations from translated document that is also part of IDS) in further view of Wang et al, Chinese Patent Application Publication No. CN 103139080 A (hereinafter Wang, part of Applicant’s Information Disclosure Statement, using citations from translated document that is also part of IDS).
Regarding Claim 7, Sachs in view of Chen discloses all the limitations of the method according to claim 1.
Sachs discloses higher priority TSN traffic and lower priority non-TSN traffic (e.g., ¶ [0746] [0751] [0777]), port configurations to handle prioritized traffic, particularly in context of gPTP rapid spanning tree (e.g., ¶ [2348] [2386] [2433]).
Sachs does not expressly disclose: obtaining second root information, wherein the second root information comprises at least one of the following: a second priority vector, information about a second port, or configuration information of a port status; performing a third operation based on the second root information or the second message; wherein the third operation comprises at least one of the following: adding egress port information to the obtained second message; generating a second message; sending the second message to a target port; generating a second priority vector; and replacing a port priority vector of the target port with a second priority vector, wherein the second priority vector is the generated second priority vector or the obtained second priority vector; wherein the second port comprises at least one of the following: a port for sending the second message, a port for sending the second priority vector, a port for sending the second root information, and a port whose port status is a master port, a designated port, or a sending port; and the second message is a message comprising information about an optimal root object.
Zhang discloses obtaining second root information (e.g., ¶ [0023], port priority vector of PTP port, message priority vector of PTP port [Examiner interprets root as being associated with priority vector]; e.g., ¶ [0062]-[0066], according to received Announce message, port role that the data of master priority vector and the port priority of each PTP port of this TC node vector determine that on this TC node, each PTP port is served; ¶ [0118]-[0122], whether more described interim message priority vector is consistent with the message priority vector of PTP port one, if inconsistent, execution step 602, if consistent, maintain the port role that on this TC node, each PTP port is served as constant, finish current flow process), wherein the second root information comprises at least one of the following: a second message or a second priority vector, information about a second port, or configuration information of a port status (e.g., ¶ [0118]-[0122], whether more described interim message priority vector is consistent with the message priority vector of PTP port one, if inconsistent, execution step 602, if consistent, maintain the port role that on this TC node, each PTP port is served as constant, finish current flow process [i.e., information about priority vector, port information, port role/status]), performing a third operation based on the second root information; wherein the third operation comprises at least one of the following: adding egress port information to the obtained second message; generating a second message; sending the second message to a target port; generating a second priority vector; and replacing a port priority vector of the target port with a second priority vector, wherein the second priority vector is the generated second priority vector or the obtained second priority vector (e.g., ¶ [0023], When receiving the Announce message of PTP regulation but not receiving TC message in the first setting-up time by the PTP port on this TC node in the second setting-up time, according to the Announce message of this reception… forming the port role that on the data of master priority vector and definite this TC node of the port priority of each PTP port of this TC node vector, each PTP port is served; e.g., ¶ [0062]-[0066], according to received Announce message, carry for form port role that the data of master priority vector and the port priority of each PTP port of this TC node vector determine that on this TC node, each PTP port is served [i.e., generating a message priority vector based on a first port and/or the first message]).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of considering prioritized traffic, as disclosed by Sachs in view of Chen, with the disclosure of action on messages according to particular optimum goals, as disclosed by Zhang. The motivation to combine would have been to prevent PTP transparent clock loops (Zhang: e.g., ¶ [0015]).
Zhang discloses a message priority vector and port priority vector (e.g., FIG. 6), but does not expressly disclose wherein the second port comprises at least one of the following: a port for sending the second message, a port for sending the second priority vector, a port for sending the second root information, and a port whose port status is a master port, a designated port, or a sending port; and the second message is a message comprising information about an optimal root object.
Wang discloses wherein the second port comprises at least one of the following: a port for sending the second message, a port for sending the second priority vector, a port for sending the second root information, and a port whose port status is a master port, a designated port, or a sending port; and the second message is a message comprising information about an optimal root object (e.g., [0075], device 2 back from its root port Port2 receiving the bridge ID change message sent by the device I from the designated port Port3 and Port5 transfer the bridge ID change message. device 2 from the received bridge ID change message old bridge ID is the bridge ID A and new bridge ID is bridge ID B, and replace-s each port (including the root port Port2 and designated ports Port3 and Port5) with bridge ID B. Bridge ID A In the port priority vector, where the port priority vector of Port:2 ls updated from {A,O,A,Pl.PZ} to {B,O,B,PLP2}, and then, device 2 Calculated according to the spanning tree protocol, s:ince the bridge ID Bis still the optimal bridge ID in the network, the .mot bridge ID in the calculated root priority vector {B,l ,B,P1.P2} is the bridge ID B, Port3 and Prot5 are designated ports; device 2 sends BPDUs from designated ports Port3 and Port5 respectively according to the calculated root priority vector, wherein the priority vector Port3 sends from the BPDU is {B, I, C, P3}, carried in the BPDU sent from Port5 priority vector is {B, I, C, P5}; e.g., ¶ [0076], later, when device 2 of the root port Port2 sent by the receiving device I {B, O, B, P1} of the BPDU, the port priority vector because Port2 held in bridge ID A has been replaced with a bridge ID B, the port priority vector of Port2 priority vector Port2 holds the received and matched, thus receives the BTOU transmitted repeatedly, namely for keep-alive of the spanning tree BPDU, the device 2 reset Port2 priority vector of the keep-alive time. thus Port2 of the priority vector is not overtime aging, then device 2 will not generate a BPDU with itself as the root bridge and sends out, so it will not cause topology flapping).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of considering a message priority vector and port priority vector, as disclosed by Sachs in view of Chen, in further view of Zhang, with the disclosure of action on messages according to particular optimum goals, as disclosed by Wang. The motivation to combine would have been to reduce network topology oscillation mused by bridge ID changes (Wang: e.g., ¶ [0031]).
Regarding Claim 27, Sachs in view of Chen discloses all the limitations of the first communications device according to claim 22.
The functional limitations of Claim 27 are similar to claim 7. Therefore, the reasoning used in the examination of claim 7 shall be applied to claim 27.
Regarding Claim 30, Sachs in view of Chen, in further view of Zhang discloses all the limitations of the method according to claim 19.
Sachs in view of Zhang does not expressly disclose wherein the performing a first operation comprises: in a case that a first condition is satisfied, performing the second-type operation of the first operation; wherein the first condition comprises that the message priority vector is superior to or equal to the port priority vector of the first port.
Wang discloses wherein the performing a first operation comprises: in a case that a first condition is satisfied, performing the second-type operation of the first operation; wherein the first condition comprises that the message priority vector is superior to or equal to the port priority vector of the first port (e.g., ¶ [0018], the port priority vector is a message received along with the port priority vector update: if the port receiving the message priority vector better than the port priority vector, the port priority vector is updated to the message priority vector, otherwise, the port priority vector remains unchanged; e.g., [0061], if the bridge ID change device is a bridge device, in which when a downstream network root bridge device receives the spanning tree protocol message, on the one hand, before the device in the downstream network has been updated port of each port according to the bridge ID change message priority vector. Namely, the old bridge ID in the port priority vector of the port is updated to the new ID, port priority vector of the priority vector, since the bridge ID is still network optimal bridge ID, so the device has received the spanning tree protocol message in the receiving port of the device is matched).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of considering a message priority vector and port priority vector, as disclosed by Sachs in view of Chen, in further view of Zhang, with the disclosure of action in the event that a message priority vector is greater than or equal to port priority vector, as disclosed by Wang. The motivation to combine would have been to reduce network topology oscillation mused by bridge ID changes (Wang: e.g., ¶ [0031]).
Regarding Claim 36, Sachs in view of Chen, in further view of Zhang discloses all the limitations of the first communications device according to claim 28.
The functional limitations of Claim 36 are similar to claim 30. Therefore, the reasoning used in the examination of claim 30 shall be applied to claim 36.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Sachs in view Chen, in further view of Wang.
Regarding Claim 9, Sachs in view of Wang discloses all the limitations of the method according to claim 8.
Sachs discloses higher priority TSN traffic and lower priority non-TSN traffic (e.g., ¶ [0746] [0751] [0777]), port configurations to handle prioritized traffic, particularly in context of gPTP rapid spanning tree (e.g., ¶ [2348] [2386] [2433]).
Sachs does not expressly disclose in a case that a second priority vector of a port is superior to or equal to a port priority vector of the port, setting a state of the port to be a master port state, a designated port state, or a sending port state.
Wang discloses in a case that a second priority vector of a port is superior to or equal to a port priority vector of the port, setting a state of the port to be a master port state, a designated port state, or a sending port state (e.g., ¶ [0060], device when calculating the port role, can be based on the existing spanning tree protocol calculation. Specifically, each vector component in priority vector sequentially comparing received by ports and port priority vector of the port, and numerical value is small, if the port priority vector than the received priority vector, ignoring the received priority vector, otherwise, port priority vector with the received priority vector updates received port, root priority vector of the computing device again and recalculating the role of each port. if the received BPDU from same one designated bridge (bridge of the opposite), then consider that it is better BPDU is received. receiving port of the BPDU has optimized root priority vector is calculated as the root port leading to the root bridge of the backup link other BPDU also receives the root priority vector of the port is calculated as replacement, that leads to the root bridge).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of the disclosure of considering prioritized traffic, as disclosed by Sachs in view of Chen, with the disclosure of action on messages according to particular optimum goals, as disclosed by Wang. The motivation to combine would have been to reduce network topology oscillation mused by bridge ID changes (Wang: e.g., ¶ [0031]).
Claims 19, 28 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Sachs in view of Chen, in further view of Zhang.
Regarding Claim 19, Sachs in view of Chen discloses all the limitations of the method according to claim 1.
Sachs does not expressly disclose: wherein the first operation further comprises at least one of: generating a message priority vector based on a first port and/or the first message; discarding the first message; or performing a second-type operation of the first operation; or sending first root information to a first target end; wherein the second-type operation of the first operation comprises at least one of the following: generating a path priority vector of the first root object based on the first port, the first message, and/or a path cost of a receiving port, or generating a path priority vector of the first root object based on the message priority vector and/or a path cost of a receiving port; or replacing a port priority vector of the first port with the message priority vector; the first root information comprises at least one of the following: the first message, the message priority vector, the port priority vector of a first port, the path priority vector of the first root object, information about the first port, or the path cost of the receiving port; the first port comprises a port for receiving the first message.
Zhang discloses wherein the first operation further comprises at least one of: generating a message priority vector based on a first port and/or the first message; discarding the first message; or performing a second-type operation of the first operation (e.g., ¶ [0023], When receiving the Announce message of PTP regulation but not receiving TC message in the first setting-up time by the PTP port on this TC node in the second setting-up time, according to the Announce message of this reception… forming the port role that on the data of master priority vector and definite this TC node of the port priority of each PTP port of this TC node vector, each PTP port is served; e.g., ¶ [0062]-[0066], according to received Announce message, carry for form port role that the data of master priority vector and the port priority of each PTP port of this TC node vector determine that on this TC node, each PTP port is served [i.e., generating a message priority vector based on a first port and/or the first message]);
or sending first root information to a first target end; wherein the second-type operation of the first operation comprises at least one of the following: generating a path priority vector of the first root object based on the first port, the first message, and/or a path cost of a receiving port, or generating a path priority vector of the first root object based on the message priority vector and/or a path cost of a receiving port (e.g., ¶ [0023], definite this TC node of the port priority of each PTP port of this TC node vector, each PTP port is served; ¶ [0062], master priority vector and the port priority of each PTP port of this TC node vector is determined the port role that on this TC node, each PTP port is served; ¶ [0137], system priority of TC node vector…optimum in the GM path priority vector that on this TC node, all PTP ports are corresponding; ¶ [0152], flow process shown in Fig. 6); or replacing a port priority vector of the first port with the message priority vector (e.g., ¶ [0122], port priority vector of PTP port one is updated to the message priority vector of PTP port one); the first root information comprises at least one of the following: the first message, the message priority vector, the port priority vector of a first port, the path priority vector of the first root object, information about the first port, or the path cost of the receiving port; the first port comprises a port for receiving the first message (e.g., FIG. 6, ¶ [0132], step 605, select global optimum's priority vector of optimum this TC of conduct node… path priority vector that all PTP ports are corresponding from current this TC of the system priority vector sum node of this TC node; ¶ [0136], step 605, select the mode of optimum global optimum's priority vector can adopt the port priority vector of PTP port one in similar step 603 and the odds of message priority vector mode; ¶ [0142], step 607 further comprises: each PTP port aiming at the TC node (in PTP port 2 as an example), the 4th class data in described global optimum priority vector, the 5th class data are updated to respectively the data that are associated with this TC node, the data that are associated with this PTP port 2, by the 4th class data after upgrading, the 5th class data, form a master priority vector together with primary sources to the three class data in described global optimum priority vector, the master priority vector of this PTP port 2 is updated to the master priority vector).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of considering prioritized traffic, as disclosed by Sachs in view of Chen, with the disclosure of action on messages according to particular optimum goals, as disclosed by Zhang. The motivation to combine would have been to prevent PTP transparent clock loops (Zhang: e.g., ¶ [0015]).
Regarding Claim 28, Sachs in view of Chen discloses all the limitations of the first communications device according to claim 22.
The functional limitations of Claim 28 are similar to claim 19. Therefore, the reasoning used in the examination of claim 19 shall be applied to claim 28.
Regarding Claim 32, Sachs in view of Chen, in further view of Zhang discloses all the limitations of the method according to claim 19.
Sachs does not expressly disclose wherein the first root information is sent to the first target end through a first data channel; and the first data channel is a data channel associated with the first port, or a data channel associated with any DS-TT port.
Zhang discloses wherein the first root information is sent to the first target end through a first data channel; and the first data channel is a data channel associated with the first port (e.g., ¶ [0023], When receiving the Announce message of PTP regulation but not receiving TC message in the first setting-up time by the PTP port on this TC node in the second setting-up time, according to the Announce message of this reception… forming the port role that on the data of master priority vector and definite this TC node of the port priority of each PTP port of this TC node vector, each PTP port is served; e.g., ¶ [0062]-[0066], according to received Announce message, carry for form port role that the data of master priority vector and the port priority of each PTP port of this TC node vector determine that on this TC node, each PTP port is served).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of considering prioritized traffic, as disclosed by Sachs in view of Chen, with the disclosure of action on messages according to particular optimum goals, as disclosed by Zhang. The motivation to combine would have been to prevent PTP transparent clock loops (Zhang: e.g., ¶ [0015]).
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Sachs in view of Chen, in further view of Zhang, in further view of Wang.
Regarding Claim 20, Sachs in view of Chen, in further view of Zhang discloses all the limitations of the method according to claim 19.
Sachs discloses a message priority vector and port priority vector (e.g., FIG. 6), but Sachs in view of Zhang does not expressly disclose wherein the discarding the first message comprises: in a case that a second condition is satisfied, discarding the first message; and/or, the method further comprises: in a case that the second condition is satisfied, skipping performing the second-type operation of the first operation; wherein the second condition comprises that the port priority vector of the first port is superior to or equal to the message priority vector.
Wang discloses wherein the discarding the first message comprises: in a case that a second condition is satisfied, discarding the first message; and/or, the method further comprises: in a case that the second condition is satisfied, skipping performing the second-type operation of the first operation; wherein the second condition comprises that the port priority vector of the first port is superior to or equal to the message priority vector (e.g., ¶ [0018, the port priority vector is a message received along with the port priority vector update: if the port receiving the message priority vector better than the port priority vector, the port priority vector is updated to the message priority vector, otherwise, the port priority vector remains unchanged; e.g., [0061], if the bridge ID change device is a bridge device, in which when a downstream network root bridge device receives the spanning tree protocol message, on the one hand, before the device in the downstream network has been updated port of each port according to the bridge ID change message priority vector. Namely, the old bridge ID in the port priority vector of the port is updated to the new ID, port priority vector of the priority vector, since the bridge ID is still network optimal bridge ID, so the device has received the spanning tree protocol message in the receiving port of the device is matched; e.g., ¶ [0066], as shown in Figure 3B, the port Port4 of the bridge ID A is the port of the root bridge priority vector {A, I, C, P3. P4} is not aging. The spanning tree protocol calculation and comparison Port6 does not Port4, result Port4 is still computing forming the designated root port, Port6 port, and outwards transmitting bridge ID A is the BPDU of the bridge, which carries {A, 2, D, P6}. and after device 2 Port5 receives the BPDU bridge ID A is the root of a better, but will be calculated as the root port, and other ports is transmitted in the root bridge ID A is BPDU. Port4 after the device 3 receives by the root bridge ID A is the root of the BPDU, and the port of the port priority vector comes from the same one sending bridge C, which received the port priority vector will be updated. result Port4 calculated as a root port, the port priority vector is {A, 3, C, P3, P4}.).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of considering a message priority vector and port priority vector, as disclosed by Sachs in view of Chen, in further view of Zhang, with the disclosure of action in the event that a message priority vector is greater than or equal to port priority vector, as disclosed by Wang. The motivation to combine would have been to reduce network topology oscillation mused by bridge ID changes (Wang: e.g., ¶ [0031]).
Claim 31 is rejected under 35 U.S.C. 103 as being unpatentable over Sachs in view of Chen, in further view of Zhang, in further view of Qiang et al, U.S. Patent Application Publication No. 20220353834 A1 (hereinafter Qiang.
Regarding Claim 31, Sachs in view of Chen, in further view of Zhang discloses all the limitations of the method according to claim 19.
Sachs does not expressly disclose wherein the first root information is comprised in a first container for sending; and the first container comprises one of the following: a port management information container of the first port and a management information container of the DS-TT.
Zhang discloses wherein the first root information is comprised in a first container for sending (e.g., ¶ [0023], When receiving the Announce message of PTP regulation but not receiving TC message in the first setting-up time by the PTP port on this TC node in the second setting-up time, according to the Announce message of this reception, carry for forming the port role that on the data of master priority vector and definite this TC node of the port priority of each PTP port of this TC node vector, each PTP port is served; e.g., ¶ [0062]-[0066], according to received Announce message, carry for form port role that the data of master priority vector and the port priority of each PTP port of this TC node vector determine that on this TC node, each PTP port is served).
Zhang discloses sending node and receiving node in a time sensitive network (e.g., FIG. 3; ¶ [0025] [0027] [0047] [0049], device for sending TC message through PTP port… data of the master priority vector of PTP port; ¶ [0055] [0064], receive TC message at [another ] TC node), but does not expressly disclose a DS-TT.
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of considering prioritized traffic, as disclosed by Sachs in view of Chen, with the disclosure of action on messages according to particular optimum goals, as disclosed by Zhang. The motivation to combine would have been to prevent PTP transparent clock loops (Zhang: e.g., ¶ [0015]).
Sachs in view of Chen, in further view of Zhang does not expressly disclose the first container comprises one of the following: a port management information container of the first port and a management information container of the DS-TT.
Qiang discloses the first container comprises one of the following: a port management information container of the first port and a management information container of the DS-TT (e.g., ¶ [0072], TSN time synchronization message from an upstream TSN node is sent by DS-TT and received by an NW-TT… For another example, in the wireless communication system, if a TSN time synchronization message from an upstream TSN node is received by a first DS-TT, the TSN time synchronization message is sent by the first DS-TT to an NW-TT, forwarded by the NW-TT to a second DS-TT in the wireless communication system, and sent by the second DS-TT to a downstream TSN node, the first apparatus may be the second DS-TT, and the second apparatus may be the first DS-TT [i.e., a DS-TT may send to another DS-TT, which may be a terminal (as seen in prior art example, Moon et al, No. 20210212069 A1 (e.g., ¶ [0120], may transmit… frame to the DS-TT/UE)]).
It would have been obvious to one of ordinary skill in the art at the time of the filing date to combine the disclosure of generating and sending a particular type of message in a time sensitive network, as disclosed by Sachs in view of Chen, in further view of Zhang, with the disclosure of target end being a network side time-sensitive networking adapter, as disclosed by Qiang. The motivation to combine would have been to reduce high processing costs of a wireless communication system during TSN synchronization (Qiang: e.g., ¶ [0006]).
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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. References considered relevant to this application are listed in the attached "Notice of References Cited” (PTO-892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VLADISLAV Y AGUREYEV whose telephone number is (571)272-0549. The examiner can normally be reached on Monday--Friday (9-5).
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, Sujoy Kundu can be reached on (571) 272-8586. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VLADISLAV Y AGUREYEV/Examiner, Art Unit 2471
/SUJOY K KUNDU/Supervisory Patent Examiner, Art Unit 2471