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 .
Examiner’s Notes
The Applicant states that the prior art does not teach or suggest network-side scheduling. Applicant’s attention is respectfully directed to the claim language where the term “network-side” is not mentioned. No argument will be raised in the forthcoming action regarding the terms “network-side” or “network component.” Gupta et al as would be detailed in the forthcoming action shows the RMS that allocates IoT carriers and therefore is read as the “network-side” scheduler.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/16/2026 has been entered.
Claim Rejections - 35 USC § 103
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.
Claims 1-5, 8-9, 13-15, and 17-21 are rejected under 35 U.S.C. 103 as being unpatentable over Flores Guerra (Publication number: US 2019/0044826) in view of Elshafie et al (Publication number: US 2024/0348439) in view of Gupta et al (Publication number: US 2018/0270820).
Consider Claim 1, Flores shows a method for communicating with an Internet of Things (IoT) device (see figure 3), the method comprising:
(a) Determining that at least one IoT device is seeking to communicate with a user equipment (UE) (see figures 2 and 4; and paragraphs 30-32); (Based on the information received from the second IoT device, the process can predict what is the first IoT device, an accurate or an approximate spatial location where the first IoT device is installed, and other parameters/information relating to the first IoT device).
(b) Linking, through an IoT hub residing on the UE, the at least one IoT device to the UE (see figure 2; and paragraphs 20-22); (The hub is read as graphical user interface 226, which is equivalent to the “IoT hub application” described in the instant application).
(c) Communicating with and controlling operations and settings of the at least one IoT device through the IoT hub (see figure 3; and paragraphs 23-25); (Flores shows an electronic device 302 in a system 300 for displaying a digital map that includes location information and operational settings for one or more IoT devices managed by electronic device 302. The electronic device 302 may be an example of the electronic device 202. Examples of an electronic device can include a set top box, a phone, a tablet computer, a router, a gateway, or an IoT controller/base station. The electronic device 302 includes a communication module 312, a floor plan editor module 318, control logic 316, a storage unit 310 storing floorplan templates 320, and a GUI rendering module 322).
However, Flores Guerra does not specifically show transmitting, from the UE to a network component comprising a scheduler, IoT device information associated with the at least one IoT device: receiving, at the UE, from the network component, a channel allocation determined by the scheduler based on unallocated channel capacity in a network; and transmitting, in response to the channel allocation, data associated with the at least one IoT device from the UE to the network, wherein the at least one IoT device is controlled through the IoT hub.
In the same field of endeavor, Elshafie et al shows transmitting, from the UE to a network component comprising a scheduler, IoT device information associated with the at least one IoT device: receiving, at the UE, from the network component, a channel allocation determined by the scheduler based on unallocated channel capacity in a network; and transmitting, in response to the channel allocation, data associated with the at least one IoT device from the UE to the network, wherein the at least one IoT device is controlled through the IoT hub (see figure 2; and paragraphs 55, and 104-106); (See update request 210 and update 215).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the link between UE 115-a and base station 105-a of Elshafie et al into the teaching of Flores Guerra in order to update secret keys (see Elshafie et al; paragraphs 109-111).
However, Flores Guerra in view of Elshafie et al do not specifically show that the scheduler determines channel allocation based on monitored activity of one or more IoT devices associated with the UE, the channel allocation being determined to transmit data collected by the one or more IoT devices.
In the same filed of endeavor, Gupta et al shows that the scheduler determines channel allocation based on monitored activity of one or more IoT devices associated with the UE, the channel allocation being determined to transmit data collected by the one or more IoT devices (see figure 5; and paragraphs 26-27); (The RSMS in Gupta et al functionally mirrors the claimed “scheduler” since the RSMS can dynamically allocate IoT carriers, for example, based on statistical information collected from one or more access points 104. Further, the RSMS 102 can provide the allocation data to the access points 104 and an IoT control center 106 that has direct connectivity to user equipment (UEs). In one aspect, the RSMS 102 can instruct the IoT control center 106 to provide the UE(s) with carrier frequencies that are to be utilized by the UE(s). On the receiving the instructions, the IoT control center 106 can provide the specified carrier frequency data to the UE(s)).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the RSMS of Gupta et al into the teachings of Flores Guerra and Elshafie in order to enhance system capacity by utilizing the dynamic allocation of the RSMS (see Gupta et al; paragraphs 2-3).
Consider Claim 13, Flores shows a method of communicating with a user equipment (UE) (see figure 3), the method comprising:
(a) Performing, by at least one internet-of-things (IoT) device, a data activity (UE) (see figures 2 and 4; and paragraphs 30-32); (Based on the information received from the second IoT device, the process can predict what is the first IoT device, an accurate or an approximate spatial location where the first IoT device is installed, and other parameters/information relating to the first IoT device).
(b) Wherein the at least one IoT device is linked with the UE through an IoT hub residing on the UE; and transmitting, by the at least one IoT device, data from the data activity, to the UE through the IoT hub (see figure 2; and paragraphs 20-22); (The hub is read as graphical user interface 226, which is equivalent to the “IoT hub application” described in the instant application).
(c) Wherein the at least one IoT device is controlled based on the transmitted data (see figure 3; and paragraphs 23-25); (Flores shows an electronic device 302 in a system 300 for displaying a digital map that includes location information and operational settings for one or more IoT devices managed by electronic device 302. The electronic device 302 may be an example of the electronic device 202. Examples of an electronic device can include a set top box, a phone, a tablet computer, a router, a gateway, or an IoT controller/base station. The electronic device 302 includes a communication module 312, a floor plan editor module 318, control logic 316, a storage unit 310 storing floorplan templates 320, and a GUI rendering module 322).
However, Flores Guerra does not specifically show transmitting, from the UE to a network component comprising a scheduler, IoT device information associated with the at least one IoT device: receiving, at the UE, from the network component, a channel allocation determined by the scheduler based on unallocated channel capacity in a network; and transmitting, in response to the channel allocation, data associated with the at least one IoT device from the UE to the network, wherein the at least one IoT device is controlled through the IoT hub.
In the same field of endeavor, Elshafie et al shows transmitting, from the UE to a network component comprising a scheduler, IoT device information associated with the at least one IoT device: receiving, at the UE, from the network component, a channel allocation determined by the scheduler based on unallocated channel capacity in a network; and transmitting, in response to the channel allocation, data associated with the at least one IoT device from the UE to the network, wherein the at least one IoT device is controlled through the IoT hub (see figure 2; and paragraphs 55, and 104-106); (See update request 210 and update 215).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the link between UE 115-a and base station 105-a of Elshafie et al into the teaching of Flores Guerra in order to update secret keys (see Elshafie et al; paragraphs 109-111).
However, Flores Guerra in view of Elshafie et al do not specifically show that the scheduler determines channel allocation based on monitored activity of one or more IoT devices associated with the UE, the channel allocation being determined to transmit data collected by the one or more IoT devices.
In the same filed of endeavor, Gupta et al shows that the scheduler determines channel allocation based on monitored activity of one or more IoT devices associated with the UE, the channel allocation being determined to transmit data collected by the one or more IoT devices (see figure 5; and paragraphs 26-27); (The RSMS in Gupta et al functionally mirrors the claimed “scheduler” since the RSMS can dynamically allocate IoT carriers, for example, based on statistical information collected from one or more access points 104. Further, the RSMS 102 can provide the allocation data to the access points 104 and an IoT control center 106 that has direct connectivity to user equipment (UEs). In one aspect, the RSMS 102 can instruct the IoT control center 106 to provide the UE(s) with carrier frequencies that are to be utilized by the UE(s). On the receiving the instructions, the IoT control center 106 can provide the specified carrier frequency data to the UE(s)).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the RSMS of Gupta et al into the teachings of Flores Guerra and Elshafie in order to enhance system capacity by utilizing the dynamic allocation of the RSMS (see Gupta et al; paragraphs 2-3).
Consider Claim 17, Flores shows a non-transitory computer storage media storing computer-useable instructions that, when used by one or more processors (see figures 3 and 4), cause the processors to:
(a) Determine that at least one IoT device is seeking to communicate with a user equipment (UE) (UE) (see figures 2 and 4; and paragraphs 30-32); (Based on the information received from the second IoT device, the process can predict what is the first IoT device, an accurate or an approximate spatial location where the first IoT device is installed, and other parameters/information relating to the first IoT device).
(b) Link, through an IoT hub residing on the UE, the at least one IoT device to the UE (see figure 2; and paragraphs 20-22); (The hub is read as graphical user interface 226, which is equivalent to the “IoT hub application” described in the instant application).
(c) Communicate with and control operations and settings of the at least one IoT device through the IoT hub (see figure 3; and paragraphs 23-25); (Flores shows an electronic device 302 in a system 300 for displaying a digital map that includes location information and operational settings for one or more IoT devices managed by electronic device 302. The electronic device 302 may be an example of the electronic device 202. Examples of an electronic device can include a set top box, a phone, a tablet computer, a router, a gateway, or an IoT controller/base station. The electronic device 302 includes a communication module 312, a floor plan editor module 318, control logic 316, a storage unit 310 storing floorplan templates 320, and a GUI rendering module 322).
However, Flores Guerra does not specifically show transmitting, from the UE to a network component comprising a scheduler, IoT device information associated with the at least one IoT device: receiving, at the UE, from the network component, a channel allocation determined by the scheduler based on unallocated channel capacity in a network; and transmitting, in response to the channel allocation, data associated with the at least one IoT device from the UE to the network, wherein the at least one IoT device is controlled through the IoT hub.
In the same field of endeavor, Elshafie et al shows transmitting, from the UE to a network component comprising a scheduler, IoT device information associated with the at least one IoT device: receiving, at the UE, from the network component, a channel allocation determined by the scheduler based on unallocated channel capacity in a network; and transmitting, in response to the channel allocation, data associated with the at least one IoT device from the UE to the network, wherein the at least one IoT device is controlled through the IoT hub (see figure 2; and paragraphs 55, and 104-106); (See update request 210 and update 215).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the link between UE 115-a and base station 105-a of Elshafie et al into the teaching of Flores Guerra in order to update secret keys (see Elshafie et al; paragraphs 109-111).
However, Flores Guerra in view of Elshafie et al do not specifically show that the scheduler determines channel allocation based on monitored activity of one or more IoT devices associated with the UE, the channel allocation being determined to transmit data collected by the one or more IoT devices.
In the same filed of endeavor, Gupta et al shows that the scheduler determines channel allocation based on monitored activity of one or more IoT devices associated with the UE, the channel allocation being determined to transmit data collected by the one or more IoT devices (see figure 5; and paragraphs 26-27); (The RSMS in Gupta et al functionally mirrors the claimed “scheduler” since the RSMS can dynamically allocate IoT carriers, for example, based on statistical information collected from one or more access points 104. Further, the RSMS 102 can provide the allocation data to the access points 104 and an IoT control center 106 that has direct connectivity to user equipment (UEs). In one aspect, the RSMS 102 can instruct the IoT control center 106 to provide the UE(s) with carrier frequencies that are to be utilized by the UE(s). On the receiving the instructions, the IoT control center 106 can provide the specified carrier frequency data to the UE(s)).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the RSMS of Gupta et al into the teachings of Flores Guerra and Elshafie in order to enhance system capacity by utilizing the dynamic allocation of the RSMS (see Gupta et al; paragraphs 2-3).
Consider Claim 18, Flores shows that the IoT hub tracks activity of the at least one IoT device from triggers displayed on the UE (see figure 2; and paragraphs 20-22); (The hub is read as graphical user interface 226, which is equivalent to the “IoT hub application” described in the instant application).
Consider Claims 3 and 19, Flores shows controlling the at least one IoT device through the IoT hub comprises setting preferences for the at least one IoT device on the IoT hub, wherein control the at least one IoT device comprises setting preferences for the at least one IoT device in response to instructions from the IoT device hub (see paragraph 25); (Control logic 316 generates command and control signals 306 that are communicated to IoT devices. The command and control signals 306 can be used to manage and/or modify the operational settings of the IoT device).
Consider Claims 4 and 20, Flores shows communicating through the IoT hub comprises receiving, at the UE, at least one trigger from the at least one IoT device, and wherein communicate through the IoT hub comprises sending at least one command to the at least one IoT device (see paragraph 25); (Control logic 316 generates command and control signals 306 that are communicated to IoT devices. The command and control signals 306 can be used to manage and/or modify the operational settings of the IoT device).
Consider Claim 5, Flores shows that the IoT hub includes a universal IoT interface to control multiple IoT devices of different types (see paragraph 25); (The command and control signals are broadcast signals directed at changing group settings, e.g., a group of IoT devices. In some applications).
Consider Claims 8 and 9, Flores shows communicating through the IoT hub comprises sending at least one command to the at least one IoT device, wherein the at least one command sent to the at least one IoT device activates the at least one IoT device (see paragraph 25); (Control logic 316 generates command and control signals 306 that are communicated to IoT devices. The command and control signals 306 can be used to manage and/or modify the operational settings of the IoT device).
Consider Claims 14 and 15, Flores shows receiving, by the at least one IoT device, a command in response to the data from the data activity, wherein the at least one IoT device alters an operating parameter in response to the command (see paragraph 25); (Control logic 316 generates command and control signals 306 that are communicated to IoT devices. The command and control signals 306 can be used to manage and/or modify the operational settings of the IoT device).
Consider Claim 21, Gupta et al shows that the one or more IoT devices comprise an NB-IoT device or an LTE-M device (see figure 5); (Read as element 504).
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over Flores Guerra (Publication number: US 2019/0044826) in view of Elshafie et al, and Gupta et al in view of Kim (Publication number: US 2020/0178177).
Consider Claim 6, Flores in view of Elshafie, and Gupta et al do not specifically show communicating through the IoT hub allows the IoT device to wake the UE from a sleep state to pose a status query.
In the same field of endeavor, Kim shows communicating through the IoT hub allows the IoT device to wake the UE from a sleep state to pose a status query (see paragraph 144).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the notification taught by Kim into the IoT system of Flores and Elshafie and Gupta et al in order to alert the user about a dangerous situation (see Flores; paragraph 144).
Consider Claim 7, Kim shows that the status query may comprise at least one of: data communication, short message service communication, or voice communication (see Flores; paragraph 144).
Claims 10-11 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Flores Guerra (Publication number: US 2019/0044826) in view of Elshafie et al, and Gupta et al in view of Bhadouriya et al (Publication number: US 2022/0164088).
Consider Claim 10, Flores in view of Elshafie, and Gupta et al do not specifically show that the at least one command sent to the at least one IoT device silences the at least one IoT device.
In the same field of endeavor, Bhadouriya et al shows that the at least one command sent to the at least one IoT device silences the at least one IoT device (see figures 5A and 10B; and paragraph 91).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teaching of Bhadouriya et al into the teaching of Flores and Elshafie, and Gupta et al in order for a user equipment to act as a remote control (see Bhadouriya et al; paragraphs 91-94).
Consider Claim 11, Bhadouriya et al shows that the at least one command sent to the at least one IoT device decreases or increases a volume of the at least one IoT device (see figures 5A and 10B; and paragraph 91).
Consider Claim 16, Flores in view of Elshafie, and Gupta et al do not specifically show that the operating parameter altered is at least one of: an activity level, a setting of an audio, text, or video message frequency, and a volume level.
In the same field of endeavor, Bhadouriya et al shows that the operating parameter altered is at least one of: an activity level, a setting of an audio, text, or video message frequency, and a volume level (see figures 5A and 10B; and paragraph 91).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teaching of Bhadouriya et al into the teaching of Flores and Elshafie, and Gupta et al in order for a user equipment to act as a remote control (see Bhadouriya et al; paragraphs 91-94).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Flores Guerra (Publication number: US 2019/0044826) in view of Elshafie et al, and Gupta et al in view of Smallwood et al (Publication number: US 2016/0282824).
Consider Claim 12, Flores in view of Elshafie, and Gupta et al do not specifically show at least one command sent to the at least one IoT device deactivates the at least one IoT device for a user-selected period of time.
In the same field of endeavor, Smallwood et al shows at least one command sent to the at least one IoT device deactivates the at least one IoT device for a user-selected period of time (see figure 1; paragraphs 55 and 56).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teaching of Smallwood et al into the teaching of Flores and Elshafie, and Gupta et al in order to make communications between users and/or various devices more convenient (see Smallwood et al; paragraphs 3-5).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL A FARAGALLA whose telephone number is (571)270-1107. The examiner can normally be reached Mon-Fri 8:00-5:00.
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, Matthew Eason can be reached at 571-270-7230. 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.
/MICHAEL A FARAGALLA/Primary Examiner, Art Unit 2624 03/21/2026