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
Claims 24-41 are pending.
3. Applicant filed Terminal Disclaimer on 05/13/2026 as a result the double
patenting rejection has been withdrawn.
Response to Arguments
4. Applicant's argument filed on 05/13/2026 have been fully considered but they are not persuasive.
5. Applicant’s obviousness argument is not persuasive.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071,5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
In this case, Jablonski teaches an IoT controller architecture in which requested operations are performed by connected devices and errors encountered during execution of those operations are reported back to the IoT Controller [0071]. Jablonski further teaches controller-based processing of requested device operations and were relied upon the determination of a desired operational state that differs from the user’s originally requested state. Further, Roche teaches controller that executes state transition commands, monitors execution of those commands, detects execution errors (et. Time out or failure to receive a response from the device), and updates a device representation based on the detected execution error. Roche also teaches handling execution failures by posting unexecuted state transition command or restoring a recorded state, thereby controllers-side state information following a failed state transition (see ([AB] and col. 2 lines 25-38, col.6, Lines 19-21) ..
One of ordinary skill in the art would have been motivated to incorporate Jablonski’s IoT controller architecture into Roche’s error detection and execution management techniques to improve the reliability of device control operation, maintain accurate controller-side state information following execution failures, and provide more robust handling of unsuccessful device operations. Such combination merely applies known error-handling techniques to a known IoT control system to obtain predictable results. Accordingly, the rejection does not improperly dissect the claims into individual elements. Instead, the rejection considers the claim as a hole and relies on the combined teachings of references to teach the claimed arrangement and relationships among the recited elements. The rejection further provides an articulated rationale supported by a rational underpinning for combing the references consistent with KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007) and MPEP 2143.
Response to Amendments
6. Applicant's amendments filed on 05/13/2026 have been fully considered but are moot in view of new ground(s) of rejection
Claim Rejections - 35 USC § 103
7. 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.
8. Claims 21, 25-28,33-34 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 and further in view of Kolchin (US 20220080856 A1) hereinafter Kolchin.
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
Jablonski may not explicitly disclose transmitting a second message to the first computing device, the second message including an indication of state of the connected device.
However, Roche discloses transmitting a second message to the first computing device, the second message including an indication of 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 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.
Jablonski teaches receiving a request corresponding to a first desisted state. For example the user request that a front door be opened ([0030], [0070]-[0076]) Jablonski further teaches that based on the device’s internal programming, the IoT device determines and initiates additional functions, such as turning on lights and/or playing music in response to the door opening [0030]. In addition, Jablonski teaches that a controller-implemented operation may result in a second desired state that differs from the user’s initially requested desired state. Roche further teaches detecting an execution error when a state transition command is not successfully completed, such as timeout occurs because the device does not respond (see col 8 lines 45-54). Jablonski in view of Roche may not explicitly disclose wherein the estimated state is determined by the controller in response to an error or issue with the connected device.
However, Kolchin disclose wherein the estimated state is determined by the controller in response to an error or issue with the connected device (para 0011] another category of battery monitoring methods is offline methods. Offline techniques are much more precise due to direct measurements of different parameters of each battery cell of the battery system and/or the entire battery system. Significantly more parameters are available for offline measuring while the battery system and/or the battery cell of the battery system are out of operation [0029] in accordance with the method for monitoring a battery state without interrupting functioning the battery system using the battery twin, the method allows the estimation of an actual battery state of the at least one battery cell and/or the battery system in online mode/regime with further adjustment of the battery state based on offline measurements of the further parameter of the battery twin, (i.e. estimating the actual state of a physical system based on available information. Specifically, the reference teaches estimation the actual battery state of the battery system. Because the controller determines the estimated state after detecting that the execution of the requested state transition failed/0ffline, the estimated state represents the controller’s best known actual condition of the connected device following the failure/offline rather than the requested first desired state or the controller directed second desired state. Accordingly, the estimated state differs from both the first desired state and the second desired state because the desired state transition was not successfully achieved).
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 the estimated state is determined by the controller in response to an error or issue with the connected device as taught by Kolchin. the motivation for doing so would have been in order to monitor the battery function without interruption such that the accuracy of the estimation of the battery state is increased by using the battery twin.
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/Roche/Kolchin further disclose 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).
9. Claims 22 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Jablonski in view Roche et al. in view of Kolchin and further in view of Tian (US 20070162518 A1) hereinafter Tian.
Regarding claims 22 and 35, Jablonski/Roche/Kolchin is discloses claim 21 as recited above. Jablonski further discloses refraining from transmitting to the connected device, information pertaining to the action request based on the 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). In addition, Kolchin disclose estimated state of the connected device [0029]). In other words, Jablonski teaches reporting the execution error ++to the controller and Roche teaches detecting an execution error while attempting to perform the requested operation. Kolchin teaches estimating the actual state of the connected device following incomplete or unsuccessful operations. Accordingly, the modified controlled determines an estimated state after the detected error, wherein the estimated state differs from the first desisted sate and the second desired state because the requested controller directed operation was not successful as recited in claim 21 above.
Jablonski/Roche/Kolchin may not explicitly disclose refraining from transmitting to the connected device, to prevent the connected device from processing additional requests to obtain the desired state. However, Tian discloses refraining from transmitting to the connected device, to prevent the connected device from processing additional requests to obtain the desired state (para. [0069] When receiving the synchronization initialization response which contains failure information from the Data Sync Server, the Data Sync Client determines whether it can satisfy the required conditions in the failure reason, if yes, the Data Sync Client resends a synchronization initialization request to the Data Sync Server, which includes the corresponding conditions in the failure reason, otherwise, the Data Sync Client stops sending synchronization initialization request to the Data Sync Server and ends the current procedure.
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 J Jablonski/Roche/Kolchin and include refraining from transmitting to the connected device, to prevent the connected device from processing additional requests to obtain the desired state.as taught by Tian.. the motivation for doing so would have been in order to avoid unnecessary network traffic conserves computing resources and prevent repeated unsuccessful processing.
.
10. Claims 23-24 and 36-37 are rejected under 35 U.S.C. 103 as being unpatentable over Jablonski in view Roche et al. in view of Kolchin and further in view of Singh et at. (US 20200311025 A1) hereinafter Singh.
Regarding claims 23 and 35, claim 21 is incorporated. Jablonski/Roche/Kolchin 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/Roche/Kolchin 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/Roche/Kolchin 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.
10. Claims 29-32 are rejected under 35 U.S.C. 103 as being unpatentable over Jablonski in view Roche et al. in view of Kolchin and further in view of Hart et at. (US 20220046094 A1) hereinafter Hart.
Regarding claim 29, claim 28 is incorporated. Jablonski/Roche/Kolchin 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/Roche/Kolchin 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/Roche/Kolchin 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/Roche/Kolchin 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/Roche/Kolchin 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
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
CN112382064B -The present invention deploys an edge server on the user terminal side, which greatly reduces the data transmission delay; fault intelligent processing, the present invention is based on digital twin technology, and physical objects can be mapped to virtual objects in real time during operation. Objects are presented to the control center through visualization technology, which can accurately determine the type and location of faults; for intelligent fault tests, the present invention can conduct simulation tests on virtual objects, which can not only reduce equipment loss, but also avoid test risks.
12. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
13. 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.
07/27/2026
/KIDEST MENDAYE/
Examiner, Art Unit 2457
/ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457
Prosecution Insights