Prioritized resident electronic devices in residence

Abstract

Aspects of the present disclosure include a method for communicating between a controller device and a resident device. An exemplary method includes detecting, by a controller, the resident device and an accessory connected to a local network. A first direct connection with the accessory is established by the controller. Input identifying control instructions for controlling the accessory is received by the controller. It is determined by the controller whether to send a message including the control instruction to the accessory via the first direct connection with the accessory or via a second direct connection with the resident device. Sending, by the controller, the message including the control instruction to the resident device via the second direct connection, the resident device configured to relay the message including the control instruction to the accessory.

Description

[0001] This application is an international application and claims the benefit of and priority under 35 U.S.C. §119(e) to U.S. Provisional Application No. 63 / 349,144, filed on June 5, 2022, and U.S. Non-Provisional Application No. 17 / 994,818, filed on November 28, 2022, the contents of each of which are incorporated herein by reference in their entirety. Technical Field

[0002] The present application relates to the field of networks, and in particular to prioritized resident electronic devices in a residence in such a network. Background Art

[0003] Environments such as residential and professional spaces are populated by devices that are able to electronically perform functions that people traditionally had to perform manually. To enable a division of labor and reduce the complexity of these devices, manufacturers design and deliver specialized devices for consumers to integrate into their environments. To enable collaborative environments where these devices can combine their work to perform tasks, systems can be used to translate instructions from one device into a response action by another device. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 is an illustration of mobility usage at an environment according to some embodiments.

[0005] Figure 2 is an illustration of a controller request to an accessory via a resident device according to some embodiments.

[0006] Figure 3 is an illustration of an exemplary architecture of a system for synchronizing data between one or more devices according to some embodiments.

[0007] Figure 4 is a diagram of a resident device according to some embodiments.

[0008] Figure 5 is a signaling diagram for routing messages from a controller device to an accessory device via a resident device according to some embodiments.

[0009] Figure 6 is a signaling diagram for synchronizing data between a server device and a controller device or an accessory device according to some embodiments.

[0010] Figure 7 is a signaling diagram for requesting the status of an accessory device by a controller device according to some embodiments.

[0011] Figure 8 is a process flow for routing messages from a controller device to an accessory device via a resident device according to some embodiments.

[0012] Fig. 9 is a process flow for synchronizing data between a server device and a controller device or an accessory device according to some embodiments.

[0013] Fig.10 is a block diagram of a controller device according to some embodiments.

[0014] Fig.11 is a block diagram of an accessory device according to some embodiments. DETAILED DESCRIPTION

[0015] In the following description, various examples will be described. For the purpose of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the examples. However, it will also be apparent to those skilled in the art that some examples may be implemented without these specific details. In addition, well-known features may be omitted or simplified to avoid confusing the described examples.

[0016] Computing devices can communicate with each other through various transmission protocols from long-range Internet-based communications to short-range technologies such as Bluetooth and near-field communication (NFC). When devices are integrated into everyday environments, communication between devices may be subject to the limitations of one or more devices in the device or the limitations of the communication network. For example, a device may try to send a message to another device through a Wi-Fi network. However, if the Wi-Fi network is not functioning properly (or is inaccessible), the message may not be received by other devices. Another problem may be that if a device has multiple communication channels open with multiple devices, the processing of the device may turn to maintaining separate communication channels and processing multiple data packets from multiple devices, rather than just sending data. This may lead to an increase in contention for the processing resources of the device and an increase in the energy demand for the device.

[0017] The embodiments described herein solve the above problems by providing a communication framework in which one device in an environment is designated as the main device for routing inter-device communication in the environment. If a device sends a communication to another device, the communication can be initially routed to the main device instead of being sent directly to the other device. The main device can then send instructions to the other device. Advantageously, the main device can be configured to have one or more stable and secure communication channels with the other device. Therefore, by routing the communication to the main device, the communication framework can ensure that the communication from the device is delivered to the other device. In some examples, the main device can be configured as a resident device, configured to be stationary and / or regularly powered on (e.g., in contrast to using a battery) at a given location (e.g., at home or in the office).

[0018] Figure 1 1 is an illustration 100 of a mobility use case at an environment according to some embodiments. As shown, a house 102 may include a resident device 104 (e.g., a tablet computer, a smart speaker, a smart digital media player configured to control a television (TV), etc.) having a secure communication channel with an accessory device 106 (e.g., a smart thermostat, a smart fan, a smart window, a smart garage door opener). The resident device 104 may be configured to receive a message from a controller device (e.g., any user device configured to provide control instructions to an accessory) that is intended for the accessory device 106. The resident device 104 may be further configured to send a message to the accessory device 106 on behalf of the controller device. The accessory device 106 may be configured to perform an action in response to receiving a message from the resident device 104.

[0019] A user may have a controller device 108 connected to a resident device 104 and an accessory device 106. In some cases, the user may need to communicate with the accessory device 106, however this may not always be practical. For example, the user may be leaving the house 102, but the garage door (e.g., the accessory device 106) is open. The controller device 108 may have a weak connection to the accessory device 106 based on, for example, the distance between the controller device 108 and the accessory device 106. Therefore, even if the resident device 104 is not configured to route all communications between the controller device 108 (e.g., a smart phone) and the accessory device 106 (e.g., a garage door), the user may not be able to properly communicate with the accessory device 106.

[0020] However, the user may communicate with the resident device 104 via the controller device 108. The controller device 108 may communicate with the resident device 104 via a variety of transmission protocols, such as Wi-Fi or cellular protocols. One protocol between the controller device 108 and the resident device 104 may perform poorly, and therefore the controller device may communicate with the resident device 104 via another protocol.

[0021] The controller device 108 may further choose to send the message to the resident device 104 rather than directly to the accessory device 106, even if the controller device 108 has a connection (however weak) with the accessory device 106. The controller device 108 may send the message to the resident device 104. The resident device 104 may receive the message and send the message to the accessory device 106. The accessory device 106 may receive the communication including the instruction (e.g., close the garage door) and perform a responsive action (e.g., close the garage door).

[0022] Figure 2200 is an illustration of a controller request to an accessory via a resident device according to some embodiments. A house 202 may include a resident device 204 (e.g., a tablet computer, a smart speaker, a smart digital media player configured to control a television (TV), etc.) and an accessory device 206. The accessory device 206 may be any device configured to perform an operation / action based on a control instruction. The accessory device 206 may also have a status, report the status, receive control instructions, and act according to the instructions. Some examples of the accessory device 206 include a smart thermostat, a smart fan, a smart window, and a smart garage door opener. At some point, a user 208 may request information from the accessory device 206, such as the status of the accessory device 206. The user 208 may have a controller device 210 connected to the resident device 204 and the accessory device 206 via a local network (such as a Wi-Fi network).

[0023] For example, the controller device 210 can further detect the resident device 204 and the accessory device 206 as being connected to the same network. The controller device 210 can further connect to the resident device 204 and the accessory device 206 via a network connection.

[0024] User 208 can enter input into controller device 210 to instruct accessory device 206 to perform some function, such as providing a status or performing an action (e.g., turning on a light, etc.). Accessory device status can be a set of variables or inputs associated with accessory device 206 at a given time.

[0025] Independent of a user instruction to request the state of accessory device 206, resident device 204 can, from time to time, send a message to all accessory devices in house 202 for accessory device state updates. Accessory device 206 can send the accessory state to resident device 204 in response to the sending. In some embodiments, accessory device 206 only sends changes to the accessory state to resident device 204. Resident device 204 can store the accessory state in a cache. If the accessory state has changed, resident device 204 can further discard the previous state based on a cache clearing policy.

[0026] Returning to controller device 210, controller device 210 can determine to send the request for the accessory status to resident device 204 instead of accessory device 206. For example, controller device 210 can be configured to determine in a selection between resident device 204 and accessory device 206 to send the message to resident device 204.

[0027] In some cases, the controller device 210 may send two messages to the resident device. A first message on a first transmission protocol including a request for an attachment state and a second redundant message on a second transmission protocol, wherein the second message is a copy of the first message. The resident device 204 may receive one or both of the messages based on the quality of the communication channel. The resident device 204 may further choose to dispose of (e.g., delete, store) the second received message based on determining that the second received message is a copy of the previous message. It should be understood that regardless of the transmission protocol on which the initial message is received, the resident device 204 can respond via any appropriate transmission protocol.

[0028] Resident device 204 can receive a message from controller device 210, including a request for the accessory state. In response to receiving the message, resident device 204 can retrieve the accessory state from the cache. Resident device 204 can send a response to controller device 210 including the accessory state.

[0029] For example, user 208 may wish to know the temperature setting of a smart thermostat (e.g., an accessory device) at house 202. The user may send a request for the temperature (e.g., the accessory status) to resident device 204. Resident device 204 may have previously received the temperature (e.g., the accessory status) from the smart thermostat and stored the temperature in a cache. Resident device 204 may retrieve the temperature from the cache and send it to controller device 210. Controller device 210 may display the temperature for user 208.

[0030] Figure 3 300 is a diagram of an exemplary architecture of a system for synchronizing data between one or more devices according to some embodiments. Diagram 300 includes one or more controller devices 302, resident devices 304, server devices 308, one or more networks 310, and one or more accessory devices 312. Figure 3 Each of these elements depicted in the diagram 300 may be similar to one or more elements depicted in other figures described herein. For example, the controller device 302 may be similar to any of the other user devices described herein, etc. In some embodiments, at least some (e.g., and / or all) of the elements of the diagram 300 may operate in the context of a residential environment or an office environment.

[0031] Turning to each element in further detail, the controller device in the one or more controller devices 302 can be any suitable computing device (e.g., a mobile phone, a tablet computer, a personal computer (PC), smart glasses, a smart watch, etc.). In some embodiments, the controller device 302 can perform any one or more of the operations of the user device described herein. Depending on the type of controller device and / or the location of the user device (e.g., within a residential environment or outside a residential environment), the controller device can enable communication over a network 310 (e.g., including a LAN and / or a WAN) using one or more network protocols (e.g., a Bluetooth connection, a Thread connection, a ZigBee connection, an infrared connection, a Wi-Fi connection, etc.) and / or network paths, as further described herein.

[0032] In some embodiments, server device 308 can be a computer system including at least one memory, one or more processing units (or processors), storage units, communication devices and I / O devices. In some embodiments, server device 308 can perform any one or more operations in the operation of server device described herein. In some embodiments, these elements can be implemented in a similar manner (or different manner) as described with reference to similar elements of resident device 304. In some embodiments, server device 308 can receive from one or more controllers or accessory devices of diagram 300 via resident device 304. In some embodiments, server device 308 can be used for sending data updates to one or more of controllers or accessory devices via resident device 304.

[0033] In some embodiments, the resident device 304 may correspond to any one or more of the resident devices described herein (e.g., tablet computers, smart speaker devices, smart media players communicatively connected to TVs, etc.). In some cases, an environment may include more than one resident device. In these cases, a resident device is designated as a resident device 304, and the remaining resident devices may be designated as redundant resident devices. In addition, the connection between one or more accessory devices 312 and the redundant resident device may be cut off so that the communication between one or more controller devices 302 and one or more accessory devices 312 is routed through the resident device 304. For example, a controller device may request an accessory device to perform a certain task, and the accessory device may require a certain capability from a redundant resident device. The resident device 304 may designate the redundant resident device as an auxiliary resident device to complete the task. In response to completing the task, the communication between the controller device, the auxiliary resident device and the accessory device may be cut off. In the case where the controller device attempts to communicate with the accessory device, the communication is routed through the resident device 304.

[0034] In some embodiments, one or more networks 310 may include a WAN (e.g., the Internet) and / or a LAN. As described herein, a residential environment may be associated with a LAN, whereby devices present within the residential environment may communicate with each other via the LAN. As described herein, a WAN may be external to the environment. For example, a router associated with a LAN (and therefore with the residential environment) may enable traffic from the LAN to be sent to the WAN, and vice versa. In some embodiments, a server device 308 may be external to the environment in which the resident device 304 and the accessory device 312 are located, and therefore communicate with other devices via the WAN via the resident device 304. In some embodiments, the resident device 304 may typically reside within the residential environment and communicate with other devices of the residential environment via the LAN. In some embodiments, the controller device 302 may be transient. For example, as described herein, the controller device 302 may be present within the residential environment (e.g., and communicate via the LAN), while in another example, the controller device 302 may be outside the residential environment and communicate via the Internet (or other suitable network) (see, e.g., Figure 1 ).

[0035] As described herein, the resident device 304 can be included in one or more resident devices of resident devices within an environment. The environment can be managed by a communication framework, wherein communications between the controller device 302 and the accessory device 312 are routed through the resident device 304. In addition, communications between the controller device 302 and the server device 308 or communications between the accessory device 312 and the server device 308 are also routed through the resident device 304.

[0036] In some cases, server device 308 can send data for receipt by one or more controller devices 302 or by one or more of accessory devices 312. The data can be, for example, a software update, a modification of a protocol, personal user data, a response to requested information, or other data received by one or more controller devices 302 or by one or more of accessory devices 312. Server device 308 can determine to communicate with resident device 304 via network 310 rather than directly with one or more of accessory devices 312. Server device 308 can make this determination even if server device 308, one or more controller devices 302, and one or more of accessory devices 312 are connected via network 310.

[0037] Resident device 304 can receive data from server device 308 via network 310. Resident device 304 can send a non-wake-up message to one or more controller devices 302 or one or more accessory devices 312 indicating receipt of data from server device 308. The message can be non-wake-up such that a controller device or accessory device in sleep mode is not awakened based on receipt of the message.

[0038] Data received from the server device 308 may be encrypted and decrypted by the resident device 304. Conversely, data sent to the server device 308 (including data received from the controller device or the accessory device) may be encrypted by the resident device 304. In this sense, any personal data received by the resident device 304 is in encrypted form before being sent to the server device 308. Therefore, the encryption / decryption logic and responsibility may be assumed by the resident device 304. One or more accessory devices 312 may rely on the resident device 304 to perform encryption / decryption, which reduces the energy usage of the accessory device and frees up processing power of one or more accessory devices 312. For example, the controller device may send the user's personal health information to the resident device 304 in an unencrypted form. In some cases, the data may be stored at the server device 308. Before sending the personal data to the server device 308, the resident device 304 may encrypt the data. Therefore, even in the case where a malicious actor wants to access the server device 308, the user's personal data is encrypted.

[0039] In response to the message, each controller device or accessory device can send a data state to resident device 304. The data state can include a token indicating the data state of the corresponding controller device or accessory device. For example, the token can include a timestamp of the last data received by the controller device or accessory device from server device 308. The token can also include a description of previously updated data.

[0040] In some cases, one controller device or accessory device may have been previously updated based on a recent data update, while the other device has not been updated based on a recent data update. Therefore, upon receiving the respective data status of each accessory device, resident device 304 can determine a difference between the data stored at the controller or accessory device and the data received from server device 308. If there is no difference between the data stored at the controller or accessory device and the data received from server device 308, resident device 304 can determine not to send the data to the controller or accessory device.

[0041] However, if resident device 304 determines that there is a difference between the data stored at the controller device or the accessory device and the data received from server device 308, resident device 304 can send data to the controller device or the accessory device to synchronize the data stored at the server device with the data stored at the controller device or the accessory device. For example, resident device 304 can determine that the accessory device should receive a certain portion of the data received from the server device based on the timestamp of the token received from the accessory device and the arrival time of the data from server device 308. In some cases, the token can include, for example, an update identifier for identifying a recent update.

[0042] In some cases, resident device 304 may further format the data to be compatible with the format of the controller device or the accessory device. For example, the accessory device may operate on an older version of an operating system than server device 308. In these cases, resident device 304 may reformat (e.g., modify the data schema) the data received from server device 308 to be compatible with the format of the accessory device.

[0043] The resident device 304 can further mediate the communication between the one or more controller devices 302 or one or more accessory devices 312 and the server device 308. For example, the resident device 304 can receive a message from a controller device or an accessory device that needs to be synchronized with data on the server device 308. In addition, in some cases, the message of the controller device or the accessory device is formatted in a format different from that which the server device can receive. For example, the controller device or the accessory device may use an older operating system version than the server device 308. The resident device 304 can reformat the message to be compatible with the server device 308. The resident device 304 can then reformat the message and send it to the server device 308.

[0044] For example, suppose a user uses an application such as a home management application on their mobile phone and wants to rename a room on the application from "Living Room" to "Living Room". The user can use a controller device to send a message requesting synchronization of changes at server device 308. However, the controller device may use an older operating system version than the version implemented by server device 308. In this case, resident device 304 may determine that the request is not properly formatted for server device 308 based on the pattern of the request. Therefore, resident device 304 may reformat the message to be compatible with the format of server device 308. Resident device 304 may then send the reformatted message to server device 308.

[0045] Figure 4400 is a diagram of a resident device according to some embodiments. Turning to each element of the resident device 402 in further detail, the processor 404 may be implemented in hardware, computer executable instructions, firmware, or a combination thereof as appropriate. The computer executable instructions or firmware implementation of the processor 404 may include computer executable instructions or machine executable instructions written in any suitable programming language to perform the various functions described.

[0046] The memory 406 can store program instructions that can be loaded and executed on the processor 404 and data generated during the execution of these programs. Depending on the configuration and type of the resident device 402, the memory 406 can be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). In some specific implementations, the memory 406 may include a variety of different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM) or ROM. The resident device 402 may also include an additional storage device 408, such as a removable storage device or a non-removable storage device, including but not limited to a magnetic storage device, an optical disk and / or a tape storage device. The disk drive and its associated computer-readable medium can provide a non-volatile storage device for computer-readable instructions, data structures, program modules and other data for the computing device. In some embodiments, the storage device 408 can be used to store data content received from one or more other devices (e.g., one or more controller devices 302, server devices 308 and / or one or more accessory devices 312). The storage device 408 may also store configuration settings, such as instructions for sending notifications to controller devices and accessory devices attached to the environment.

[0047] The resident device 402 may also include a communication interface 410 that allows the resident device 402 to communicate with a stored database, another computing device or server, a user terminal, and / or other devices over the network 310. Specifically, the communication interface 410 may enable the resident device 402 to route communications between one or more controller devices 302 and one or more accessory devices 312 through the resident device 402. The communication interface 410 may further enable the resident device 402 to route communications between one or more controller devices 302 and a server device 308, or between one or more accessory devices 312 and a server device 308 through the resident device 402.

[0048] The resident devices 402 may also include I / O devices 412 such as for enabling connections to a keyboard, mouse, pen, voice input device, touch input device, display, speaker, printer, etc. In some embodiments, the I / O devices 412 may be used to input information from or output information to one or more controller devices 302 or one or more accessory devices 312. This may include, but is not limited to, a light that may light up in a particular manner (e.g., a particular color, flashing light, etc.) when a message arrives.

[0049] Turning to the contents of memory 406 in further detail, memory 406 may include an operating system 422 and one or more applications or services for implementing the features disclosed herein, including a communication module 424, a message analysis module 426, a device identification module 428, a notification module 430, and an encryption / decryption module 432. The communication module 424 may include code that causes the processor 404 to generate messages, forward messages, reformat messages, and / or otherwise communicate with other entities (e.g., controller devices, accessory devices, and server devices). For example, as described herein, the communication module 424 may route, send, and / or receive messages to and from one or more controller devices 302, one or more accessory devices 312, and / or server devices 308. As described herein, the communication module 424 may send messages via one or more network paths of the network 310 (e.g., via a LAN and / or WAN associated with a residential environment).

[0050] The message analysis module 426 can include code that causes the processor 404 to receive and process messages to / from one or more controller devices 302, one or more accessory devices 312, and / or a server device 308. For example, the message analysis module 426 can obtain a message to determine a format of the message and compare the format to a format of one or more controller devices 302, one or more accessory devices 312, and / or a server device 308. The message analysis module 426 can also determine, for example, the identity of the device, the location of the device, and other suitable information from the message.

[0051] The device identification module 428 may include code that causes the processor 404 to identify one or more devices that have sent a status update, a data status, or are configured to receive data from the server device 308. For example, the device identification module 428 may retrieve one or more device profiles (e.g., from the storage device 408) and identify one or more messages associated with the device profiles. In another example, the device identification module 428 may further identify one or more candidate data recipient devices based on the data status analysis.

[0052] The notification module 430 may include code that causes the processor 404 to send a non-wake-up data update notification. In some embodiments, the presentation of the notification may depend in part on the type of recipient device (e.g., mobile phone, smart watch, smart speaker, etc.). In other words, the notification may selectively select which device to send the notification.

[0053] The encryption / decryption module 432 may include code that causes the processor 404 to encrypt and / or decrypt messages. For example, the encryption / decryption module 432 may send an encrypted message with data to the server device 308. In one example, the server device 308 may not have access to a cryptographic key that is operable to decrypt the encrypted message. Therefore, in response to a request for data from the server device 308, the server device 308 may return the data in an encrypted form. The encryption / decryption module may store encryption keys, such as public and private keys, to perform both encryption and decryption operations on data to and from the server device 308.

[0054] Figure 5 500 is a signaling diagram for routing messages from a controller device to an accessory device via a resident device according to some embodiments. As shown, a controller device 502 communicates with a resident device 504 and an accessory device 506. Although the operations of processes 500, 600, 700, 800, and 900 are described as being performed by a general-purpose computer, it should be understood that any suitable device may be used to perform one or more operations of these processes. Processes 500, 600, 700, 800, and 900 (described below) are illustrated as logic flow diagrams, respectively, and each operation of these logic flow diagrams represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation represents a computer executable instruction stored on one or more computer-readable storage media, which performs the operation when executed by one or more processors. Generally speaking, a computer executable instruction includes a routine, a program, an object, a component, a data structure, etc. that performs a specific function or implements a specific data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the described processes.

[0055] At 508, the controller device 502 may establish a first direct connection with the resident device 504. The connection may be based on, for example, the controller device 502 being connected to a network, such as a Wi-Fi network, to which the resident device 504 is also connected.

[0056] At 510, the controller device 502 can establish a direct connection with the accessory device 506. The connection can also be based on the connection of the accessory device 506 to the network. Each of the controller device 502, the resident device 504, and the accessory device 506 can be located in the same environment, such as a residential environment.

[0057] At 512, the controller device 502 may receive an input identifying a control instruction for controlling the accessory device 512. The controller device 502 may be a device such as a smart phone or a laptop computer and operated by a user. The controller device 502 may also include an I / O device such as a keyboard or a touch screen. The user may interact with the controller device 502 via the I / O device to enter the input. The input may also be to control some aspect of the accessory device 506. For example, the input may generate a volume control instruction to control the volume of the accessory device 506.

[0058] At 514, the controller device 502 can determine whether to send the message including the control instructions to the resident device 504 or the accessory device 506. Generally speaking, the controller device 502 will send the message with the control instructions directly to the accessory device 506 via the connection. However, as described herein, the controller device 502 can be configured to not only recognize a direct and simultaneous connection with both the resident device 504 and the accessory device 506, but also to deny the option of sending the message directly to the accessory device 506 based at least in part on detecting the resident device 504. The controller device 502 can be configured to determine whether to send the message to the accessory device 506 via routing the message through the resident device 504. In some embodiments, the controller device can be configured to always determine to send the message to the resident device 504. In this sense, the resident device 504 can act as a relay device between the controller device 502 and the accessory device 506.

[0059] At 516, the controller device 502 may send a message including the control instructions to the resident device 504. In some embodiments, the controller device 502 sends the message via a first transmission protocol and sends a second repeating message via a second transmission protocol. For example, the controller device 502 may send the message via a Wi-Fi network and send the repeating message via a cellular transmission.

[0060] At 518, resident device 504 can send a message including the control instructions to accessory device 506. In the event that controller device 502 sends a message and a repeat message, resident device 504 can further process the later received message or repeat message.

[0061] At 520, accessory device 506 may receive the message from resident device 504 and further execute the control instruction. For example, the control instruction is to adjust the volume, and in response, the accessory device may adjust its volume higher or lower. In some embodiments, accessory device 506 will further send an accessory state change back to resident device 504 in response to the volume change.

[0062] Figure 6 600 is a signaling diagram for synchronizing data between a server device and a controller device or an accessory device according to some embodiments. As shown, a controller / accessory device 602 communicates with a resident device 604 and a server device 606. For the purpose of this diagram, the process for the controller device is the same as the process for the accessory device. At 608, the server device 606 can send data to the resident device 604. Data can be sent based on various reasons, such as general software updates, requests from devices, or in response to triggering events. Data can include objects such as software patches, encrypted personal information, information. It should be understood that the server device 606 sends data to the resident device 604, rather than sending data to each controller / accessory device. When receiving data, the resident device 604 can be responsible for decrypting the data, identifying the data format, identifying which controller / accessory devices the data may be related to, and converting the data into a compatible format for the controller / accessory device 602.

[0063] At 610, in response to receiving the data transmission, resident device 604 can send a non-wake-up data change notification, which can include a request for the current data state of controller / accessory device 602. The notification can be non-wake-up because if controller / accessory device 602 is in sleep mode when the notification is received, the device will not wake up.

[0064] 612 is an optional step in the event that the controller / accessory device 602 is in sleep mode when it receives the notification from the resident device at step 610. If the controller / accessory device 602 is asleep, the device may enter wake mode based on some triggering event other than the notification of step 610.

[0065] At 614, the controller / accessory device 602 can transmit the current data state to the resident device in response to the notification. The current data state can also include a token that can be used to identify the current data state. For example, the token can include a timestamp of the last time the data at the controller / accessory device was updated. In another case, the token can include a data identifier that identifies the last data received from the server device 606.

[0066] At 616, the resident device 604 can identify the data state and determine the difference between the data stored at the controller / accessory device 602 and the data received from the server device 606 at step 608 based on the token. For example, the resident device 604 can store a transaction log describing each data update for each device. The resident device 604 can further identify the entry in the transaction log based on the token. The resident device 604 can identify the difference based on the data received at step 608 and the entry in the transaction log. The difference can include, for example, an update to a library, an update to a user's personal information, an update to a protocol, or some other data difference.

[0067] At 618, resident device 604 can determine whether to send the data to the controller / accessory device based on the analysis at step 616. Resident device 604 can further reformat data received from server device 606 from the server device format to a format compatible with the intended resident device.

[0068] At 620, resident device 604 may send data to controller / accessory device 602. Even though resident device 604 sends data, it may not send all of the data to the device. Data received for server device 606 may be sent in batches, and not all of the data is relevant to each device. Therefore, resident device 604 does not have to send all of the data to each device. For example, resident device 604 may send a first portion of the data to a first controller / accessory device and a second portion of the data to a second controller / accessory device based on the data state of each individual device.

[0069] At 622 , the controller / accessory device 602 can integrate the data into the device. For example, the controller / accessory device 602 can store data, delete data, and reconfigure memory based on the data received at step 620 .

[0070] Figure 7 700 is a signaling diagram for requesting the state of an accessory device by a controller device according to some embodiments. As shown, the controller device 702 communicates with a resident device 704 and an accessory device 706. At 708, the accessory device can send the state of the accessory device 706 (including the accessory device identifier) ​​to the resident device 704. The sending can be based on various triggers. For example, the sending can be based on a change in the state of the accessory device 702, a periodic state notification, or in response to a request from the resident device 704.

[0071] At 708, the resident device 704 can store the state in a cache. In some embodiments, the resident device can have previously stored the state of the accessory device 706. In these embodiments, if the state has not changed, the state stored in the cache can persist. However, if the state of the accessory device 706 has changed, the resident device 704 can delete the old state and write a new state including the associated accessory device identifier to the cache.

[0072] At 710, the controller device 702 can send a request for the status of the accessory device 710. The request can be generated based on input from a user, which causes the request message to be created by the controller device 702. For example, the request can be a request regarding whether a garage door is open or closed. In some embodiments, the request also includes an accessory device identifier.

[0073] At 712, resident device 704 can retrieve the state from the cache. Resident device 704 can identify the state by comparing the accessory device identifier accompanying the request at step 710 with the accessory device identifier stored in the cache and associated with the state. Resident device 704 can also generate a response message including the accessory device identifier and the state.

[0074] At 714, the resident device 704 may send a response including the status of the accessory device and the accessory device identifier to the controller device 702. In response to receiving the response, the controller device 702 may present the status to the user. For example, the controller device may display whether the garage is open or closed.

[0075] Figure 8 800 is a process flow for routing messages from a controller device to an accessory device via a resident device according to some embodiments. At 802, the method may include a controller device detecting a resident device and an accessory device connected to a local network. In some cases, when connected to the local network, the controller device may detect each other device connected to the network, including the resident device and the accessory device. The controller device may be, for example, a smartphone or laptop of a user in an environment. The resident device may be, for example, a smart speaker. The accessory device may be, for example, a garage door opener. The controller device, the resident device, and the accessory device may all be devices in an environment such as a house or an office.

[0076] At 804, the method may include the controller device establishing a first direct connection with the resident device. The connection may be based on, for example, a connection between the computing device and the resident device through a network, such as a Wi-Fi network.

[0077] At 806, the method may include the controller device receiving an input identifying a control instruction for controlling the accessory device. A user may interact with the controller device via an I / O device to input the input identifying the control instruction. The input may also be to control some aspect of the accessory device connected to the network. For example, the control instruction may be to open or close a garage door.

[0078] At 808, the method may include a controller device determining whether to send a message including a control instruction to a resident device using a first direct connection or to send a message including a control instruction to an accessory device using a second direct connection. In a conventional communication framework, the controller device will send a message with a control instruction directly to the accessory device via a network connection. However, as described herein, the controller device may be configured to not only recognize a direct and simultaneous connection with both a resident device and an accessory device, but also to deny the option of sending a message directly to the accessory device based at least in part on detecting the resident device. The controller device may be configured to determine to send a message to the accessory device via routing the message through the resident device. In some embodiments, the controller device may be configured to always send a message to the accessory device by routing the message through the resident device.

[0079] At 810, the controller device may send a message including control instructions to the resident device using the first direct connection. In some embodiments, the controller device sends the message via a first transmission protocol (e.g., Wi-Fi) and sends a second repeating message via a second transmission protocol (e.g., cellular). The resident device may be further configured to relay the message including the control instructions to the accessory device.

[0080] Fig. 9 900 is a process flow for synchronizing data between a server device and a controller device or an accessory device according to some embodiments. At 902, a resident device may send a non-wake-up data change notification, which may include a request for a first data state of the controller / accessory device. The notification may be sent in response to receiving data from a server device. The primary controller device may be located in the same environment as the controller / accessory device.

[0081] The resident device can receive a data state from the controller / accessory device at 904. The data state can be received based on a notification and include a token describing the data state.

[0082] At 906, the resident device may identify differences between data stored on the controller / accessory device and data received from the server device based on the token. Rather than determining the differences by comparing the data stored at each controller / accessory with the data received from the server device, the resident device determines the differences by comparing the data state described by the token with the data received from the server device. For example, the resident device may store a transaction log describing each update of each device. The resident device may further identify entries in the transaction log based on the token. The resident device may identify the differences based on the data received at step and the entries in the transaction log. The differences may include updates to a library, updates to a user's personal information, updates to a protocol, or some other data differences.

[0083] At 908, the resident device may send data to the controller / accessory devices. Even if the resident device sends data, it may not send all of the data to each device. For example, the resident device may send a first portion of the data to a first controller / accessory device and a second portion of the data to a second controller / accessory device based on the data state of each individual device. The data received for the server device may be sent in batches, and not all of the data is relevant to each device. Therefore, the resident device does not send data to each device.

[0084] Fig.10 1000 is a block diagram of a controller 1000 according to some embodiments. The controller 1000 implements any or all of the controller functions, behaviors and capabilities described herein, as well as other functions, behaviors and capabilities that are not explicitly described. The controller 1000 may include a processing subsystem 1010, a storage device 1012, a user interface 1014, a communication interface 1016, a security element 1018 and a cryptographic logic module 1020. The controller 1000 may also include other components (not explicitly shown), such as batteries, power controllers and other components that can operate to provide various enhanced capabilities. In various embodiments, the controller 1000 may be implemented in a desktop computer, a laptop computer, a tablet computer, a smart phone, a wearable computing device or other systems with any desired form factor. In addition, as described above, the controller 1000 may be partially implemented in a base station and partially implemented in a mobile unit that communicates with the base station and provides a user interface.

[0085] The storage device 1012 may be implemented, for example, using a disk, a flash memory, or any other non-transitory storage medium or combination of media, and may include volatile media and / or non-volatile media. In some embodiments, the storage device 1012 may store one or more applications and / or operating system programs to be executed by the processing subsystem 1010, including programs for implementing any or all operations performed by the controller described herein. For example, the storage device 1012 may store a unified controller application that reads an accessory definition record and generates a graphical user interface for controlling the accessory based on the information therein. In some embodiments, some (or all) of the controller functions described herein may be implemented in an operating system program rather than an application. In some embodiments, the storage device 1012 may also store applications designed for specific accessories or specific categories of accessories (e.g., an IP camera application for managing IP camera accessories or a security application for interacting with door lock accessories).

[0086] The user interface 1014 may include input devices such as a touch pad, a touch screen, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a microphone, etc.; and output devices such as a video screen, indicator lights, speakers, a headphone jack, etc., together with supporting electronic components (e.g., digital-to-analog converters or analog-to-digital converters, signal processors, etc.). The user can operate the input devices of the user interface 1014 to invoke functions of the controller 1000, and can view and / or listen to outputs from the controller 1000 via the output devices of the user interface 1014.

[0087] The processing subsystem 1010 may be implemented as one or more integrated circuits, such as one or more single-core or multi-core microprocessors or microcontrollers, examples of which are known in the art. In operation, the processing system 1010 may control the operation of the controller 1000. In various embodiments, the processing subsystem 1010 may execute various programs in response to program code, and may maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in the processing subsystem 1010 and / or a storage medium such as a storage device 1012.

[0088] Through appropriate programming, the processing subsystem 1010 can provide various functions for the controller 1000. For example, in some embodiments, the processing subsystem 1010 can implement various processes (or portions thereof) described above as implemented by the controller. The processing subsystem 1010 can also execute other programs (including programs that can be stored in the storage device 1012) to control other functions of the controller 1000. In some embodiments, these programs can interact with the accessory, for example, by generating messages to be sent to the accessory and / or by receiving messages from the accessory. Such messages can conform to the unified accessory protocol as described above.

[0089] The communication interface 1016 may provide voice and / or data communication capabilities for the controller 1000. In some embodiments, the communication interface 1016 may include: a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular phone technology, data network technology such as 3G, 4G / LTE, Wi-Fi (IEEE 802.11 series standards) or other mobile communication technology, or any combination thereof), a component for short-range wireless communication (e.g., using Bluetooth standard and / or Bluetooth LE standard, NFC, etc.), and / or other components. In some embodiments, in addition to or instead of a wireless interface, the communication interface 1016 may provide wired network connectivity (e.g., Ethernet). The communication interface 1016 may be implemented using a combination of hardware components (e.g., drive circuits, antennas, modulators / demodulators, encoders / decoders, and other analog signal processing circuits and / or digital signal processing circuits) and software components. In some embodiments, the communication interface 1016 may support multiple communication channels concurrently using the same transmission or different transmissions.

[0090] The secure element 1018 may be an integrated circuit or the like that may securely store cryptographic information for the controller 1000. Examples of information that may be stored within the secure element 1018 include the controller's long-term public and private keys (LTPKC, LTSKC as described above) and a list of paired accessories (e.g., a lookup table that maps accessory IDs to accessory long-term public keys LTPKA of accessories that have completed the pairing setup or pairing add process as described above).

[0091] In some embodiments, cryptographic operations may be implemented in a cryptographic logic module 1020 that communicates with the secure element 1018. Physically, the cryptographic logic module 1020 may be implemented in the same integrated circuit with the secure element 1018 or in a different integrated circuit (e.g., a processor in the processing subsystem 1010), as desired. The cryptographic logic module 1020 may include various logic circuits (fixed or programmable, as desired) that implement or support the cryptographic operations of the controller 1000 (including any or all of the cryptographic operations described above). The secure element 1018 and / or the cryptographic logic module 1020 may appear as a "black box" to the rest of the controller 1000. Thus, for example, the communication interface 1016 may receive a message in encrypted form that it cannot decrypt, and may simply deliver the message to the processing subsystem 1010. The processing subsystem 1010 may also be unable to decrypt the message, but it may recognize the message as encrypted and deliver it to the cryptographic logic module 1020. Cryptographic logic module 1020 may decrypt the message (e.g., using information extracted from secure element 1018) and determine which information to return to processing subsystem 1010. Therefore, certain information may only be available within secure element 1018 and cryptographic logic module 1020. If secure element 1018 and cryptographic logic module 1020 are implemented on a single integrated circuit that executes only code from an internal secure repository, this may make information extraction very difficult, thereby providing a high degree of security. Other specific implementations are also possible.

[0092] Fig.11 is a block diagram of an accessory 1100 according to some embodiments. Accessory 1100 may implement any or all of the accessory functions, behaviors, and capabilities described herein, as well as other functions, behaviors, and capabilities not explicitly described. Accessory 1100 may include storage device 1128, processing subsystem 1130, user interface 1132, accessory-specific hardware 1134, communication interface 1136, security element 1138, and cryptographic logic module 1140. Accessory 1100 may also include other components (not explicitly shown), such as batteries, power controllers, and other components that can operate to provide various enhanced capabilities.

[0093] Accessory 1100 represents a broad class of accessories that may be operated by a controller such as controller 1000, and such accessories may vary widely in capabilities, complexity, and form factors. Various accessories may include Fig.11 Components not explicitly shown in the drawings include, but are not limited to: storage devices with fixed or removable storage media (disks, flash memory, etc.); video screens, speakers, or ports for connecting to external audio / video devices; camera components, such as lenses, image sensors, and controls for camera components (e.g., aperture, zoom, exposure time, frame rate, etc.); microphones for recording audio (alone or in combination with video recording); etc.

[0094] The storage device 1128 may be implemented, for example, using a disk, a flash memory, or any other non-transitory storage medium or combination of media, and may include volatile media and / or non-volatile media. In some embodiments, the storage device 1128 may store one or more programs to be executed by the processing subsystem 1130 and operations related to specific accessory behaviors, wherein the one or more programs include programs for implementing the various operations described above as being performed by the accessory. The storage device 1128 may also store an accessory object or an accessory definition record (e.g., as described above), which may be provided to the controller device, for example, as described above. The storage device 1128 may also store accessory state information and any other data that may be used during the operation of the accessory 1100.

[0095] Processing subsystem 1130 may include, for example, one or more single-core or multi-core microprocessors and / or microcontrollers that execute program code to perform various functions associated with accessory 1100. For example, processing subsystem 1130 may implement any or all of the operations described herein as being implemented by the accessory, such as by executing program code stored in storage device 1128. Processing subsystem 1130 may also execute other programs to control other functions of accessory 1130. In some cases, the programs executed by processing subsystem 1130 may interact with a controller (e.g., controller 1000), such as by generating messages to be sent to the controller and / or receiving messages from the controller. Such messages may conform to a unified accessory protocol as described above.

[0096] User interface 1132 may include user-operable input devices such as a touchpad, touch screen, scroll wheel, click wheel, dial, button, switch, keypad, microphone, etc.; and output devices such as a video screen, indicator lights, speakers, headphone jack, etc., along with supporting electronics (e.g., digital-to-analog converters or analog-to-digital converters, signal processors, etc.). Depending on the specific implementation of a particular accessory 1100, a user may operate the input devices of user interface 1132 to invoke functions of accessory 1100, and may view and / or hear output from accessory 1100 via the output devices of user interface 1134. Some accessories may provide minimal or no user interface.

[0097] Accessory-specific hardware 1134 can include any other components that may be present in accessory 1100 to enable or support its functionality. For example, in various embodiments, accessory-specific hardware 1134 can include one or more storage devices using fixed or removable storage media; a GPS receiver; a power source and / or power management circuitry; a camera; a microphone; one or more actuators; an environmental sensor (e.g., a temperature sensor, a pressure sensor, an accelerometer, a chemical sensor, etc.); and the like. It should be appreciated that any type of accessory functionality can be supported by providing appropriate accessory-specific hardware 1134.

[0098] The communication interface 1136 may provide voice and / or data communication capabilities for the accessory 1100. In some embodiments, the communication interface 1136 may include: a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular phone technology, data network technology such as 3G, 4G / LTE, Wi-Fi (IEEE 802.11 series standards) or other mobile communication technology, or any combination thereof), a component for short-range wireless communication (e.g., using Bluetooth standard and / or Bluetooth LE standard, NFC, etc.), and / or other components. In some embodiments, in addition to or in place of a wireless interface, the communication interface 1136 may provide wired network connectivity (e.g., Ethernet). The communication interface 1136 may be implemented using a combination of hardware components (e.g., drive circuits, antennas, modulators / demodulators, encoders / decoders, and other analog signal processing circuits and / or digital signal processing circuits) and software components. In some embodiments, the communication interface 1136 may support multiple communication channels concurrently using the same transmission or different transmissions.

[0099] Secure storage module 1138 can be an integrated circuit or the like that can securely store cryptographic information for accessory 1100. Examples of information that can be stored within secure storage module 1138 include the accessory's long-term public and private keys (LTPKA, LTSKA as described above) and a paired controller list (e.g., a lookup table that maps controller IDs to controller long-term public keys LTPKC of controllers that have completed the pairing setup or pairing add process as described above).

[0100] In some embodiments, cryptographic operations may be implemented in a cryptographic logic module 1140 that communicates with the secure storage module 1138. Physically, the cryptographic logic module 1140 may be implemented in the same integrated circuit with the secure storage module 1138 or in a different integrated circuit (e.g., a processor in the processing subsystem 1130), as desired. The cryptographic logic module 1140 may include various logic circuits (fixed or programmable, as desired) that implement or support the cryptographic operations of the accessory 1100, including any or all of the cryptographic operations described above. The secure storage module 1138 and / or the cryptographic logic module 1140 may appear as a "black box" to the rest of the accessory 1100. Thus, for example, the communication interface 1136 may receive a message in encrypted form that it cannot decrypt, and may simply deliver the message to the processing subsystem 1130. The processing subsystem 1130 may also be unable to decrypt the message, but it may recognize the message as encrypted and deliver it to the cryptographic logic module 1140. The cryptographic logic module 1140 may decrypt the message (e.g., using information extracted from the secure storage module 1138) and determine which information to return to the processing subsystem 1130. Therefore, certain information may be available only within the secure storage module 1138 and the cryptographic logic module 1140. If the secure storage module 1138 and the cryptographic logic module 1140 are implemented on a single integrated circuit that executes only code from an internal secure repository, this may make information extraction very difficult, thereby providing a high degree of security. Other specific implementations are also possible.

[0101] Accessory 1100 can be any electronic device that interacts with a controller such as controller 1000. In some embodiments, as described above, controller 1000 can provide remote control over the operation of accessory 1100. For example, controller 1000 can provide a remote user interface for accessory 1100 that can include both input controls and output controls (e.g., a display screen for displaying current status information obtained from accessory 1100 and input controls such as a touch screen overlay for allowing changes in status information). In various embodiments, controller 1000 can control any function of accessory 1100 and can also receive data from accessory 1100.

[0102] Example

[0103] In the following sections, additional exemplary embodiments are provided.

[0104] Embodiment 1 includes a method, the method comprising: detecting, by a controller device, a resident device and an accessory device connected to a local network; and establishing, by the controller device, a first direct connection with the resident device; receiving, by the controller device, an input identifying a control instruction for controlling the accessory device; determining, by the controller device, whether to send a message including the control instruction to the accessory device via a second direct connection with the accessory device, or to send the message including the control instruction to the resident device via the first direct connection; and sending, by the controller device, the message including the control instruction to the resident device via the first direct connection, the resident device being configured to relay the message including the control instruction to the accessory device.

[0105] Embodiment 2 includes the method of embodiment 1, wherein the method further comprises establishing, by the controller device, the second direct connection with the accessory device.

[0106] Embodiment 3 includes the method of any one of Embodiments 1 and 2, wherein the method further comprises severing the second direct connection with the accessory device before receiving the input.

[0107] Embodiment 4 includes the method of any one of embodiments 1 to 3, wherein the method further comprises always determining to send the message including the control instruction to the resident device via the first direct connection with the resident device.

[0108] Embodiment 5 includes the method of any one of embodiments 1 to 4, wherein the method further comprises: receiving an accessory device state from the resident device; and storing the accessory device state in a local memory.

[0109] Embodiment 6 includes the method of embodiment 5, wherein the method further comprises: receiving a request for the accessory device status from a second device; retrieving the accessory device status from the local memory; and sending the accessory device status to the second device.

[0110] Embodiment 7 includes a method according to any one of embodiments 1 to 6, wherein the method further includes: receiving a notification of a data state of the accessory device; determining a difference between the data state of the accessory device and data received from a server; and sending a first portion of the data received from the server to the accessory device based at least in part on the determination.

[0111] Embodiment 8 includes a computing device, comprising: a processor; and a computer-readable medium, the computer-readable medium including instructions stored thereon, the instructions, when executed by the processor, causing the processor to perform a method according to any one of embodiments 1 to 7.

[0112] Embodiment 9 includes a non-transitory computer-readable medium, which includes instructions stored thereon, which instructions, when executed by a processor, cause the processor to perform operations, wherein the operations include the method according to any one of embodiments 1 to 7.

[0113] Although specific embodiments have been described, those skilled in the art will recognize that numerous modifications are possible. A single controller can use the processes described herein to establish pairings with any number of accessories and selectively communicate with different accessories at different times. Similarly, a single accessory can be controlled by multiple controllers with which pairings have been established. Any function of an accessory can be controlled by modeling the function as a service with one or more characteristics and allowing the controller to interact with the service and / or the characteristics of the service (e.g., read, modify, receive updates). Therefore, regardless of the accessory function or the controller form factor or specific interface, the protocols and communication processes described herein can be "universal", meaning that they can be applied in any scenario with one or more controllers and one or more accessories.

[0114] Therefore, although specific embodiments have been described, it should be understood that the embodiments may include all modifications and equivalents within the scope of the following claims.

[0115] As described above, one aspect of the present technology is the collection and use of available data and the routing of message delivery from a resident device to one or more devices. The present disclosure contemplates that, in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data may include demographic data, location-based data, online identifiers, phone numbers, email addresses, home addresses, data or records, date of birth, or any other personal information.

[0116] The present disclosure recognizes that the use of such personal information data in the present technology can be used to benefit the user. For example, the personal information data can be used to deliver commands from a user profile on a computing device to one or more computing devices. In addition, the present disclosure also contemplates other uses of the personal information data that benefit the user. For example, a specific state of a device associated with a user can be sent from the device back to the user profile.

[0117] The present disclosure envisions that entities responsible for collecting, analyzing, disclosing, transmitting, storing or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities will be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding the industry or government requirements for maintaining user privacy. Such information about the use of personal data should be highlighted and easily accessible to users, and should be updated as the collection and / or use of data changes. The user's personal information should be collected only for legal use. In addition, such collection / sharing should only occur after receiving user consent or other legal basis specified in applicable law. In addition, such entities should consider taking any necessary steps to protect and safeguard access to such personal information data, and ensure that other entities with access to personal information data comply with their privacy policies and procedures. In addition, such entities may subject themselves to third-party assessments to prove that they comply with widely accepted privacy policies and practices. In addition, policies and practices should be adjusted for specific types of personal information data collected and / or accessed, and applied to applicable laws and standards, including considerations that are exclusive to jurisdictions that can be used to impose higher standards. For example, in the United States, collection or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0118] Regardless of the foregoing, the present disclosure also contemplates implementation schemes in which users selectively block the use or access of personal information data. That is, the present disclosure contemplates that hardware elements and / or software elements may be provided to prevent or block access to such personal information data. For example, such as with respect to a token generation service, the present technology may be configured to allow a user to choose to "opt in" or "opt out" to participate in the collection of personal information data at any time during or after registration for the service. In addition to providing "opt-in" and "opt-out" options, the present disclosure also contemplates providing notifications related to access or use of personal information. For example, a user may be notified that the user's personal information data will be accessed when downloading an application, and then the user may be reminded again just before the personal information data is accessed by the application.

[0119] Illustrative techniques for using a computing device to delegate authority to generate tokens from an owner to a sharing platform and for tokens to be provisioned by the sharing platform. Some or all of these techniques may be implemented at least in part by at least Figures 1 to 11, but not necessarily by those shown in . Although many embodiments are described above with reference to computing devices and user devices, it should be understood that other types of computing devices may be suitable for performing the technology disclosed herein. In addition, various non-limiting examples are described in the foregoing description. For the purpose of explanation, many specific configurations and details are set forth in order to provide a thorough understanding of the examples. However, it should also be apparent to those skilled in the art that some examples can be implemented without these specific details. In addition, well-known features are sometimes omitted or simplified to prevent confusion with the examples described herein.

[0120] Various embodiments may also be implemented in a variety of operating environments, which in some cases may include one or more user computers, computing devices, or processing devices that can be used to operate any of a plurality of applications. User equipment or client devices may include any of a number of general-purpose personal computers, such as desktop computers or laptop computers running standard operating systems, and cellular devices, wireless devices, and handheld devices running mobile software and capable of supporting a plurality of networking protocols and instant messaging protocols. This system may also include multiple workstations running various commercially available operating systems and any of other known applications for purposes such as development and database management. These devices may also include other electronic devices, such as virtual terminals, thin clients, gaming systems, and other devices capable of communicating via a network.

[0121] Most embodiments utilize at least one network familiar to those skilled in the art to support communications using any of a variety of commercial protocols such as TCP / IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. The network can be, for example, a local area network, a wide area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.

[0122] In embodiments utilizing a web server, the web server may run any of a variety of server or middle-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. One or more servers may also be capable of executing programs or scripts in response to requests from user devices, such as by executing one or more applications, which may be implemented in any programming language such as One or more scripts or programs written in C, C# or C++ or any scripting language such as Perl, Python or TCL and combinations thereof. The server may also include a database server, including but not limited to databases that can be accessed from and Those obtained commercially.

[0123] Environment can include various data storage repositories and other memory and storage media, as discussed above. These can reside in various locations, such as on a storage medium local to one or more computers or away from the storage medium of any or all computers on the network (and / or reside in one or more computers). In a specific set of embodiments, information can reside in a storage area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing functions belonging to computers, servers or other network devices can be stored locally and / or remotely as needed. When the system includes a computerized device, each such device may include a hardware element that can be electrically coupled via a bus, and the element includes, for example, at least one central processing unit (CPU), at least one input device (e.g., mouse, keyboard, controller, touch screen or keypad), and at least one output device (e.g., display device, printer or speaker). Such systems can also include one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices such as RAM or ROM, and removable media devices, memory cards, flash memory cards, etc.

[0124] Such devices may also include a computer-readable storage medium reader, a communication device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.) and a working memory as described above. A computer-readable storage medium reader may be connected to or configured to receive a non-transient computer-readable storage medium representing a remote, local, fixed and / or removable storage device, and a storage medium for temporarily and / or more permanently containing, storing, sending and retrieving computer-readable information. Systems and various devices will also typically include a plurality of software applications, modules, services or other elements located within at least one working memory device, including an operating system and an application, such as a client application or a browser. It should be understood that alternative embodiments may have many variations according to those described above. For example, custom hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software, such as applets), or both. In addition, connections with other computing devices such as network input / output devices may be employed.

[0125] Non-transitory storage media and computer-readable storage media for containing code or parts of code may include any suitable media known or used in the art, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data), including RAM, ROM, electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, DVD or other optical storage, cassettes, tapes, disk storage devices or other magnetic storage devices, or any other medium that can be used to store the required information and can be accessed by system devices. Based at least in part on the disclosure and teachings provided herein, a person of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments. However, computer-readable storage media do not include transient media such as carrier waves.

[0126] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the claims.

[0127] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the present disclosure to the particular forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalent forms that fall within the spirit and scope of the present disclosure as defined by the appended claims.

[0128] The use of the terms "one", "an" and "the" and similar indicators in the context of describing the disclosed embodiments (particularly in the context of the claims below) will be interpreted as covering the singular and plural, unless otherwise stated or clearly contradicted by the context. Unless otherwise stated, the terms "comprise", "have", "include" and "contain" should be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" is interpreted as being partially or completely included, attached or joined together even if there are intervening things. The phrase "at least in part based on" should be understood as open, and is not limited in any way, and is intended to be interpreted or otherwise understood as "at least in part based on" where appropriate. Unless otherwise stated herein, the description of the numerical range herein is intended only to be used as a simple method of referring to each individual value falling within the range individually, and each individual value is incorporated into the specification as quoted individually in this article. All methods described herein can be performed in any suitable order, unless otherwise stated herein or otherwise clearly contradicted by the context. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate the embodiments of the present disclosure and will not limit the scope of the present disclosure. No language in the specification should be construed as indicating that any unclaimed element is essential to the practice of the present disclosure.

[0129] Unless otherwise specifically stated, disjunctive language such as the phrase "at least one of X, Y, or Z" is understood in context as generally used to present an item, term, or the like that can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z each be present. Additionally, conjunctive language such as the phrase "at least one of X, Y, and Z" is also understood to mean X, Y, Z, or any combination thereof, including "X, Y, and / or Z," unless otherwise specifically stated.

[0130] Preferred embodiments of the present disclosure are described herein, including the best mode known to the inventor for carrying out the present disclosure. After reading the foregoing description, variations of those preferred embodiments may become apparent to those of ordinary skill in the art. The inventor expects that the technical staff will appropriately adopt such variations, and the inventor intends to practice the present disclosure in a manner different from that specifically described herein. Therefore, as permitted by applicable law, the present disclosure includes all modifications and equivalents of the subject matter recorded in the claims attached to the present disclosure. In addition, unless otherwise noted herein or obviously contradictory to the context, the present disclosure includes any combination of all possible variations of the above-mentioned elements.

[0131] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

Claims

1. A method, comprising: Detecting, by the controller device, resident devices and accessory devices connected to the local network; establishing, by the controller device, a first direct connection with the accessory device; establishing, by the controller device, a second direct connection with the resident device; receiving, by the controller device, input identifying a control instruction for controlling the accessory device; determining, by the controller device, whether to send a message including the control instruction to the accessory device via the first direct connection with the accessory device or via the second direct connection with the resident device; as well as The message including the control instructions is sent by the controller device to the resident device via the second direct connection, and the resident device is configured to relay the message including the control instructions to the accessory device. 2 . The method of claim 1 , further comprising, before receiving the input, severing, by the controller device, the first direct connection with the accessory device.

3. The method according to any one of claims 1 and 2, further comprising always determining to send the message including the control instruction to the resident device via the second direct connection with the resident device.

4. The method of any one of claims 1 to 3, further comprising determining not to send the message including the control instruction to the accessory device via the first direct connection with the accessory device.

5. The method according to any one of claims 1 to 4, wherein the method further comprises: receiving an accessory device status from the resident device; as well as The accessory device state is stored in a local cache memory.

6. The method according to claim 5, wherein the method further comprises: receiving a request for a status of the accessory device from a second device; retrieving said accessory device status from said local cache memory; as well as The accessory device status is sent to the second device.

7. A device, comprising: a memory configured to store computer-executable instructions; as well as One or more processors configured to access the memory and execute the computer executable instructions to perform the method according to any one of claims 1 to 6.

8. A computer readable medium storing computer executable instructions which, when executed by one or more processors of a controller device, cause the one or more processors to perform the method according to any one of claims 1 to 6.

9. A method comprising: Receiving, by the resident device, a notification of a data status of the accessory device; determining, by the resident device, a difference between the data state of the accessory device and data received from a server; as well as A first portion of the data received from the server is sent, by the resident device, to the accessory device based at least in part on the determination.

10. The method of claim 9, wherein the resident device determines the difference between the data state of the accessory device and the data received from the server based on a token received from the accessory device.

11. The method of any one of claims 9 and 10, wherein determining the difference between the data state of the accessory device and data received from the server based on the token comprises: comparing a first time associated with the token to a second time associated with receiving the data from the server; as well as The data received from the server is sent to the accessory device based at least in part on the comparison.

12. The method according to claim 11, wherein the method further comprises: determining a difference between the data state of the controller device and data received from the server; as well as A second portion of data received from the server is sent to the controller device based at least in part on the determination, wherein the first portion of data is different than the second portion of data.

13. The method according to claim 12, wherein the method further comprises: determining a compatible response format for the accessory device via notification of the data status; sending a request for data to a server based at least in part on the notification of the state of the data; receiving the data from the server based at least in part on the sending; converting the data into the compatible response format for the accessory device; as well as The data in the compatible response format is sent to the accessory device.

14. The method according to claim 13, wherein the method further comprises: A first non-wake-up request for the notification of a data status is sent to the accessory device.

15. The method of claim 14, wherein the method further comprises sending the first non-wake-up request via a first communication protocol.

16. The method of any one of claims 9 to 16, wherein the method further comprises installing the first portion of data in the accessory device.

17. A device, comprising: a memory configured to store computer-executable instructions; as well as One or more processors configured to access the memory and execute the computer executable instructions to perform the method according to any one of claims 9 to 16.

18. A computer readable medium storing computer executable instructions which, when executed by one or more processors of a controller device, cause the one or more processors to perform the method according to any one of claims 9 to 16.

Images