CTNF 18/768,829 CTNF 91320 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Information Disclosure Statement The information disclosure statements (IDS) submitted on 07/10/2024 has been placed in record and considered by the examiner. Duplicate Claims, Objection 07-05-06 Claim 13 objected under 37 CFR 1.75 as being a substantial duplicate of claim 9 . When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m) . Claim Rejections - 35 USC § 103 07-20-aia AIA 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 of this title, 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. 07-20-02-aia AIA 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. 07-21-aia AIA Claim s 1-3, 5-6, 8, 11-12, 14-16 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Herber et al. (US 20200280383 A1, hereinafter 'HERBER') in view of Tzeng; Shr-Jie (US 9769047 B2, of IDS, hereinafter ‘TZENG’) and with further in view of MATSUNAGA et al. (US 20240373382 A1 with priority of PCT/JP2022/006449, hereinafter ‘MATSUNAGA’) . Regarding claim 1 , HERBER teaches a computer-implemented method for synchronizing timing between two different time synchronization stacks connected by a timing synchronization connector ( Fig. 1, [0037] FIG. 1 depicts a network 100 , such as an in-vehicle network (IVN) that is configured to use, for example, IEEE 802.1AS (e.g., gPTP), to enable distributed clock synchronization. The network includes various nodes that include end stations 102 - 1 - 102 - 6 and bridges 104 - 1 - 104 - 6 . The end stations may include, for example, various electronic control units (ECUs)…… FIG. 1 also includes two clock sources (clock source 110 - 1 and clock source 110 - 2 ) and various clock targets 112 - 1 - 112 - 6 that are associated with the end stations…… In the example network, each clock source is used to establish two gPTP clock domains that are distributed throughout the network (taking separate paths for the best possible redundancy). Fig. 2, [0039] In order to maintain synchronization of the end stations with the grandmaster, a synchronization operation is performed. The synchronization operation is performed, in part, by the grandmaster periodically transmitting synchronization (or “sync”) messages and follow-up messages (e.g., via Ethernet frames) and, in part, by bridges or end stations computing a local clock time based on information from the follow-up messages and a locally computed network propagation delay. ….. FIG. 2 illustrates the transmission of sync and follow-up messages from a grandmaster 202 - 1 to bridges 204 - 1 and 204 - 2 and to an end station 202 - 2 in the network….. [0051] At each end station that is designated as a slave device with regard to clock information, synchronization information that is distributed throughout the network (e.g., as specified by IEEE 801.2AS), is used to adjust the clock at the slave device (sometimes referred to as the “slave clock”) so that the slave clock is synchronized with the clock of the grandmaster), the method comprising: receiving, at a first virtual Ethernet controller of the timing synchronization connector ( Fig. 2, Bridge 1 receiving message sent at 210) , a frame transmit request from a first time synchronization stack connected to the timing synchronization connector ( Fig. 2, [0039] At time 210 , a sync message can be sent from the grandmaster to bridge 1 and, at time 212 a follow-up message carrying an initial clock time can subsequently be sent. Bridge 1 can then compute a local clock time by adding the propagation delay between the grandmaster and bridge 1 to the clock time. Bridge 1 can then forward the sync message to bridge 2 at time 214 and compute a clock time to transmit in a follow-up message at time 216 to bridge 2 ) ; generating, at a virtual timestamp module of the timing synchronization connector, a sampled timestamp value for the frame transmit request by sampling a hardware counter ( Fig. 2, ΔL1, ΔS1, ΔL2, ΔS2 [0039] bridges or end stations computing a local clock time based on information from the follow-up messages and a locally computed network propagation delay ….… Bridge 1 can then forward the sync message to bridge 2 at time 214 and compute a clock time to transmit in a follow-up message at time 216 to bridge 2 . The process can be repeated to send a sync message to the end station at time 218 and a follow-up message to the end station at time 220 . The clock time to transmit in a follow-up message can be the source GM clock time plus the correction for accumulated network propagation delay and accumulated residence time. The network propagation delay can be computed from a follow-up message based on the propagation delay of a message between two nodes (e.g., between the grandmaster and bridge 1 ), residence time of a message within a node (e.g., within bridge 1 ), and a rate ratio between bridges or end stations in the network with respect to the grandmaster (e.g., a rate ratio between bridge 1 204 - 1 and end station 202 - 2 ). (Construed that a sampled timestamp values ΔL1, ΔS1, ΔL2, ΔS2 are generated for the frame transmit request by sampling a hardware counter or clock at respective bridges)) ; forwarding, over a second virtual Ethernet controller of the timing synchronization connector, the sampled timestamp value for the frame transmit request along with the frame transmit request to a second time synchronization stack connected to the timing synchronization connector ( [0039] … Bridge 1 can then forward the sync message to bridge 2 at time 214 and compute a clock time to transmit in a follow-up message at time 216 to bridge 2 . The process can be repeated to send a sync message to the end station at time 218 and a follow-up message to the end station at time 220 ……. The network propagation delay can be computed from a follow-up message based on the propagation delay of a message between two nodes (e.g., between the grandmaster and bridge 1 ), residence time of a message within a node (e.g., within bridge 1 ), and a rate ratio between bridges or end stations in the network with respect to the grandmaster (e.g., a rate ratio between bridge 1 204 - 1 and end station 202 - 2 (Construed the end station receives sync and follow-up messages with respective time stamps) ); and where the first and second time synchronization stacks each use the sampled timestamp value to compute a time synchronized Precision Time Protocol (PTP) clock domain signal ( [0037] … In the example network, each clock source is used to establish two gPTP clock domains that are distributed throughout the network …. [0051] At each end station that is designated as a slave device with regard to clock information, synchronization information that is distributed throughout the network (e.g., as specified by IEEE 801.2AS), is used to adjust the clock at the slave device (sometimes referred to as the “slave clock”) so that the slave clock is synchronized with the clock of the grandmaster) . HERBER does not explicitly disclose sending, over the first virtual Ethernet controller of the timing synchronization connector, the sampled timestamp value for the frame transmit request to the first time synchronization stack connected to the timing synchronization connector ( Although HERBER Fig. 1 shows signal flow from Bridge 104-1 to End Station with Current GM connected to Clock Source 110-1). In an analogous art, TZENG teaches sending, over the first virtual Ethernet controller of the timing synchronization connector, the sampled timestamp value for the frame transmit request to the first time synchronization stack connected to the timing synchronization connector ( Fig. 3, Col 9 Lines 7-40: In operation, the egress device 306 can receive a first egress packet associated with a synchronization event (e.g., SYNC) from the CPU 310 via the host interface 328 . In some aspects, the egress packet includes an indication from the CPU 310 to generate a timestamp of the first egress packet. The egress device 306 can transmit the first egress packet using the egress interface as a synchronization message for a two-step clock scheme of the IEEE 1588 protocol. In this regard, the first egress packet can send an estimated clock value to a slave device in the network medium 206 . Upon transmission of the first egress packet, the egress device 306 via the timestamp generator 236 (FIG. 2) can generate an egress timestamp corresponding to a time at which the first egress packet (e.g., representing all of, or at least a portion of, the synchronization message) is transmitted from the egress device 306 to the network medium 206 . … the egress device 306 can compare a packet identifier of the first egress packet included as part of the indication with an egress identifier maintained by the network entity (or master). The egress identifier can be set by the CPU 310 to identify a packet that has been modified to support the timestamp generation independent of a packet format. The egress device 306 can store the egress timestamp in the timestamp memory 242 when the packet identifier of the first egress packet is determined to match the egress identifier (e.g., process 312 ). In various aspects, the egress device 306 can generate a notification to indicate that the egress timestamp is stored in the timestamp memory 242 . In turn, the egress device 306 can transmit the notification to the CPU 310 using the host interface 328 . (It is obvious that , Fig. 3 network physical layer device (PHY) 302 with egress device 306, equivalent to timing synchronization connector, generates a sampled timestamp for the first egress packet transmitted to slave device in the network medium 206, and also sends, over interface 328, equivalent to the first virtual Ethernet controller of the timing synchronization connector, the sampled timestamp value for the egress packet from the CPU 310, to the CPU 310, first time synchronization stack)). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of time synchronization between network entities of TZENG to the system for merging clocks from multiple PTP clock domains of HERBER in order to take the advantage of a method for providing robust cost-effective time synchronization for distributed systems by taking timestamps at the edge of the physical layer for a network interface very close to the network medium to minimize the time difference between when a packet is transmitted from a first network node to that packet being received at a second network node ( TZENG: Col 1 Lines 32-42 ). HERBER and TZENG do not explicitly disclose receiving, at a first virtual Ethernet controller of the timing synchronization connector, forwarding, over a second virtual Ethernet controller of the timing synchronization connector. In an analogous art, MATSUNAGA teaches receiving, at a first virtual Ethernet controller of the timing synchronization connector, forwarding, over a second virtual Ethernet controller of the timing synchronization connector ( Fig. 1, [0018] In a case where a time synchronization message is forwarded to all the TSNs 3 , the wireless communication system 2 , which is a virtual bridge, operates as a time-aware system. The wireless communication system 2 adds the wireless time at which to receive a Sync message, to an extended area of the Sync message or a Follow_Up message. The Sync message is a gPTP message input from each TSN 3 to the wireless communication system 2 . (It is obvious that for time synchronization across TSN System 1, the wireless communication system 2 as virtual bridge, equivalent to timing synchronization connector receives Sync messages from a first TSN3 at virtual first virtual Ethernet controller of the virtual bridge, and forwards the Sync message to a second TSN3 over second virtual Ethernet controller of the virtual bridge)). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of synchronizing control circuits or terminals with clock in virtual bridge of MATSUNAGA to the system for merging clocks from multiple PTP clock domains of HERBER and TZENG in order to take the advantage of a method for reducing the effect of the propagation delay variation impacted by clock drift in virtual bridge ( MATSUNAGA: [0006, 0076] ). Regarding claim 8 , HERBER teaches a device (Fig. 1 Bridges 104, Fig. 2 Bridges 204 ) , comprising: at least one processor circuit configured to execute a timing synchronization connector module ( Fig. 2 Bridges 204 measures Times ΔL1, ΔS1, ΔL2, ΔS2 indicates Bridges comprising processor circuit). Further claim 8 is interpreted mutatis mutandis of claim 1 , and rejected for the same reason as set forth for claim 1 . Regarding claim 14 , HERBER teaches a timing synchronization connector ( Fig. 1 Bridges 104, Fig. 2 Bridges 204) connected between two different time synchronization stacks ( Fig. 1 End Station 102-1 with current GM, connected to Clock Source or Fig. 2 Grand Master 202-1 as time synchronization stack, and Fig. 1 End Stations 102-2..102-6 or Fig. 2 End Station 202-2 as the second time synchronization stack). Further claim 14 is interpreted mutatis mutandis of claim 1 , and rejected for the same reason as set forth for claim 1 . Regarding claim 2 , HERBER, in view of TZENG, teaches the computer-implemented method of claim 1, where the frame transmit request comprises a request to transmit an Ethernet time synch frame ( [0039] In order to maintain synchronization of the end stations with the grandmaster, a synchronization operation is performed. The synchronization operation is performed, in part, by the grandmaster periodically transmitting synchronization (or “sync”) messages and follow-up messages (e.g., via Ethernet frames)…). Regarding claim 3 , HERBER, in view of TZENG, teaches the computer-implemented method of claim 1, where the first time synchronization stack comprises a bridging time synchronization stack for implementing bridging of generalized Precision Time Protocol (gPTP) packets ( Fig. 1, [0037] FIG. 1 depicts a network 100 , such as an in-vehicle network (IVN) that is configured to use, for example, IEEE 802.1AS (e.g., gPTP), to enable distributed clock synchronization. The network includes various nodes that include end stations 102 - 1 - 102 - 6 and bridges 104 - 1 - 104 - 6 . Fig. 2, [0039] FIG. 2 illustrates the transmission of sync and follow-up messages from a grandmaster 202 - 1 to bridges 204 - 1 and 204 - 2 and to an end station 202 - 2 in the network….. [0051] At each end station that is designated as a slave device with regard to clock information, synchronization information that is distributed throughout the network (e.g., as specified by IEEE 801.2AS), is used to adjust the clock at the slave device (sometimes referred to as the “slave clock”) so that the slave clock is synchronized with the clock of the grandmaster (the process of clock synchronization is also sometime referred to as “clock recover”). For example, the nodes within the network exchange messages and perform timing related calculations as described above with regard to FIGS. 2 and 3.). Regarding claim 5 , HERBER, in view of TZENG, teaches the computer-implemented method of claim 1. HERBER does not explicitly disclose where the timing synchronization connector forwards the sampled timestamp value for the frame transmit request to the second time synchronization stack by storing the sampled timestamp value with the metadata for the frame transmit request being forwarded to the second time synchronization stack. TZENG teaches where the timing synchronization connector forwards the sampled timestamp value for the frame transmit request to the second time synchronization stack by storing the sampled timestamp value with the metadata for the frame transmit request being forwarded to the second time synchronization stack ( Col 10 Lines 51-57: The egress timestamp can be stored in the timestamp memory 242 when a match is determined between the packet identifier of the first egress packet and the egress identifier. In addition, the egress device 306 can store the signature of the egress timestamp of the first egress packet in the timestamp memory 242 with the signature ). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of time synchronization between network entities of TZENG to the system for merging clocks from multiple PTP clock domains of HERBER in order to take the advantage of a method for providing robust cost-effective time synchronization for distributed systems by taking timestamps at the edge of the physical layer for a network interface very close to the network medium to minimize the time difference between when a packet is transmitted from a first network node to that packet being received at a second network node ( TZENG: Col 1 Lines 32-42 ). Regarding claim 6 , HERBER, in view of TZENG, teaches the computer-implemented method of claim 1. HERBER does not explicitly disclose where the timing synchronization connector sends the sampled timestamp value for the frame transmit request to the first time synchronization stack by storing the sampled timestamp value with the metadata for the frame transmit request being sent to the first time synchronization stack. TZENG teaches where the timing synchronization connector sends the sampled timestamp value for the frame transmit request to the first time synchronization stack by storing the sampled timestamp value with the metadata for the frame transmit request being sent to the first time synchronization stack ( Col 9 Lines 33-40: The egress device 306 can store the egress timestamp in the timestamp memory 242 when the packet identifier of the first egress packet is determined to match the egress identifier (e.g., process 312 ). In various aspects, the egress device 306 can generate a notification to indicate that the egress timestamp is stored in the timestamp memory 242 . In turn, the egress device 306 can transmit the notification to the CPU 310 using the host interface 328 .). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of time synchronization between network entities of TZENG to the system for merging clocks from multiple PTP clock domains of HERBER in order to take the advantage of a method for providing robust cost-effective time synchronization for distributed systems by taking timestamps at the edge of the physical layer for a network interface very close to the network medium to minimize the time difference between when a packet is transmitted from a first network node to that packet being received at a second network node ( TZENG: Col 1 Lines 32-42 ). Regarding claim 11 , the claim is interpreted and rejected for the same reason as set forth for claim 5 . Regarding claim 12 , the claim is interpreted and rejected for the same reason as set forth for claim 6 . Regarding claim 15 , HERBER, in view of TZENG and MATSUNAGA, teaches the computer-implemented method of claim 14. HERBER does not explicitly disclose where the first and second time synchronization stacks each use the sampled timestamp value to compute a time synchronized Precision Time Protocol (PTP) clock domain signal. TZENG teaches where the first and second time synchronization stacks each use the sampled timestamp value to compute a time synchronized Precision Time Protocol (PTP) clock domain signal ( Fig. 3, Col 9 Lines 13-43: The egress device 306 can transmit the first egress packet using the egress interface as a synchronization message for a two-step clock scheme of the IEEE 1588 protocol. In this regard, the first egress packet can send an estimated clock value to a slave device in the network medium 206 . Upon transmission of the first egress packet, the egress device 306 via the timestamp generator 236 (FIG. 2) can generate an egress timestamp corresponding to a time at which the first egress packet (e.g., representing all of, or at least a portion of, the synchronization message) is transmitted from the egress device 306 to the network medium 206 . …. the egress device 306 can generate a notification to indicate that the egress timestamp is stored in the timestamp memory 242 . In turn, the egress device 306 can transmit the notification to the CPU 310 using the host interface 328 . In response to the notification, the CPU 310 can perform an MDIO access to retrieve the egress timestamp stored in the timestamp memory 242 .). Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to take the technique of time synchronization between network entities of TZENG to the system for merging clocks from multiple PTP clock domains of HERBER and MATSUNAGA in order to take the advantage of a method for providing robust cost-effective time synchronization for distributed systems by taking timestamps at the edge of the physical layer for a network interface very close to the network medium to minimize the time difference between when a packet is transmitted from a first network node to that packet being received at a second network node ( TZENG: Col 1 Lines 32-42 ). Regarding claim 16 , the claim is interpreted and rejected for the same reason as set forth for claim 2 . Regarding claim 18 , the claim is interpreted and rejected for the same reason as set forth for claim 5 . Regarding claim 19 , the claim is interpreted and rejected for the same reason as set forth for claim 6 . Allowable Subject Matter 07-43 Claims 4, 7, 9-10, 13, 17, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and in intervening claims. 13-03-01 AIA The following is a statement of reasons for the indication of allowable subject matter: Regarding claim 4 , HERBER, TZENG, MATSUNAGA or any prior art of record either alone or in combination fails to teach the computer-implemented method of claim 3, where the second time synchronization stack comprises a time synchronization stack that does not implement bridging of generalized Precision Time Protocol (gPTP) packets. Regarding claim 7 , HERBER, TZENG or any prior art of record either alone or in combination fails to teach the computer-implemented method of claim 1, where the timing synchronization connector is connected and configured to provide read access to the hardware counter by the second time synchronization stack. Regarding claim 9 , the claim having similar features as in claim 7 , is also interpreted same as claim 7 . Regarding claim 10 , the claim having similar features as in claim 4 , is also interpreted same as claim 4 . Regarding claim 13 , the claim having similar features as in claim 7 , is also interpreted same as claim 7 . Regarding claim 17 , the claim having similar features as in claim 4 , is also interpreted same as claim 4 . Regarding claim 20 , the claim having similar features as in claim 7 , is also interpreted same as claim 7 . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure : Zinner; Helge (US 12255735 B2) describing Method For Securing The Time Synchronization Of An Ethernet On-board Network Dror; Nitzan (US 20230269063 A1), describing TIMESTAMPING FOR MULTIPLE SYNCHRONIZATION DOMAINS IN A NETWORK DEVICE Lee at al. (US 20230163871 A1), describing NETWORK INTERFACE CARD STRUCTURE AND CLOCK SYNCHRONIZATION METHOD TO PRECISELY ACQUIRE HETEROGENEOUS PTP SYNCHRONIZATION INFORMATION FOR PTP SYNCHRONIZATION NETWORK EXTENSION Oga et al. (US 20220312358 A1) describing INTERFACE CONVERSION DEVICE, CONTROL CIRCUIT, STORAGE MEDIUM, AND ANOMALY DETECTION METHOD Fong et al. (US 20210050988 A1) describing VLAN-Aware Clock Synchronization Sachs et al. (US 20200259896 A1), describing Industrial Automation With 5G And Beyond Garner et al., "Synchronization of AudioVideo Bridging Networks Using IEEE 802.1AS" Jesse; Bernd, "Global Time Synchronization in an Automotive Ethernet Network - Everything Done" Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAH M RAHMAN whose telephone number is (571)272-8951. The examiner can normally be reached 9:30AM-5:30PM PST. 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, UN C CHO can be reached at 571-272-7919. 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. /SHAH M RAHMAN/Primary Examiner, Art Unit 2413 Application/Control Number: 18/768,829 Page 2 Art Unit: 2413 Application/Control Number: 18/768,829 Page 3 Art Unit: 2413 Application/Control Number: 18/768,829 Page 4 Art Unit: 2413 Application/Control Number: 18/768,829 Page 5 Art Unit: 2413 Application/Control Number: 18/768,829 Page 6 Art Unit: 2413 Application/Control Number: 18/768,829 Page 7 Art Unit: 2413 Application/Control Number: 18/768,829 Page 8 Art Unit: 2413 Application/Control Number: 18/768,829 Page 9 Art Unit: 2413 Application/Control Number: 18/768,829 Page 10 Art Unit: 2413 Application/Control Number: 18/768,829 Page 11 Art Unit: 2413 Application/Control Number: 18/768,829 Page 12 Art Unit: 2413 Application/Control Number: 18/768,829 Page 13 Art Unit: 2413 Application/Control Number: 18/768,829 Page 14 Art Unit: 2413 Application/Control Number: 18/768,829 Page 15 Art Unit: 2413 Application/Control Number: 18/768,829 Page 16 Art Unit: 2413 Application/Control Number: 18/768,829 Page 17 Art Unit: 2413 Application/Control Number: 18/768,829 Page 18 Art Unit: 2413
Prosecution Insights