DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to the amendment filed by Applicant on 06/10/2026. This action is made FINAL.
Response to Arguments
Applicant's arguments filed 06/10/2026 have been fully considered but they are not persuasive.
The Applicant argues that “Gupta does not disclose or suggest monitoring activity of IoT devices linked to a UE through an IoT hub, nor does Gupta disclose using such monitored IoT-device activity as an input to a scheduler's channel allocation determination.” However, the claims do not mention that the activity is an input.
Further, Gupta et al specifically states that “system 100 can facilitate an intelligent and dynamic management of radio resources across traditional consumer mobility services and IoT services in an end-to-end manner. Moreover, system 100 can be utilized to facilitate selective offloading based on traffic dynamics to ensure that IoT traffic (read as monitored activity) can be steered on-demand to an optimized and/or dedicated core network slice.”
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, wherein the IoT device is linked to the UE through the IoT hub residing on the UE.
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, wherein the IoT device is linked to the UE through the IoT hub residing on the UE (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, wherein the IoT device is linked to the UE through the IoT hub residing on the UE.
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, wherein the IoT device is linked to the UE through the IoT hub residing on the UE (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, Gupta et al shows that the monitored activity comprises activity tracked by the IoT hub from triggers sent to the UE from the at least one IoT device (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)).
Consider Claims 3 and 19, Flores shows that controlling the at least one IoT device through the IoT hub comprises establishing user preferences for multiple IoT devices through a control interface of the IoT 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 that the monitored activity comprises at least one trigger received at the UE from the at least one IoT device through the IoT 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 Claim 5, Flores shows the IoT hub includes a universal IoT interface configured to control multiple different types of IoT devices through a common control interface (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 Claim 8, 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 in response to a trigger received from 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 an operating parameter is altered in response to a user preference established through a control interface of the IoT 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 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 communicate a status query and receive a response to the status query through the IoT hub.
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 communicate a status query and receive a response to the status query through the IoT hub (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 9 and 11 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) in view of an official notice taken by the USPTO.
Consider Claims 9 and 11, Flores, Guerra, Elshafie, and Gupta do not specifically show that the trigger indicates that a user of the UE has been inactive for longer than a predetermined period of time, and that the at least one command decreases a volume of the at least one IoT device in response to detecting that a user of the UE is participating in a call or video call. However, the USPTO takes official notice that it is well known and expected in the art that the trigger indicates that a user of the UE has been inactive for longer than a predetermined period of time, and that the at least one command decreases a volume of the at least one IoT device in response to detecting that a user of the UE is participating in a call or video call in order to provide convenience for the user.
Allowable Subject Matter
Claims 10, 12, and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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 09/09/2026
Prosecution Insights