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 21-39 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 2-9 of U.S. Patent No. 12,035,266 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because all of the claimed features of the current Application are disclosed, nearly identically, in the claims of U.S. Patent No. 12,035,266 B2 as shown in the Table below.
Current Application
US 12,035,266 B2
21. (New) A method comprising: receiving, at a device, a clock synchronization request from a remote device, the request being received over a wireless communication link; generating, by a controller associated with a firmware layer of the device, a response to the synchronization request, the response being configured for synchronizing a remote clock of the remote device and a local clock of the device; and sending, to the remote device, the response to the synchronization request, the controller of the firmware layer configured for generating the response without accessing an application processor (AP) of the device.
1. A method comprising: receiving a clock synchronization request, the request being received over a wireless communication link from a remote device; generating, by at least one processor, response data to respond to the synchronization request, the response data being configured for synchronizing a remote clock of the remote device and a local clock of a device; wherein generating the response data comprises, prior to receiving the request, precomputing the response data to respond to the synchronization request, the precomputed response data comprising L2CAP layer data; and preparing, for transmission to the remote device, the response data to the synchronization request.
2. The method of claim 1, wherein the at least one processor is configured for generating the response data without accessing an application processor (AP) of the device.
22. (New) The method of claim 21, further comprising: prior to receiving the request, precomputing response data for including in the response to the synchronization request, the precomputed response data comprising L2CAP layer data.
1. A method comprising: receiving a clock synchronization request, the request being received over a wireless communication link from a remote device; generating, by at least one processor, response data to respond to the synchronization request, the response data being configured for synchronizing a remote clock of the remote device and a local clock of a device; wherein generating the response data comprises, prior to receiving the request, precomputing the response data to respond to the synchronization request, the precomputed response data comprising L2CAP layer data; and preparing, for transmission to the remote device, the response data to the synchronization request.
23. (New) The method of claim 21, further comprising: maintaining the AP of the device in a hibernation state while generating the response, wherein the AP of the device consumes a reduced power in the hibernation state relative to an increased power consumed during an active state in which the AP is enabled to process data.
3. The method of claim 1, further comprising: maintaining an application processor (AP) of the device in a hibernation state while generating the response, wherein the AP of the device consumes a reduced power in the hibernation state relative to an increased power consumed during an active state in which the AP is enabled to process data.
24. (New) The method of claim 21, wherein the firmware layer comprises a Logical Link Control and Adaptation Protocol L2CAP layer.
4. The method of claim 1, wherein a firmware layer associated with the at least one processor comprises a Logical Link Control and Adaptation Protocol L2CAP layer.
25. (New) The method of claim 21, wherein generating the response to the synchronization request comprises: obtaining, from the request, a first clock value for the remote clock; accessing a second clock value for the local clock corresponding to receiving the request from the remote device; determining an adjustment for a first frequency of the remote clock, a second frequency value of the local clock, or both the first frequency and the second frequency; and generating data representing the determined adjustment, the response enabling the remote device to synchronize the remote clock with the local clock.
5. The method of claim 1, wherein generating the response data to respond to the synchronization request comprises: obtaining, from the request, a first clock value for the remote clock; accessing a second clock value for the local clock corresponding to receiving the request from the remote device; determining an adjustment for a first frequency of the remote clock, a second frequency value of the local clock, or both the first frequency and the second frequency; and generating data representing the determined adjustment, the response data configured to enable the remote device to synchronize the remote clock with the local clock.
26. (New) The method of claim 21, wherein the response comprises a converted Bluetooth (BT) clock value and a clock accuracy value, and wherein the synchronization request comprises a request for an ultra-wideband (UWB) clock value.
6. The method of claim 1, wherein the response data comprises a converted Bluetooth (BT) clock value and a clock accuracy value, and wherein the synchronization request comprises a request for an ultra-wideband (UWB) clock value.
27. (New) The method of claim 21, further comprising: generating BT credit data for controlling transmission to the remote device while an AP is in hibernation; sending the BT credit data to the firmware layer; and causing the AP to initiate hibernation.
7. The method of claim 1, further comprising: generating Bluetooth (BT) credit data, the BT credit data for use in controlling transmission to the remote device while an application processor (AP) is in hibernation; sending the BT credit data to firmware layer associated with the at least one processor; and causing the AP to initiate hibernation.
28. (New) The method of claim 21, wherein the wireless communications link comprises a Bluetooth link.
8. The method of claim 1, wherein the wireless communications link comprises a Bluetooth link.
29. (New) The method of claim 28, wherein the Bluetooth link comprises a Bluetooth Low Energy Long Range (LE-LR) link or a Bluetooth Low Energy (LE) Coded Physical Layer (PHY) link.
9. The method of claim 8, wherein the Bluetooth link comprises a Bluetooth Low Energy Long Range (LE-LR) link or a Bluetooth Low Energy (LE) Coded Physical Layer (PHY) link.
30. (New) One or more processors configured for wireless communication by performing operations comprising: receiving, for a device, a clock synchronization request from a remote device, the request being received over a wireless communication link; generating, for a firmware layer of the device, a response to the synchronization request, the response being configured for synchronizing a remote clock of the remote device and a local clock of the device; and sending, to the remote device, the response to the synchronization request without accessing an application processor (AP) of the device.
1. A method comprising: receiving a clock synchronization request, the request being received over a wireless communication link from a remote device; generating, by at least one processor, response data to respond to the synchronization request, the response data being configured for synchronizing a remote clock of the remote device and a local clock of a device; wherein generating the response data comprises, prior to receiving the request, precomputing the response data to respond to the synchronization request, the precomputed response data comprising L2CAP layer data; and preparing, for transmission to the remote device, the response data to the synchronization request.
2. The method of claim 1, wherein the at least one processor is configured for generating the response data without accessing an application processor (AP) of the device.
31. (New) The one or more processors of claim 30, further comprising: prior to receiving the request, precomputing response data for including in the response to the synchronization request, the precomputed response data comprising L2CAP layer data.
1. A method comprising: receiving a clock synchronization request, the request being received over a wireless communication link from a remote device; generating, by at least one processor, response data to respond to the synchronization request, the response data being configured for synchronizing a remote clock of the remote device and a local clock of a device; wherein generating the response data comprises, prior to receiving the request, precomputing the response data to respond to the synchronization request, the precomputed response data comprising L2CAP layer data; and preparing, for transmission to the remote device, the response data to the synchronization request.
32. (New) The one or more processors of claim 30, further comprising: maintaining the AP of the device in a hibernation state while generating the response, wherein the AP of the device consumes a reduced power in the hibernation state relative to an increased power consumed during an active state in which the AP is enabled to process data.
3. The method of claim 1, further comprising: maintaining an application processor (AP) of the device in a hibernation state while generating the response, wherein the AP of the device consumes a reduced power in the hibernation state relative to an increased power consumed during an active state in which the AP is enabled to process data.
33. (New) The one or more processors of claim 30, wherein the firmware layer comprises a Logical Link Control and Adaptation Protocol L2CAP layer.
4. The method of claim 1, wherein a firmware layer associated with the at least one processor comprises a Logical Link Control and Adaptation Protocol L2CAP layer.
34. (New) The one or more processors of claim 30, wherein generating the response to the synchronization request comprises: obtaining, from the request, a first clock value for the remote clock; accessing a second clock value for the local clock corresponding to receiving the request from the remote device; determining an adjustment for a first frequency of the remote clock, a second frequency value of the local clock, or both the first frequency and the second frequency; and generating data representing the determined adjustment, the response enabling the remote device to synchronize the remote clock with the local clock.
5. The method of claim 1, wherein generating the response data to respond to the synchronization request comprises: obtaining, from the request, a first clock value for the remote clock; accessing a second clock value for the local clock corresponding to receiving the request from the remote device; determining an adjustment for a first frequency of the remote clock, a second frequency value of the local clock, or both the first frequency and the second frequency; and generating data representing the determined adjustment, the response data configured to enable the remote device to synchronize the remote clock with the local clock.
35. (New) The one or more processors of claim 30, wherein the response comprises a converted Bluetooth (BT) clock value and a clock accuracy value, and wherein the synchronization request comprises a request for an ultra-wideband (UWB) clock value.
6. The method of claim 1, wherein the response data comprises a converted Bluetooth (BT) clock value and a clock accuracy value, and wherein the synchronization request comprises a request for an ultra-wideband (UWB) clock value.
36. (New) The one or more processors of claim 30, further comprising: generating BT credit data for controlling transmission to the remote device while an AP is in hibernation; sending the BT credit data to the firmware layer; and causing the AP to initiate hibernation.
7. The method of claim 1, further comprising: generating Bluetooth (BT) credit data, the BT credit data for use in controlling transmission to the remote device while an application processor (AP) is in hibernation; sending the BT credit data to firmware layer associated with the at least one processor; and causing the AP to initiate hibernation.
37. (New) The one or more processors of claim 30, wherein the wireless communications link comprises a Bluetooth link.
8. The method of claim 1, wherein the wireless communications link comprises a Bluetooth link.
38. (New) The one or more processors of claim 37, wherein the Bluetooth link comprises a Bluetooth Low Energy Long Range (LE-LR) link or a Bluetooth Low Energy (LE) Coded Physical Layer (PHY) link.
9. The method of claim 8, wherein the Bluetooth link comprises a Bluetooth Low Energy Long Range (LE-LR) link or a Bluetooth Low Energy (LE) Coded Physical Layer (PHY) link.
39. (New) The one or more processors of claim 30, wherein the one or more processors are included in a controller associated with the firmware layer of the device.
4. The method of claim 1, wherein a firmware layer associated with the at least one processor comprises a Logical Link Control and Adaptation Protocol L2CAP layer.
As shown in bold in the table above, claims 2-9 of US 12,035,266 B2 recites claim features nearly identical to those of claims 21-39 of the current Application. Claims 21-39 of the current Application are therefore rejected for obviousness-type double-patenting.
Claim 21, 23-30 and 32-39 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 2-9 of co-pending Application No. 18/737,925 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because all of the claimed features of the current applications are recited with nearly identical wordings as those of co-pending Application No. 18/737,925. The claims of the co-pending Application include claim features nearly identical to those of US 12,035,266 B2 as shown in the table above except for the claim features disclosed in claims 22 and 31 of the current Application. A side-by-side table comparing the current Application and the co-pending Application No. 18/737,925 is therefore not provided herein, please refer to the table above for the claim comparison.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claim Objections
Claims 27 and 36 objected to because of the following informalities: undefined abbreviation. Claims 27 and 36 recites the abbreviation “BT”, which are not defined in claims 27 and 36 or its parent claims.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 27 and 36 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention.
Claims 27 and 36 recites “generating BT credit data for controlling transmission to the remote device while an AP is in hibernation; sending the BT credit data to the firmware layer; and causing the AP to initiate hibernation”. As the method in claim 8 begins, the AP is already in hibernation. Therefore, it is not enabling how the method causes the AP to initiate hibernation when the AP is already in hibernation.
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.
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.
Claim(s) 21, 23, 25, 28, 30, 32, 34, 37 and 39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anvari (US 11,250,696) in view of Bhat Noojady Krishna (US 10,771,294).
Anvari discloses the following features.
Regarding claim 21, a method comprising:
receiving, at a device, a clock synchronization request from a remote device, the request being received over a wireless communication link (see Fig. 10D and column 26, lines 3-52, wherein an IoT1 device transmits a request for clock synchronization to IoT2 device over a wireless link, such a Bluetooth or WiFi link as shown in column 11, lines 27-34);
generating a response to the synchronization request, the response being configured for synchronizing a remote clock of the remote device of the remote device and a local clock of the device (see Fig. 10D and column 26, lines 3-52, wherein the IoT2 device receives the clock synchronization request and sends a response packet including timing information to the IoT1 device for clock synchronization; Fig. 10B shows that each of the IoT1 and IoT2 device includes its local clock and it is apparent that the clock synchronization protocol in Fig. 10D are used to synchronize the local clocks of IoT1 and IoT2); and
sending, to the remote device, the response to the synchronization request (see Fig. 10D and column 26, lines 3-52, wherein the IoT2 device receives the clock synchronization request and sends a response packet including timing information to the IoT1 device for clock synchronization; and see transceiver 867 in Fig. 10B for the IoT2 device for sending the wireless packets, including the claimed response to the synchronization request as shown in Fig. 10D).
Regarding claim 25, obtaining, from the request, a first clock value for the remote clock (see IoT2 receiving the timestamp t1 in the request packet shown in Fig. 10D); accessing a second clock value for the local clock corresponding to receiving the request from the remote device (see IoT2 accessing value t2 upon receiving the request in Fig. 10D); determining an adjustment for a first frequency of the remote clock, a second frequency value of the local clock, or both the first frequency and the second frequency; and generating data representing the determined adjustment, the response enabling the remote device to synchronize the remote clock with the local clock (see column 26, lines 37-52, “Then time offset is used by IoT1 device 936 to adjust its time of day and its clock frequency to match IoT2 device 937. In protocol 935, IoT2 device also send to IoT1 device the frame structure (frame start TOD and frame duration)”, wherein a time offset for adjusting the clock frequency of IoT1 device is determined from the message exchange to synchronize the clocks of IoT1 device and IoT2 device).
Regarding claim 28, wherein the wireless communications link comprises a Bluetooth link (see “Bluetooth” recited in column 11, lines 27-34 and throughout the document).
Regarding claim 30, one or more processors configured for wireless communication (see control processor 979 and transceiver circuits 971-974 in Fig. 13) by performing operations comprising:
receiving, for a device, a clock synchronization request from a remote device, the request being received over a wireless communication link (see Fig. 10D and column 26, lines 3-52, wherein an IoT1 device transmits a request for clock synchronization to IoT2 device over a wireless link, such a Bluetooth or WiFi link as shown in column 11, lines 27-34);
generating a response to the synchronization request, the response being configured for synchronizing a remote clock of the remote device and a local clock of the device (see Fig. 10D and column 26, lines 3-52, wherein the IoT2 device receives the clock synchronization request and sends a response packet including timing information to the IoT1 device for clock synchronization; Fig. 10B shows that each of the IoT1 and IoT2 device includes its local clock and it is apparent that the clock synchronization protocol in Fig. 10D are used to synchronize the local clocks of IoT1 and IoT2); and
sending, to the remote device, the response to the synchronization request (see Fig. 10D and column 26, lines 3-52, wherein the IoT2 device receives the clock synchronization request and sends a response packet including timing information to the IoT1 device for clock synchronization; and see transceiver 867 in Fig. 10B for the IoT2 device for sending the wireless packets, including the claimed response to the synchronization request as shown in Fig. 10D).
Regarding claim 34, obtaining, from the request, a first clock value for the remote clock (see IoT2 receiving the timestamp t1 in the request packet shown in Fig. 10D); accessing a second clock value for the local clock corresponding to receiving the request from the remote device (see IoT2 accessing value t2 upon receiving the request in Fig. 10D); determining an adjustment for a first frequency of the remote clock, a second frequency value of the local clock, or both the first frequency and the second frequency; and generating data representing the determined adjustment, the response enabling the remote device to synchronize the remote clock with the local clock (see column 26, lines 37-52, “Then time offset is used by IoT1 device 936 to adjust its time of day and its clock frequency to match IoT2 device 937. In protocol 935, IoT2 device also send to IoT1 device the frame structure (frame start TOD and frame duration)”, wherein a time offset for adjusting the clock frequency of IoT1 device is determined from the message exchange to synchronize the clocks of IoT1 device and IoT2 device).
Regarding claim 37, wherein the wireless communications link comprises a Bluetooth link (see “Bluetooth” recited in column 11, lines 27-34 and throughout the document).
Anvari does not disclose the following features: regarding claims 21 and 30, generating, by a controller associated with a firmware layer associated with the transceiver of the device, a response to the synchronization request (Anvari discloses the generating of the response, but does not disclose a controller associated with a firmware layer); and wherein the controller of the firmware layer configured for generating the response without accessing an application processor of the device; regarding claims 23 and 32, maintaining the AP of the mobile device in a hibernation state while generating the response, wherein the AP of the device consumes a reduced power in the hibernation state relative to an increased power consumed during an active state in which the AP is enabled to process data; regarding claim 39, wherein the one or more processors are included in a controller associated with the firmware layer of the device.
Bhat Noojady Krishna discloses the following features.
Regarding claims 21 and 30, generating, by a controller associated with a firmware layer associated the device, a response to the synchronization request (see “For example, BT firmware (e.g., a Bluetooth component or BT chip 820) may use the CoP data transport mechanism to send both a data payload and associated timestamp metadata using the sideband ID specific to send timestamps information. ADSP 815 may receive this sideband payload along with data…” recited in column 18, line 50- column 19, line 3; and see “Sideband data may be transported to convey parameter control information (e.g., control information for codec parameter control interfaces, such as information for quality mode changes), in band data (e.g., data specific parameters, such as timestamps for playback timing control and synchronization purposes), etc. Sideband data may be transported (e.g., communicated) over an interface between a Bluetooth component and an ADSP component while an applications processor is operating in a low power state or sleep mode” recited in the abstract); and wherein the controller of the firmware layer is configured for generating the response without accessing an application processor of the device (see “For example, BT firmware (e.g., a Bluetooth component or BT chip 820) may use the CoP data transport mechanism to send both a data payload and associated timestamp metadata using the sideband ID specific to send timestamps information. ADSP 815 may receive this sideband payload along with data…” recited in column 18, line 50- column 19, line 3; and see “Sideband data may be transported to convey parameter control information (e.g., control information for codec parameter control interfaces, such as information for quality mode changes), in band data (e.g., data specific parameters, such as timestamps for playback timing control and synchronization purposes), etc. Sideband data may be transported (e.g., communicated) over an interface between a Bluetooth component and an ADSP component while an applications processor is operating in a low power state or sleep mode” recited in the abstract).
Regarding claims 23 and 32, maintaining an AP of the device in a hibernation state while generating the response, wherein the AP of the device consumes a reduced power in the hibernation state relative to an increased power consumed during an active state in which the AP is enabled to process data (see “For example, BT firmware (e.g., a Bluetooth component or BT chip 820) may use the CoP data transport mechanism to send both a data payload and associated timestamp metadata using the sideband ID specific to send timestamps information. ADSP 815 may receive this sideband payload along with data…” recited in column 18, line 50- column 19, line 3; and see “Sideband data may be transported to convey parameter control information (e.g., control information for codec parameter control interfaces, such as information for quality mode changes), in band data (e.g., data specific parameters, such as timestamps for playback timing control and synchronization purposes), etc. Sideband data may be transported (e.g., communicated) over an interface between a Bluetooth component and an ADSP component while an applications processor is operating in a low power state or sleep mode” recited in the abstract).
Regarding claim 39, wherein the one or more processors are included in a controller associated with the firmware layer of the device (see “For example, BT firmware (e.g., a Bluetooth component or BT chip 820) may use the CoP data transport mechanism to send both a data payload and associated timestamp metadata using the sideband ID specific to send timestamps information. ADSP 815 may receive this sideband payload along with data…” recited in column 18, line 50- column 19, line 3)
It would have been obvious to one of ordinary skill in the art at the effective filing date of the current application to modify the system of Anvari using features, as taught by Bhat Noojady Krishna, in order to reduce delay and saves power consumption (see column 9, lines 25-51 of Bhat Noojady Krishna).
Claim(s) 24 and 33 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anvari and Bhat Noojady Krishna as applied to claims 21 and 30 above, and further in view of Kuang (US 2018/0083884).
Anvari and Bhat Noojady Krishna disclose the features as shown above.
Anvari does not disclose the following features: regarding claims 24 and 33, wherein the firmware layer comprises a L2CAP layer.
Kuang discloses the following features.
Regarding claims 24 and 33, wherein the firmware layer comprises a L2CAP layer (see “The BLUETOOTH host is configured to process BLUETOOTH upper layer protocol data exchange. The BLUETOOTH upper layer protocol includes the Logical Link Control & Adaptation Protocol (L2CAP)” recited in paragraph [0253], which may be implemented onto the Bluetooth component in Bhat Noojady Krishna’s invention).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the current application to modify the system of Anvari and Bhat Noojady Krishna using features, as taught by Kuang, in order to process BLUETOOTH upper layer data exchange (see paragraph [0253] of Kuang).
Claim(s) 29 and 38 is/are rejected under 35 U.S.C. 103 as being unpatentable over Anvari and Bhat Noojady Krishna as applied to claims 28 and 37 and above, and further in view of Su (US 2023/0071506).
Anvari and Bhat Noojady Krishna disclose the features as shown above.
Anvari does not disclose the following features: regarding claim 29 and 38, wherein the Bluetooth link comprises a Bluetooth LE-LR link or a Bluetooth LE Coded PHY link.
Su discloses the following features.
Regarding claim 29 and 38, wherein the Bluetooth link comprises a Bluetooth LE-LR link or a Bluetooth LE Coded PHY link (see “The format of the BLE packet is a packet format of a LE coded PHY in the Bluetooth protocol” recited in paragraph [0023]).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the current application to modify the system of Anvari and Bhat Noojady Krishna using features, as taught by Su, in order to provide wireless communication for devices with energy constraint (see paragraph [0021] of Su).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUTAI KAO whose telephone number is (571)272-9719. The examiner can normally be reached Monday-Friday 8:00-17:00 EST.
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, Kwang Yao can be reached at (571)272-3182. 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.
/JUTAI KAO/Primary Examiner, Art Unit 2473
Prosecution Insights