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 .
Detailed Action
2. Claims 21-40 are pending.
Double Patenting
3. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321 © or 1.321 (d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) -706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.qov/patents/process/file/efs/Quidance/eTD-info-l.isp.
4. Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of U.S. Patent No. (US 12113671 B2). Although the conflicting claims are not identical, they are not patentably distinct from each other because all elements of instant application 18/909,540 claim 1 correspond to elements of claim 1 of the U.S. Patent No. (US 12113671 B2). The above claim of the present application would have been obvious over claim 1 of U.S. Patent No. (US 12113671 B2) because each element of the claims of the present application is anticipates by claim 1 of U.S. Patent No. (US 12113671 B2).
Instant application# 18/909,540
US Patent (US 12113671 B2 )
21. (New) A method for communicating with connected devices, the method comprising:
identifying one or more traits for a connected device;
receiving, from a first computing device, an action request, wherein the action request corresponds to a first desired state of the connected device;
receiving, via an internet or cellular data connection, a trait configuration for the one or more traits corresponding to the connected device;
calculating, at a controller, a second desired state for the connected device, wherein the second desired state is calculated based on the action request and the trait configuration for the connected device, and the second desired state differs from the first desired state;
transmitting a first message to the connected device, the first message including an indication of the second desired state;
transmitting a second message to the first computing device, the second message including an indication of an estimated state of the connected device.
1. A method for communicating with connected devices, the method comprising:
identifying one or more traits for a connected device;
receiving, from a first computing device, an action request, wherein the action request corresponds to a first desired state of the connected device;
receiving, via an internet or cellular data connection, a trait configuration for the one or more traits corresponding to the connected device;
calculating, at a controller, a second desired state for the connected device, wherein the second desired state is calculated based on the action request and the trait configuration for the connected device, and the second desired state differs from the first desired state;
calculating an expected state for the connected device, the expected state based upon one or more of the action request, a behavior model, and the trait configuration for the connected device;
transmitting a first message to the connected device, the first message including an indication of the second desired state;
receiving, from the connected device, a reported state;
determining at least one error or issue for the connected device based on identifying a discrepancy between the reported state and the expected state; and
transmitting a second message to the first computing device, the second message including an indication of an estimated state of the connected device and an indication of the error or the issue.
Independent claims 34 and 40 of the instant application are anticipated by independent claims of 9, 10, 16 and 17 of the patent application . And dependent claims 22-28 and 35-39 of the instant application are anticipated by claims 2-6, 9-10 and 11-15 of the patent application respectively.
Claim Rejections - 35 USC § 103
5. 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 of this title, 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.
6. Claims 21-22, 25-28,33-35 and 38- 40 are rejected under 35 U.S.C. 103 as being unpatentable over Jablonski (US 20190208024 A1) hereinafter Jablonski in view of Roche et al. (US 10412190 B1) hereinafter Roche.
Regarding claims 21, 34 and 40 Roche Jablonski discloses a method for communicating with connected devices (see Figs. 4 and 6), the method comprising:
identifying one or more traits for a connected device (para. [0028] IoT controller devices may perform the processes of discovering accessible IoT thing devices, determining the purpose, status, and functions capable of being performed via the accessible IoT thing devices, and then invoking the appropriate functions on selected IoT thing devices to perform the tasks requested by the user. [0069]-[0070] IoT devices capable of performing operation/function Open; Close; Slam; Crack; Handle Lock; Handle Unlock; Deadbolt Lock; Deadbolt Unlock door, [0077] IoT device may perform the requested operations such as turning on/off a light or an appliance, opening/closing a door or window, configuring a sensor device, dispensing an item from a vending machine, printing a document, rendering content on a nearby display, playing music from a nearby speaker, reserving a parking space or car-share vehicle for some duration of time.. [i.e. traits]);
receiving, via an internet or cellular data connection, a trait configuration for the one or more traits corresponding to the connected device (para. [0027]- [0028] IoT devices 121-125 receive and process a variety of requests from users, IoT device 121-125 also may have IP-based network interfaces and the capability to connect to the internet through one or more wide area network connections (e.g., cellular, WiFi, etc.). .. [0061]-[0064]… the request received in step 401 immediately after that request was spoken, typed, or otherwise input by the user into the IoT control device 120; as part of the user's setup or configuration settings for a home monitoring system or IoT device management system, for instance, a particular user may configure their smartphone IoT controller 122 to automatically request that their electronic front door IoT thing device 128 be locked whenever they leave the house, or that their electronic garage door opener IoT thing device be opened whenever they drive up to their house … In step 402, the IoT controller device 120 may discover one or more accessible IoT thing devices, and may select a particular IoT thing device (or multiple IoT thing devices) that can be used to perform the requested task received in step 401.. After receiving the transmissions from one or more IoT thing devices, the IoT controller device in step 402, identify one or more nearby IoT thing devices that may be capable of performing the requested task. [0069] an IoT controller device 120 may identify a single IoT thing device in step 402 that is capable of performing the requested task. For example, when the user requests, “Lock my front door,” IoT device, the electronic door device 128, capable of executing that task. In this example, in order to perform the requested task, the IoT controller device 120 may initiate a device-to-device communication session with the electronic door 128… (see also Figs. 4 and 5))
calculating, at a controller, a second desired state for the connected device, wherein the second desired state is calculated based on the action request and the trait configuration for the connected device (para. [ 0069]… in order to perform the requested task, the IoT controller device 120 may initiate a device-to-device communication session with the electronic door 128. For example, the IoT controller device 120 may query the electronic door device 128 for its current status, and may receive a natural language reply such as “Open,” “Closed,” “Shut,” “Locked,” “Deadbolted Shut,” “Unlocked,” “Opened a Crack,” or the like. The controller device 120 may then query the electronic door device 128 for all of its supported operations (or functions), and may receiving a listing of operations, for example, “Open; Close; Slam; Crack; Handle Lock; Handle Unlock; Deadbolt Lock; Deadbolt Unlock.” Then, in step 404, the IoT controller 120 may select which of these operations to perform, based on the comparison of the natural language operation/function names (and/or accompanying operation descriptions, if present), and based on the current status of the IoT thing device. For instance, if a status query reveals that the electronic door device 128 is already in the “Locked” state, then the IoT controller 120 may determine that no function is to be performed in step 404. However, if the status query reveals that the electronic door device 128 is “Open,” “Opened a Crack,” or the like, then the IoT controller 120 might select the sequence of operations “Close” followed by “Deadbolt Lock” and/or “Handle Lock” to complete the requested task. [0070]-[0076] and Fig. 6 – calculating/evaluating steps to find a nearby parking space. In additions, [0030] an IoT controller device may receive a request from a user to open the front door of the user's house. Through device discovery and inquiry, the IoT controller 122 may identify door 128 as the correct IoT thing device, and may transmit an open request to the door IoT thing device 128. In response, the door IoT device 128 may, based on its own internal programming, decide to turn on one or more lights and/or begin playing music in response to the door being opened. Thus, the door IoT thing device 128 may take the role of an IoT controller by discovering and then instructing one or more light IoT thing devices 136 and/or speaker IoT thing devices 136 to perform the desired functions); and
the second desired state differs from the first desired state (para [0030] an IoT controller device may receive a request from a user to open the front door [desire state] of the user's house. Through device discovery and inquiry, the IoT controller 122 may identify door 128 as the correct IoT thing device, and may transmit an open request to the door IoT thing device 128. In response, the door IoT device 128 may, based on its own internal programming, decide to turn on one or more lights and/or begin playing music in response to the door being opened. Thus, the door IoT thing device 128 may take the role of an IoT controller by discovering and then instructing one or more light IoT thing devices 136 and/or speaker IoT thing devices 136 to perform the [second] desired functions);
transmitting a first message to the connected device, the first message including an indication of the second desired state (para. [0069] identify the IoT device in step 402 that is capable of performing the requested task. For example, when the user requests, “Lock my front door,” The IoT controller device 120 may query the electronic door device 128 for its current status, The controller device 120 may then query the electronic door device 128 for all of its supported operations (or functions), and may receiving a listing of operations, for example, “Open; Close; Slam; Crack; Handle Lock; Handle Unlock; Deadbolt Lock; Deadbolt Unlock.” Then, in step 404, the IoT controller 120 may select which of these operations to perform, based on the comparison of the natural language operation/function names (and/or accompanying operation descriptions, if present), and based on the current status of the IoT thing device. For instance, if a status query reveals that the electronic door device 128 is already in the “Locked” state, then the IoT controller 120 may determine that no function is to be performed in step 404. However, if the status query reveals that the electronic door device 128 is “Open,” “Opened a Crack,” or the like, then the IoT controller 120 might select the sequence of operations “Close” followed by “Deadbolt Lock” and/or “Handle Lock” to complete the requested task. [0030] an IoT controller device may receive a request from a user to open the front door of the user's house. Through device discovery and inquiry, the IoT controller 122 may identify door 128 as the correct IoT thing device, and may transmit an open request to the door IoT thing device 128. In response, the door IoT device 128 may, based on its own internal programming, decide to turn on one or more lights and/or begin playing music in response to the door being opened. Thus, the door IoT thing device 128 may take the role of an IoT controller by discovering and then instructing one or more light IoT thing devices 136 and/or speaker IoT thing devices 136 to perform the desired functions).
Jablonski may not explicitly disclose transmitting a second message to the first computing device, the second message including an indication of an estimated state of the connected device.
However, Roche discloses transmitting a second message to the first computing device, the second message including an indication of an estimated state of the connected device ([AB] and col. 2 lines 25-38, a state change listing may include a set of transition commands that when executed as a set, instruct a network addressable door to open. For example, a first state transition command may instruct the network addressable door to disengage a lock, a second state transition command may instruct the door to retract a latch, and a third state transition command may instruct the door to engage an actuator that opens the door. Fig.5, "Instruct device to assume first state 518, instruct device to assume second state 522” and "Return success 530"; Col.6, Lines 19-21, ... the recorded state 116 may be provided to the application or service 102 that made the state change request).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teaching of Jablonski and include transmitting a second message to the first computing device, the second message including an indication of an estimated state of the connected device using the teaching of Roche. The motivation for doing so would have been in order to monitor transactions within the device shadowing service by a transaction monitoring service or control plane and before submitting a state change listing for execution to update the state of a device.
Regarding claims 22 and 35, claim 21 is incorporated. Jablonski further discloses refraining from transmitting to the connected device, information pertaining to the action request based on the estimated state of the connected device ((para [0069]… if a status query reveals that the electronic door device 128 is already in the “Locked” state, then the IoT controller 120 may determine that no function is to be performed in step 404. Further, Roche, col.4, Lines 63-67 & Col.5, Lines 1-2, prior to submitting a state change listing 108 for a device 110, a determination may be made that an initial state or recorded state 116 of the device 110 may be different from a state114 specified by the state change listing 108. In other words, if the current state of a device is the same as a specified state of a state change listing 108, there may be no need to execute the state change listing 108).
Regarding claims 25 and 38, claim 21 is incorporated. Jablonski further discloses wherein each of the one or more traits is associated with one or more of a capability, a functionality, and a behavior of the connected device (para. [0023] [0069], [0077] the types of operations that may be performed in step 409 are too many to name, and potentially may include any function supported by any electronic device. Non-limiting examples of such operations may include turning on/off a light or an appliance, opening/closing a door or window, configuring a sensor device, dispensing an item from a vending machine, printing a document, rendering content on a nearby display, playing music from a nearby speaker, reserving a parking space or car-share vehicle for some duration of time, and so on).
Regarding claims 26 and 39, claim 1 is incorporated. Jablonski further discloses calculating an expected state, the expected state based upon one or more of the action request, a behavior model, and the trait configuration for the connected device; determining an error or issue for the connected device based on one of: receiving a reported state from the connected device, wherein the reported state is different from the expected state; or identifying an absence of an error response, an updated state, or a reported state from the connected device; and transmitting a third message to the connected device, the third message including an indication of a third desired state for the connected device, and wherein the third message is transmitted based upon determining the error or the issue for the connected device (para. [0077] the IoT thing device may perform the requested operations for the IoT controller device 120. The types of operations that may be performed in step 409 are too many to name, and potentially may include any function supported by any electronic device. Non-limiting examples of such operations may include turning on/off a light or an appliance, opening/closing a door or window, configuring a sensor device, dispensing an item from a vending machine, printing a document, rendering content on a nearby display, playing music from a nearby speaker, reserving a parking space or car-share vehicle for some duration of time, and so on. Any errors encountered by the IoT thing device while performing the requested operations may be reported back to the IoT controller device 120 and/or to a separate data store (e.g., a cloud-based IDDP data repository 210), and if necessary, a return payment may be refunded from the IoT thing device to the IoT controller device 120. Furter, Roche, Col.8, Lines 45-54, the execution module 214 may be configured to monitor the execution of a state transition command for a time-out operation, where a response from a device 230 indicating that the device 230 assumed a specified state is not received within a specified amount of time. In one example, the execution module 214 may initiate a timer as part of executing a state transition command. In the event that a response is not received. From a device 230 prior to the expiration of the timer, an execution error may be assumed resulting in an execution error; Col.8, Lines 62-67, as another example, the execution module 214 may run an error handler that restores a state (e.g., a recorded state) of a device representation to an initial state that existed prior to executing a state change listing 220, and then re-executes the state change listing 220).
Regarding claim 27, claim 21 is incorporated. Jablonski further discloses receiving, from the connected device, a reported state; and refraining from transmitting information pertaining to the action request to the connected device based at least in part on identifying that the first desired state is the same as or approximately the same as the reported state (para [0069]… if a status query reveals that the electronic door device 128 is already in the “Locked” state, then the IoT controller 120 may determine that no function is to be performed in step 404. In addition Roche,Col.4, Lines 63-67 & Col.5, Lines 1-2, prior to submitting a state change listing 108 for a device 110, a determination may be made that an initial state or recorded state 116 of the device 110 may be different from a state114 specified by the state change listing 108. In other words, if the current state of a device is the same as a specified state of a state change listing 108, there may be no need to execute the state change listing 108).
Regarding claim 28, claim 21 is incorporated. Jablonski in view of Roche further discloses validating the action request, wherein the validating comprises assessing the action request with respect to the trait configuration for the connected device; generating an action intent from the action request, wherein generating the action intent is based at least in part on validating the action request; and wherein calculating the second desired state is further based on the action intent and a reported state of the connected device (Roche, Col.4, Lines 55-63, ..for example , transactions may be monitored within the device shadowing service 112 by a transaction monitoring service or control plane and before submitting a state change listing 108 for execution to update the state of a device 110, the monitoring service or control plane may be queried to ensure that in-progress transactions associated with the device 110 that would cause a collision in updating the state of the device 110 are not executing [i.e. checking for collision corresponds to the validating as claimed]. Also see Col.4, Lines 38-42, the rules engine may be configured to evaluate state transition commands included in a state change listing 108 and transform the state transition commands to a format recognized by a device 110 and deliver the transformed state transition commands to the device 110. [i.e. the transformed state transition commands correspond the action intent as claimed]).
Regarding claim 33, claim 21 is incorporated. Jablonski further discloses wherein the controller validates the action request by assessing the action request with respect to the trait configuration for the connected device (para. [0021] Figs 4 and 6,
after receiving communications from one or more IoT thing devices, an IoT controller device may select one or more particular IoT thing devices to perform some or all of a requested task. The IoT controller device may select the IoT thing device(s) based on comparisons of the natural language input identifying the requested task, to the natural language device descriptions and/or function/operation descriptions received from the various IoT thing devices, and/or based on additional characteristics of the IoT thing devices, such as the current statuses of the devices, prices/rates for performing
certain functions, and/or the authorization credentials required by the IoT thing devices. In addition to selecting the particular IoT thing device(s), the IoT controller device may use similar techniques to discover and then select the particular functions/operations
supported by those IoT thing device(s) in order to perform the requested tasks. Further, the IoT controller device may transmit instructions to the selected IoT thing devices, to perform the selected functions/operations on those devices. (see also Roche Col.4, Lines38-42 and 55-63, and Col.6, Lines 32-39).
7. Claims 23-24 and 36-37 are rejected under 35 U.S.C. 103 as being unpatentable over Jablonski (US 20190208024 A1) hereinafter Jablonski in view of Roche et al. (US 10412190 B1) hereinafter Roche and further in view of Singh et at. (US 20200311025 A1) hereinafter Singh.
Regarding claims 23 and 35, claim 21 is incorporated. Jablonski in view of Roche discloses receiving one or more state for the one or more traits for the connected device, wherein each of the one or more state comprises one or more state fields ( Roche, Col.6, Lines 32-39, using the network addressable door example above, a recorded state of a device representation for the door may be updated to "lock disengaged" after receiving an indication of a first state transition from the door, and updating the recorded state to "latch retracted" after an indication of a second state, and updating the recorded state to "open" after an indication of a third state assumed by the door. Also see Col.5, Lines 28-35, in the event that a failure to update the state of the device 110 is detected, then in one example, unexecuted state transition commands included in the state change listing I 08 may be posted to the device representation 106 for the device 110 as the desired state 114 for the device 110, and the next time that the device 110 connects to the device shadowing service 112, the device 110 may be instructed to assume the desired state 114).
Jablonski in view of Roche may not explicitly disclose state of snapshot. However, Singh disclose state of snapshot ([Abstract] techniques for verifying a replicated snapshot integrity includes steps for storing a snapshot at a first computing system where the snapshot has a corresponding first data integrity value (e.g., a checksum). Another storing operation stores a replica snapshot as two or more portions at respective two or more computing nodes of a second computing system…).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teaching of Jablonski in view of Roche and include state of snapshot using the teaching of Singh. The motivation for doing so would have been in order to automatically verify replicated snapshot integrity.
Regarding claims 24 and 36, claim 21 is incorporated. Jablonski in view of Roche discloses receiving one or more of an updated trait configuration, and an updated state for at least one of the one or more state, for the connected device, based on transmitting the request to the connected device; and calculating a third desired state for the connected device (Roche Col.6, Lines 32-39, a recorded state of a device representation for the door may be updated to "lock disengaged" after receiving an indication of a first state transition from the door, and updating the recorded state to "latch retracted" after an indication of a second state, and updating the recorded state to "open" after an indication of a third state assumed by the door. Also see Col.5, Lines 28-35, in the event that a failure to update the state of the device 110 is detected, then in one example, unexecuted state transition commands included in the state change listing I 08 may be posted to the device representation 106 for the device 110 as the desired state 114 for the device 110, and the next time that the device 110 connects to the device shadowing service 112, the device 110 may be instructed to assume the desired state 114 [i.e. the desired state 114 corresponds to the third desired state as claimed]).
Jablonski in view of Roche may not explicitly disclose state of snapshot. However Singh disclose state of snapshot ([Abstract] techniques for verifying a replicated snapshot integrity includes steps for storing a snapshot at a first computing system where the snapshot has a corresponding first data integrity value (e.g., a checksum). Another storing operation stores a replica snapshot as two or more portions at respective two or more computing nodes of a second computing system…).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teaching of Jablonski in view of Roche and include state of snapshot using the teaching of Singh. The motivation for doing so would have been in order to automatically verify replicated snapshot integrity.
8. Claims 29-32 are rejected under 35 U.S.C. 103 as being unpatentable over Jablonski (US 20190208024 A1) hereinafter Jablonski in view of Roche et al. (US 10412190 B1) hereinafter Roche and further in view of Hart et at. (US 20220046094 A1) hereinafter Hart.
Regarding claim 29, claim 28 is incorporated. Jablonski in view of Roche may not explicitly disclose wherein the action intent is a modified form of the action request that fits within a capability of connected device that is determined from the reported state of the connected device. However Hart discloses wherein the action intent is a modified form of the action request that fits within a capability of connected device that is determined from the reported state of the connected device (see para. [0050], [0054] [0079] and [0081] –[0082])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teaching of Jablonski in view of Roche and include wherein the action intent is a modified form of the action request that fits within a capability of connected device that is determined from the reported state of the connected device using the teaching of Hart. The motivation for doing so would have been in order to maintain high security for IoT devices, while avoiding power and bandwidth intensive operations that occur when the IoT devices connect to the server.
Regarding claim 30, claim 21 is incorporated. Jablonski in view of Roche may not explicitly disclose wherein the second desired state corresponds to an expected change in the connected device in response to the action request However, Hart discloses wherein the second desired state corresponds to an expected change in the connected device in response to the action request (see para. [0050], [0054] [0079] and [0081] –[0082])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teaching of Jablonski in view of Roche and include wherein the second desired state corresponds to an expected change in the connected device in response to the action request using the teaching of Hart. The motivation for doing so would have been in order to maintain high security for IoT devices, while avoiding power and bandwidth intensive operations that occur when the IoT devices connect to the server.
Regarding claim 31, claim 21 is incorporated. Jablonski in view of Roche may not explicitly disclose wherein the action request is received from a user device of an end-user. However, Hart discloses wherein the action request is received from a user device of an end-user (see para. [0050], [0054] [0079] and [0081] –[0082]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teaching of Jablonski in view of Roche and include wherein the action request is received from a user device of an end-user using the teaching of Hart. The motivation for doing so would have been in order to maintain high security for IoT devices, while avoiding power and bandwidth intensive operations that occur when the IoT devices connect to the server.
Regarding claim 32, claim 31 is incorporated. Jablonski in view of Roche may not explicitly disclose wherein the controller generates an action intent from the action request, the action intent corresponding to a functionality the end-user desired to perform on the connected device. However, Hart discloses wherein the controller generates an action intent from the action request, the action intent corresponding to a functionality the end-user desired to perform on the connected device. (see para. [0050], [0054] [0079] and [0081]-[0082]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to modify the teaching of Jablonski in view of Roche and include wherein the controller generates an action intent from the action request, the action intent corresponding to a functionality the end-user desired to perform on the connected device using the teaching of Hart. The motivation for doing so would have been in order to maintain high security for IoT devices, while avoiding power and bandwidth intensive operations that occur when the IoT devices connect to the server.
Conclusion
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Kidest Mendaye whose telephone number is (571)272-2603. The examiner can normally be reached on Monday through Friday 7:00 am-5:00pm EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ario Etienne can be reached on (571) 272-4001. 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.
02/07/2026
/KIDEST MENDAYE/Examiner, Art Unit 2457 /ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457