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 .
This Office Action is a response to communications dated 10/24/2024. Claims 1-20 are pending in the application.
Information Disclosure Statement
The information disclosure statement filed 10/24/2024 complies with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. It has been considered and placed in the application file.
Claim Rejections - 35 USC § 112
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the time at which the first message is transmitted from the first device according to the first clock" in lines 6-7. There is insufficient antecedent basis for this limitation in the claim.
Dependents claims 2-5 inherit the discrepancy of their base claim as above discussed.
Claim 6 recites the limitation "the time at which the first message is transmitted from the first device according to the first clock" in lines 6-7. There is insufficient antecedent basis for this limitation in the claim.
Dependents claims 7-19 inherit the discrepancy of their base claim as above discussed.
Claim 20 recites the limitation "the time at which the first message is transmitted from the first device according to the first clock" in lines 7-8. There is insufficient antecedent basis for this limitation in the claim.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Celinski et al. (US 7,539,889) (hereinafter “Celinski”).
Regarding claim 1, in accordance with Celinski reference entirety, Celinski teaches a method, at a first device (FIG. 1; 106) comprising a first clock (FIG. 2; 222), of enabling synchronisation of a second clock (FIG. 2; 222) at a second device (FIG. 1; any one of 103, 104, 105, and 107) with the first clock (FIG. 2; 222) (col. 9, lines 16-46: “The access point and each client device … includes a MAC that provides a Time Synchronization Function (TSF); which includes a local TSF counter that is automatically incremented by the MAC module … broadcasts beacon frames and sends probe response frames that cause synchronization of all the TSF counters in the client devices … .”), the first device (FIG. 1; 106) further comprising a third clock (FIG. 2; 225) (page 9, lines 59-63: “Each IEEE client device 103, 104, 105, or 107, and the master device 106 provides the TSF function in the form of a TSF counter. Each device further includes a local clock, e.g., for devices that have the architecture 200 of FIG. 2, clock value 222.” Moreover, col. 7, lines 3-17: “… the control logic 220 include clock synchronization logic 221 … clock generator 225 … to provide a local clock signal 222.”), the method comprising:
transmitting a first message (beacon frames) comprising an identifier (TSF) generated in dependence on the third clock (FIG. 2; 225) to the second device (FIG. 1; any one of 103, 104, 105, and 107) (FIG. 3; step 301 and col. 10, lines 1-7: “… the access point, e.g., master device 106 regularly, although not necessarily in a periodic fashion, sending beacon frames to enable client stations to synchronize their TSF counts. 301 also includes the master device 106 optionally sending one or more probe response frames in response to receiving a corresponding probe request frame”);
generating a timestamp (pair of (master_local_clock, TSF master_reading) values) in dependence on the time at which the first message (beacon frames) is transmitted from the first device (FIG. 1; 106) according to the first clock (FIG. 1; 222) (col. 10, lines 15-25: "In 303, the method 300 reads the master's local clock counter value, e.g., from the clock value 222 of the clock control unit 220 and denoted master_local_clock herein. In 305, when the value master_local_clock is obtained, the master device 106 reads the master's TSF value at the master device's IEEE 802.11 transceiver 212 to independently mark the time at which the master local clock is read. Denote this TSF value as TSF master_reading. Thus, when the master_local_clock is read in 303, the master device's TSF is read in 305, so that a pair of (master_local_clock, TSF master_reading) values is generated");
generating a second message (data) comprising the identifier (TSF) and the generated timestamp (pair of (master_local_clock, TSF master_reading) values); and transmitting the second message (data) to the second device (FIG. 1; any one of 103, 104, 105, and 107) (col. 10, lines 25-33: "In 307, the master transmits this data over the wireless network 100, such that each receiving playback unit can use the received data, the relationship of the receiving playback unit's local clock and the receiving playback unit's local TSF reading to adjust its local clock frequency to synchronize its local clock frequency to the master device's local clock's frequency, such that the adjusted local clock is usable for the DAC and other synchronization requirements.").
Regarding claim 2, in addition to features recited in base claim 1 (see rationales discussed above), Celinski also teaches wherein the first clock (FIG. 1; 222) is configured to operate to a first clock resolution and the third clock (FIG. 1; 225) is configured to operate to a second resolution lower than the first resolution (col. 9, lines 47-57: “… adjusting the signal into the signal control oscillator (SCO) of the clock generator 225 so that the reading o the local slave clock, e.g., clock value 222 of the clock control logic 220 of … slave clock frequency is synchronized with the master device’s clock frequency.”).
Regarding claim 3, in addition to features recited in base claim 1 (see rationales discussed above), Celinski also teaches wherein the first device (FIG. 1; 106) comprises a communications interface (FIG. 2; 212) comprising the third clock (FIG. 2; 225), the third clock (FIG. 2; 225) being a physical layer clock (crystal controlled clock) (col. 8, line 66 to col. 9, line 3: "In one embodiment, the clock control logic 220 provides an internal fast local counter 222 as the clock signal. Both the frequency adjustment logic and the phase lock loop use the same clock generator 225 including an SCO and a crystal controlled clock.").
Regarding claim 4, in addition to features recited in base claim 1 (see rationales discussed above), Celinski also teaches wherein the first message is transmitted directly (unicast packet) to the second device (FIG. 1; any one of 103, 104, 105, and 107) (col. 10, lines 34-42: "In one embodiment, the master device broadcasts or multicasts to all the slave devices a new type of broadcast or multicast packet, e.g., a UDP packet that includes the timing information. In another embodiment, an unicast packet is sent individually to all the slave devices over separate unicast-based channels, such that slave devices can receive the pairs (master_local_clock, TSF master_reading). In either case, in one embodiment, the information is broadcast, multicast, or unicast regularly.").
Regarding claim 5, in addition to features recited in base claim 1 (see rationales discussed above), Celinski also teaches determining a playback time for playing media in dependence on a time according to the first clock and an offset period of time; and directly transmitting the determined playback time to the second device (col. 10, lines 23-33: "In 307, the master transmits this data over the wireless network 100, such that each receiving playback unit can use the received data, the relationship of the receiving playback unit's local clock and the receiving playback unit's local TSF reading to adjust its local clock frequency to synchronize its local clock frequency to the master device's local clock's frequency, such that the adjusted local clock is usable for the DAC and other synchronization requirements.").
Regarding claim 6, in accordance with Celinski reference entirety, Celinski discloses a first device (FIG. 1; 106) comprising a first clock (FIG. 2; 222), the first device (Fig. 1; 106) for enabling synchronisation of a second clock (FIG. 2; 222) at a second device (FIG. 1; any one of 103, 104, 105, and 107) with the first clock (FIG. 2; 222) (col. 9, lines 16-46: “The access point and each client device … includes a MAC that provides a Time Synchronization Function (TSF); which includes a local TSF counter that is automatically incremented by the MAC module … broadcasts beacon frames and sends probe response frames that cause synchronization of all the TSF counters in the client devices … .”), the first device (FIG. 1; 106) further comprising a third clock (FIG. 2; 225) (page 9, lines 59-63: “Each IEEE client device 103, 104, 105, or 107, and the master device 106 provides the TSF function in the form of a TSF counter. Each device further includes a local clock, e.g., for devices that have the architecture 200 of FIG. 2, clock value 222.” Moreover, col. 7, lines 3-17: “… the control logic 220 include clock synchronization logic 221 … clock generator 225 … to provide a local clock signal 222.”), the first device (Fig. 1; 106) being configured to:
transmit a first message (beacon frames) comprising an identifier (TSF) generated in dependence on the third clock (FIG. 2; 225) to the second device (FIG. 1; any one of 103, 104, 105, and 107) (FIG. 3; step 301 and col. 10, lines 1-7: “… the access point, e.g., master device 106 regularly, although not necessarily in a periodic fashion, sending beacon frames to enable client stations to synchronize their TSF counts. 301 also includes the master device 106 optionally sending one or more probe response frames in response to receiving a corresponding probe request frame”);
generate a timestamp (pair of (master_local_clock, TSF master_reading) values) in dependence on the time at which the first message (beacon frames) is transmitted from the first device (FIG. 1; 106) according to the first clock (FIG. 1; 222) (col. 10, lines 15-25: "In 303, the method 300 reads the master's local clock counter value, e.g., from the clock value 222 of the clock control unit 220 and denoted master_local_clock herein. In 305, when the value master_local_clock is obtained, the master device 106 reads the master's TSF value at the master device's IEEE 802.11 transceiver 212 to independently mark the time at which the master local clock is read. Denote this TSF value as TSF master_reading. Thus, when the master_local_clock is read in 303, the master device's TSF is read in 305, so that a pair of (master_local_clock, TSF master_reading) values is generated");
generate a second message (data) comprising the identifier (TSF) and the generated timestamp (pair of (master_local_clock, TSF master_reading) values); and transmit the second message (data) to the second device (FIG. 1; any one of 103, 104, 105, and 107) (col. 10, lines 25-33: "In 307, the master transmits this data over the wireless network 100, such that each receiving playback unit can use the received data, the relationship of the receiving playback unit's local clock and the receiving playback unit's local TSF reading to adjust its local clock frequency to synchronize its local clock frequency to the master device's local clock's frequency, such that the adjusted local clock is usable for the DAC and other synchronization requirements.").
Regarding claim 7, in addition to features recited in base claim 6 (see rationales discussed above), Celinski also discloses determine an event time in dependence on a time according to the first clock and an offset period of time; and, transmit the determined event time to the second device (col. 10, lines 23-33: "In 307, the master transmits this data over the wireless network 100, such that each receiving playback unit can use the received data, the relationship of the receiving playback unit's local clock and the receiving playback unit's local TSF reading to adjust its local clock frequency to synchronize its local clock frequency to the master device's local clock's frequency, such that the adjusted local clock is usable for the DAC and other synchronization requirements.").
Regarding claim 8, in addition to features recited in base claim 7 (see rationales discussed above), Celinski also discloses wherein the event time comprises a playback time for playing media (col. 10, lines 23-33: "In 307, the master transmits this data over the wireless network 100, such that each receiving playback unit can use the received data, the relationship of the receiving playback unit's local clock and the receiving playback unit's local TSF reading to adjust its local clock frequency to synchronize its local clock frequency to the master device's local clock's frequency, such that the adjusted local clock is usable for the DAC and other synchronization requirements.").
Regarding claim 9, in addition to features recited in base claim 6 (see rationales discussed above), Celinski also discloses wherein the first clock is configured to operate to a first clock resolution and the third clock is configured to operate to a second resolution lower than the first resolution (col. 9, lines 47-57: “… adjusting the signal into the signal control oscillator (SCO) of the clock generator 225 so that the reading o the local slave clock, e.g., clock value 222 of the clock control logic 220 of … slave clock frequency is synchronized with the master device’s clock frequency.”).
Regarding claim 10, in addition to features recited in base claim 6 (see rationales discussed above), Celinski also discloses a communications interface (FIG. 2; 212) comprising the third clock (FIG. 2; 225), the third clock (FIG. 2; 225) being a physical layer clock (crystal controlled clock) (col. 8, line 66 to col. 9, line 3: "In one embodiment, the clock control logic 220 provides an internal fast local counter 222 as the clock signal. Both the frequency adjustment logic and the phase lock loop use the same clock generator 225 including an SCO and a crystal controlled clock.").
Regarding claim 11, in addition to features recited in base claim 6 (see rationales discussed above), Celinski also discloses wherein the first message is transmitted directly (unicast packet) to the second device (FIG. 1; any one of 103, 104, 105, and 107) (col. 10, lines 34-51: "In one embodiment, the master device broadcasts or multicasts to all the slave devices a new type of broadcast or multicast packet, e.g., a UDP packet that includes the timing information. In another embodiment, an unicast packet is sent individually to all the slave devices over separate unicast-based channels, such that slave devices can receive the pairs (master_local_clock, TSF master_reading). In either case, in one embodiment, the information is broadcast, multicast, or unicast regularly … .").
Regarding claim 12, in addition to features recited in base claim 8 (see rationales discussed above), Celinski also discloses the first device being further configured to transmit the media to the second device (see FIG. 1 for connection details between device 106 and any of device 103-105, and 107 and col. 10, lines 34-51).
Regarding claim 13, in addition to features recited in base claim 7 (see rationales discussed above), Celinski also discloses the first device being further configured to: transmit the first message to a third device; determine a further event time in dependence on a time according to the first clock and an offset period of time; and transmit the determined further event time to the third device (the recitation appears to corresponding to the master device 106 broadcasts or multicast the playback time to all slave devices. And Celinski discloses the recitation at col. 10, lines 23-52 and thereinafter).
Regarding claim 14, in addition to features recited in base claim 13 (see rationales discussed above), Celinski also discloses wherein the further event time comprises a further playback time for playing media (playback time is discussed in col. 10, lines 23-33 and thereinafter).
Regarding claim 15, in addition to features recited in base claim 6 (see rationales discussed above), Celinski also discloses, the first device being further configured to: receive a third message comprising a second identifier from a fourth device; generate a second timestamp in dependence on the time at which the third message is received at the first device according to the first clock; generate a fourth message comprising the identifier and the generated second timestamp; and
transmit the fourth message to a fifth device (the recitations appear to correspond to the master device 106 broadcasts or multicast the playback time to all slave devices. And Celinski discloses the recitation at col. 10, lines 23-52 and thereinafter).
Regarding claim 16, in addition to features recited in base claim 15 (see rationales discussed above), Celinski also discloses wherein the first and second messages are transmitted in a first communications mode (unicast/broadcast) and the third and fourth messages are received and transmitted in a second communications mode (broadcast/unicast) (col. 10, lines 34-51: "In one embodiment, the master device broadcasts or multicasts to all the slave devices a new type of broadcast or multicast packet, e.g., a UDP packet that includes the timing information. In another embodiment, an unicast packet is sent individually to all the slave devices over separate unicast-based channels, such that slave devices can receive the pairs (master_local_clock, TSF master_reading). In either case, in one embodiment, the information is broadcast, multicast, or unicast regularly … .").
Regarding claim 17, in addition to features recited in base claim 6 (see rationales discussed above), Celinski also discloses the first device being further configured to: receive a third message comprising a second identifier from a fourth device; generate a second timestamp in dependence on the time at which the third message is received at the first device according to the first clock; receive a fourth message from a fifth device comprising the second identifier and a third timestamp, the third timestamp having been generated in dependence on the time at which the fifth device received the third message from the fourth device; and adjust the first clock in dependence on a difference between a time indicated by the second timestamp and a time indicated by the third timestamp (the recitations appear to correspond to the master device 106 broadcasts or multicast the playback time to all slave devices. And Celinski discloses the recitation at col. 10, lines 23-52 and thereinafter).
Regarding claim 18, in addition to features recited in base claim 17 (see rationales discussed above), Celinski also discloses wherein the first and second messages are transmitted in a first communications mode (unicast/broadcast) and the third and fourth messages are received in a second communications mode (broadcast/unicast) (col. 10, lines 34-51: "In one embodiment, the master device broadcasts or multicasts to all the slave devices a new type of broadcast or multicast packet, e.g., a UDP packet that includes the timing information. In another embodiment, an unicast packet is sent individually to all the slave devices over separate unicast-based channels, such that slave devices can receive the pairs (master_local_clock, TSF master_reading). In either case, in one embodiment, the information is broadcast, multicast, or unicast regularly … .").
Regarding claim 19, in addition to features recited in base claim 6 (see rationales discussed above), Celinski also discloses wherein the first device is further configured to operate according to a WLAN standard (IEEE 802.11) and the identifier is a timing synchronisation function (TSF) (col. 9, lines 15-47 and thereinafter; IEEE 802.11 and TSF are discussed).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Bui et al. (US 8,971,357).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK DUONG whose telephone number is (571)272-3164. The examiner can normally be reached 7:00AM-3:30PM.
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, MICHAEL THIER can be reached at 571-272-2832. 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.
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
/FRANK DUONG/Primary Examiner, Art Unit 2474 September 28, 2026
Prosecution Insights