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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 – 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 – 22 and 29 of U.S. Patent No. 12,028,155. Although the claims at issue are not identical, they are not patentably distinct from each other because independent claims 1, 19 and 20 of Application No. 18/415,883 are directed to the same inventive concept as claims 1, 9 and 29 of U.S. Patent No. 12,028,155. Plus, independent claims 1, 19 and 20 of Application No. 18/415,883 broaden the scope of the claims by eliminating some elements and functions from the independent claims when compared to independent claims 1, 9 and 29 of U.S. Patent No. 12,028,155.
The mappings of the conflicting claims are shown in the table below.
Claims from Application No. 18/415,883
Claims from U.S. Patent No. 12,028,155
1. A system for maintaining a Precision Time Protocol (PTP) hardware clock, the system being operative in conjunction with a network device which is external to the system, the system comprising: a controller to receive information characterizing a network peer oscillator frequency, wherein said information was extracted from an RX symbol rate, and to adjust the PTP Hardware Clock's frequency responsive to the information characterizing the network peer oscillator frequency.
8. The system according to claim 1 wherein the controller uses the RX symbol rate to determine an ensemble time and wherein the ensemble time is used to adjust the PTP Hardware Clock's frequency.
2. The system according to claim 1 and also comprising an apparatus which extracts the information characterizing a network peer oscillator frequency from the RX symbol rate.
3. The system according to claim 2 wherein extraction of said information from the RX symbol rate is implemented in firmware and/or hardware, to mitigate software-to-firmware/hardware interface jitter.
4. The system according to claim 1 wherein the controller is implemented at least partly in hardware.
5. The system according to claim 1 wherein the controller is implemented at least partly in firmware.
6. The system according to claim 1 and also comprising Time Source Selection functionality which selects a network port having an RX symbol rate known to a partner, from among plural network ports having an RX symbol rate known to the partner, from which the partner will extract the network peer oscillator frequency.
7. The system according to claim 1 and also comprising a PTP hardware clock whose frequency is adjusted by the controller.
9. The system according to claim 8, wherein the controller determines the ensemble time based on a plurality of RX symbol rates determined for a plurality of network peers, respectively.
10. The system according to claim 1 wherein the PTP Hardware Clock's update rate is updated as a function of an RX—PHC frequency ratio computed by extracting an RX frequency from an Ethernet physical layer over which clock signals are transferred.
11. The system according to claim 1 wherein the PTP Hardware Clock's update rate is updated as a function of a ratio between RX frequency and TX frequency values extracted from an Ethernet physical layer over which clock signals are transferred.
12. The system according to claim 1 wherein a “set status” command tells the network device whether or not to track one of the network device's network ports, and wherein at least one “set status” command tells the network device not to track any one of the network device's network ports, and, instead, to use an internal clock with default configuration.
13. The system according to claim 1 wherein, responsive to a network node losing a link partner whose clock has higher accuracy than the network node itself, the network node goes into a “holdover” state in which incoming rate information from the network node's past is used.
14. The system according to claim 1 wherein a software entity which owns said PTP Hardware Clock determines whether to perform phase adjustment and/or whether to perform frequency adjustment.
15. The system according to claim 1 wherein a software entity which owns said PTP Hardware Clock selects, at least once, to perform frequency adjustment, and, wherein, responsively, the controller is activated.
16. The system according to claim 1 wherein a frequency difference is periodically measured by the network device and wherein the PTP Hardware Clock's DPLL is updated accordingly.
17. The system according to claim 1 and also comprising an active PTP which provides PTP daemon frequency updates and a DPLL for converting a core clock to a PTP Hardware Clock which is characterized by numerator and denominator parameters, one of which is allocated to the PTP daemon frequency updates, and the other of which is allocated to PTP Hardware Clock frequency adjustment.
18. The system according to claim 1 wherein a protocol is used by the network device to communicate with at least one link partner to extract and then use frequency, wherein the protocol carries information regarding said at least one link partner's clock quality, wherein said link partner's clock quality is represented by at least one of SSM codes and ESSM codes, and wherein the protocol carries information on the frequency stability of the link partner's clock.
19. A system for maintaining at least one of a local clock and a Precision Time Protocol (PTP) hardware clock, the system being operative in conjunction with a network device which is external to the system, the system comprising: a controller that receives information characterizing at least two network peer oscillator frequencies, wherein said information is extracted from at least a first RX symbol rate and a second RX symbol rate, and to adjust the local clock's and/or PTP Hardware Clock's frequency responsive to the information characterizing the at least two network peer oscillator frequencies.
20. A method for providing clock and frequency synchronization among plural network devices wherein at least one network device from among said plural network devices has a Precision Time Protocol (PTP) hardware clock having a frequency, in a network having a network peer oscillator frequency and a received (RX) symbol rate, the method comprising: extracting the network peer oscillator frequency from the RX symbol rate and using the network peer oscillator frequency thus extracted to adjust the frequency of the at least one network device's PTP Hardware Clock (PHC).
1. A system for maintaining a Precision Time Protocol (PTP) hardware clock, the system being operative in conjunction with a network device which is external to the system, the system comprising: a controller to receive information characterizing a network peer oscillator frequency, wherein said information was extracted from a received (RX) symbol rate, and to adjust the PTP Hardware Clock's frequency responsive to the information characterizing the network peer oscillator frequency,
wherein the controller uses the RX symbol rate to determine an ensemble time, and wherein the ensemble time is used to adjust the PTP Hardware Clock's frequency.
2. The system according to claim 1 and also comprising an apparatus which extracts the information characterizing a network peer oscillator frequency from the RX symbol rate.
3. The system according to claim 2 wherein extraction of said information from the RX symbol rate is implemented in firmware and/or hardware, to mitigate software-to-firmware/hardware interface jitter.
4. The system according to claim 1 wherein the controller is implemented at least partly in hardware.
5. The system according to claim 1 wherein the controller is implemented at least partly in firmware.
6. The system according to claim 1 and also comprising Time Source Selection functionality which selects a network port having an RX symbol rate known to a partner, from among plural network ports having an RX symbol rate known to the partner, from which the partner will extract the network peer oscillator frequency.
7. The system according to claim 1 and also comprising a PTP hardware clock whose frequency is adjusted by the controller.
8. The system according to claim 1, wherein the controller determines the ensemble time based on a plurality of RX symbol rates determined for a plurality of network peers, respectively.
10. The system according to claim 1 wherein the PTP Hardware Clock's (PHC) update rate is updated as a function of an RX-PHC frequency ratio computed by extracting an RX frequency from an Ethernet physical layer over which clock signals are transferred.
11. The system according to claim 1 wherein the PTP Hardware Clock's update rate is updated as a function of a ratio between RX frequency and transmit (TX) frequency values extracted from an Ethernet physical layer over which clock signals are transferred.
12. The system according to claim 1 wherein a “set status” command tells the network device whether or not to track one of the network device's network ports.
13. The system according to claim 12 wherein at least one “set status” command tells the network device not to track any one of the network device's network ports, and, instead, to use an internal clock with default configuration.
14. The system according to claim 1 wherein, responsive to a network node losing a link partner whose clock has higher accuracy than the network node itself, the network node goes into a “holdover” state in which incoming rate information from the network node's past is used.
15. The system according to claim 1 wherein a software entity which owns said PTP Hardware Clock determines whether to perform phase adjustment and/or whether to perform frequency adjustment.
16. The system according to claim 1 wherein a software entity which owns said PTP Hardware Clock selects, at least once, to perform frequency adjustment, and, wherein, responsively, the controller is activated.
17. The system according to claim 1 wherein a frequency difference is periodically measured by the network device and wherein the PTP Hardware Clock's digital phase-locked loop (DPLL) is updated accordingly.
18. The system according to claim 1 and also comprising an active PTP which provides PTP daemon frequency updates and a digital phase-locked loop (DPLL) for converting a core clock to a PTP Hardware Clock which is characterized by numerator and denominator parameters, one of which is allocated to the PTP daemon frequency updates, and the other of which is allocated to PTP Hardware Clock frequency adjustment.
19. The system according to claim 1 wherein a protocol is used by the network device to communicate with at least one link partner to extract and then use frequency.
20. The system according to claim 19 and wherein the protocol carries information regarding said at least one link partner's clock quality.
21. The system according to claim 20 and wherein said link partner's clock quality is represented by at least one of synchronization status message (SSM) codes and Ethernet SSM (ESSM) codes.
22. The system according to claim 19 and wherein the protocol carries information on the frequency stability of the link partner's clock.
29. A system for maintaining at least one of a local clock and a Precision Time Protocol (PTP) hardware clock, the system being operative in conjunction with a network device which is external to the system, the system comprising: a controller that receives information characterizing at least two network peer oscillator frequencies, wherein said information is extracted from at least a first received (RX) symbol rate and a second RX symbol rate, and to adjust the local clock's and/or PTP Hardware Clock's frequency responsive to the information characterizing the at least two network peer oscillator frequencies, wherein the information characterizing the at least two peer network peer oscillator frequencies comprises an ensemble time that is determined as a weighted average of the at least the first RX symbol rate and the second RX symbol rate.
9. A method for providing clock and frequency synchronization among plural network devices wherein at least one network device from among said plural network devices has a Precision Time Protocol (PTP) hardware clock having a frequency, in a network having a network peer oscillator frequency and a received (RX) symbol rate, the method comprising: extracting the network peer oscillator frequency from the RX symbol rate and using the network peer oscillator frequency thus extracted to adjust the frequency of the at least one network device's PTP Hardware Clock (PHC); determining an ensemble time from the RX symbol rate; and using the ensemble time to adjust the PTP hardware clock.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1 – 3, 6, 8 - 11, and 16 – 19 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1 – 3, 6, 8 - 11, and 16 – 19 fail to set forth what the symbols of “RX”, “TX”, “PHC”, “DPLL”, “SSM”, and “ESSM” represent in the claims.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 – 5, 7, 14, 15, 19 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Hoang (Pub. No.: US 2012/0063556; hereinafter Hoang).
Regarding claim 1, Hoang discloses a system for maintaining a Precision Time Protocol (PTP) hardware clock, the system being operative in conjunction with a network device which is external to the system, the system comprising: a controller (see Fig. 2A, Fig. 8, Fig. 9, system 900 with FPGA 908 which contains clock and recovery circuit CDR 814 (ex: CDR 200 of Fig. 2A)) to receive information characterizing a network peer oscillator frequency, wherein said information was extracted from an RX symbol rate, and to adjust the PTP Hardware Clock's frequency responsive to the information characterizing the network peer oscillator frequency (see Fig. 2A, input data signal DXP/DXN with a data rate, para. 0029 – 0030, CDR circuit 200 can change the frequencies of its output clock signals CLKL1[3:0] to correspond to changes in the data rate of the input data signal DXP/DXN between three different data rates that are based on three different data transmission protocols… para. 0037 – 0038, Oscillator circuit 206 adjusts the phases and the frequencies of output clock signals OSC[3:0] based on changes in control voltage signal VCL which is based on the data rate of the input data signal DXP/DXN, para. 0046, CDR circuit 200 adjusts the frequency of the output clock signals CLKL1[3:0] between three or more different frequencies based on changes in the data rate of the differential input data signal DXP/DXN).
Regarding claim 2, Hoang discloses comprising an apparatus which extracts the information characterizing a network peer oscillator frequency from the RX symbol rate (see Fig. 2A, input data signal DXP/DXN with a data rate, para. 0029 – 0030, CDR circuit 200 can change the frequencies of its output clock signals CLKL1[3:0] to correspond to changes in the data rate of the input data signal DXP/DXN between three different data rates that are based on three different data transmission protocols… para. 0037 – 0038, Oscillator circuit 206 adjusts the phases and the frequencies of output clock signals OSC[3:0] based on changes in control voltage signal VCL which is based on the data rate of the input data signal DXP/DXN).
Regarding claim 3, Hoang discloses wherein extraction of said information from the RX symbol rate is implemented in firmware and/or hardware, to mitigate software-to-firmware/hardware interface jitter (see Fig. 8, Fig. 9, para. 0087 – 0096, FPGA 800 (ex: integrated circuit) includes CDR 814 in a processing unit 902 coupled to memory 904; also note the combination of devices, circuits, microprocessors, etc…).
Regarding claim 4, Hoang discloses wherein the controller is implemented at least partly in hardware (see Fig. 8, Fig. 9, para. 0087 – 0096, FPGA 800 (ex: integrated circuit) includes CDR 814 in a processing unit 902 coupled to memory 904; also note the combination of devices, circuits, microprocessors, etc…).
Regarding claim 5, Hoang discloses wherein the controller is implemented at least partly in firmware (see Fig. 8, Fig. 9, para. 0087 – 0096, FPGA 800 (ex: integrated circuit) includes CDR 814 in a processing unit 902 coupled to memory 904; also note the FPGA 800 also includes a distributed memory structure).
Regarding claim 7, Hoang discloses comprising a PTP hardware clock whose frequency is adjusted by the controller (see para. 0046, CDR circuit 200 adjusts the frequency of the output clock signals CLKL1[3:0] between three or more different frequencies based on changes in the data rate of the differential input data signal DXP/DXN).
Regarding claim 14, Hoang discloses wherein a software entity which owns said PTP Hardware Clock determines whether to perform phase adjustment and/or whether to perform frequency adjustment (see para. 0031, oscillator circuit 206 is replaced with another type of phase adjustment circuit and/or frequency adjustment circuit that adjusts phases and/or frequencies of periodic output clock signals based on changes in an input control signal).
Regarding claim 15, Hoang discloses wherein a software entity which owns said PTP Hardware Clock selects, at least once, to perform frequency adjustment, and, wherein, responsively, the controller is activated (see para. 0046, CDR circuit 200 adjusts the frequency of the output clock signals CLKL1[3:0] between three or more different frequencies based on changes in the data rate of the differential input data signal DXP/DXN).
Regarding claim 19, Hoang discloses a system for maintaining at least one of a local clock and a Precision Time Protocol (PTP) hardware clock, the system being operative in conjunction with a network device which is external to the system, the system comprising: a controller (see Fig. 2A, Fig. 8, Fig. 9, system 900 with FPGA 908 which contains clock and recovery circuit CDR 814 (ex: CDR 200 of Fig. 2A)) that receives information characterizing at least two network peer oscillator frequencies, wherein said information is extracted from at least a first RX symbol rate and a second RX symbol rate, and to adjust the local clock's and/or PTP Hardware Clock's frequency responsive to the information characterizing the at least two network peer oscillator frequencies (see Fig. 2A, input data signal DXP/DXN with a data rate (note: DXP signal with a data rate and DXN signal with another data rate; hence a first rate and a second rate), para. 0029 – 0030, CDR circuit 200 can change the frequencies of its output clock signals CLKL1[3:0] to correspond to changes in the data rate of the input data signal DXP/DXN between three different data rates that are based on three different data transmission protocols… para. 0037 – 0038, Oscillator circuit 206 adjusts the phases and the frequencies of output clock signals OSC[3:0] based on changes in control voltage signal VCL which is based on the data rate of the input data signal DXP/DXN, para. 0046, CDR circuit 200 adjusts the frequency of the output clock signals CLKL1[3:0] between three or more different frequencies based on changes in the data rate of the differential input data signal DXP/DXN).
Regarding claim 20, Hoang discloses a method for providing clock and frequency synchronization among plural network devices wherein at least one network device from among said plural network devices has a Precision Time Protocol (PTP) hardware clock having a frequency, in a network having a network peer oscillator frequency and a received (RX) symbol rate (see Fig. 2A, Fig. 8, Fig. 9, system 900 with FPGA 908 which contains clock and recovery circuit CDR 814 (ex: CDR 200 of Fig. 2A)), the method comprising: extracting the network peer oscillator frequency from the RX symbol rate and using the network peer oscillator frequency thus extracted to adjust the frequency of the at least one network device's PTP Hardware Clock (PHC) (see Fig. 2A, input data signal DXP/DXN with a data rate, para. 0029 – 0030, CDR circuit 200 can change the frequencies of its output clock signals CLKL1[3:0] to correspond to changes in the data rate of the input data signal DXP/DXN between three different data rates that are based on three different data transmission protocols… para. 0037 – 0038, Oscillator circuit 206 adjusts the phases and the frequencies of output clock signals OSC[3:0] based on changes in control voltage signal VCL which is based on the data rate of the input data signal DXP/DXN, para. 0046, CDR circuit 200 adjusts the frequency of the output clock signals CLKL1[3:0] between three or more different frequencies based on changes in the data rate of the differential input data signal DXP/DXN).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Hoang (Pub. No.: US 2012/0063556; hereinafter Hoang) in view of Su et al. (Pub. No.: US 2020/0235905; hereinafter Su).
Regarding claim 18, Hoang discloses wherein a protocol is used by the network device to communicate with at least one link partner to extract and then use frequency (see abstract, para. 0014, 0029 - 0030, The circuit varies a frequency of the third periodic signal to correspond to changes in a data rate of the data signal between at least three different data rates that are based on at least three data transmission protocols), wherein the protocol carries information on the frequency stability of the link partner's clock (see para. 0030, CDR circuit 200 can generate three or more different frequencies of the output clock signals CLKL1[3:0] that are used to sample data in the input data signal DXP/DXN at three or more different data rates according to three or more data transmission protocols).
Hoang does not disclose the following claimed features: regarding claim 18, wherein the protocol carries information regarding said at least one link partner's clock quality, and wherein said link partner's clock quality is represented by at least one of SSM codes and ESSM codes.
Regarding claim 18, Su discloses wherein the protocol carries information regarding said at least one link partner's clock quality (see para. 0080, The SSM packet is used to transfer information such as clock source quality), and wherein said link partner's clock quality is represented by at least one of SSM codes and ESSM codes (see para. 0080, The SSM packet is used to transfer information such as clock source quality).
It would have been obvious to one ordinary skilled in the art before the effective filing date of the claimed invention to modify the invention of Hoang, and have the features, as taught by Su, without transparently transmitting the service data streams as a whole, classification and reorganization reduce bandwidth waste and improve transmission efficiency, as discussed by Su (para. 0038).
Allowable Subject Matter
Claims 6, 8 – 13, 16 and 17 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 any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Anh Ngoc M Nguyen whose telephone number is (571) 270-5139. The examiner can normally be reached on Monday to Friday, from 7:30 am to 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kwang Bin Yao can be reached on ((571) 272-3182. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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 .
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 http://pair-direct.uspto.gov. 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.
/ANH NGOC M NGUYEN/Primary Examiner, Art Unit 2473
Prosecution Insights