Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
2. Claim 26 objected to because of the following informalities: Claim 12 is cancelled. What should be claim 26 is written as "12". Please change claim 26 to the number 26. . Appropriate correction is required.
Claim Rejections - 35 USC § 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 26-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
In claim 26, “computer-readable medium” is disclosed and the specification is silent with the definition of the “computer-readable medium” In ordinary and customary meaning, the computer-readable medium can be transitory medium such as signal as well as non-transitory medium. Thus, the broadest reasonable interpretation in light of specification encompasses that the computer-readable medium a forms transitory propagating signal per se that is non-statutory subject matter under 35 U.S.C. 101, signal per se
Claims 27-30 depend from claim 26 and are rejected for the same reasons
Claim Rejections - 35 USC § 102
3. 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)(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 and 8 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Le et al. (E.P. Pub. No. 4080920A1).
Regarding claim 1, Le teaches a method implemented by an electronic device having a wireless short-range communication circuit and a system on a chip (SOC), the SOC including a coprocessor, a memory, and a processor, ([0138]: communications device 700 according to an embodiment of this application. The device 700 may include one or more processors 702, system control logic 708 connected to at least one of the processors 702, a system memory 704. [0147]: at least one of the processors 702 may be packaged with logic of one or more controllers for the system control logic 708 to form a system in a package (SiP). In an embodiment, at least one of the processors 702 may be integrated on the same die with the logic of one or more controllers for the system control logic 708 to form a system on chip (SoC). [0054]: in FIG. 1b, the user equipment 1 may include one or more (only one is shown in the figure) processors 10, a sensor hub 12, and a Bluetooth communications module 14. The processor 10 may include, but is not limited to, a central processing unit (central processing unit, CPU), an application processor (application processor). [0056]: The sensor hub 12, or referred to as sensor hub or a sensor coprocessor, is mainly configured to connect various sensor devices and process data from the various sensor devices with low power consumption. The sensor hub 12 may include processing circuits such as a low-power application processor (application processor), a coprocessor (coprocessor). [0085]: the sensor hub 12 may include a volatile or non-volatile storage medium.) the method comprising: receiving, from one or more other devices, proximity messages at the wireless short-range communication circuit ([0031]: the coprocessor is further configured to receive, from the wireless communications module, a second broadcast message from at least one second device other than the device. [0059]: the Bluetooth communications module 14 can implement Bluetooth functions such as Bluetooth advertising (advertising, ADV), Bluetooth scanning (scanning).) forwarding, via a power management bus, the proximity messages to the coprocessor of the SOC ([0083]: After the Bluetooth communications module 14 receives an HCI (host controller interface, host controller interface) uplink data during scanning, the filter 143 filters the uplink data. The controller 142 controls the channel switching module 141 to send the filtered data to the sensor hub 12. data conforming to the filter of the sensor hub 12 is sent to the sensor hub 12 by using the I2C/I3C.), while the processor is in a low power mode ([0079]: The instruction for offline Bluetooth scanning is used to instruct the processor 10 to go offline after the instruction is sent, to instruct the sensor hub 12 that the processor 10 is about to go offline, and to instruct the sensor hub 12 to start standard Bluetooth scanning or BLE scanning.); processing the proximity messages by the coprocessor to obtain processed proximity messages ([0085]: At block 306, the sensor hub 12 parses the reported scanning result and stores the parsed data. For example, if the scanning result is broadcast data, the Bluetooth application 121 parses data such as broadcast device address, broadcast access address and local name from the broadcast data. The parsed data may be stored in the sensor hub 12.); storing the processed proximity message in a proximity buffer in the memory of the SOC ([0085]: At block 306, the sensor hub 12 parses the reported scanning result and stores the parsed data. For example, if the scanning result is broadcast data, the Bluetooth application 121 parses data such as broadcast device address, broadcast access address and local name from the broadcast data. The parsed data may be stored in the sensor hub 12.); determining whether a triggering event has occurred ( [0087]: the sensor hub 12 may send a wake-up request after the capacity of the stored data reaches a predetermined size, such as 64 KB or 128 KB.); responsive to a triggering event, waking the processor from the low power mode ([0086]: at block 307, the sensor hub 12 can send a wake-up request to the processor 10 to wake up the processor 10 from the sleep state.); and analyzing the processed proximity messages using the processor ([0086]: After the processor 10 is woken up at block 308, at 309, the sensor hub 12 sends the parsed data, for example, the Bluetooth application 121 sends the parsed data to the processor 10. As an example, the processor 10 receives the parsed data by using the sensor driver 103, the data is uplinked and passes through the sensor HAL 102 and the sensor architecture 101 and reaches the application layer, and at the application layer, an application requesting for Bluetooth data may use the parsed data.).
Regarding claim 8, Le teaches the subject matter of claim 1. Le further teaches wherein the trigger event occurs when an amount of utilized space in the memory of the SOC exceeds a memory threshold ([0086]: at block 307, the sensor hub 12 can send a wake-up request to the processor 10 to wake up the processor 10 from the sleep state. [0087]: the sensor hub 12 may send a wake-up request after the capacity of the stored data reaches a predetermined size, such as 64 KB or 128 KB.).
Claim Rejections - 35 USC § 103
4. 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 2 is rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view of Johnsen et al. (U.S. Pub. No. 20160226999A1).
Regarding claim 2, Le teaches the subject matter disclosed in claim 1 but fails to teach claim 2.
However, Johnsen does teach wherein the processing comprises deduplicating ([0025]: The second screen application 150 performs a deduplication on the updated device list, for example by gathering entries in the device list by application identifier, and then creating a single device entry, for each application identifier, in a session interface that is used to interface with the second screen application 150.) the proximity messages ([0025]: The second screen application 150 discovers devices that are available to couple to the client device 100 via, for example, WIFI, BLUETOOTH. The second screen application 150 maintains a device list of the discovered devices. The second screen application 150 updates the device list with information about the discovered devices (e.g., application identifiers, coupling protocols, etc.).). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising and scanning on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le further teaches a mechanism performed by the coprocessor to wake-up the main processor from a low power state, upon a certain storage capacity being reached. This method therefore requires an efficient storage solution to maximize the quantity of data being stored before the main processor is triggered. Johnsen provides such a solution applied to a Bluetooth-capable device. Johnsen teaches a method of deduplicating proximity/discovery messages. Johnsen discloses a second screen application maintains a device list that accumulates multiple entries for the same device, and then deduplicated the devices list based on a common application identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le’s low-energy wireless communication method with Johnsen’s proximity message deduplication technique in order to enhance user experience (Johnsen [0005]).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view of Johnsen et al. (U.S. Pub. No. 20160226999A1) as applied to claim 2, and further in view of Ippatapu et al. (U.S. Pub. No. 20230027284A1).
Regarding claim 3, Le in view of Johnsen teach the subject matter disclosed in claims 1 and 2 but fail to teach claim 3.
However, Le in view of Johnsen does teach wherein deduplicating the messages comprises: identifying a first byte pattern in the proximity messages; storing the first byte pattern to the memory of the SOC; locating one or more additional byte patterns that match the first byte pattern; and replacing the one or more additional byte patterns with a reference to the stored first byte pattern ([0016]: Storage arrays can be configured to perform data deduplication (dedupe) to eliminate duplicate copies of data. Dedupe techniques include comparing data ‘chunks’ (also known as ‘byte patterns’) which are unique, contiguous data blocks. The techniques identify the chunks by comparing them to other chunks within existing data using input/output (IO) fingerprints. Whenever a match occurs, the techniques replace the redundant chunk with a reference that points to the stored chunk. Examiner note: the “stored chunk” is interpreted to be the stored first byte pattern). Le teaches that the coprocessor parses the proximity messages it receives and stores the parsed data in its own memory, accumulating it until a storage-capacity threshold is reached, at which point it wakes the main processor. Le's method, therefore, depends on storing as much message data as possible in the coprocessor's memory before the processor must be woken. Johnsen adds that those proximity messages are deduplicated. However, the combination of Le and Johnsen does not specify how that deduplication mechanism identifies and removes redundant data. Ippatapu teaches such a mechanism applied to memory. Ippatapu discloses identifying a byte pattern, storing it in memory, locating byte patterns that match the stored pattern, and replacing redundant matching patterns with a reference to the stored byte pattern, such that one copy of the data remains. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined teachings of Le and Johnsen with Ippatapu's deduplication technique in order to reduce redundant data stored in memory (Ippatapu [0001]).
Claims 4, 5, and 6 are rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view of Zakaria (U.S. Pub. No. 9503969B1).
Regarding claim 4, Le teaches the subject matter of claim 1 but fails to teach claim 4.
However, Zakaria does teach wherein the proximity message ([Col. 24, Lines 40-41]: the message is sent to the IoT device on the negotiation channel. [Col. 26, Lines 40-43]: The “negotiation messages" may include messages used by the BT device 1910 and the BT communication module 1901 to establish a secure communication channel.) comprises a unique identifier and a signature that is generated with a private key corresponding to a second electronic device ([Col. 24, Lines 22-30]: The IoT service 120 initially generates a message containing the following: the IoT service’s unique ID; signature over the unique ID. Examiner Note: Generating a digital signature necessarily requires a private key.). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le does not address the security of the BLE messages being exchanged during these advertising, scanning, and data synchronization operations. However, Zakaria teaches a comprehensive security architecture for BLE communications, including a negotiation channel built on GATT characteristics, an ECDH key exchange that generates a shared session secret, and encrypted device packets that pass through the IoT hub to the IoT device over BTLE. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Zakaria's BLE secure communications technique in order to more effectively secure communications (Zakaria [Col. 14, Line 54]).
Regarding claim 5, Le in view of Zakaria teaches the subject matter disclosed in claims 1 and 4. Zakaria further teaches wherein generating the signature comprises: calculating a signature value using the unique identifier and the private key; and appending the signature to the unique identifier to produce the proximity message ([Col. 24, Lines 7-8, Lines: private key is used to generate a signature over IoT service public keys and IoT device public keys. Lines 22-30: The IoT service 120 initially generates a message containing the following: the IoT service’s unique ID; signature over the unique ID). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le does not address the security of the BLE messages being exchanged during these advertising, scanning, and data synchronization operations. However, Zakaria teaches a comprehensive security architecture for BLE communications, including a negotiation channel built on GATT characteristics, an ECDH key exchange that generates a shared session secret, and encrypted device packets that pass through the IoT hub to the IoT device over BTLE. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Zakaria's BLE secure communications technique in order to more effectively secure communications (Zakaria [Col. 14, Line 54]).
Regarding claim 6, Le in view of Zakaria teaches the subject matter disclosed in claims 1, 4, and 5. Zakaria further teaches wherein processing the proximity messages (Col. 24, Lines 40-41: the message is sent to the IoT device on the negotiation channel. Col. 26, Lines 40-43: The “negotiation messages" may include messages used by the BT device 1910 and the BT communication module 1901 to establish a secure communication channel.) comprises verifying the signature using a public key corresponding to the private key ([Col. 24, Lines 45-46: Verifies the signature of the unique ID using the key identified by the unique ID). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le does not address the security of the BLE messages being exchanged during these advertising, scanning, and data synchronization operations. However, Zakaria teaches a comprehensive security architecture for BLE communications, including a negotiation channel built on GATT characteristics, an ECDH key exchange that generates a shared session secret, and encrypted device packets that pass through the IoT hub to the IoT device over BTLE. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Zakaria's BLE secure communications technique in order to more effectively secure communications (Zakaria [Col. 14, Line 54]).
Claims 7, 21, 24, 26, and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view of Dunsbergen et al. (U.S. Pub. No. 20200120597A1).
Regarding claim 7, Le teaches the subject matter disclosed in claim 1 but fails to teach claim 7.
However, Dunsbergen does teach wherein the triggering event occurs at an expiration of a timer ([0019]: the memory resource 109 can include instructions, executable by the processor 107 to receive, via the BLE SoC 105 an indication to wake up the AP 100. AP 100 can receive an indication in response to a timer indicating to wake up the AP 100 in response to the timer reaching an elapsed amount of time.). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]).
Regarding claim 21, Le teaches a method implemented by an electronic device having a wireless short-range communication circuit and a system on a chip (SOC), the SOC including a coprocessor, a memory, and a processor, ([0138]: communications device 700 according to an embodiment of this application. The device 700 may include one or more processors 702, system control logic 708 connected to at least one of the processors 702, a system memory 704. [0147]: at least one of the processors 702 may be packaged with logic of one or more controllers for the system control logic 708 to form a system in a package (SiP). In an embodiment, at least one of the processors 702 may be integrated on the same die with the logic of one or more controllers for the system control logic 708 to form a system on chip (SoC). [0054]: in FIG. 1b, the user equipment 1 may include one or more (only one is shown in the figure) processors 10, a sensor hub 12, and a Bluetooth communications module 14. The processor 10 may include, but is not limited to, a central processing unit (central processing unit, CPU), an application processor (application processor). [0056]: The sensor hub 12, or referred to as sensor hub or a sensor coprocessor, is mainly configured to connect various sensor devices and process data from the various sensor devices with low power consumption. The sensor hub 12 may include processing circuits such as a low-power application processor (application processor), a coprocessor (coprocessor). [0085]: the sensor hub 12 may include a volatile or non-volatile storage medium.) the method comprising: receiving, from one or more other devices, proximity messages at the wireless short-range communication circuit ([0031]: the coprocessor is further configured to receive, from the wireless communications module, a second broadcast message from at least one second device other than the device. [0059]: the Bluetooth communications module 14 can implement Bluetooth functions such as Bluetooth advertising (advertising, ADV), Bluetooth scanning (scanning).) forwarding, via a power management bus, the proximity messages to the coprocessor of the SOC ([0083]: After the Bluetooth communications module 14 receives an HCI (host controller interface, host controller interface) uplink data during scanning, the filter 143 filters the uplink data. The controller 142 controls the channel switching module 141 to send the filtered data to the sensor hub 12. data conforming to the filter of the sensor hub 12 is sent to the sensor hub 12 by using the I2C/I3C.), while the processor is in a low power mode ([0079]: The instruction for offline Bluetooth scanning is used to instruct the processor 10 to go offline after the instruction is sent, to instruct the sensor hub 12 that the processor 10 is about to go offline, and to instruct the sensor hub 12 to start standard Bluetooth scanning or BLE scanning.); processing the proximity messages by the coprocessor to obtain processed proximity messages ([0085]: At block 306, the sensor hub 12 parses the reported scanning result and stores the parsed data. For example, if the scanning result is broadcast data, the Bluetooth application 121 parses data such as broadcast device address, broadcast access address and local name from the broadcast data. The parsed data may be stored in the sensor hub 12.); storing the processed proximity message in a proximity buffer in the memory of the SOC ([0085]: At block 306, the sensor hub 12 parses the reported scanning result and stores the parsed data. For example, if the scanning result is broadcast data, the Bluetooth application 121 parses data such as broadcast device address, broadcast access address and local name from the broadcast data. The parsed data may be stored in the sensor hub 12.); determining whether a triggering event has occurred ( [0087]: the sensor hub 12 may send a wake-up request after the capacity of the stored data reaches a predetermined size, such as 64 KB or 128 KB.); responsive to a triggering event, waking the processor from the low power mode ([0086]: at block 307, the sensor hub 12 can send a wake-up request to the processor 10 to wake up the processor 10 from the sleep state.); and analyzing the processed proximity messages using the processor ([0086]: After the processor 10 is woken up at block 308, at 309, the sensor hub 12 sends the parsed data, for example, the Bluetooth application 121 sends the parsed data to the processor 10. As an example, the processor 10 receives the parsed data by using the sensor driver 103, the data is uplinked and passes through the sensor HAL 102 and the sensor architecture 101 and reaches the application layer, and at the application layer, an application requesting for Bluetooth data may use the parsed data.). Le fails to teach a computing device ([0015]: an AP 100 including BLE SoC ), comprising: one or more memories; and one or more processors in communication with the one or more memories and configured to execute instructions stored in the one or more memories.
However, Dunsbergen does teach a computing device ([0015]: an AP 100 including BLE SoC ), comprising: one or more memories; and one or more processors in communication with the one or more memories and configured to execute instructions stored in the one or more memories ([0015]: AP 100 can include BLE SoC 105, and antenna 145. AP 100 can include a processor 107 and a memory resource 109. The memory resource 109 can be used to store instructions executable by the processor to perform a number of operations). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]).
Regarding claim 24, Le in view Dunsbergen teaches the subject matter disclosed in claim 21. Le further teaches wherein the triggering event occurs at an expiration of a timer or occurs when an amount of utilized space in the memory of the SOC exceeds a memory threshold ([0086]: at block 307, the sensor hub 12 can send a wake-up request to the processor 10 to wake up the processor 10 from the sleep state. [0087]: the sensor hub 12 may send a wake-up request after the capacity of the stored data reaches a predetermined size, such as 64 KB or 128 KB.). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]).
Regarding claim 26, Le teaches a method implemented by an electronic device having a wireless short-range communication circuit and a system on a chip (SOC), the SOC including a coprocessor, a memory, and a processor, ([0138]: communications device 700 according to an embodiment of this application. The device 700 may include one or more processors 702, system control logic 708 connected to at least one of the processors 702, a system memory 704. [0147]: at least one of the processors 702 may be packaged with logic of one or more controllers for the system control logic 708 to form a system in a package (SiP). In an embodiment, at least one of the processors 702 may be integrated on the same die with the logic of one or more controllers for the system control logic 708 to form a system on chip (SoC). [0054]: in FIG. 1b, the user equipment 1 may include one or more (only one is shown in the figure) processors 10, a sensor hub 12, and a Bluetooth communications module 14. The processor 10 may include, but is not limited to, a central processing unit (central processing unit, CPU), an application processor (application processor). [0056]: The sensor hub 12, or referred to as sensor hub or a sensor coprocessor, is mainly configured to connect various sensor devices and process data from the various sensor devices with low power consumption. The sensor hub 12 may include processing circuits such as a low-power application processor (application processor), a coprocessor (coprocessor). [0085]: the sensor hub 12 may include a volatile or non-volatile storage medium.) the method comprising: receiving, from one or more other devices, proximity messages at the wireless short-range communication circuit ([0031]: the coprocessor is further configured to receive, from the wireless communications module, a second broadcast message from at least one second device other than the device. [0059]: the Bluetooth communications module 14 can implement Bluetooth functions such as Bluetooth advertising (advertising, ADV), Bluetooth scanning (scanning).) forwarding, via a power management bus, the proximity messages to the coprocessor of the SOC ([0083]: After the Bluetooth communications module 14 receives an HCI (host controller interface, host controller interface) uplink data during scanning, the filter 143 filters the uplink data. The controller 142 controls the channel switching module 141 to send the filtered data to the sensor hub 12. data conforming to the filter of the sensor hub 12 is sent to the sensor hub 12 by using the I2C/I3C.), while the processor is in a low power mode ([0079]: The instruction for offline Bluetooth scanning is used to instruct the processor 10 to go offline after the instruction is sent, to instruct the sensor hub 12 that the processor 10 is about to go offline, and to instruct the sensor hub 12 to start standard Bluetooth scanning or BLE scanning.); processing the proximity messages by the coprocessor to obtain processed proximity messages ([0085]: At block 306, the sensor hub 12 parses the reported scanning result and stores the parsed data. For example, if the scanning result is broadcast data, the Bluetooth application 121 parses data such as broadcast device address, broadcast access address and local name from the broadcast data. The parsed data may be stored in the sensor hub 12.); storing the processed proximity message in a proximity buffer in the memory of the SOC ([0085]: At block 306, the sensor hub 12 parses the reported scanning result and stores the parsed data. For example, if the scanning result is broadcast data, the Bluetooth application 121 parses data such as broadcast device address, broadcast access address and local name from the broadcast data. The parsed data may be stored in the sensor hub 12.); determining whether a triggering event has occurred ( [0087]: the sensor hub 12 may send a wake-up request after the capacity of the stored data reaches a predetermined size, such as 64 KB or 128 KB.); responsive to a triggering event, waking the processor from the low power mode ([0086]: at block 307, the sensor hub 12 can send a wake-up request to the processor 10 to wake up the processor 10 from the sleep state.); and analyzing the processed proximity messages using the processor ([0086]: After the processor 10 is woken up at block 308, at 309, the sensor hub 12 sends the parsed data, for example, the Bluetooth application 121 sends the parsed data to the processor 10. As an example, the processor 10 receives the parsed data by using the sensor driver 103, the data is uplinked and passes through the sensor HAL 102 and the sensor architecture 101 and reaches the application layer, and at the application layer, an application requesting for Bluetooth data may use the parsed data.). Le fails to teach a computer-readable medium storing a plurality of instructions that, when executed by one or more processors of a computing device, cause the one or more processors to perform.
However, Dunsbergen does teach a computer-readable medium storing a plurality of instructions that, when executed by one or more processors of a computing device, cause the one or more processors to perform ([0015]: AP 100 can include a processor 107 and a memory resource 109. The memory resource 109 can be used to store instructions executable by the processor to perform a number of operations). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]).
Regarding claim 29, Le in view of Dunsbergen teach the subject matter disclosed in claim 26. Le further teaches computer-readable medium of claim 26, wherein the triggering event occurs at an expiration of a timer or occurs when an amount of utilized space in the memory of the SOC exceeds a memory threshold ([0086]: at block 307, the sensor hub 12 can send a wake-up request to the processor 10 to wake up the processor 10 from the sleep state. [0087]: the sensor hub 12 may send a wake-up request after the capacity of the stored data reaches a predetermined size, such as 64 KB or 128 KB.). Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]).
Claims 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view of Good et al. (U.S. Pub. No. 20160026837A1).
Regarding claim 9, Le teaches the subject matter disclosed in claim 1 but fails to teach claim 9.
However, Good does teach the receiving further comprises: identifying one or more messages with a signal strength below a signal threshold; and discarding the identified one or more messages ([0125]: the proximity engine 560 discards the received beacon message when the RSSI strength does not satisfy the proximity threshold. [0147]: The processor 1112 of the illustrated example executes the instructions to implement the example proximity engine 560.). Le discloses a sensor hub that performs BLE scanning while the main processor sleeps, receiving broadcast messages from nearby devices and caching the scanned data. However, Le fails to specify any mechanism for qualifying the scanned messages before storing or acting on them. Le's sensor hub indiscriminately collects and processes all BLE broadcast messages it receives, including those from distant devices whose signals are too weak to be meaningful, and stores that data in the coprocessor. Good teaches a reader badge that determines the signal strength associated with each received beacon message, compares that signal strength to a signal strength threshold, and records the message only if the threshold is satisfied, discarding messages that fall below it. This RSSI-based filtering step ensures that only messages from sufficiently proximate devices are collected and processed. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's method with Good's technique in order to reduce perceived interference in BLE communication (Good [0007]).
Regarding claim 10, Le teaches the subject matter disclosed in claim 1 but fails to teach the subject matter disclosed in claim 10.
However, Good does teach wherein the processing further comprises: identifying one or more messages with a signal strength below a signal threshold; and discarding the identified one or more messages ([0125]: the proximity engine 560 discards the received beacon message when the RSSI strength does not satisfy the proximity threshold. [0147]: The processor 1112 of the illustrated example executes the instructions to implement the example proximity engine 560.). Le discloses a sensor hub that performs BLE scanning while the main processor sleeps, receiving broadcast messages from nearby devices and caching the scanned data. However, Le fails to specify any mechanism for qualifying the scanned messages before storing or acting on them. Le's sensor hub indiscriminately collects and processes all BLE broadcast messages it receives, including those from distant devices whose signals are too weak to be meaningful, and stores that data in the coprocessor. Good teaches a reader badge that determines the signal strength associated with each received beacon message, compares that signal strength to a signal strength threshold, and records the message only if the threshold is satisfied, discarding messages that fall below it. This RSSI-based filtering step ensures that only messages from sufficiently proximate devices are collected and processed. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's method with Good's technique in order to reduce perceived interference in BLE communication (Good [0007]).
Claims 22 and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view Dunsbergen et al. (U.S. Pub. No. 20200120597A1) and further in view of Johnsen et al. (U.S. Pub. No. 20160226999A1).
Regarding claim 22, Le in view of Dunsbergen teach the subject matter disclosed in claim 21. Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]). Le in view of Dunsbergen fails to teach the subject matter disclosed in claim 22.
However, Johnsen does teach wherein the processing comprises deduplicating ([0025]: The second screen application 150 performs a deduplication on the updated device list, for example by gathering entries in the device list by application identifier, and then creating a single device entry, for each application identifier, in a session interface that is used to interface with the second screen application 150.) the proximity messages ([0025]: The second screen application 150 discovers devices that are available to couple to the client device 100 via, for example, WIFI, BLUETOOTH. The second screen application 150 maintains a device list of the discovered devices. The second screen application 150 updates the device list with information about the discovered devices (e.g., application identifiers, coupling protocols, etc.).). The combination of Le and Dunsbergen teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising and scanning on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le and Dunsbergen further teach a mechanism performed by the coprocessor to wake-up the main processor from a low power state, upon a certain storage capacity being reached. This method therefore requires an efficient storage solution to maximize the quantity of data being stored before the main processor is triggered. Johnsen provides such a solution applied to a Bluetooth-capable device. Johnsen teaches a method of deduplicating proximity/discovery messages. Johnsen discloses a second screen application maintains a device list that accumulates multiple entries for the same device, and then deduplicated the devices list based on a common application identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le and Dunsbergen method with Johnsen’s proximity message deduplication technique in order to enhance user experience (Johnsen [0005]).
Regarding claim 27, Le in view of Dunsbergen teaches the subject matter disclosed in claim 26. Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]). Le in view of Dunsbergen fails to teach claim 27.
However, Johnsen does teach wherein the processing comprises deduplicating ([0025]: The second screen application 150 performs a deduplication on the updated device list, for example by gathering entries in the device list by application identifier, and then creating a single device entry, for each application identifier, in a session interface that is used to interface with the second screen application 150.) the proximity messages ([0025]: The second screen application 150 discovers devices that are available to couple to the client device 100 via, for example, WIFI, BLUETOOTH. The second screen application 150 maintains a device list of the discovered devices. The second screen application 150 updates the device list with information about the discovered devices (e.g., application identifiers, coupling protocols, etc.).). The combination of Le and Dunsbergen teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising and scanning on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le and Dunsbergen further teach a mechanism performed by the coprocessor to wake-up the main processor from a low power state, upon a certain storage capacity being reached. This method therefore requires an efficient storage solution to maximize the quantity of data being stored before the main processor is triggered. Johnsen provides such a solution applied to a Bluetooth-capable device. Johnsen teaches a method of deduplicating proximity messages. Johnsen discloses a second screen application maintains a device list that accumulates multiple entries for the same device, and then deduplicated the devices list based on a common application identifier. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le and Dunsbergen method with Johnsen’s proximity message deduplication technique in order to enhance user experience (Johnsen [0005]).
Claims 23 and 28 are rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view Dunsbergen et al. (U.S. Pub. No. 20200120597A1) and further in view of Zakaria (U.S. Pub. No. 9503969B1).
Regarding claim 23, Le in view of Dunsbergen teaches the subject matter disclosed in claim 21. Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]). Le in view of Dunsbergen fails to teach the subject matter disclosed in claim 23.
However, Zakaria does teach wherein the proximity message (Col. 24, Lines 40-41: the message is sent to the IoT device on the negotiation channel. Col. 26, Lines 40-43: The “negotiation messages" may include messages used by the BT device 1910 and the BT communication module 1901 to establish a secure communication channel.) comprises a unique identifier and a signature that is generated with a private key corresponding to a second electronic device ([Col. 24, Lines 22-30: The IoT service 120 initially generates a message containing the following: the IoT service’s unique ID; signature over the unique ID. Examiner Note: Generating a digital signature necessarily requires a private key.). The combined system of Le and Dunsbergen teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le and Dunsbergen do not address the security of the BLE messages being exchanged during these advertising, scanning, and data synchronization operations. However, Zakaria teaches a comprehensive security architecture for BLE communications, including a negotiation channel built on GATT characteristics, an ECDH key exchange that generates a shared session secret, and encrypted device packets that pass through the IoT hub to the IoT device over BTLE. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined system of Le and Dunsbergen with Zakaria's BLE secure communications technique in order to more effectively secure communications (Zakaria [Col. 14, Line 54]).
Regarding claim 28, Le in view of Dunsbergen teaches the subject matter disclosed in claim 26. Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]). Le in view of Dunsbergen fails to teach the subject matter disclosed in claim 28.
However, Zakaria does teach wherein the proximity message (Col. 24, Lines 40-41: the message is sent to the IoT device on the negotiation channel. Col. 26, Lines 40-43: The “negotiation messages" may include messages used by the BT device 1910 and the BT communication module 1901 to establish a secure communication channel.) comprises a unique identifier and a signature that is generated with a private key corresponding to a second electronic device ([Col. 24, Lines 22-30: The IoT service 120 initially generates a message containing the following: the IoT service’s unique ID; signature over the unique ID. Examiner Note: Generating a digital signature necessarily requires a private key.). The combined system of Le and Dunsbergen teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le and Dunsbergen do not address the security of the BLE messages being exchanged during these advertising, scanning, and data synchronization operations. However, Zakaria teaches a comprehensive security architecture for BLE communications, including a negotiation channel built on GATT characteristics, an ECDH key exchange that generates a shared session secret, and encrypted device packets that pass through the IoT hub to the IoT device over BTLE. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined system of Le and Dunsbergen with Zakaria's BLE secure communications technique in order to more effectively secure communications (Zakaria [Col. 14, Line 54]).
Claims 25 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Le et al. (E.P. Pub. No. 4080920A1) in view Dunsbergen et al. (U.S. Pub. No. 20200120597A1) and further in view of Good et al. (U.S. Pub. No. 20160026837A1).
Regarding claim 25, Le in view of Dunsbergen teaches the subject matter disclosed in claim 21. Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]). Le in view of Dunsbergen fails to teach claim 25.
However, Good does teach wherein the receiving further comprises: identifying one or more messages with a signal strength below a signal threshold; and discarding the identified one or more messages ([0125]: the proximity engine 560 discards the received beacon message when the RSSI strength does not satisfy the proximity threshold. [0147]: The processor 1112 of the illustrated example executes the instructions to implement the example proximity engine 560.). The combined system of Le and Dunsbergen disclose a sensor hub that performs BLE scanning while the main processor sleeps, receiving broadcast messages from nearby devices and caching the scanned data. However, Le and Dunsbergen fail to specify any mechanism for qualifying the scanned messages before storing or acting on them. Le and Dunsbergen's sensor hub indiscriminately collects and processes all BLE broadcast messages it receives, including those from distant devices whose signals are too weak to be meaningful, and stores that data in the coprocessor. Good teaches a reader badge that determines the signal strength associated with each received beacon message, compares that signal strength to a signal strength threshold, and records the message only if the threshold is satisfied, discarding messages that fall below it. This RSSI-based filtering step ensures that only messages from sufficiently proximate devices are collected and processed. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined system of Le and Dunsbergen with Good's technique in order to reduce perceived interference in BLE communication (Good [0007]).
Regarding claim 30, Le in view of Dunsbergen teaches the subject matter disclosed in claim 26. Le teaches a low-energy wireless communication process where a coprocessor handles Bluetooth advertising, scanning, and data synchronization on behalf of the main processor, to enable the main processor to sleep while the coprocessor handles the Bluetooth driving, thereby enabling low power Bluetooth communication. Le fails to employ a timer-based trigger in the coprocessor, so the main processor can be awakened at scheduled intervals to process synchronization data, update system state, or initiate communication events, balancing power conservation with timely execution of BLE functions. However, Dunsbergen teaches that upon detecting that the access point is in power save mode, the BLE SoC activates a timer and continuously monitors it to determine the elapsed time. Once that elapsed period has passed, the BLE SoC transmits a signal indicating that the device should exit power-save mode and be woken up. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Le's low-energy wireless communication method with Dunsbergen's teachings in order to more effectively manage BLE power state transitions (Dunsbergen [0011]). Le in view of Dunsbergen fails to teach claim 30.
However, Good does teach wherein the receiving further comprises: identifying one or more messages with a signal strength below a signal threshold; and discarding the identified one or more messages ([0125]: the proximity engine 560 discards the received beacon message when the RSSI strength does not satisfy the proximity threshold. [0147]: The processor 1112 of the illustrated example executes the instructions to implement the example proximity engine 560.). The combined system of Le and Dunsbergen disclose a sensor hub that performs BLE scanning while the main processor sleeps, receiving broadcast messages from nearby devices and caching the scanned data. However, Le and Dunsbergen fail to specify any mechanism for qualifying the scanned messages before storing or acting on them. Le and Dunsbergen's sensor hub indiscriminately collects and processes all BLE broadcast messages it receives, including those from distant devices whose signals are too weak to be meaningful, and stores that data in the coprocessor. Good teaches a reader badge that determines the signal strength associated with each received beacon message, compares that signal strength to a signal strength threshold, and records the message only if the threshold is satisfied, discarding messages that fall below it. This RSSI-based filtering step ensures that only messages from sufficiently proximate devices are collected and processed. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined system of Le and Dunsbergen with Good's technique in order to reduce perceived interference in BLE communication (Good [0007]).
Conclusion
5. Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIJAY K MANNAVA whose telephone number is (571)272-9505. The examiner can normally be reached 7:30-5 M-F.
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, Jae Y. Lee can be reached at (571) 270-3936. 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.
/VIJAY K MANNAVA/ Examiner, Art Unit 2479 /JAE Y LEE/Supervisory Patent Examiner, Art Unit 2479
Prosecution Insights