WO2022221360A1

WO2022221360A1 - Techniques for communication between hub device and multiple endpoints

Info

Publication number: WO2022221360A1
Application number: PCT/US2022/024531
Authority: WO
Inventors: Jared S. Grubb; Robert M. Stewart; Gabriel Sanchez; Anshul Jain; Zaka Ur Rehman ASHRAF; David J. CHANDLER; Andrew Byrne; Anumita Biswas; Minsub LEE; Mahesh SHANBHAG
Original assignee: Apple Inc.
Priority date: 2021-04-15
Filing date: 2022-04-13
Publication date: 2022-10-20

Abstract

Techniques are disclosed for coordinating interactions between a user device and a plurality of accessory devices. In one example, a user device receives information identifying one or more accessory devices in communication with the user device. The user device may implement accessory interaction instances for each of the identified accessories. A first accessory interaction instance can be associated with a first accessory among the identified accessories and receive a first audio input from the first accessory corresponding to a user request. The first accessory interaction instance can process a portion of the received audio input and receive a first response from a server computer. The user device may then transmit the first response to the first accessory device.

Description

TECHNIQUES FOR COMMUNICATION BETWEEN HUB DEVICE AND MULTIPLE ENDPOINTS CROSS-REFERENCES TO RELATED APPLICATIONS [0001] This application claims the benefit of U.S. Non-Provisional Application No. 17/718,977, entitled “TECHNIQUES FOR COMMUNICATION BETWEEN HUB DEVICE AND MULTIPLE ENDPOINTS,” filed on April 12, 2022, which claims the priority under 35 U.S.C. § 119(e) to U.S. Provisional Application No.63/175,473, entitled “TECHNIQUES FOR COMMUNICATION BETWEEN HUB DEVICE AND MULTIPLE ENDPOINTS,” filed on April 15, 2021. The contents of which are herein incorporated by reference. [0002] This application claims the benefit of U.S. Non-Provisional Application No. 17/718,984, entitled “TECHNIQUES FOR LOAD BALANCING WITH A HUB DEVICE AND MULTIPLE ENDPOINTS,” filed on April 12, 2022, which claims the priority under 35 U.S.C. § 119(e) to: U.S. Provisional Application No.63/175,478, entitled “TECHNIQUES FOR LOAD BALANCING WITH A HUB DEVICE AND MULTIPLE ENDPOINTS,” filed on April 15, 2021, the contents of which are herein incorporated by reference. [0003] This application claims the benefit of U.S. Non-Provisional Application No. 17/719,086, entitled “TECHNIQUES FOR ESTABLISHING COMMUNICATIONS WITH THIRD-PARTY ACCESSORIES,” filed on April 12, 2022, which claims the priority under 35 U.S.C. § 119(e) to: U.S. Provisional Application No.63/175,480, entitled “TECHNIQUES FOR ESTABLISHING COMMUNICATIONS WITH THIRD-PARTY ACCESSORIES,” filed on April 15, 2021, the contents of which are herein incorporated by reference. BACKGROUND [0004] Techniques exist for multiple user devices in a home environment to communicate among the multiple devices. For example, a user can interact with a device that provides a digital assistant program. This device, via the digital assistant, can communicate with other devices to perform requests from the user, including controlling smart accessory devices such as light switches, speakers, and thermostats. However, controlling smart device functionality has continued challenges. A user may not have direct access to a user device with a digital assistant to provide the desired interaction. Accessory devices can have many different features and capabilities and are produced by various manufacturers. In a home environment, a user may want to interact with accessories by voice command in the same manner as they would interact with a user device with a device assistant. BRIEF SUMMARY [0005] Embodiments of the present disclosure can provide methods, systems, and computer-readable media for providing interaction management between accessory devices that receive audio user requests and user devices that process those requests. In some examples, a user device can be associated with one or more accessories and can implement separate instances of device assistant applications to manage user requests at the accessories. [0006] According to one embodiment, a method may be executed by a computer system within a home environment. The computer system can be a user device such as a smartphone, a tablet, a smart television (TV) media streaming device, a smart hub speaker, or the like. The user device may receive information identifying one or more accessories present within the home environment. The user device can use the information to form associations with the identified accessories. In forming the associations, the user device may implement an instance of one or more processes or other applications corresponding to the associated accessories. The instance can be a device assistant application or other processes for analyzing human speech or other audio signals. [0007] In some examples, the user device can receive an audio input from one or more of the associated accessory devices. The audio input can be audio data transmitted in a streaming fashion from the accessory to the user device. At least a portion of this audio input can correspond to an audio trigger or wake word. A first accessory interaction instance corresponding to the accessory transmitting the audio input can receive the audio and process it. In some embodiments, the processing may include transmitting some or all of the received audio input to a server computer or cloud service for robust language analysis. The server computer can parse and analyze the audio to determine whether the audio corresponds to an identified user within the home, whether it is a user request or command, in what language any spoken audio is presented, what a suitable response should be, and whether the user or the transmitting accessory device is authorized to make the identified request or receive the determined response. The first interaction instance can then receive the response and transmit it to the accessory device. [0008] In other embodiments, the accessory interaction instance can also execute another process or operation as part of the received response. This can include setting a timer, instructing another device to take some action (like turning off a light), or invoking a music streaming service to transmit audio to the accessory device. The accessory instance can also delegate the execution of the response to another device, including another accessory that may be more suitable for the response. [0009] In some embodiments, a user device may receive a second audio input from a second accessory device. Because each associated accessory has its own interaction instance at the user device, this second audio input can be processed contemporaneously with the first audio input. At least a portion of the second audio input can correspond to a trigger or wake word. The second accessory interaction instance can process this portion of the second audio input to determine if a wake word is present. The instance may also determine if the second accessory is authorized to interact with the instance. If the wake word is present and the second accessory is authorized, the second interaction instance can process the remainder of the second input audio in a manner similar to the processing of the first audio. [0010] To effect the interaction between the accessory devices and the user device, in some embodiments the accessory devices can each include a software development kit (“SDK”) within their memories. This software can be provided by an entity associated with the user device (e.g., the manufacturer) so that regardless of the manufacturer of the accessory devices, they can communicate with a particular user device. The accessory interaction instances can be configured to communicate with the SDK, which may include transmitting accessory settings from the accessories to the user device for management. The SDK may also provide additional features including wake word detection for the audio input received at the accessory devices. [0011] Embodiments of the present disclosure can provide methods, systems, and computer-readable media for providing load balancing management between accessory devices and hub devices. In some examples, a user device can act as a leader device to assign accessory devices to hub devices and provide information corresponding to the assignments. [0012] According to one embodiment, a method may be executed by a computer system within a home environment. The computer system can be a user device such as a smartphone, a tablet, a smart television (TV) media streaming device, a smart hub speaker, or the like. The user device may receive an assignment request from an accessory device present within the home environment. The user device can then select a hub device within the home environment to connect to the accessory device. The selection can be based on a determination of which hub device is the best hub device to connect to the accessory. [0013] In some embodiments, the user device can receive information from the accessory device identifying accessory traits that correspond to features or functionality of the accessory. The user device can also receive information from one or more hub devices within the home environment. The hub information can correspond to attributes of each hub, including each hub’s features and capabilities. The hub information can also include a number of accessory connection slots available at the hub devices. The user device may then score the hub devices by comparing the accessory traits with the hub attributes to obtain a score corresponding to the suitability of the hubs to connect with the accessory device. The score can then be multiplied by the number of available accessory slots at each hub to obtain a final connection score. The hub with the highest connection score can be assigned to the accessory. [0014] In another embodiment, a hub device can update its available connection slots due to changes at the hub device, including increased processing load at the hub device. The updated slots may result in a currently assigned accessory being dropped from the hub device. The dropped accessory can then request a new assignment from the leader device. [0015] In another embodiment, a user device acting as a leader device can receive information that it is no longer suitable to act as the leader device. This information can be a determination made by the user device based upon its own current attributes, including that the user device is experiencing a higher processing load and can no longer effectively manage hub devices. The user device can transmit a request to a server device to select another user device to act as the leader device. The server device can then select a second user device to be the leader device. The server device can then instruct the second user device to assume management control over the hub devices and accessory devices. The first user device can then transmit current hub information and accessory assignment information to the second user device. [0016] In some embodiments, a user device acting as a leader device can obtain information about the current processing capabilities of a first hub device. This information can indicate that the first hub device is not able to respond to an accessory assigned to the first hub device within a threshold amount of time. The user device can then obtain hub information from other hub devices and compare that hub information to the accessory traits of the accessory currently associated with the first hub device to obtain connection scores. The user device can then instruct the first hub device to drop the accessory device and instruct the highest scoring other hub device to connect to the accessory device. [0017] Embodiments of the present disclosure can provide methods, systems, and computer-readable media for providing communication between an accessory device and a cellular-capable device. In some examples, a controller device can receive a call request from the accessory device and select an appropriate cellular-capable device to make the call. The cellular-capable device can then establish an audio connection with the accessory device to relay the call audio to and from the accessory device. [0018] According to one embodiment, a method may be executed by a computer system within a home environment. The computer system can be a user device such as a smartphone, a tablet, a smart television (TV) media streaming device, a smart hub speaker, or the like. The user device may receive a call request from an accessory device present within the home environment. The user device can then select a cellular-capable device within the home environment to place the call and connect to the accessory device. The selection can be based on a determination of which cellular-capable devices are associated with the user making the call request. [0019] In some embodiments, one or more accessory devices can be associated with a user device. The user device may implement an instance of one or more processes or other applications corresponding to the associated accessories. The instance can be a device assistant application or other processes for analyzing human speech or other audio signals. The collection of processes in each instance may correspond to a software ecosystem on the user device. [0020] In another embodiment, when an accessory device participates in a call with a cellular-capable device, the user device can enter a call listening state. While in the call listening state, the instance corresponding to the accessory device can have speech processing capabilities limited to only detecting an end word. In other embodiments, an interaction instance corresponding to other accessories associated with the user device may not be limited while a first accessory device is participating in a call. The other instances may receive and process user requests from the other accessories as per the normal operation of the accessories and user device when a call is not in progress. BRIEF DESCRIPTION OF THE DRAWINGS [0021] FIG.1 is a simplified block diagram of an example method, according to some embodiments. [0022] FIG.2 is a schematic of a home environment containing user devices and accessory devices, according to some embodiments. [0023] FIG.3 is another simplified block diagram illustrating at least some methods of coordinating communications between user devices and accessory devices, according to some embodiments. [0024] FIG.4 is a block diagram illustrating at least some techniques for communication between an accessory device and a user device. [0025] FIG.5 is a flow diagram illustrating an example process for detecting and acting upon a user request by an accessory device and a user device, according to an embodiment. [0026] FIG.6 is a simplified block diagram illustrating example architecture of a system used to detect and act upon a user request, according to some embodiments. [0027] FIG.7 is another simplified block diagram illustrating an example of an accessory device receiving and processing multiple communications from user devices, according to some embodiments. [0028] FIG.8 is a flow diagram showing a process for an accessory device to determine which among a plurality of accessory devices will respond to a user request, according to some embodiments. [0029] FIG.9 is a flow diagram illustrating a process for a user device to coordinate interactions with a plurality of accessory devices, according to some embodiments. [0030] FIG.10 is a simplified block diagram of an example method, according to some embodiments. [0031] FIG.11 is a schematic of a home environment containing hub devices and accessory devices, according to some embodiments. [0032] FIG.12 is another simplified block diagram illustrating at least some methods of managing the associations between accessory devices and hub devices, according to some embodiments. [0033] FIG.13 is a simplified block diagram illustrating an example architecture of a system used to detect and act upon a user request, according to some embodiments. [0034] FIG.14 is a flow diagram illustrating an example process for assigning an accessory device to a selected hub device, according to an embodiment. [0035] FIG.15 is another flow diagram illustrating an example process for reassigning an accessory device from one hub device to another hub device, according to an embodiment. [0036] FIG.16 is another flow diagram illustrating an example process for reassigning an accessory device from one hub device to another hub device, according to an embodiment. [0037] FIG.17 is another flow diagram illustrating an example process for transferring hub management from one user device to another user device, according to an embodiment. [0038] FIG.18 is a flow diagram showing a process for a user device to assign an accessory device to a selected hub device, according to some embodiments. [0039] FIG.19 is a simplified block diagram of an example process, according to some embodiments. [0040] FIG.20 is a schematic of a home environment containing user devices and accessory devices, according to some embodiments. [0041] FIG.21 is another simplified block diagram illustrating at least some methods of establishing communications between an accessory device and a cellular-capable device, according to some embodiments. [0042] FIG.22 is a simplified block diagram illustrating at least some techniques for communication between an accessory device and a cellular-capable device. [0043] FIG.23 is another simplified block diagram illustrating an example architecture of a system used to establish communications between an accessory device and a cellular capable device according to an embodiment. [0044] FIG.24 is another flow diagram illustrating an example process for requesting a phone call at an accessory device and placing that phone call at a cellular-capable device, according to an embodiment. [0045] FIG.25 is another flow diagram illustrating an example process for requesting the termination of a phone call at an accessory device and ending the call at a cellular-capable device, according to an embodiment. [0046] FIG.26 is a flow diagram showing a process for a user device to establish a connection between an accessory device and cellular-capable device, according to some embodiments. DETAILED DESCRIPTION OF THE EMBODIMENTS [0047] In the following description, various examples will be described. For purposes 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 one skilled in the art that the examples may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the example being described. [0048] Embodiments of the present disclosure can provide techniques for coordinating interactions between a user device and a plurality of accessory devices. As a first example, consider a home environment corresponding to a home. A person within the home may want to know the current time. The person may query an accessory device (e.g., a nearby smart speaker) within the home environment with a verbal request (e.g., “What time is it?”). The accessory device can determine that the request was intended for the device and then transmit the received audio information to a user device (e.g., a hub speaker). The user device can process the audio information to determine the nature of the request and prepare a corresponding response (e.g., “It is 10:30 p.m.”). Alternatively, or partly in combination with the above, the user device may transmit some or all of the verbal request to a server computer (e.g., implementing a service provider), where the service provider can determine the nature of the request and/or prepare a corresponding response. The user device can then transmit the response back to the accessory device for playback to the user. In another example, the user may have a request that does not require a response (e.g., “Turn off the lamp.”). The user device can process the audio request to identify another device or devices corresponding to the request and transmit instructions to the other device to execute the request (e.g., instructing a device controlling the lamp to switch off). Similarly to the alternative noted above, the user device may transmit the request that does not require a response to a service provider, which can either transmit the instructions to the other device or return instructions for the other device back to the user device. In the latter case, the user device would then send the server-generated instructions to the other device. [0049] As an illustration of the examples above, the home environment can include numerous “smart” devices, e.g., electronic devices with features allowing them to operate, to some extent, interactively and autonomously. The smart devices can have various functionality, including cameras, speakers, thermostats, headphones and headsets, phones, or media players. The smart devices can also have various network communication capabilities, including WiFi, Ethernet, Bluetooth, Zigbee, cellular, and the like. The devices can be produced by various manufacturers. In some instances, the smart devices may be categorized into user devices and accessory devices. A user device can be a resident device of the home (e.g., a smart speaker, a smart digital media player configured to control a television (TV), a mobile phone, etc.). While not always, in some examples, a resident device may be expected to reside within the home and not move (e.g., within the home or to outside of the home) often. A user device can have capabilities equal to or exceeding the capabilities of an accessory device. For example, a user device can be a mobile phone, which can include wireless (e.g., WiFi) and cellular communications capabilities, multimedia capabilities, and a device assistant. In this same example, an accessory device can be a smart speaker, which can include audio media and wireless communications capabilities but lack a device assistant. A device assistant can be a virtual assistant program configured to interact with a user. In these examples, depending on its capabilities, a smart speaker can be either a user device or an accessory device. In some examples, if an accessory is manufactured by an entity different from the entity that manufactured the user devices, the accessory may not initially be configured to with the ability to communicate with the user devices. In some instances, the user device manufacturer may provide an accessory development kit (“ADK”) for installation on the accessory that enables such communication either after the accessory is manufactured, sold, provisioned, or used. [0050] In some embodiments, the user device can obtain information about the accessory devices present in the home environment. This information can be obtained by the user device communicating directly with accessory devices sharing the same network within the home environment. In other embodiments, information about accessory devices can be sent to the user device by a second user device, a user device configured as a leader device, or a remote server device (e.g., a service provider). For example, a user in the home may add a new accessory device to the home environment. As part of this process, the user can interact with a second user device (e.g., a mobile phone) to configure the new accessory device and send the new accessory device information to the first user device. As another example, a leader device in the home environment can have information about a plurality of accessory devices in the home environment and report information about some or all of the accessory devices to the user device. The user device can then use the information to form an association with the corresponding accessory devices. The accessory information may be stored by the user device. [0051] The user device can associate with a plurality of accessory devices by creating an accessory interaction instance for each accessory device. The interaction instances can be software modules or processes configured to perform tasks at the user device. In some embodiments, the interaction instances can each implement and/or communicate with a device assistant. For example, a user device can receive information about an accessory smart speaker and a smart thermostat located in the home environment. The user device can create two interaction instances corresponding to a device assistant, one for each of the smart speaker and the smart thermostat. The interaction instances can be duplicates of the device assistant in some embodiments, while in other embodiments the instances can be a collection of modules including the device assistant and other processes for carrying out tasks on the user device. The interaction instances can comprise different modules or processes depending on the associated accessory and its capabilities. It should be understood that any suitable combination of processes running on the user device can be included in an interaction instance corresponding to an accessory device. [0052] Continuing with the first example above, a user may voice a request to an accessory. For example, the user may speak into the microphone of a nearby smart speaker (or thermostat, light bulb, etc.), “Computer, what time is it?” In this example, the request (“what time is it?”) may correspond to a portion of the of the user’s audio input into the smart speaker. The opening phrase (“Computer”) may correspond to a second portion of the user’s audio input and can be a trigger or wake word. In some embodiments, the smart speaker may perform speech recognition processing on the wake word. Based on the processing, the smart speaker can determine if the user’s speech was intended to be a request or command to which the speaker should respond. The wake word processing at the accessory device can be at a first level sufficient to identify that a command or request may be contained within the user’s audio input. If so identified, the smart speaker can then transmit the user audio to a user device running an accessory interaction instance corresponding to the smart speaker. In some embodiments, the accessory device can store a copy of the audio input temporarily for transmission to the user device after processing the wake word portion. In other embodiments, upon processing the wake word portion of an audio input, the accessory device can establish a streaming audio connection with the user device to relay the portion of the user’s audio input that follows the wake word. In these embodiments, the accessory device can transmit a stored copy of the wake word portion of the audio input to the user device for additional processing. [0053] Upon receiving an audio input from the smart speaker, the user device can perform additional processing on both the wake word portion of the audio input and the portion corresponding to a request or command. For example, the user device can perform natural language processing (“NLP”) on the wake word. The wake word processing at the user device can be at a second level sufficient to determine to a higher degree of probability that the wake word is present than the wake word processing performed at the accessory (e.g., at the first level). Based on this wake word processing, the user device can then process the portion of the audio corresponding to the request. If the user device determines that the wake word portion was not, in fact, an accurate wake word, it can ignore the remaining portion of the audio or terminate the audio stream from the accessory. In some embodiments, the speech processing module on the user device can be part of the accessory interaction instance. The interaction instance can also transmit all or a portion of the audio input to another device for analysis (e.g., to a service provider device). This service provider device can be a remote server computer or cloud device that can perform speech processing and parse the request for an appropriate response. In some cases, the user device performs the processing of the wake word while the remaining portion of the audio is processed remotely. Parsing the request includes determining the content and context of the user’s spoken audio and providing a response for the user device to take action on. In the current example, the response would be an indication of the time, which can be determined and prepared by the user device using an appropriate process or by the remote server device, or combination of the two devices. [0054] Once a response has been determined, the user device can execute that response. This can include preparing an audio response to transmit back to the accessory device for playback to the user. The preparation and execution of the response can take place in the interaction instance corresponding to the accessory. A response that requires a particular action can be delegated as appropriate from the interaction instance to another process on the user device or to another device with which the user device can communicate. Any response audio can be generated by a text-to-speech process within the interaction instance and transmitted to the accessory. The accessory can then play the response. Some embodiments may provide for various pre-generated audio responses that correspond to frequently encountered requests that do not require unique responses. These responses can be stored at either the user device or the accessory device. For example, if an accessory device fails to connect to a user device to transmit user audio, it can provide an audio response stored at the accessory indicating that the request could not be processed. [0055] Expanding on the example just described, consider another scenario where a second user in the home also wants to make a request with the second accessory smart thermostat. That request might be, appropriately, “Computer, increase the temperature 3° F.” As before, the thermostat can process a portion of the user’s audio input to determine the presence of a wake word and, if detected, transmit the wake word and the request to the user device associated with the smart thermostat. Once received by the user device, an instance of a speech processing module and accessory interaction module, distinct from the interaction module associated with the earlier example smart speaker, can process the audio. In this way the user device can process and execute requests from multiple accessories simultaneously. The accessory interaction instance corresponding to the smart thermostat can include a thermostat management module configured to manage the ambient environment (e.g., heating or air conditioning) of a home environment. Upon processing the user request, the thermostat management module can execute the request and instruct the smart thermostat to increase its temperature setting by 3° F. In other embodiments, the thermostat management module can exist as a single instance on the user device. The accessory interaction instance corresponding to the smart thermostat can then delegate its execution of the request to that single management module, as may be desired in a system containing multiple smart thermostat accessories but a need for a unified management of the ambient environment on a user device. In several embodiments, the architecture of the accessory interaction instances and other software modules on the user device can be configured in any suitable way to improve the efficiency of request processing and execution by the interaction instances on the user device. This can include various combinations of modules and process that relate to the features and capabilities of the accessory devices and the user device. [0056] FIG.1 is a simplified block diagram 101 of an example embodiment. The process 100 is an example high-level process flow for a system that includes a user device 110 that can associate with various accessory devices 111 to receive a user request from an accessory. The diagram 101 shows states of the system that correspond to the blocks of the process 100. The process 100 can be performed within a home environment containing multiple user devices 110 and accessories. As described herein, the user device 110 can be a hub speaker while the accessory devices 111 can be a smart thermostat 112, a camera 114, or a smart speaker 116. Although described as being a particular device, it should be apparent that the accessory devices 111 can be several types of smart devices in various combinations and number. Similarly, although a hub speaker is depicted as the user device 110 performing the process 100, other suitable devices can perform one or more of the operations in the process 100. For example, a smartphone, media device (e.g., a smart TV), or tablet (either connected to a cellular network, to a local area network via WiFi of a home network, or to a wide area network (“WAN”) can perform one or more of the operations of the process 100. [0057] Turning to the process 100 in more detail, at block 102 the user device 110 can create one or more accessory interaction instances corresponding to one or more associated accessory devices 111. Each accessory interaction instance represents one or more software modules or processes running on the user device 110 to enable the interaction of the accessory devices 111 with the user device 110. As shown in FIG.1, accessory interaction instance 122 can correspond to a smart thermostat 112, accessory interaction instance 124 can correspond to a camera 114, and accessory interaction instance 126 can correspond to a smart speaker 116. [0058] At block 104, an accessory device, illustrated as the smart speaker 116, receives an audio input 120. In some embodiments, the audio input 120 can contain a portion of audio corresponding to a user request or command (e.g., “what time is it”) and a second portion corresponding to a wake word (e.g., “Computer”). The wake word need not be a single word and can be a word or phrase that signals to the system that the user has or is about to voice a request, command, or other audible interaction to the system. The audio input can also be other sounds not uttered by a user, including glass breaking or a baby crying. In these cases the wake word, as described herein, can be a trigger sound corresponding to a portion of the audio input 120. In other embodiments, the portions of the audio input 120 corresponding to the wake word and the user request can be received by the accessory 116 separated by a period of time. This period of time can be sufficient to allow the user to voice the wake word and receive a confirmatory response from the accessory 116 before voicing the user request. Upon receiving input containing a wake word, the accessory 116 can process that portion of the audio input 120 at a first level to determine the presence of the wake word. The first level processing can be done in a time and resource efficient manner that determines that the wake word may be present. For example, the accessory can perform voice pattern matching using stored voice patterns corresponding to users speaking the wake word. The stored patterns can be associated with the users in a home environment containing the system or can be generic patterns that are applicable to a large number of possible users. In this way, the accessory device 116 is not burdened with sophisticated speech detection processes but also does not respond to every extraneous audio input received by users or other sources in its vicinity. [0059] Moving down to block 106, upon detecting the wake word, the accessory device 116 can transmit the received audio input 120 to the user device 110 where it will be processed. As illustrated, the smart speaker 116 has a corresponding accessory interaction instance 126 on the user device 110, such that the accessory interaction instance 126 manages the processing of the audio input 120 received from the smart speaker 116. As described in more detail below with reference to FIG.4, the accessory interaction instance 126 can contain modules configured to process the audio input 120. For example, accessory interaction instance 126 can include a speech detection module that can analyze the portion of the audio input 120 that corresponds to the wake word. This analysis can be at a second level that can confirm the presence of the wake word to a higher degree of probability than the wake word detection at the smart speaker 116. In addition, in some embodiments, the speech detection module can determine a user’s language and perform the wake word detection based on the determined language. If the speech detection module of the accessory interaction instance 126 does not detect the wake word, the user device 110 can ignore the audio input. [0060] The accessory interaction instance 126 can also contain modules configured to communicate with remote services 130. The remote services 130 can be provided by a remote server associated with the home environment of the user device 110 over a WAN or other network and can be, in some embodiments, a cloud server. The remote services can include NLP or other speech analysis services. If the accessory interaction instance 126 does detect the wake word, it can then process the portion of the audio input 120 corresponding to a user request by transmitting that portion to the remote services 130. The remote services 130 can analyze the request to determine the type of request, the appropriate response, and one or more devices to execute the response. In some embodiments, the remote services 130 can also determine an identity of the user making a request. This identity can be determined from user profile information accessed by the remote service 130. User profile information can be stored at the user device and transmitted to the remote services 130 as a part of the accessory interaction instance’s 126 processing of the audio input 120. In some cases, the user profile information is stored on a remote device accessible by the remote services 130 or on the remote server providing the remote services 130. Once the request portion has been analyzed by the remote services 130, a response can be transmitted back to the user device 110 for execution. Upon receiving the response, the accessory interaction instance 126 can then execute the response. Execution of the response can include delegating one or more elements of the response to other processes on the user device or another device, including other user or accessory devices in the home environment or a remote device. Following the example illustrated in diagram 101, execution can include determining the current time and preparing an audio response to be played for the user. The accessory interaction instance 126 can delegate a request to a process on the user device 110 to provide the current time to the accessory interaction instance 126. The accessory interaction instance 126 can comprise a text to speech module that can convert the current time information received to an audio response. [0061] Moving to block 108, the user device 110 can transmit the response to the accessory device 116. For responses that require an audio response 140 to the user, the accessory interaction instance 126 on the user device 110 can communicate with the smart speaker 116 and transmit the audio. As illustrated in diagram 101, the audio response 140 is the reply “10:30 p.m.,” corresponding to the current time as requested by the user. Other responses can include indications that the user request was performed by another device or that the request could not be performed. In some embodiments, the accessory device 116 may not have the capability to play an audio response (e.g., it does not have a speaker output) but contains a visual user interface (e.g., a screen) or other means (e.g., lights) to indicate a response to the user. [0062] FIG.2 illustrates a home environment 200 containing user devices and accessory devices, according to some embodiments. User devices can include a hub speaker 202, a media player 204, and a smartphone 206. These user devices can correspond to user device 110 from the embodiments described above with respect to FIG.1. Accessory devices can include smart speakers 212, 214, a smartwatch 216, and a thermostat 224. Similarly, these accessory devices can correspond to accessory devices 111 described with respect to FIG.1. All or some of these accessory devices may be third-party devices (e.g., not manufactured, programmed, or provisioned by the manufacturer, programmer, or provisioner of the user devices). Because of this, they may not be automatically and/or initially compatible with the user devices. Each user device in the home environment 200 can be associated with zero, one, or more accessory devices. As illustrated by the long-dashed lines, hub speaker 202 is associated with smart speakers 212, 214 and smartwatch 216 while media player 204 is associated with thermostat 224. The smartphone 206 is not associated with an accessory device. The devices within the home environment 200 can be configured to communicate using one or more network protocols over one or more networks associated with the home environment 200. For example, the home environment 200 can be associated with a local area network (“LAN”), a WAN, a cellular network, or other network, and the devices can communicate using a WiFi connection, a Bluetooth connection, a Thread connection, a Zigbee connection, or other communication method. [0063] The arrangement of associations of accessory devices with user devices can include various different combinations and can be modified by the user devices. For example, the smartphone 206 may receive information about accessory devices to be associated with the smartphone. The accessory devices can include one or more of the accessory devices currently associated with other user devices in the home and can include new accessory devices added to the home. The smartphone 206 would then create accessory interaction instances for each accessory association. In some embodiments, a user device in the home environment 200 can communicate with another user device to transfer one or more accessory devices associated with the first user device to the second user device. This transfer can occur automatically based on information that the user device receives about the home environment 200, including, but not limited to, information that another user device may be more suitable for association with one or more accessories or that accessories have been added to or removed from the home environment 200. The suitability of any particular user device to associate with an accessory can be based at least in part on the capabilities of the user device, the capabilities of the accessory device, the current processing load experienced by the user device, the locations of the devices within the home environment, and the status of communications between the devices on a network. Many other criteria for rearranging device associations in a home environment are contemplated. [0064] In some embodiments, accessory devices and non-resident user devices may also leave the home environment or lose network connectivity with the home environment. An accessory device that leaves the home environment can be disassociated by the previously associated user device, such that the user device removes the corresponding accessory interaction instance from its memory. Accessory devices associated with a user device that loses network connectivity with the home environment can be reassigned by another user device that retains network connectivity. Some embodiments may have a user device designated as a leader device to manage the assignment of accessory devices among the user devices within the home environment. In other embodiments, if user devices and accessory devices are associated and leave the home environment and lose network connectivity, the user devices can retain their associations with the accessory devices and perform the embodied methods described herein. [0065] Returning to FIG.2, as an example of the foregoing description of some embodiments, the hub speaker can communicate with the smartphone 206 to transfer the association with smartwatch 216. The user 230 wearing the smartwatch 216 may collect the smartphone 206 and move into a different room in the home environment, making the smartphone 206 a more suitable user device to associate with the smartwatch 216. User 230 may then leave the home environment 200 with the smartphone 206 and smartwatch 216. The smartphone 206 can retain its association with the smartwatch 216 as its accessory device even if the smartwatch 216 loses network connectivity to the other devices in the home environment. Moreover, user 230 could take an additional accessory device outside the home environment and that accessory can also be associated with the smartphone 206 such that the smartphone 206 is associated with two accessory devices while outside the home environment 200. As another example, media player 204 may begin processing and playing a media file and become unsuitable to be associated with thermostat 224 due to load. The media player 204 can transfer the association of its accessory thermostat 224 to smartphone 206 or hub speaker 202. [0066] Continuing with FIG.2, a home environment 200 can have multiple users 230, 234 making multiple audio requests 232, 236 of accessories. The requests 232, 236 correspond to the audio input 120 described above with reference to FIG.1. The requests 232, 236 can occur separately or simultaneously and can be received by multiple accessory devices as depicted by the short-dashed lines. For example, request 232 can be received by smart speaker 214 or smartwatch 216, while request 236 can be received by smart speaker 212 and thermostat 224. As described previously, the arrangement of accessory devices and their associations can take various forms and can change over time. Thus, a user request may be received by multiple accessory devices associated with different user devices. For example, user request 236 is received by both thermostat 224 associated with media player 204 and by smart speaker 212 associated with hub speaker 202. [0067] In some embodiments, accessory devices can coordinate with other accessory devices within the home environment 200 to determine which accessory device should respond to a user request that is received by one or more accessory devices. As described in more detail below with reference to FIG.8, the selection of an accessory device to respond to an audio input can occur through an election process among the accessory devices. The election can use a score based upon criteria including, but not limited to, strength (e.g., loudness) of the received audio input at the accessory device, quality of the received audio input, the capabilities of the accessory device, and the capabilities of a user device associated with the accessory device. As an example, smart speaker 212 and thermostat 224 both receive user request 236. Upon receiving the request, both accessories can process the portion of the user request corresponding to a wake word and transmit the audio to their respective user devices, hub speaker 202 and media player 204. The accessory interaction instances associated with the respective accessories on the user devices can process the wake word received and determine a score for the accessories. The user devices can transmit the score back to the accessories prior to further processing the user request 236. The accessories can then open a communication channel between themselves and exchange scores. Each accessory compares its score to the other scores to determine a winner. The winning accessory can report to its user device that it has won. Similarly, losing accessories can report to their user devices that they have lost and will not respond to the user request. In the present example, because user 234 is in the same room as thermostat 224, it may be the case that the thermostat heard the user request 236 more loudly and clearly than smart speaker 212 in another room. Thus, the accessory election could result in the thermostat 224 being the winning accessory. Conversely, smart speaker 212 or hub speaker 202 may have capabilities that are more suitable to responding to the user request, as in the case where the request requires an audio response and the thermostat 224 does not have an audio output capability. In this scenario, the score determined for smart speaker 212 can be higher to reflect the greater capabilities and result in the smart speaker 212 winning the election. One skilled in the art would recognize a great number of potential scoring criteria for the accessory devices. [0068] FIG.3 illustrates an example coordination process 300 for associating one or more user devices 302 with one or more accessories 304. In some embodiments, the user devices 302 can correspond to user devices described herein (e.g., user device 110 of FIG.1, user devices 202, 204, and 206 of FIG. 2, etc.). Configuration device 306, depicted here to be a smartphone, can be a user device among the user devices 302, a hub device, a leader device, or other devices used to configure the device associations. The configuration device 306 can be configured to communicate with the user devices 302 and accessories 304 over one or more networks described herein, including a LAN or a WAN. In some embodiments, the configuration device 306 is a remote server device configured to communicate with the user devices 302 and accessories 304 over a WAN, e.g., the Internet. [0069] Multiple elements of the coordination process 300 are presented in more detail. The configuration device 306 can comprise an accessory configuration module 310. The accessory configuration module 310 can be a software process running on the configuration device 306. The accessory configuration module 310 can be configured to store, update, receive, and transmit information related to the association of accessories 304 and user devices 302. That information can include accessory management settings 312 and accessory settings 314. The accessory management settings 312 can comprise information identifying which accessories 304 are assigned to any particular device among the user devices 302. The accessory configuration module 310 can also include accessory settings 314 that can provide association information about an assigned user device for each accessory. [0070] Each of the user devices 302 can comprise an accessory management module 320, which can be a software process running on the user device 302. The accessory management module 320 can, in some embodiments, receive, process, store, update, and transmit accessory management settings 322. The accessory management settings 322 correspond to the information in the accessory management settings 312 associated with the particular user device 302. For a particular user device, its accessory management settings 322 can include a list of all accessories assigned to that user device and other information related to the capabilities of those assigned accessories. The accessory management module 320 can also comprise accessory interaction instance(s) 324, which can correspond to the accessory interaction instances 122, 124, and 126 of FIG.1. The accessory interaction instance(s) 324 can be created by the user device 302 based upon the accessory management settings 322 it receives from the configuration device 306. In this way, the configuration device 306 can update the associations of accessories 304 with user devices 302 by sending each user device an updated accessory management settings 322 based on an updated accessory management settings 312. The accessory management module 320 on each user device can then create or remove accessory interaction instance(s) 324 as necessary so that it has accessory interaction instance(s) 324 corresponding to its currently associated accessories. [0071] Each accessory can also store accessory settings 334. The accessory settings 334 can comprise information identifying the user device to which the accessory is currently associated. The accessory settings 334 can also include information pertaining to the processing of a trigger or wake word at the accessory. For example, a user may change the wake word that they want to activate (e.g., “wake”) the device, which may differ from a generic wake word and be identifiable with that particular user. The configuration device 306 can transmit corresponding information about the custom wake word (e.g., audio patterns of the wake word for comparing to received audio input) to the accessory devices 304. The accessory settings 334 can be configured to include information about multiple wake word or trigger configurations corresponding to different wake words or triggers that can be detected at the accessory devices 304. [0072] Completing the detailed elements of FIG.3, process indicators 330, 340 represent data transmission between the configuration device 306 and the user devices 302 and the user devices 302 and the accessories 304, respectively. The process indicators 330, 340 can indicate communication over one or more networks between the various devices as described herein, including, but not limited to, a WiFi LAN, or an Internet WAN. Process indicator 330 indicates transmission of data within the accessory management settings 312 and the accessory settings 314 to the user devices 302. Correspondingly, the user devices 302 can transmit data within their accessory management settings 322 or other data to the configuration device 306. This data can identify that one or more accessories is no longer in communication with its assigned user device. Similarly, process indicator 340 indicates transmission of data including accessory settings 334 between the user devices 302 and the accessories 304. In some embodiments, the configuration device 306 can also communicate directly with the accessories to transmit accessory settings 314 and receive information in return. [0073] As a specific example of the foregoing description of several embodiments, consider the scenario where a new accessory device is introduced into a home environment. The home environment can correspond to the home environment 200 of FIG.2. Initially, none of the devices in the home environment have any information pertaining to the new accessory, and no user devices are associated with it. The configuration device 306 can be a user’s smartphone and can obtain information about the new accessory. This information can be obtained through user input, for example, through an application running on the smartphone to configure and provision devices within a home environment. The information can also include identification of the new accessory from list of recognized accessories that can be added to a home environment, or through communication with the new accessory by the smartphone over one of the networks in the home environment. The smartphone can then communicate with user devices 302 within the home environment to receive information about the user devices 302 and the current accessories 304 that they are associated with. Once the smartphone has appropriate information about the new accessory and the existing devices, it can update the accessory management settings 312 and accessory settings 314 in its accessory configuration module 310 and then assign the new accessory to one of the user devices 302. The assignment can include transmitting data corresponding to the accessory management settings 322 to the selected user device and transmitting data corresponding to the accessory settings 334 to the new accessory. [0074] In a corresponding specific example, an accessory may be removed from the home environment. This can occur if the accessory is a non-resident device and is capable of leaving the home environment (e.g., a smartwatch) or if the accessory has lost network communication with its assigned user device. In this instance, the user device can transmit updated accessory management settings 322 to the configuration device 306, which can in turn update its accessory management settings 312 and accessory settings 314 and transmit updated information back to the user device. Updating the accessory management settings 312 can include reconfiguring the arrangement of accessories 304 still present in the home environment with the user devices 302. Similar updates can occur if a user device is removed (e.g., if it is a non-resident device like a smartphone or has lost network connectivity). Accessories previously associated with the removed user device can communicate with the configuration device 306 and report updated accessory settings 334, including the inability to communicate with the assigned user device. The configuration device 306 can then select a new user device for association with the accessory and transmit updated accessory management settings 322 and accessory settings 334 to the respective devices. [0075] It should be understood that various scenarios described in reference to process 300 are representative. One or more aspects of each scenario may be changed, and still perform embodiments as described herein, including, but not limited to, the number and type of accessories, the number and type of user devices, the type of network over which the configuration device communicates with the other devices, and the manner in which the configuration device obtains information about a new accessory device. [0076] FIG.4 is a block diagram 400 illustrating at least some techniques for communication between an accessory device 401 and a user device 402 to process an audio input to create a response. The diagram 400 includes some detailed architecture of representative devices as well as process flow arrows providing a general indication of the transfer of data or information. The process flow arrows are not intended to connote any specific architectural connections between the elements detailed herein. Each of the elements depicted in FIG.4 may be similar to one or more elements depicted in other figures described herein. For example, the accessory device 401 may correspond to one or more of the accessories and accessory devices described herein, and so forth. In some embodiments, at least some of the elements in diagram 400 may operate within the context of a home environment like the home environment 200 of FIG.2. [0077] Turning to each element in further detail, accessory device 401 can have audio input and output functionality, including an accessory microphone input 404 and an accessory speaker output 406. The accessory microphone input 404 can include both hardware and software/firmware necessary to provide audio input functionality. Similarly, the accessory speaker output 406 can include both hardware and software to provide its functionality. The accessory device 401 also has an accessory audio module 412 that can interface with one or both of the accessory microphone input 404 and the accessory speaker output 406, as well as receive audio from other devices. The accessory device 401 also comprises an accessory development kit (“ADK”) 408. The ADK can be an SDK stored and configured to be executed or processed on the accessory device 401. As used herein, an SDK can include application programming interfaces and related software libraries sufficient to enable the operation of other software within or associated with the SDK. In some embodiments, the ADK can be provided by an entity associated with the user device 402 (e.g., its manufacturer). The ADK 408 can include a wake word detection module 410 that performs a first processing of a portion of an audio input corresponding to a trigger or wake word. The wake word detection module 410 can itself contain information about wake words and triggers, including, for example, triggering criteria and audio patterns corresponding to specific wake words. As shown by the process flow arrows, the accessory device 401 can receive an audio input at its microphone 404 and then process a portion of that audio in a wake word detection module 410. This processing can be done at a first level to determine the presence of the wake word. The first level processing can be done in a time and resource efficient manner that determines that the wake word may be present. If the wake word is detected, the received audio input can be transmitted to the user device 402. In some embodiments, this transmission involves establishing a streaming audio connection from the accessory device 401 to the user device 402. [0078] The user device 402 can include a management module 414, which can correspond to the accessory management module 320 of FIG.3. The management module 414 can provide one or more audio input relays 416, each associated with an accessory device. In this way the user device 402 can manage multiple inbound audio inputs received from multiple accessory devices, including multiple simultaneous streaming audio connections. The audio input relay 416 can send the received audio input to a speech processing module 420, where it is received by an accessory input plugin 422. In some embodiments, the speech processing module 420 does not have a running instance for each accessory device associated with the user device. In these cases, the speech processing module can have separate, per-accessory instances of the accessory input plugin and wake word detection module 424. [0079] As described above with respect to FIG.1, the user device can process audio received from the accessory device. This can include the processing of a portion of the received audio to detect the presence of a wake word. The speech processing module 420 can include multiple instances of the wake word detection module 424, including, in some embodiments, a wake word detection module 426 configured to process an audio input received directly by the user device. The wake word detection module 424 can process the wake word audio at a second level that can confirm the presence of the wake word to a higher degree of probability than the wake word detection module 410 at the accessory device 401. If the speech processing module 420 does not detect the wake word, the user device 402 can ignore the audio input. If the wake word is detected, then the audio input can be further processed at the accessory interaction instances 430. [0080] The accessory interaction instances 430 can comprise a virtual device assistant and include other processes such as server interaction module 432, delegation process 434, and text to speech module 436. To process the audio from a user request or other audio input that passes the wake word detection module 424, the accessory interaction instances 430 can connect to remote service(s) 450 and transmit a portion of the audio input to the remote service(s) 450. Each accessory interaction instance associated with an accessory can connect to the remote service(s) 450 separately through the server interaction module 432 corresponding to that accessory interaction instance. The remote service(s) 450 can be hosted on a remote server or other remote device and can be reached through one of the networks with which the user device can connect (e.g., the Internet WAN). NLP and other services used to process the audio input can comprise the remote service(s) 450. In addition, the remote service(s) can also include information related to user profiles, user languages, and user authorizations with regard to voice interaction between users and accessories and user devices within the home environment. In some embodiments, some components of user information or user profiles can be stored locally on the user device, and are accessible to the accessory interaction instances 430 via one of the local service(s) 452. As such, the remote service(s) can identify a user making the user request, process the audio input in a language that corresponds to the identified user, and determine whether the user is authorized to have that request executed by one or more devices. Since each accessory interaction instance 430 can interact separately and individually with the remote service(s) 450, multiple user requests can be processed and executed simultaneously or nearly simultaneously by a single user device 402. [0081] Once a request has been processed, the accessory interaction instances 430 can receive a response from the remote service(s) 450 to execute. The response can contain data corresponding to an audio message to be played for the requesting user at the accessory device 401. An audio response can be generated by the text to speech module 436. In some embodiments, the response received may require that the accessory interaction instances 430 communicate with local service(s) 452 to receive additional information to complete the request. For example, if the request asked for the current time, the accessory interaction instances 430 could obtain the current time from a clock process or other service located elsewhere on the user device 402. In other embodiments, the response can require execution by another device, or an action with no further output expected of the user device 402 or the accessory device 401. In those cases, the accessory interaction instances 430 can delegate the response to the local service(s) 452 via the delegation process 434. The local service(s) 452 can include communication process for transmitting response instructions to other user devices for execution on those user devices or accessories associated with them. The local service(s) 452 can also include a music service. A user request can include a response to play music or other audio content at the accessory. The music service can then communicate with a media module 470 to transmit music or other audio to the accessory device 401 as described below. In still other embodiments, the response can include a delay, such that the delegation to the local service(s) 452 is temporary. For example, the request could be to set a timer, which can be delegated to a local timer process. The accessory interaction instance that delegated the response can then be free to handle additional request processing from its associated accessory until the delegation process 434 receives an indication that the timer process has completed, at which point the accessory interaction instance would finish executing the timer response by sending the appropriate indicator to the accessory. [0082] Continuing with the detailed elements of the user device 402, an audio response can be sent to the accessory device 401 via a media module 470 that comprises an accessory audio relay 472. The accessory audio relay can negotiate an audio connection with the accessory device 401. The audio connection can be over one of the networks to which the user device 402 and accessory device 401 are connected and can use any number of methods or protocols, including, but not limited to AirPlay, Real-time Transport Protocol (“RTP”), Real Time Streaming Protocol (“RTSP”), or the like. In some embodiments, the response is a phrase or sentence converted to audible speech to be played at the accessory device 401. In other embodiments, the response can be an audio stream of music or similar media to be played at the accessory device 401. In still other embodiments, the response can be an indication to the accessory device 401 to play a piece of audio stored locally at the accessory device 401, for example, a notification chime particular to that accessory. [0083] Depending on its capabilities, the accessory device 401 may not be configured to store received audio responses, which can be due to space limitations, the streaming nature of the audio responses, or other reasons. As described in more detail with respect to FIG.7, below, the accessory interaction instances 430 can provide, as part of a response to a user request, instructions to the accessory device 401 for handling received audio in the event that the accessory device 401 receives multiple input audio responses or other audio inputs simultaneously or nearly simultaneously. The instructions can include rules for ducking or muting portions of the output audio in favor of other portions of the audio or providing other rules for mixing or balancing of levels of the output audio generated from the received audio responses. For example, a user may request at the accessory device 401 a timer and then later request that the accessory play a music stream. When the timer goes off, the accessory interaction instance on the user device 402 can send, with the response corresponding to the timer alert, instructions for the accessory device 401 to duck the streaming audio at the output so that the timer alert can be heard over the music. [0084] Returning to the depiction in FIG.4, in some embodiments the audio input relay 416, the accessory input plugin 422, the wake word detection module 424, and the accessory audio relay 472 represent multiple instances of the same or similar processes or modules running on the user device 402. The instances of these elements correspond to the associated accessory devices in the same manner as the accessory interaction instances 430 correspond to the associated devices. Depending on the software architecture, the accessory interaction instances as described herein can also encompass one or more of these instanced elements such that accessory interaction instances 430 comprise one or more audio input relay 416, accessory input plugin 422, wake word detection module 424, and accessory audio relay 472. Multiple ways to render the device architecture to provide per-accessory instances of various processes are contemplated. [0085] Continuing with FIG.4, the user device 402 can have its own microphone and speaker input and output functionality, represented by microphone input 474 and speaker output 476 within media module 470. In several embodiments, the user device 402 is capable of receiving an audio input and processing the audio directly by way of a wake word detection module 426 and a device interaction instance 440 that can comprise a digital virtual assistant and server interaction module 442, delegation process 444, and text to speech module 446. Other embodiments feature a user device that cannot directly receive an audio input but can still process audio data transmitted from an accessory device to accessory interaction instances. For example, a media player user device (e.g., a television media player) may not have a microphone input and thus cannot “hear” any user audio input. The media player can still be associated with one or more accessory devices and comprise one or more corresponding accessory interaction instances. The processing of a user request directly by the user device 402 proceeds similarly to the processing of audio received by an accessory device. Because the device interaction instance 440 and accessory interaction instances 430 are separate, a user device 402 can process a user request received from an accessory contemporaneously with a second user request received directly by the user device 402. [0086] FIG.5 is a flow diagram illustrating a particular example process 500 for detecting and acting upon a user request by an accessory device and a user device. Each of the elements and operations depicted in FIG.5 may be similar to one or more elements depicted in other figures described herein. For example, the user device 502 may be similar to other user devices, and so forth. In some embodiments, process 500 may be performed within a home environment (e.g. the home environment 200 of FIG.2). Process 500, as well as processes 800 and 900 of FIGs.8 and 9 (described below) are illustrated as logical flow diagrams, each operation of which represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer- readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. 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 processes. [0087] Additionally, some, any, or all of the processes may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium is non-transitory. [0088] At block 504, an accessory device 501 may receive a user utterance 503. The user utterance can correspond to the audio input 120 of FIG.1. The user utterance 503 can comprise a portion corresponding to a trigger or wake word (e.g., “Computer”) and a portion corresponding to a user request (e.g., “what time is it?”). [0089] At block 506, the accessory device 501 can process the portion of the user utterance 503 corresponding to the wake word in a first pass to determine the presence of the wake word. The first pass processing can be done in a time and resource efficient manner that determines that the wake word may be present. At decision 508, based upon the first pass processing, the accessory device 501 determines if the wake word is present. If not, then the process can terminate at endpoint 510 by ignoring the user utterance. If the wake word is present according to the first pass processing, then the process continues to block 512. [0090] At block 512, the accessory device 501 can establish a streaming audio connection with user device 502. This connection can occur over one of the networks to which the accessory device 501 and user device 502 are connected, for example over a WiFi LAN. The streaming audio can use any number of methods or protocols, including, but not limited to AirPlay, Real-time Transport Protocol (“RTP”), Real Time Streaming Protocol (RTSP), or the like. The user utterance 503 is then transmitted to the user device 502 over the streaming audio. In some embodiments, the portions of the user utterance 503 corresponding to the wake word and the user request can be received by the accessory device 501 separated by a period of time. Due to the first pass processing of the wake word portion, that portion may be sent to the user device 502 separately over a buffered audio connection via the WiFi LAN using Transport Control Protocol (“TCP”) or other suitable method of sending recorded audio data. [0091] At block 514, the user device 502 receives the user utterance 503 and any other streaming audio that is transmitted from the accessory device, which can include portions of a longer user request that are transmitted after the accessory device processes the wake word and opens the streaming audio connection. At block 516, the user device 502 can process the wake word for a second pass. This processing can be at a second level that can confirm the presence of the wake word to a higher degree of probability than the first pass processing at block 506 at the accessory device 501. At decision 518, if the user device 502 does not confirm the presence of the wake word, the process moves to block 520 and terminates the streaming audio connection. The process then moves to endpoint 522 and ignores the user utterance. If the user device 502 does confirm the presence of the wake word, then the process moves to block 524 and begins processing the other portions of the user utterance received from the streaming audio connection or that were transmitted with the wake word portion. [0092] Block 524 can comprise additional blocks 526–534. These blocks represent parts of the process related to processing of speech by the user device 502 or a remote server in communication with the user device 502. The blocks 526–534 are not necessarily arranged in a particular implied order, and processing the audio may require performing one, some, or all of the blocks. At block 526, the user device 502 can connect to remote services located at a remote server. The speech processing can include NLP or other speech analysis services provided as part of the remote services. In block 528, the user device or, in some embodiments, one or more of the remote services can determine the identity of the user who made the user utterance 503. This identification can be based upon user information or user profile data stored at the user device 502 or at a remote device to which the remote services have access. Similarly, at block 530, the user device or the remote services can determine a language for the user utterance. This determination can be based upon the user information associated with block 528 or from the NLP analysis or similar analysis. At block 532, as a result of the NLP or other speech processing analysis, the user’s request is determined. This step includes parsing the request to determine the appropriate response and which device or devices should execute that response. In some embodiments, at block 534, the process can determine whether the identified user is authorized to make the request contained in the user utterance 503. For example, the user may not have authorization to access a streaming music service that the user device 502 could access and transmit to the accessory device. In this case, the response to the request could be playing a message to the user indicating their lack of appropriate authorization. Other authorization can encompass device level authorization. For example, the process at block 534 can determine that an accessory device is not authorized to interact with an associated accessory interaction instance, to request a specific response, or to be delegated a specific response to execute. Still other authorization can encompass higher level functions, like a user not having authorization to make specific types of voice requests of one or more devices within the home environment or being able to make any voice requests at all. [0093] With the audio processed and a response determined, the process 500 moves to decision 536. Depending on the nature of the request, part or all of the response can require playing an audio response to the user at the accessory device 501. If the request requires an audio response, the process moves to block 538 and the user device can synthesize an audio message for the user. This synthesis can occur by way of a text to speech module on the user device 502. It can also include selecting from among a number of previously prepared responses that correspond to commonly made requests or situations to which the user device 502 can respond. At block 540, the prepared response is transmitted to the accessory device 501, which plays that response at endpoint 542. [0094] At endpoint 544, the user device executes the request according to the response determined from the audio processing. Execution of the response can include delegating one or more elements of the response to other processes on the user device or another device, including other user or accessory devices in the home environment or a remote device. Some examples include delegating to a music streaming process or voice communication service which can then connect the user device 502 to the accessory device and transmit streaming music or voice communications to the accessory device 501. [0095] FIG.6 is a simplified block diagram 600 illustrating an example architecture of a system used to detect and act upon a user request, according to some embodiments. The diagram includes a representative user device 602, one or more accessory devices 604, a representative accessory device 606, one or more network(s) 608, and a server device. Each of these elements depicted in FIG.6 may be similar to one or more elements depicted in other figures described herein. In some embodiments, at least some elements of diagram 600 may operate within the context of a home environment (e.g. the home environment 200 of FIG.2). [0096] The accessory devices 604 and representative accessory device 606 may be any suitable computing device (e.g., smart speaker, smartwatch, smart thermostat, camera, etc.). In some embodiments, an accessory device may perform any one or more of the operations of accessory devices described herein. Depending on the type of accessory device and/or location of the accessory device (e.g., within the home environment or outside the home environment), the accessory device may be enabled to communicate using one or more network protocols (e.g., a Bluetooth connection, a Thread connection, a Zigbee connection, a WiFi connection, etc.) and network paths over the network(s) 608 (e.g., including a LAN or WAN), described further herein. [0097] In some embodiments, the server device 610 may be a computer system that comprises at least one memory, one or more processing units (or processor(s)), a storage unit, a communication device, and an I/O device. In some embodiments, the server device 610 may perform any one or more of the operations of server devices described herein. In some embodiments, these elements may be implemented similarly (or differently) than as described in reference to similar elements of user device 602. [0098] In some embodiments, the representative user device 602 may correspond to any one or more of the user devices described herein. For example, the user device 602 may correspond to one or more of the user devices of the home environment 200 of FIG.2. The representative user device may be any suitable computing device (e.g., a mobile phone, tablet, a smart hub speaker device, a smart media player communicatively connected to a TV, etc.). [0099] In some embodiments the one or more network(s) 608 may include an Internet WAN and a LAN. As described herein, the home environment may be associated with the LAN, whereby devices present within the home environment may communicate with each other over the LAN. As described herein, the WAN may be external from the home environment. For example, a router associated with the LAN (and thus, the home environment) may enable traffic from the LAN to be transmitted to the WAN, and vice versa. In some embodiments, the server device 610 may be external to the home environment, and thus, communicate with other devices over the WAN. [0100] As described herein, user device 602 may be representative of one or more user devices connected to one or more of the network(s) 608. The user device 602 has at least one memory 612, a communications interface 614, one or more processing units (or processor(s)) 616, a storage unit 618, and one or more input/output (I/O) device(s) 620. [0101] Turning to each element of user device 602 in further detail, the processor(s) 616 may be implemented as appropriate in hardware, computer-executable instructions, firmware or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s) 616 may include computer-executable or machine executable instructions written in any suitable programming language to perform the various functions described. [0102] The memory 612 may store program instructions that are loadable and executable on the processor(s) 616, as well as data generated during the execution of these programs. Depending on the configuration and type of user device 602, the memory 612 may be volatile (such as random access memory (“RAM”)) or non-volatile (such as read-only memory (“ROM”), flash memory, etc.). In some implementations, the memory 612 may include multiple different types of memory, such as static random access memory (“SRAM”), dynamic random access memory (“DRAM”) or ROM. The user device 602 may also include additional storage 618, such as either removable storage or non-removable storage including, but not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer- readable instructions, data structures, program modules, and other data for the computing devices. In some embodiments, the storage 618 may be utilized to store data contents received from one or more other devices (e.g., server device 610, other user devices, accessory devices 604, or the representative accessory device 606). For example, the storage 618 may store accessory management settings, accessory settings, and user data associated with users affiliated with the home environment. [0103] The user device 602 may also contain the communications interface 614 that allows the user device 602 to communicate with a stored database, another computing device or server, user terminals, or other devices on the network(s) 608. The user device 602 may also include I/O device(s) 620, such as for enabling connection with a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc. In some embodiments, the I/O devices(s) 620 may be used to output an audio response or other indication as part of executing the response to a user request. [0104] The memory 612 may include an operating system 622 and one or more application programs or services for implementing the features disclosed herein, including a communications module 624, a user interface module 626, a speech processing module 630, accessory interaction instance(s) 632, and a management module 634. The speech processing module further comprises a wake word module 636 and the accessory interaction instance(s) 632 further comprise a digital assistant 638. [0105] The communications module 624 may comprise code that causes the processor(s) 616 to generate instructions and messages, transmit data, or otherwise communicate with other entities. For example, the communications module 624 may, in conjunction with management module 634, transmit and receive data associated with accessory settings, accessory management settings, accessory scoring from accessory devices 604, 606, other user devices, or the server device 610. As described herein, the communications module 624 may transmit messages via one or more network paths of network(s) 608 (e.g., via a LAN associated with the home environment or an Internet WAN). [0106] The user interface module 626 may comprise code that causes the processor(s) 616 to present information corresponding to the accessory devices and user devices present within a home environment. For example, the user interface module 626 can present a graphical representation of user devices and the accessory devices currently associated with each accessory device. In some embodiments, the user interface module 626 can allow a user to provide configuration information about a new accessory device to be added to a home environment or allow the user to select user devices or accessory devices for removal from the home environment. [0107] The speech processing module 630 can comprise code that causes the processor(s) 616 to receive and process an audio input corresponding to speech or other sound amenable to analysis by techniques described herein. In some embodiments, one or more of the operations of speech processing module 630 may be similar to those described in reference to block 524 of FIG.5. Wake word module 636 can comprise code that causes processor(s) 616 to receive and process a portion of an audio input corresponding to a trigger or wake word. In some embodiments, one or more of the operations of the wake word module 636 may be similar to those described in reference to block 516 of FIG.5 or wake word detection module 424 of FIG.4. For example, wake word module 636 can analyze a portion of an audio input to determine the presence of a wake word. The speech processing module can also, in some embodiments, determine a language corresponding to the audio input and use that language to inform the analysis of the wake word portion. [0108] The accessory interaction instance(s) 632 may comprise code that causes the processor(s) 616 to receive and process a portion of an audio input corresponding to a user request. In some embodiments, one or more of the operations of accessory interaction instance(s) 632 may be similar to those described in reference to accessory interaction instances 430 of FIG.4. For example, the accessory interaction instance(s) 632 can comprise a number of processes or services that can cause the processor(s) 616 to send and receive data to a remote service, delegate the execution of a response to another process or service, or synthesize an audio response based on the speech analysis of the portion of the audio input. The accessory interaction instance(s) 632 may comprise a digital assistant 638 that can perform one or more of these example operations as well as additional operations related to the interaction between the accessory devices 604, 606 and the user device 602 as described herein. The accessory interaction instance(s) 632 may also comprise an election scoring module 644. In some embodiments, multiple accessory devices 604, 606 can receive the same audio input. In those cases, the election scoring module 644 can comprise code that causes the processor(s) to compute a score for a wake word received and processed at the user device (e.g., by the wake word module 636) and then transmit that score to the associated accessory device. [0109] The management module 634 may comprise code that causes the processor(s) 616 to send and receive information to and from one or more accessory devices 604, 606 or other user devices. In some embodiments, one or more of the operations of the management module may be similar to those described in reference to accessory management module 320 of FIG.3 and management module 414 of FIG.4. For example, the management module may, in conjunction with the communications module 624, transmit and receive information corresponding to accessory devices 604, 606 associated with the user device 602. The management module 634 can include accessory management settings 640, and a new accessory set-up module 642. The accessory management settings 640 can include information corresponding to one or more accessory devices 604, 606 and their associations with one or more user devices within a home environment. The accessory management settings 640 can also include information corresponding to the features and capabilities of the accessory devices 604, 606, the user device 602, or other user devices. In some embodiments, the user device 602 can be a configuration device that can send and receive accessory information to add a new accessory device to home environment. The new accessory set-up module 642 can perform one or more of the processes included in configuring the association between the new accessory device and a selected user device. [0110] Turning now to the details of the representative accessory device 606, the accessory device 606 can have, in some embodiments, at least one memory 650, a communications interface 652, processor(s) 654, a storage unit 656, and I/O devices 658. As described herein with respect to the user device 602, these elements of the accessory device can have the same appropriate hardware implementations as their counterparts on the user device 602. [0111] The memory 650 of the accessory device 606 can include an operating system 664 and one or more application programs or services for implementing the features disclosed herein, including communications module 660, audio module 662, and ADK 670. As described herein with respect to the user device 602, the communications module 660 can have similar appropriate functionality as its counterpart communications module 624. [0112] The audio module 662 may comprise code that causes the processor(s) 654, in conjunction with the I/O devices 658, to receive, process, and transmit audio signals. In some embodiments, one or more of the operations of the audio module may be similar to those described in reference to accessory audio module 412 of FIG.4. For example, the audio module 662 can receive a user utterance or other audio input at a microphone with the I/O devices 658 and transmit that audio data to the user device 602 over a streaming audio channel or other suitable connection. The audio module 662 can also receive response audio from the user device 602 and play that audio at a speaker within the I/O devices 658. [0113] The ADK 670 may comprise code that causes the processor(s) 654 to receive and process a portion of an audio input corresponding to a trigger or wake word. In some embodiments, one or more of the operations of the ADK 670 may be similar to those described in reference to ADK 408 of FIG.4. The ADK 670 can comprise a speech detection module 672 and wake word module 674. Wake word module 674 can comprise code that causes processor(s) 654 to receive and process the wake word. In some embodiments, one or more of the operations of the wake word module 674 may be similar to those described in reference to block 506 of FIG.5 or wake word detection module 410 of FIG.4. For example, wake word module 674 can analyze a portion of an audio input to determine the presence of a wake word. [0114] In some embodiments, the ADK 670 can also include an accessory election module 676. The accessory election module 676 may comprise code that causes processor(s) 654 to send and receive scores to and from accessory device 606 and user device 602, and cause the processor(s) 654 to compare received scores from the other accessories to determine a winning score. For example, when the wake word module receives a wake word for processing, the accessory election module 676 can communicate with other accessory devices 604 to hold an election to determine which accessory device should respond to the wake word. This process is described in detail with reference to FIG.8 below. [0115] FIG.7 is another simplified block diagram 700 illustrating an example architecture of an accessory device 702 receiving and processing multiple communications from user devices, according to some embodiments. The accessory device 702 and each of the depicted elements therein may be similar to other accessory devices and similar elements depicted in other figures described herein, including accessory device 606 of FIG.6. In some embodiments, the accessory device 702 may perform any one or more of the operations of accessory devices described herein. The accessory device 702 may be any suitable computing device (e.g., a smart speaker, a smartwatch, etc.) and can include a memory 710, processor(s) 724, a storage unit 726, I/O devices 728, and a communications interface 730. Each of these elements can have an appropriate implementation in hardware, firmware, computer- executable instructions, or combinations thereof and have functionality similar to the computing devices described in detail with respect to FIG.6, above, for the user device 602 and accessory device 606. [0116] Turning to the elements of the memory 710 in more detail, the memory 710 can include a communications module 712, an audio module 714, an operating system 716, and an ADK 720. Each of these elements may be similar to those described in reference to the accessory device 606 of FIG.6. In some embodiments, the ADK 720 can include audio mixing logic 722. The audio mixing logic can comprise code that, in conjunction with the communications module 712 and the audio module 714, causes the processor(s) 724 to receive, process, combine, mix, and output one or more audio sources. The audio sources can include one or more streaming audio inputs 754 or request responses 750, 752. In addition, the audio mixing logic 722 can also receive mixing rules 756. The mixing rules 756 can instruct the accessory device 702, via its audio mixing logic 722 or other elements of the ADK 720, to perform one or more audio mixing processes on the received audio input. The mixing rules 756 can be transmitted to the accessory device 702 by an associated user device and can be a part of a request response 750, 752, a streaming audio input 754, or a separate communication. The mixing rules 756 can provide instructions corresponding to the required volume of an incoming audio response, the required volume of any other audio response to be output contemporaneously with the incoming audio response, whether a currently output audio stream should be ducked or muted during the output of the incoming audio response or other audio response, etc. [0117] As an example of the foregoing embodiments, consider the scenario where the accessory device 702, in response to a previous user request, is currently playing a music stream over its speaker. The user then makes another request at the accessory device (e.g., “Computer, what time is it?”). This request can be processed at an associated user device and the accessory device 702 can receive an audio response (e.g., “The time is 10:30 p.m.”). This audio response can be accompanied by mixing rules generated by the user device that indicate that the audio response is to be played at the speaker with a particular volume over the top of the music stream and that the music stream should be ducked to a lower volume. The accessory device can apply the mixing rules and play the audio response over the music stream. As a further example, consider the addition of a second request corresponding to alarm (e.g., “Computer, set an alarm for 10:30 p.m.”). In this case, the response for the request for the time and the response for the alarm can arrive at the accessory device 702 simultaneously or nearly so. The user device can generate mixing rules to indicate that both the music stream and the alarm indication should be muted until the time response is announced, followed by restoring the volume of the music stream to a ducked level and playing the alarm indication over the music stream. Many other rules, parameters, or combinations thereof are contemplated. In some embodiments, the audio mixing logic 722 can store mixing rules 756 such that the rules persist and apply to future request responses and other received audio. Subsequent mixing rules can modify or update the stored rule set. In other embodiments, the mixing rules 756 are transient and only apply to one or more request responses or audio inputs currently received or playing at the accessory device 702. [0118] FIG.8 is a flow diagram showing a process 800 for an accessory device 801 to determine which among a plurality of accessory devices will respond to a user request, according to some embodiments. The accessory device 801 can correspond to any one or more of the accessory devices described herein. In some embodiments, some or all of the processes may be performed by one or more user devices or another device (e.g., a server device), which may, respectively, correspond to any of the user devices or server devices/server computers described herein. [0119] At block 802, the accessory device 801 can receive a wake word. In some embodiments, the wake word can correspond to a portion of an audio input received at the accessory device 801, including a user utterance. Block 802 can also encompass processing the wake word at a first level, similar to the wake word detection module 410 of FIG.4. [0120] At block 804, the accessory device 801 can establish an audio channel with a user device. The accessory device 801 can transmit the wake word over the audio channel to the user device. At block 806, the accessory device can receive an accessory response score from the user device. The accessory response score can be based on an analysis of the wake word sent to the user device. In some embodiments, the score is based on criteria including, but not limited to, strength (e.g., loudness) of the received audio input at the accessory device, quality of the received audio input, the capabilities of the accessory device, and the capabilities of a user device associated with the accessory device. [0121] At block 808, the accessory device 801 can open an election communications channel with one or more accessory devices that may have received audio inputs from the same user utterance or other audio source. The election communications channel may also be configured to communicate with one or more user devices, such that the participants in the election include both accessory devices and user devices. In some embodiments, the communications channel can occur over one or more networks to which the accessory devices can communicate. In other embodiments, an ad-hoc network or other small area network or LAN can be established for the purpose of the election. For example, the accessory devices may establish an anonymous election connection using Bluetooth to send and receive election scores. [0122] At block 810, the accessory device 801 can transmit its accessory response score to other accessories connected to the election communication channel. At block 812, the accessory device receives competing scores from one or more other accessories. In some scenarios, no other accessory device or user device transmits a score to accessory device 801, in which case the accessory device can proceed as if it had won the election. Once scores are received from all participant devices, the process can move to block 814 where the accessory device 801 compares its score to all other received scores. At the same time, in some embodiments, the other participant devices are performing the same or similar comparisons between their scores and the score transmitted by the accessory device 801. The comparison can include a simple comparison between numerical scores. In some embodiments, the scores can be generated in such a way to ensure that there is a unique winner (i.e. no ties). As depicted here in FIG.8, a “better” score is indicated as being greater than a less desirable score, such that the election winner will have the higher score. Other scoring systems are possible that change the comparison hierarchy but do not change the outcome of the election process as described herein. [0123] At decision 816, if the accessory device receives a score from another accessory that exceeds its own score, the process can proceed to endpoint 818 and the accessory device can ignore the wake word. Ignoring the wake word can include terminating the audio channel with the associated user device. If the response score of accessory device 801 is greater than all other received scores from other participant devices, then the accessory device 801 has won the election. The process moves to endpoint 820 where the accessory device 801 reports its victory to its associated user device. The election can determine which among multiple devices receiving an audio input is the preferred device for responding to that input. The winning device can continue to other operations relating to receiving or executing a response to the audio input. [0124] FIG.9 is another simplified flow diagram illustrating an example process 900 for a user device to coordinate interactions with a plurality of accessory devices. In some embodiments, one or more of the operations of process 900 may be similar to those as described in reference to FIGs.1 and 4. [0125] At block 902, a user device may receive information identifying one or more accessories that are able to communicate with the user device. In some embodiments, one or more of the operations of block 902 may be similar to one or more operations described for process indicator 330 in reference to FIG.3. [0126] At block 904, the user device can implement an accessory interaction instance corresponding to each of the accessories identified in block 902. In this way, the user device can have an accessory interaction instance associated with each identified accessory, such that operations performed by the user device that interact with an accessory device can be managed by one accessory interaction instance without impacting the user device’s interaction with other accessory devices. In some embodiments, one or more of the operations of block 904 may be similar to one or more operations of block 102 of FIG.1. [0127] At block 906, the user device can receive a first audio input from a first accessory and a second audio input from a second accessory, where the first and second accessories are among those previously identified in block 902 and associated with an accessory interaction instance in block 904. The first and second audio inputs can correspond to user utterances or other audio source received at the first and second accessories. In some embodiments, the first and second audio inputs can have the same audio source. [0128] At block 908, a first accessory interaction instance of the user device can process at least a portion of the first audio input received in block 906. The first accessory interaction instance can be the accessory interaction instance that corresponds to the first accessory. The portion of the first audio input can correspond to a user request, such that the processing by the accessory interaction instance can parse or otherwise analyze the request and determine a response. Processing the portion of the first audio input can include transmitting the portion to a server computer for analysis. The first audio input need not contain a request, and the processing can determine an appropriate response based upon the analyzed portion. In some embodiments, one or more of the operations of block 908 may be similar to one or more operations of block 524 of FIG.5. [0129] At block 910, the first accessory interaction instance can receive a first response from a server computer that corresponds to the processed portion of the first audio input. In some embodiments, the analysis of the portion of the audio input is performed by server computer, such that the server computer parses any request or determines a first response corresponding to the processed portion. The analysis can included techniques like NLP or other speech processing. In some embodiments, one or more of the operations of block 910 may be similar to one or more operations of blocks 524 and 532 of FIG.5. [0130] At block 912, the user device can transmit the first response to the first accessory. In some embodiments, one or more of the operations of block 904 may be similar to one or more operations of block 540 of FIG.5. [0131] Illustrative techniques for coordinating interactions between a user device and a plurality of accessory devices are described above. Some or all of these techniques may, but need not, be implemented at least partially by architectures such as those shown at least in FIGS.1-9 above. While many of the embodiments are described above with reference to server devices, accessory devices, and user devices, it should be understood that other types of computing devices may be suitable to perform the techniques disclosed herein. Further, in the foregoing description, various non-limiting examples were described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the examples. However, it should also be apparent to one skilled in the art that the examples may be practiced without the specific details. Furthermore, well-known features were sometimes omitted or simplified in order not to obscure the example being described. Techniques For Load Balancing With A Hub Device And Multiple Endpoints [0132] Additional embodiments of the present disclosure can provide techniques for managing the associations of accessory devices and hub devices. As a first example, consider a home environment corresponding to a home. A person within the home may want to know the current time. The person may query an accessory device (e.g., a nearby smart speaker) within the home environment with a verbal request (e.g., “What time is it?”). The accessory device can determine that the request was intended for the device and then transmit the received audio information to a hub device (e.g., a hub speaker). The hub device can process the audio information to determine the nature of the request and prepare a corresponding response (e.g., “It is 10:30 p.m.”). Alternatively, or partly in combination with the above, the user device may transmit some or all of the verbal request to a server computer (e.g., implementing a service provider), where the service provider can determine the nature of the request and/or prepare a corresponding response. The hub device can then transmit the response back to the accessory device for playback to the user. To provide coordination between the accessory device and the hub device, a user device can be configured to assign the accessory device to that particular hub device. The user device can monitor the hub device and other hub devices in the home environment and reassign the accessory device to another hub device if the other hub device would be more suitable for processing user requests or other interactions with the accessory. Additionally, the user device may be configured to assign a newly added accessory device to one of the hub devices based at least in part on various factors (e.g., accessory capabilities, hub capabilities, etc.). [0133] As an illustration of the example above, the home environment can include numerous “smart” devices, e.g., electronic devices with features allowing them to operate, to some extent, interactively and autonomously. The smart devices (which can have various functionality) can be cameras, speakers, thermostats, headphones and headsets, phones, or media players. The smart devices can also have various network communication capabilities, including WiFi, Ethernet, Bluetooth, Zigbee, cellular, and the like. The devices can be produced by various manufacturers. In some instances, the smart devices may be categorized into hub devices and accessory devices. A hub device can be a resident device of the home (e.g., a smart speaker, a smart digital media player configured to control a television (TV), a mobile phone, etc.). While not always, in some examples, a resident device may be expected to reside within the home and not move (e.g., within the home or to outside of the home) often. A hub device can have capabilities equal to or exceeding the capabilities of an accessory device. For example, a hub device can be a mobile phone, which can include wireless (e.g., WiFi) and cellular communications capabilities, multimedia capabilities, and a device assistant. In this same example, an accessory device can be a smart speaker, which can include audio media and wireless communications capabilities but lack a device assistant. A device assistant can be a virtual assistant program configured to interact with a user. In these examples, depending on its capabilities, a smart speaker can be either a hub device or an accessory device. In some examples, if an accessory is manufactured by an entity different from the entity that manufactured the user devices, the accessory may not initially be configured with the ability to communicate with the user devices. In some instances, the user device manufacturer may provide an accessory development kit (“ADK”) for installation on the accessory that enables such communication either after the accessory is manufactured, sold, provisioned, or used. A user device can be a hub device as described herein, and may include user interface features. In some embodiments, the user device is a leader device selected from among the hub devices in the home environment. As used herein, the terms hub device, user device, and leader device can indicate one or more similar devices distinguished from the accessory devices. [0134] In some embodiments, the user device can obtain information about the accessory devices and hub devices present in the home environment. This information can be obtained by the user device communicating directly with accessory devices and hub devices sharing the same network within the home environment. In other embodiments, information about accessory devices and hub devices can be sent to the user device by a second user device, a leader device, or a remote server device. For example, a user in the home may add a new accessory device to the home environment. As part of this process, the user can interact with a second user device (e.g., a mobile phone) to configure the new accessory device and send the new accessory device information to the first user device. As another example, a leader device in the home environment can have information about a plurality of accessory devices and hub devices in the home environment and report information about some or all of these devices to the user device. The user device can then use the information to assign the accessory device to a suitable hub device. The accessory information and hub device information may be stored by the user device. [0135] The information received by the user device from the hub devices and accessory devices can correspond to traits, attributes, or capabilities of the hub devices and accessory devices. For example, a hub device can be a hub speaker with a microphone input, a speaker output, and a device assistant with support for multiple spoken languages. The hub speaker’s attributes would then identify that the hub speaker could receive audio input (through the microphone), produce audio outputs (through the speaker), and process user requests (through the device assistant). Moreover, the hub speaker could have, as an attribute, support for multiple language processing, such that the hub speaker could be able to process user requests in a variety of spoken languages. Continuing the example, an accessory device can be a smart thermostat with a touch screen, a microphone input, no speaker output, and a connection to a furnace in the home environment. The smart thermostat’s attributes would then identify that the thermostat can interact with a user at the touch screen, present visual information or other indications to the user at the touch screen, receive audio inputs, be incapable of producing audio outputs, and operate the furnace to control ambient environmental conditions in the home. However, one of ordinary skill would understand that is merely one example, and that most if not all accessories will have a speaker for output. In some embodiments, the attribute information can also include information corresponding to the computational capabilities of the devices, including the current processing load of the device. In addition, each hub device can have a finite number of connection slots corresponding to the maximum number of associated accessories that the hub device can support. Each accessory associated with the hub occupies one slot, leaving unoccupied slots available for association with other accessories. The attribute information can also include the network communications capabilities of the devices. Any particular capability or functionality of the devices may be an identifiable attribute, and many combinations of capabilities and device functions are contemplated and described in several examples herein. [0136] Once the user device has received attribute information from the hub devices and the accessory device, the user device can score the hub devices to determine which hub device is the “best” hub device to associate with the accessory device. The score can be based on whether the accessory device requires particular attributes of a hub device. For instance, a camera accessory may require that any hub device that it is to associate with possess a hardware video decoder such that any hub that does not have the required decoder would receive a low score or a zero score from the user device. As another example, an accessory smart speaker may require specific language support from any hub device with which it is associated. One hub device may implement that language support partially, while a second hub device may implement that language support with high quality assets. The first hub may receive a low score while the second hub may receive a higher score with respect to being the best hub to associate with the smart speaker. [0137] In some embodiments, the hub devices can receive a base score that corresponds to their general computing power. For example, a tablet or smartphone hub device may have a higher base score than a hub speaker due to its more substantial computational capabilities. However, in other examples, a smartphone hub device may have a lower base score because of ephemeral nature (e.g., the smartphone may move around in the home and/or leave the home more often than other devices). Ephemeral devices may not make the best hubs because when they move, they may drop the associated accessory devices and force re-associations of those accessory devices to other hubs (which can create latency within the system). The base score can be modified by the comparison of accessory and hub attributes. A final connection score can then be computed by multiplying the modified score by the number of available connection slots at each hub. The hub device with the highest connection score is deemed the best hub device for the accessory, and the user device can transmit information to that best hub device to associate the accessory with it. [0138] FIG.10 is a simplified block diagram 1001 of an example embodiment. The process 1000 is an example high-level process flow for a system that includes an accessory device 1010 requesting assignment to a hub device via user device 1012. The diagram 1001 shows states of the system that correspond to the blocks of the process 1000. The process 1000 can be performed within a home environment containing multiple accessory devices, user devices, and hub devices. As depicted here, the accessory device 1010 can be a smart speaker while the user device 1012 can be a hub speaker. Although described as being a particular device, it should be apparent that the accessory device 1010, the user device 1012, or the hub devices 1014, 1016 can be several types of smart devices in various combinations and number. For example, a smartphone, media device (e.g., a smart TV), or tablet (either connected to a cellular network, to a local area network via WiFi of a home network, or to a wide area network (“WAN”)) can perform one or more of the operations of the process 1000. [0139] Turning to the process 1000 in more detail, at block 1002 the user device 1012 can receive an assignment request from the accessory device 1010. The assignment request can occur when the accessory device 1010 recognizes that it is not currently associated with a hub device. For example, the accessory device 1010 may be a new accessory device introduced into the home environment. As another example, the hub device previously associated with accessory device 1010 may have lost network connection with devices in the home environment, such that accessory device 1010 needs to be associated with a new hub device to properly relay user requests or other functions. In other instances, the accessory device 1010 may be dropped by its currently associated hub device. This can occur when the currently associated hub device reduces its total number of connection slots, for example due to an increased computational load is instructed to do so by the user device or another device. [0140] At block 1004, the user device 1012 can receive information from the accessory device 1010, a first hub device 1014, and a second hub device 1016. The information can include attributes 1020 from accessory device 1010 and attribute information 1024, 1026 from the hub devices 1014, 1016. As described in more detail with respect to FIG.12, below, the accessory attributes 1020 can include any feature of the accessory device 1010 relevant to its association with a hub device. Some accessory attributes can be classified as requirement attributes. Similarly, the hub information 1024, 1026 can include any attribute or feature of the hub devices 1014, 1016 relevant to selecting a best hub device. In some embodiments, the user device 1012 can receive hub attribute information 1024, 1026 upon request. The user device 1012 can store the received hub and accessory attribute information. The stored attribute information may be stored locally at the user device or at a remote device like a server computer. In other embodiments, the hub devices 1014, 1016 can periodically update stored attribute information 1024, 1026 without a request from the user device 1012. For example, the hub devices 1014, 1016 may update their attribute information stored at a server device each time those attributes change (e.g. if the number of accessory slots decreases) or at a regular interval (e.g. every minute). The user device 1012 can then access the stored data to receive hub attribute information 1024, 1026 without directly querying each hub within the home environment. [0141] Moving down to block 1006, the user device 1012 can compare the accessory attributes 1020 with the first hub information 1024 and the second hub information 1026. The comparison can result in a score or other metric to determine which of the first hub device 1014 and the second hub device 1016 should be assigned to accessory device 1010. In some embodiments, each of the hub devices 1014, 1016 can be given a base score corresponding to each device’s general computing power. The user device 1012 can then modify that base score by combining it with the result of the comparison. A connection score for each hub device is computed by multiplying the modified score by the number of slots available at hub device 1014 and hub device 1016. The user device 1012 can then assign the accessory device 1010 to the hub device with the highest connection score, as in block 1008. [0142] As an example of the foregoing embodiments, consider the scenario depicted in FIG.10, where the accessory device 1010 is a smart speaker, hub device 1014 is a hub speaker, and hub device 1016 is a tablet. Because the tablet may have a greater general computing power than a hub speaker, hub device 1016 can be assigned a higher base score than the hub device 1014. The smart speaker may only require basic language support for one language in the home environment, and both the hub speaker and tablet can provide that support. Thus, when comparing the requirement attributes of accessory device 1010 to the hub information 1024, 1026, each hub receives the same non-zero score. With regard to other accessory features, the tablet can provide both a microphone and a speaker as well as a touch screen, while the hub speaker may only provide a microphone and a speaker. The smart speaker accessory attributes may indicate that a hub device that can present information visually (e.g., via speech to text) is beneficial. All other attributes being equal, the tablet may receive a higher comparison score than the hub speaker. Then, the user device 1012 can compute a modified score for the second hub device 1016 that is significantly higher than the modified score for the first hub device 1014. But the tablet may only have one accessory connection slot that is already occupied by another accessory, while the hub speaker may have two open slots. The user device 1012 can then compute the connection score for each hub device, multiplying the hub speaker’s modified score by two and the tablet’s modified score by zero. The result would be that the hub speaker is the winning device and the user device 1012 can assign accessory device 1010 to hub device 1014 as depicted. The above description should only be considered as one example of the outcome of the disclosed process. One skilled in the art would recognize that a home environment with numerous devices can produce various different outcomes for accessory/hub assignments depending on the dynamic nature of the hub attributes, the available connection slots, and the migration of hub devices and accessory devices into or out of the home networks. [0143] FIG.11 is a schematic of a home environment 1100 containing hub devices and accessory devices, according to some embodiments. Hub devices can include a hub speaker 1102, a media player 1104, and a smartphone 1106. These hub devices can correspond to hub devices 1014, 1016 from the embodiments described above with respect to FIG.10. Accessory devices can include smart speakers 1112, 1114, a smartwatch 1116, and a thermostat 1124. Similarly, these accessory devices can correspond to accessory device 1010 described with respect to FIG.10. All or some of these accessory devices may be third-party devices (e.g., not manufactured, programmed, or provisioned by the manufacturer, programmer, or provisioner of the hub devices or user devices). Because of this, they may not be automatically and/or initially compatible with the user devices. Each hub device in the home environment 1100 can be associated with zero, one, or more accessory devices. As illustrated by the long-dashed lines, hub speaker 1102 is associated with smart speakers 1112, 1114 and smartwatch 1116 while media player 1104 is associated with thermostat 1124. The smartphone 1106 is not associated with an accessory device. The devices within the home environment 1100 can be configured to communicate using one or more network protocols over one or more networks associated with the home environment 1100. For example, the home environment 1100 can be associated with a local area network (“LAN”), a WAN, a cellular network, a personal area network, or other network, and the devices can communicate using a WiFi connection, a Bluetooth connection, a Thread connection, a Zigbee connection, or other communication method. [0144] The arrangement of associations of accessory devices with hub devices can include various different combinations and can be modified by a user device. For example, a user device may receive an assignment request from an accessory device within the home environment. The accessory device can be one of the accessory devices previously associated with a hub device in the home or can be a new accessory device added to the home. The user device would then obtain attribute information from the accessory device and the hub speaker 1102, media player 1104, and smartphone 1106 and then score these hub devices. Because the smartphone 1106 is not currently associated with an accessory device, it may have the highest score and receive the assignment of the new accessory. In some embodiments, a user device in the home environment 1100 can communicate with a hub device to transfer one or more accessory devices associated with the first hub device to the second hub device. This transfer can occur automatically based on information that the user device receives about the home environment 1100, including, but not limited to, information that another hub device may be more suitable for association with one or more accessories or that accessories have been added to or removed from the home environment 1100. The suitability of any particular hub device to associate with an accessory can be based at least in part on the capabilities of the hub device, the capabilities of the accessory device, the current processing load experienced by the hub device, the locations of the devices within the home environment, and the status of communications between the devices on a network. Many other criteria for rearranging device associations in a home environment are contemplated. [0145] In some embodiments, accessory devices and non-resident hub devices may also leave the home environment or lose network connectivity with the home environment. An accessory device that leaves the home environment can be disassociated by the previously associated hub device, such that the hub device updates its accessory slots to account for a newly available slot. Accessory devices associated with a hub device that loses network connectivity with the home environment can be reassigned by a user device that retains network connectivity. In this case, the user device can receive information that the hub device is no longer able to communicate with the accessory device and reassign the accessory device. Some embodiments may have a user device designated a leader device to manage the assignment of accessory devices among the hub devices within the home environment. In other embodiments, if user devices and accessory devices are associated and leave the home environment and lose network connectivity, the user devices can retain their associations with the accessory devices and perform the embodied methods described herein. [0146] In another embodiment, a user device acting as a leader device can monitor the hub devices within the home environment to determine whether each hub device can respond to its accessories in an acceptable timeframe. In some circumstances, a hub device may come under increased processing load, making it unable to respond to one or more of its assigned accessories within a threshold amount of time. The user device can receive information about the hub device indicating its delayed response to accessory requests and instruct the hub device to drop one or more of its accessory devices. The user device can then determine which other hubs within the home environment should be assigned the dropped accessory devices. [0147] Returning to FIG.11, as an example of the foregoing description of some embodiments, the hub speaker 1102 can drop its association with smartwatch 1116. This can occur due to an increased processing load occurring at hub speaker 1102, for instance if it is currently streaming separate music channels to smart speakers 1112, 1114. Because it has no associated hub, the smartwatch 1116 can request assignment from a user device, which can be smartphone 1106. Smartphone 1106 can then receive attribute information from the hub devices in the home environment 1100. This can include attribute information about smartphone 1106 itself, since user devices can act similarly to hub devices, in some embodiments. Smartwatch 1116 would then score each hub device based on the comparison of attribute information and the accessory attributes. Since hub speaker 1102 recently dropped the accessory smartwatch 1116 due to increased demands, the hub speaker can reduce its total number of accessory connection slots and have no slots available. The smartphone 1106 could then determine the winning hub device between itself and the media player 1104 and assign the smartwatch 1116 appropriately. [0148] Continuing with FIG.11, a home environment 1100 can have multiple users 1130, 1134 making audio requests 1132, 1136 of accessories. The requests 1132, 1136 can occur separately or simultaneously and can be received by multiple accessory devices as depicted by the short-dashed lines. For example, request 1132 can be received by smart speaker 1114 or smartwatch 1116, while request 1136 can be received by smart speaker 1112 and thermostat 1124. As described previously, the arrangement of accessory devices and their associations can take various forms and can change over time. Thus, a user request may be received by multiple accessory devices associated with different hub devices. For example, user request 1136 is received by both thermostat 1124 associated with media player 1104 and by smart speaker 1112 associated with hub speaker 1102. Since user interactions with the devices in the home environment 1100 can occur in several arrangements, the ability for a user device or leader device to assign accessories to the best hub device can prevent user requests from being missed. If an accessory device is dropped by its hub device, as described in a previous example, or if a hub device loses network connectivity, the accessory devices may not be able to process user requests unless they are quickly reassigned to the best available hub device. [0149] Hub device management by a user device or leader device can also allow hub devices to receive and process audio requests 1132, 1136 that require a response at one or more accessory devices other than the accessory device initially receiving the request. In these embodiments, the accessory devices may have no information about other accessories within the home environment and no mechanism to establish trust or permissions with other accessories on one or more of the networks of the home. For example, the smart thermostat 1124 and smartwatch 1116 can be third party accessories manufactured by two different entities, and thus may have no inherent ability or permissions to connect directly to one another to communicate or exchange data and information. A user device can manage the assignments of accessories to hub devices so that each hub can establish a connection with each of its accessories and transmit information received from other hubs to those accessories without the accessories knowing about any other device in the home environment except for its assigned hub. [0150] As a specific example of the foregoing embodiments, consider the case where user 1134 wants to make an announcement to user 1130 to remember to buy milk at the grocery store as user 1130 is about to leave the home. The user request 1136 may be heard more clearly by smart thermostat 1124 assigned to media player 1104 because user 1134 is in the same room with thermostat 1124. Upon processing the user request, media player 1104 can transmit the response to hub speaker 1102 and smartphone 1106 (e.g., the other known hub devices in the home environment). The announcement can be played at every capable device within the home, including smartphone 1106, hub speaker 1102, smart speakers 1112, 1114, and smartwatch 1116 to ensure that it is heard by user 1130. The announcement can also be selectively transmitted by hub speaker 1102 to smartwatch 1116 so that it is presented by the most appropriate device. In this way, a user request can be received at one third party device (the thermostat) and executed at a second third party device (the smartwatch) without either third party device directly communicating with the other. Consider a further example where user 1130 collects smartphone 1106 and leaves the home environment before user 1134 makes the announcement request. Since the smartwatch 1116 has left the home environment, it may lose network connectivity with hub speaker 1102. When it does so, the smartwatch 1116 can request assignment to another hub device. The smartphone 1106 or other user device can assign the smartwatch 1116 to another suitable hub device, which can be the smartphone 1106 since it remains in close proximity to the smartwatch 1116. Smartphone 1106 can also retain network connectivity with the home environment via its cellular network connection to an Internet WAN. When user 1134 makes the announcement to bring back milk from the grocery store, the request can again be processed by media player 1104 and transmitted to hub speaker 1102 and smartphone 1106 for playback. Since hub speaker 1102 is no longer assigned to smartwatch 1116, it will take no further action executing the announcement request. Smartphone 1106 can receive the announcement and transmit it to its accessory smartwatch 1116 for audio playback to user 1130. [0151] FIG.12 is a schematic illustrating a process 1200 for a user device 1201 to assign an accessory device 1206 to one of the hub devices 1202. In some embodiments, the user device 1201 can correspond to user devices described herein (e.g., user device 1012 of FIG. 10). Similarly, accessories 1204 and accessory device 1206 may correspond to other accessory devices and hub devices 1202 may correspond to other similar hub devices described herein. User device 1201, depicted here to be a hub speaker, can be a hub device among the hub devices 1202, a leader device, a configuration device, or other device used to determine device assignments and associations. The user device 1201 can be configured to communicate with the hub devices 1202, accessories 1204, and accessory device 1206 over one or more networks described herein, including a LAN or a WAN. In some embodiments, the user device 1201 is a remote server device configured to communicate with the hub devices 1202, accessories 1204, and accessory device 1206 over a WAN. [0152] Multiple elements of the assignment process 1200 are presented in more detail. The hub devices 1202 can each comprise hub attribute information including hub attributes 1210 and slots 1216. This information may be stored in a memory or storage unit at the hub device. In some embodiments, the hub information can be stored at a remote device like a server computer or cloud device. In other embodiments, the hub information is stored at the user device 1201 and updated periodically. The hub attributes 1210 can include any attribute or feature of the hub devices 1202 relevant to selecting a best hub device. This can include language processing 1212, hardware decoder 1214, supported network connections (e.g. WiFi, cellular, or Thread), ability to act as an edge router for a personal area network (e.g., Thread border router), and the types of other accessories currently associated with the hub device. The slots 1216 can include both the number of available accessory connection slots 1218 and the number of currently assigned slots 1220. The number of total slots 1216 is a dynamic quantity and may be changed or updated by the hub device according to changing circumstances in the home environment. Changes to the number total slots 1216 can result in an assigned accessory being removed from the hub device if the hub device no longer has enough slots 1216 available to support the accessory. In some embodiments, if the number of slots 1216 becomes fewer than the number of assigned accessories, accessories that are assigned to the hub based on a matching requirement trait 1226 are disassociated from the hub only if no other accessory devices can be disassociated first. As depicted here, an exemplary hub device can have four total slots, with two slots available and two slots assigned to “Accessory 1,” a thermostat, and “Accessory 2,” a camera. [0153] Accessory device 1206 can be a representative accessory from among the accessories 1204 and can comprise information corresponding to the accessory state 1222 and the accessory traits 1224. As used herein, the terms accessory traits and accessory attributes can be used interchangeably. The accessory state 1222 is a piece of information corresponding to whether the accessory 1206 is currently assigned to a hub. If it is assigned then the accessory state 1222 will identify the assigned hub. If the accessory is not assigned (e.g., it is a new accessory to the home environment), then the accessory state 1222 can indicate that the accessory 1206 needs assignment, instructing the accessory to request assignment from the user device 1201. In some embodiments, an accessory device can be unassigned to a hub and not request a hub assignment. In these cases, the unassigned accessory can transmit its state information to the user device 1201 but not request an assignment to a hub device. The accessory traits 1224 can include any feature of the accessory device 1206 relevant to its association with a hub device, including, but not limited to, language support requirements, hardware encoding/decoding requirements, the input/output (“I/O”) devices present (e.g., speaker and microphone or a screen), the type of network connections supported (e.g., WiFi and Bluetooth), and external device control (e.g., control of a light switch or a home furnace). Some accessory attributes can be classified as requirement attributes. [0154] Completing the detailed elements of FIG.12, process indicators 1230, 1240 represent data transmission between the accessory user device 1201 and the accessory device 1206 and between the user device 1201 and the hub devices 1202, respectively. The process indicators 1230, 1240 can indicate communication over one or more networks between the various devices as described herein, including, but not limited to, a WiFi LAN or an Internet WAN. Process indicator 1230 indicates transmission of data corresponding to the request for assignment and the accessory traits 1224 to the user device 1201. This data can include that the accessory device 1206 is no longer in communication with its assigned hub device. Similarly, process indicator 1240 indicates transmission of data including hub attributes 1210 and slots 1216 between the hub devices 1202 and the user device 1201. [0155] The process 1200 provides a more detailed picture of the scoring process described above with respect to block 1004 of FIG.10. Once user device 1201 has received accessory traits 1224 and hub attributes 1210 and slots 1216 from the hub devices 1202, it can score the hub devices 1202 to determine the best hub. The scoring begins by determining a base score for each hub device. Then, user device 1201 can compare accessory traits 1224 with hub attributes 1210. The comparison begins by comparing the requirement traits 1226 of the accessory device 1206 with the hub attributes 1210. Since the accessory device 1206 has indicated that these attributes are required in some manner, if the comparison does not match a requirement trait 1226 with a corresponding attribute 1210 of the hub device, then the resulting score for that hub device will be zero. This zero result will occur regardless of how well the hub device scores with respect to other attributes of the accessory device 1206. In some instances a hub device may only partially match a requirement trait 1226 (e.g., by providing a required feature at low quality). The user device 1201 may give a non-zero score to the hub device for the partial fulfillment of the requirement. Once the requirement traits 1226 are compared, the user device 1201 then compares the other accessory traits 1228 to each feature in the hub attributes 1210. The result is then combined with the base score to obtain a modified score. The connection score for each hub device can be computed by multiplying the modified score by the number of slots available at each of the hub devices 1202. [0156] FIG.13 is a simplified block diagram 1300 illustrating an example architecture of a system used assign an accessory device to a hub device, according to some embodiments. The diagram includes a user device 1302 (e.g., a leader device), one or more accessory devices 1304, a representative accessory device 1306, one or more network(s) 1310, and a server device 1312. In some examples, the user device 1302 may be one of a plurality of hub devices that may have been elected as a leader of hub devices). Each of these elements depicted in FIG.13 may be similar to one or more elements depicted in other figures described herein. In some embodiments, at least some elements of diagram 1300 may operate within the context of a home environment (e.g. the home environment 1100 of FIG.11). [0157] The accessory devices 1304 and representative accessory device 1306 may be any suitable computing device (e.g., smart speaker, smartwatch, smart thermostat, camera, etc.). In some embodiments, an accessory device may perform any one or more of the operations of accessory devices described herein. Depending on the type of accessory device and/or location of the accessory device (e.g., within the home environment or outside the home environment), the accessory device may be enabled to communicate using one or more network protocols (e.g., a Bluetooth connection, a Thread connection, a Zigbee connection, a WiFi connection, etc.) and network paths over the network(s) 1310 (e.g., including a LAN or WAN), described further herein. [0158] In some embodiments, the server device 1312 may be a computer system that comprises at least one memory, one or more processing units (or processor(s)), a storage unit, a communication device, and an I/O device. In some embodiments, the server device 1312 may perform any one or more of the operations of server devices described herein. In some embodiments, these elements may be implemented similarly (or differently) than as described in reference to similar elements of user device 1302. [0159] In some embodiments, the user device 1302 may correspond to any one or more of the user devices described herein. For example, the user device 1302 may correspond to one or more of the user devices of the home environment 1100 of FIG.11. The representative user device may be any suitable computing device (e.g., a mobile phone, tablet, a smart hub speaker device, a smart media player communicatively connected to a TV, etc.). Similarly, the hub devices 1308 can be any device capable of performing the functions of a user device. [0160] In some embodiments the one or more network(s) 1310 may include an Internet WAN and a LAN. As described herein, the home environment may be associated with the LAN, whereby devices present within the home environment may communicate with each other over the LAN. As described herein, the WAN may be external from the home environment. For example, a router associated with the LAN (and thus, the home environment) may enable traffic from the LAN to be transmitted to the WAN, and vice versa. In some embodiments, the server device 1312 may be external to the home environment, and thus communicate with other devices over the WAN. [0161] As described herein, user device 1302 may be representative of one or more user devices connected to one or more of the network(s) 1310. The user device 1302 has at least one memory 1314, a communications interface 1316, one or more processing units (or processor(s)) 1318, a storage unit 1320, and one or more input/output (I/O) device(s) 1322. [0162] Turning to each element of user device 1302 in further detail, the processor(s) 1318 may be implemented as appropriate in hardware, computer-executable instructions, firmware or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s) 1318 may include computer-executable or machine executable instructions written in any suitable programming language to perform the various functions described. [0163] The memory 1314 may store program instructions that are loadable and executable on the processor(s) 1318, as well as data generated during the execution of these programs. Depending on the configuration and type of user device 1302, the memory 1314 may be volatile (such as random access memory (“RAM”)) or non-volatile (such as read-only memory (“ROM”), flash memory, etc.). In some implementations, the memory 1314 may include multiple different types of memory, such as static random access memory (“SRAM”), dynamic random access memory (“DRAM”) or ROM. The user device 1302 may also include additional storage 1320, such as either removable storage or non-removable storage including, but not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some embodiments, the storage 1320 may be utilized to store data contents received from one or more other devices (e.g., server device 1312, other user devices, hub devices 1308, accessory devices 1304, or the representative accessory device 1306). For example, the storage 1320 may store accessory management settings, accessory attributes, hub attribute information, and user data associated with users affiliated with the home environment. [0164] The user device 1302 may also contain the communications interface 1316 that allows the user device 1302 to communicate with a stored database, another computing device or server, user terminals, or other devices on the network(s) 1310. The user device 1302 may also include I/O device(s) 1322, such as for enabling connection with a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc. [0165] The memory 1314 may include an operating system 1324 and one or more application programs or services for implementing the features disclosed herein, including a communications module 1326, a user interface module 1328, a digital assistant 1330, and a management module 1332. The management module 1332 further comprises a scoring module 1334 and device attributes 1336. [0166] The communications module 1326 may comprise code that causes the processor(s) 1318 to generate instructions and messages, transmit data, or otherwise communicate with other entities. For example, the communications module 1326 may, in conjunction with management module 1332, transmit and receive data associated with accessory assignment requests, accessory traits, and hub device attributes from accessory devices 1304, 1306, the hub devices 1308, other user devices, or the server device 1312. As described herein, the communications module 1326 may transmit messages via one or more network paths of network(s) 1310 (e.g., via a LAN associated with the home environment or an Internet WAN). [0167] The user interface module 1328 may comprise code that causes the processor(s) 1318 to present information corresponding to the accessory devices 1304 and hub devices 1308 present within a home environment. For example, the user interface module 1328 can present a graphical representation of hub devices 1308 and the accessory devices 1304 currently associated with each hub device. In some embodiments, the user interface module 1328 can allow a user to provide configuration information about a new accessory device to be added to a home environment or allow the user to select hub devices 1308 or accessory devices 1304 for removal from the home environment. [0168] The digital assistant 1330 may comprise code that causes the processor(s) 1318 to receive and process user requests. The user requests may be transmitted to the user device from accessory devices 1304. The digital assistant 1330 can comprise speech processing capabilities and language support. The presence of a digital assistant 1330 and features therein can comprise one or more of the attributes considered when comparing accessory traits 1358 to hub attributes to score the hub devices 1308. [0169] The management module 1332 may comprise code that causes the processor(s) 1318 to send and receive information to and from one or more accessory devices 1304, 1306 and to and from one or more hub devices 1308 or other user devices. For example, the management module 1332 may, in conjunction with the communications module 1326, receive an assignment request and accessory traits from accessory device 1306 or receive hub attributes from the hub devices 1308. The management module 1332 may also transmit information to the accessory device 1306 and one of the hub devices 1308 indicating an assignment to the best hub. In some embodiments, the management module 1332 may store information corresponding to the accessory state of each accessory managed by the user device 1302 within the home environment. The accessory state can identify to which hub of a plurality of hub devices 1308 each accessory device of the plurality of accessory devices 1304 is assigned. [0170] The management module 1332 can include scoring module 1334 and device attributes 1336. The device attributes 1336 can include accessory traits 1358 received from accessory device 1306 and hub attributes received from the hub devices 1308. The device attributes 1336 may be stored in memory 1314 or the storage 1320 at the user device. In some embodiments, the device attributes can be stored at another device, including the server device 1312, and received into memory 1314 when user device 1302 processes an assignment request. The scoring module 1334 can comprise code that causes the processor(s) 1318 to compare the accessory traits and hub attributes comprising the device attributes 1336 to compute a score for each of the hub devices 1308. [0171] Turning now to the details of the representative accessory device 1306, the accessory device 1306 can have, in some embodiments, at least one memory 1342, a communications interface 1344, processor(s) 1346, a storage unit 1348, and I/O devices 1350. As described herein with respect to the user device 1302, these elements of the accessory device can have the same appropriate hardware implementations as their counterparts on the user device 1302. [0172] The memory 1342 of the accessory device 1306 can include an operating system 1354 and one or more application programs or services for implementing the features disclosed herein, including communications module 1352 and an accessory development kit (“ADK”) 1356. The ADK can be a software development kit (“SDK”) stored and configured to be executed or processed on the accessory device 1306. As used herein, an SDK can include application programming interfaces and related software libraries sufficient to enable the operation of other software within or associated with the SDK. In some embodiments, the ADK can be provided by an entity associated with the hub devices 1308 or the user device 1302 (e.g., their manufacturer). As described herein with respect to the user device 1302, the communications module 1352 can have similar appropriate functionality as its counterpart communications module 1326. [0173] The ADK 1356 may comprise code that causes the processor(s) 1346 to determine the assignment state of the accessory device 1306 and, if the accessory device 1306 is not currently assigned to a hub device, transmit an assignment request to the user device 1302. The ADK 1356 can comprise the accessory traits, including requirement traits and other traits of the accessory device 1306. In some embodiments, the accessory traits may be similar to those described in reference to accessory traits 1224 of FIG.12. For example, accessory device 1306 may require a particular language support of any of the hub devices 1308 to which it is assigned. [0174] FIG.14 is a flow diagram illustrating a particular example process 1400 for assigning an accessory 1402 to a selected hub device. Each of the elements and operations depicted in FIG.14 may be similar to one or more elements depicted in other figures described herein. For example, the user device 1401 may be similar to other user devices (e.g., leader devices), and so forth. In some embodiments, process 1400 may be performed within a home environment (e.g. the home environment 1100 of FIG.11). Process 1400, as well as processes 1500, 1600, 1700, and 1800 of FIGS.15, 16, 17, and 18 (described below) are illustrated as logical flow diagrams, each operation of which represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. 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 processes. [0175] Additionally, some, any, or all of the processes may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium is non-transitory. [0176] At block 1408, the accessory 1402 can request assignment to a hub device. The request can be initiated based on the accessory device recognizing that it is currently unassigned to a hub device. This can be due to the accessory device being new to the home environment or the previously assigned hub device dropping the accessory device. At block 1410, the user device 1401 can receive the assignment request. In some embodiments, the user device 1401 can be a leader hub device among the hub devices in the home environment. The leader hub device can be chosen as a leader by another process, including a process that occurs at a server device or other device that determines leadership among the hub devices. [0177] At block 1412, the user device 1401 can obtain accessory traits reported by the accessory 1402 at block 1414. The accessory traits may be similar to accessory traits 1224 described with reference to FIG.12. In some embodiments, the user device 1401 can query the accessory 1402 to obtain those traits. In other embodiments, the accessory device transmits the accessory traits along with the assignment request. In still other embodiments, the accessory 1402 can periodically report its accessory traits to a leader device (or one or more other devices (including other leader devices)) or server device such that the leader device, other devices, or server device maintains an up-to-date store of the accessory traits. Similarly, at block 1416, the user device 1401 can obtain hub information from one or more hub devices. The hub information may be similar to the hub attributes 1210 and slots 1216 described in detail above with respect to FIG.12. [0178] In some examples, controller devices may have hub capabilities enabled or disabled, such that only devices with the hub capabilities enabled can act as a hub for accessory 1402. Similarly, or alternatively, the devices may have a digital and/or virtual assistant enabled or disabled, which may be used to determine whether the device can act as a hub. The user device 1401 may maintain a list of all devices that have hub capabilities (or assistant capabilities) enabled. Thus, when the user device 1401 obtains the hub information at block 1416, it may only query devices (e.g., first hub device 1404 and second hub device 1406) because those devices are already listed as hub-enabled or assistant-enabled. Alternatively, the hub information may have already been obtained from the hub devices when the user device 1401 was updated with information identifying the hub-enabled or assistant-enabled devices (e.g., when it learns which devices have hub and/or assistant capabilities enabled, the user device 1401 may obtain each devices hub information at the same time). Additionally, in some examples, block 1416 may actually be performed when the user device 1401 becomes a leader and, thus, is configured to poll all other devices in the mesh about their capabilities. As noted above, it may be at this point, when the user device 1401 obtains hub information, as opposed to obtaining the information in response to accessory 1402 requesting assignment at block 1408. In which case, at block 1416, the user device 1401 may obtain the hub information by retrieving it from its own memory, as it would have presumably already received it from the first hub device 1404 and/or the second hub device 1406 upon creation of the mesh or when the user device 1401 becomes the leader. In some examples, the hub devices may periodically update their respective hub information (e.g., as features are added/removed). When this occurs, the user device 1401 may need to obtain updated hub information from each of the first hub device 1404 and second hub device 1406. [0179] As depicted in FIG.14, the hub devices can comprise a first hub device 1404 and a second hub device 1406. Process 1400 is not limited to only two hub devices and may be performed for any number of hub devices in the home environment. As with receiving the accessory traits, in some embodiments the user device 1401 can query the hub devices 1404, 1406 to report hub information at block 1418 and block 1420. The hub devices 1404, 1406 may also periodically report hub information to the user device 1401 or a server device to maintain an up-to-date store of hub information. In these embodiments, the user device 1401 may receive the hub information by accessing the repository of hub information stored at itself or a server device. [0180] At block 1422, the user device 1401 can compute a base metric for the first hub device 1404 and the second hub device 1406. This base metric can be based upon the general computing capabilities of the hub devices 1404, 1406. For example, the first hub device 1404 can be a tablet computer with a powerful processor and substantial on-board memory while the second hub device 1406 can be a hub speaker with a less powerful processor and memory. The base score for the tablet computer can be higher than for the hub speaker. The base score can also depend on the current processing load experienced by a hub device. In the previous example, although a tablet computer may have greater computational capabilities than a hub speaker, the tablet may be in continual use performing other computational tasks for users in the home environment (e.g., running applications or playing media). Thus, the computed base score can be different for the same hub device depending on the current processing capabilities of the hub device when the score is determined. [0181] At block 1424, the user device 1401 can compare the received accessory traits to the received hub information from the first hub device 1404 and the second hub device 1406. In some embodiments, one or more of the operations of block 1424 may be similar to one or more of the operations described for block 1006 of FIG.10 or process 1200 in reference to FIG.12. For example, the accessory 1402 can have requirement traits and other traits. The hub information can identify features and functionality of the hub devices 1404, 1406 that can meet the requirements of the accessory requirement traits. The user device 1401 can compare the requirement traits to the attributes of the first hub device 1404 and the second hub device 1406 and compute a modified score for each hub device. The modified score is a modification of the base score using the results of the comparison. Hub devices that cannot meet the requirement traits of the accessory device are given a modified score of zero. [0182] Many methods of quantifying the comparison of accessory traits to hub attributes are contemplated, and the scoring algorithm used by the user device 1401 can be updated or modified over time to provide different quantifications of the best hub device score. Consider, for example, a home environment wherein the hub devices frequently encounter significant loading due to activity unrelated to the interaction between the hub devices and accessory devices. This loading can be due to many of the hub devices receiving user interaction to perform other tasks, like a tablet computer or media player streaming video content from the Internet. In these cases, the hub devices may frequently indicate that they cannot support their assigned accessories, which can result in frequent reassignments of the accessories. Connection stability among the assigned accessory devices and the hub devices may be improved by altering the scoring algorithm such that hub devices with attributes indicating that the hub device may come under frequent loading will receive a lower score. [0183] Returning to process 1400, at block 1426 the user device 1401 can compute final scores for the first hub device 1404 and the second hub device 1406. The final scores can be a first connection score for the first hub device 1404 and a second connection score for the second hub device 1406. The final scores are computed by multiplying the modified scores obtained at block 1424 by each hub device’s available connection slots. If a hub device has no available slots, its final score can be zero. Similarly, if a hub device received a modified score of zero because it did not meet the requirements of the accessory traits, its final score can also be zero, regardless of the number of available slots the hub device has or its general computing power. [0184] At decision 1428, the final scores from the hub devices 1404, 1406 are compared and the highest score wins, indicating the best hub device for the accessory assignment. If the first hub device 1404 has the higher connection score, the process moves to block 1430 and the user device 1401 assigns accessory 1402 to the first hub device 1404. The assignment can include the first hub device 1404 receiving assignment instructions identifying the accessory 1402 and allowing the first hub device to associate with the accessory 1402. The association can include, for example, creating an interaction instance comprising software modules for communicating with the accessory 1402 and processing user requests transmitted from the accessory 1402 to the first hub device 1404. The association may also include the first hub device 1404 establishing a connection with the accessory 1402. At endpoint 1434, the first hub device 1404 can update its slots to reflect one fewer available connection slots owing to the newly associated accessory 1402. Conversely, if the second hub device 1406 has a higher connection score, the process can move to block 1436 and the user device 1401 can assign accessory 1402 to the second hub device 1406. Block 1438 and endpoint 1440 are similar to block 1432 and endpoint 1434, but with operations performed by the second hub device 1406. For example, upon receipt of the assignment instructions at block 1438, the second hub device may associate itself with the accessory 1402 (e.g., establishing a connection with the accessory 1402). In some examples, when the accessory 1402 is first connected to the network (e.g., the same network to which each of user device 1401, first hub device 1404, and second hub device 1406 are connected), the accessory 1402 may provide its information (e.g., an identifier, etc.), and thus each device on the network will be aware of the device and how to connect to it. In this way, once the first hub device 1404 or the second hub device 1406 are assigned to be the hub for the accessory 1402, they are already configured to connect. [0185] Once the best hub device has been determined and assigned, the process can move to block 1442 to assign the accessory 1402 to the best hub device. Assignment of the accessory 1402 can include transmitting information to the accessory 1402 identifying which of the first hub device 1404 and the second hub device 1406 received the higher connection score. At endpoint 1444, the accessory 1402 can update its accessory state to reflect the current hub assignment. However, in some instances, block 1442 is skipped, and the user device 1401 does not report any information about hub assignments back the accessory 1402. In that case, at endpoint 1444, the accessory 1402 may instead update its accessory state based on being contacted by (and/or connecting with) either one of first hub device 1404 or second hub device 1406 as desired (e.g., as described above). [0186] FIG.15 is another flow diagram illustrating an example process 1500 for reassigning an accessory device from one hub device to another hub device, according to an embodiment. Each of the elements and operations depicted in FIG.15 may be similar to one or more elements depicted in other figures described herein. For example, the user device 1501 may be similar to other user devices (e.g., a leader device), while the first, second, and third hub devices 1504, 1506, 1508 may be similar to other hub devices, and so forth. As with the process 1400 described previously, in some embodiments, process 1500 may be performed within a home environment (e.g. the home environment 1100 of FIG.11) or within any type of network environment (e.g., office network, school network, generic network, etc.). [0187] At block 1510, the first hub device 1504 can drop a currently assigned accessory 1502 (e.g., ending a session with the accessory 1502 by closing the socket or the like), for instance because the first hub device 1504 begins to experience an increased processing load due to other activity at the first hub device 1504. At block 1512, the first hub device 1504 can indicate to the accessory 1502 that it has been dropped and disassociated. The first hub device can then update its slot information to reflect that accessory 1502 is no longer associated. In some embodiments, the first hub device 1504 can update its slot information in response to an increased processing load before reporting to the accessory 1502 that it is being dropped. In these embodiments, the operations of blocks 1510, 1512, and 1514 can occur in different orders than depicted in the diagram of process 1500. The slot information can be similar to the slots 1216 described in detail with respect to FIG.12. [0188] At block 1516, upon receiving information from the first hub device 1504 that it is being dropped, the accessory 1502 can update its state to reflect that it is no longer assigned to the first hub device. At block 1518, the accessory can request assignment from the user device 1501. Blocks 1520–1526 may comprise one or more operations that are similar to blocks 1410–1416 of FIG.14. At block 1526, the user device 1501 can receive a second hub information from the second hub device 1506 and a third hub information from the third hub device 1508. The second hub device 1506 can report hub information at block 1528, while the third hub device 1508 can report hub information at block 1530. In some embodiments, although not depicted in FIG.15, the user device 1501 may also obtain a first hub information from the first hub device 1504 and a hub information corresponding to its own attributes. In these embodiments, the first hub device 1504 may not have reported updated hub information to the user device 1501, leaving the user device 1501 unaware that the first hub device 1504 recently dropped accessory 1502 and would likely lose the subsequent scoring process among the hub devices. Such embodiments can represent instances wherein the scoring algorithm and communication between the hub devices and the user device 1501 are more efficient if the user device 1501 is agnostic to the particular cause for the accessory 1502 to make an assignment request. [0189] At block 1532, the user device 1501 scores the hubs based on the received accessory traits and hub information. Blocks 1532–1536 may comprise one or more operations that are similar to blocks 1422–1436 of FIG.14. At block 1536, the user device 1501 can assign the accessory 1502 to either the second hub device 1506 or the third hub device 1508 according to their connection scores. If the second hub device 1506 has the higher connection score, it can receive assignment instructions at block 1542, update its slots accordingly at endpoint 1544, and connect to the accessory device 1502 at endpoint 1548. Similarly, if the third hub device 1508 has the higher connection score, it can receive assignment instructions at block 1538, update its slots at endpoint 1540, and connect to the accessory 1502 at endpoint 1548. The operations at endpoints 1544, 1540, and/or 1548 can be performed in any order. In other words, the second hub device 1506 can connect to the accessory 1502 at endpoint 1548 before or after it updates its slot information at endpoint 1544, and the same is true for endpoints 1548 and 1540. [0190] As with several previous blocks, one or more of the operations of block 1546 and endpoint 1548 may be similar to one or more operations of block 1442 and endpoint 1444 as described with respect to FIG.14. [0191] FIG.16 is another flow diagram illustrating an example process 1600 for reassigning an accessory device from one hub device to another hub device, according to an embodiment. Each of the elements and operations depicted in FIG.16 may be similar to one or more elements depicted in other figures described herein. For example, the user device 1601 may be similar to other user devices (e.g., a leader device), while the first, second, and third hub devices 1604, 1606, 1608 may be similar to other hub devices, and so forth. As with the process 1400 described previously, in some embodiments, process 1600 may be performed within a home environment (e.g. the home environment 1100 of FIG.11) or within any type of network environment (e.g., office network, school network, generic network, etc.). [0192] At block 1610, the first hub device 1604 can lose connectivity to the network or lose a connection with the accessory 1602, for instance because the first hub device is turned off or moved. In some examples, a hub device (e.g., first hub device 1604) acting as a hub for an accessory (e.g., accessory 1602) may be configured to ping the accessory every so often (e.g., every 15-30 seconds or the like), informing the accessory that it is still acting as the hub. If the accessory 1602 does not detect the ping within a threshold period of time, then the accessory device 1602 can enter a dropped state at block 1616. The ping may be a “keep alive” message that is sent to each connected accessory. In some examples, the “keep alive” message may be a request from the first hub device 1604 to read a “ping” characteristic of the accessory 1602. When the accessory device 1602 detects that the first hub device 1604 has read the “ping” characteristic, detection of that reading of the “ping” characteristic informs the accessory 1602 that the first hub device 1604 is still acting as the hub and the session is still active. Alternatively, instead of the hub devices sending “ping” messages to accessories (and reading accessory characteristics), in some cases, the accessory devices may be configured to initiate pings to their assigned hubs, to validate the connection to each assigned hub. If an accessory pings its respective hub, and is unable to validate the connection, the accessory device 1602 can enter the dropped state at block 1616. [0193] In some examples, the accessory 1602 may stay in the dropped state at block 1616 for a period of time (e.g., a “grace period”) before requesting a new hub. If the first device 1604 comes back online and attempts to the connect (e.g., establish a new socket and/or session) with the accessory 1602, then the accessory 1602 can reassign to the first hub device 1604 (e.g., reconnect to the first hub device 1604) without needing to request a new hub from the leader (e.g., the user device 1601). However, if the grace period expires, the accessory 1602 will instead transition to block 1618, where the accessory 1602 will request assignment of a new hub from the leader (e.g., the user device 1601). [0194] Blocks 1620–1626 may comprise one or more operations that are similar to blocks 1410–1416 of FIG.14 or blocks 1520-1526 of FIG.15. At block 1626, the user device 1601 can receive a second hub information from the second hub device 1606 and a third hub information from the third hub device 1608. The second hub device 1606 can report hub information at block 1628, while the third hub device 1608 can report hub information at block 1630. In some embodiments, although not depicted in FIG.16, the user device 1601 may also obtain a first hub information from the first hub device 1604 and a hub information corresponding to its own attributes. In these embodiments, the first hub device 1604 may not have reported updated hub information to the user device 1601, leaving the user device 1601 unaware that the first hub device 1604 recently dropped accessory 1602 and would likely lose the subsequent scoring process among the hub devices. Such embodiments can represent instances wherein the scoring algorithm and communication between the hub devices and the user device 1601 are more efficient if the user device 1601 is agnostic to the particular cause for the accessory 1602 to make an assignment request. [0195] At block 1632, the user device 1601 scores the hubs based on the received accessory traits and hub information. Blocks 1632–1636 may comprise one or more operations that are similar to blocks 1422–1436 of FIG.14. At block 1636, the user device 1601 can assign the accessory 1602 to either the second hub device 1606 or the third hub device 1608 according to their connection scores. If the second hub device 1606 has the higher connection score, it can receive assignment instructions at block 1642, update its slots accordingly at endpoint 1644, and connect to the accessory device 1602 at endpoint 1648. Similarly, if the third hub device 1608 has the higher connection score, it can receive assignment instructions at block 1638, update its slots at endpoint 1640, and connect to the accessory 1602 at endpoint 1648. The operations at endpoints 1644, 1640, and/or 1648 can be performed in any order. In other words, the second hub device 1606 can connect to the accessory 1602 at endpoint 1648 before or after it updates its slot information at endpoint 1644, and the same is true for endpoints 1648 and 1640. [0196] As with several previous blocks, one or more of the operations of block 1646 and endpoint 1648 may be similar to one or more operations of block 1442 and endpoint 1444 as described with respect to FIG.14. [0197] FIG.17 illustrates an example process 1700 for transferring hub management from one user device to another user device, according to an embodiment. A server device 1703 can participate in the transfer of hub management responsibilities from a first user device 1701 to a second user device 1702. The first user device 1701, second user device 1702, and server device 1703 can correspond to any one or more of the user devices, hub devices, and server devices described herein. In some embodiments, process 1700 may be performed within a home environment (e.g., the home environment 1100 of FIG.11). [0198] At block 1704, the first user device 1701 can receive information or instructions to transfer hub leadership to another hub device within the home environment. In some embodiments, the user device 1701 can determine that it is no longer capable of functioning as a leader device for the hub devices in the home environment. For example, the user device 1701 can be a tablet computer that is experiencing a significant processing load due to playing streaming media for a user in the home. Upon determining that it is no longer suitable to provide management for the other hub devices, the tablet computer can transmit a request to another device to transfer leadership. In other embodiments, another user device or a server device 1703 can instruct the first user device 1701 to relinquish its leadership duties. This may happen when a user reconfigures the devices within the home environment and selects a different device to act as a default leader device. The first user device 1701 can then transmit a leader reassignment request to the server device 1703. [0199] At block 1708, the server device 1703 can identify a new leader device. This operation is analogous to a user device reassigning an accessory device to another hub device. The server device can select a new leader device based on several criteria including, but not limited to, the processing capabilities of the new leader device, the number of hub devices and accessory devices present within the home, whether the new leader device is a resident device of the home, and whether a user has indicated that a particular device should be the new leader device. In some embodiments, another user device or hub device within the home can perform one or more of the operations of the server device 1703, including selecting a new leader device based upon the criteria described above. [0200] Once a suitable device is selected to be the new leader, the first user device 1701 can assign leadership to the selected device at block 1710. As depicted in FIG.17, the new leader device can be the second user device 1702. As part of the assignment operation, the first user device 1701 may send information about hub devices, accessory devices, and the associations between them to the second user device 1702. This information can include the current hub attributes and accessory traits. In some embodiments, the first user device 1701 only sends an instruction to the second user device 1702 to accept leadership duties for the hub devices and accessories in the home environment. In still other embodiments, the server device 1703 can communicate directly with the second user device 1702 to provide the leadership assignment. For example, in some instances the first user device 1701 may lose network connectivity with the other devices in the home environment. The server device, without receiving a leader assignment from the first user device 1701, can receive information that the first user device is disconnected from the network and no longer capable of acting as a leader device. The server device 1703 can then direct the second user device 1702 to assume hub leadership. [0201] At block 1712, the second user device 1702 receives the leadership assignment. At decision 1714, the second user device determines whether it received hub and accessory information from the first user device 1701. If it did not, then the process proceeds to block 1716 and the second user device can query the hubs for their current hub attributes and accessory assignment information. Once the second user device 1702 has the current hub information, it can store it at endpoint 1718, either at the second user device or another device. [0202] FIG.18 is a flow diagram showing an example process 1800 for a user device to assign an accessory device to a selected hub device from among a plurality of hub devices. In some embodiments, one or more of the operations of process 1800 may be similar to those as described in reference to FIGS.10 and 14. [0203] At block 1802, a user device may receive a first information about a first hub device and a second information about a second hub device. The first information and second information can correspond to hub attribute information as described herein and may be similar to hub attributes 1210 and slots 1216 of FIG.12 and device attributes 1336 of FIG. 13. In some embodiments, one or more of the operations of block 1802 may be similar to one or more operations described for process indicator 1240 in reference to FIG.12 or block 1416 of FIG.14. [0204] At block 1804, the user device can receive a connection request from an accessory. The connection request can be a request to connect to a hub device to which the user device assigns the accessory. In some embodiments, one or more of the operations of block 1804 may be similar to one or more operations described for block 1412 of FIG.14. [0205] At block 1806, the accessory device can send accessory information to the user device for use in determining the accessory assignment. The accessory information can include information about accessory attributes or traits and requirements of assigned hub devices. In some embodiments, one or more of the operations of block 1806 may be similar to one or more operations described for process indicator 1230 of FIG.12 and block 1414 of FIG.14. [0206] At block 1808, the user device can determine scores for the first hub device and the second hub device by comparing the accessory attribute information received at block 1806 with the first information and the second information received from the first and second hub devices at block 1802. In some embodiments, one or more of the operations of block 1808 may be similar to one or more operations described for block 1424 of FIG.14. [0207] At block 1810, the user device can compare the scores determined at block 1808 to determine whether to assign the accessory to the first hub device or the second device. The determination can be based upon which of the hub devices has the higher score. In some embodiments, one or more of the operations of block 1810 may be similar to one or more operations described for decision 1428 of FIG.14. [0208] At block 1812, the selected hub device can receive instructions to connect to the accessory. In some embodiments, connecting to the accessory can include creating, at the hub device, an accessory interaction instance corresponding to the assigned accessory device. In some embodiments, one or more of the operations of block 1802 may be similar to one or more operations described for block 1430 of FIG.14 or block 1536 of FIG.15. [0209] Illustrative techniques for load balancing between a plurality of hub devices and accessories are described above. Some or all of these techniques may, but need not, be implemented at least partially by architectures such as those shown at least in FIGS.10-18 above. While many of the embodiments are described above with reference to server devices, accessory devices, user devices, and hub devices, it should be understood that other types of computing devices may be suitable to perform the techniques disclosed herein. Further, in the foregoing description, various non-limiting examples were described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the examples. However, it should also be apparent to one skilled in the art that the examples may be practiced without the specific details. Furthermore, well-known features were sometimes omitted or simplified in order not to obscure the example being described. [0210] Although specific example embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the disclosure. Embodiments are not restricted to operation within certain specific data processing environments, but are free to operate within a plurality of data processing environments. Additionally, although embodiments have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly. [0211] Examples of the described techniques can be illustrated by the below clauses. [0212] Clause 1. A method, comprising: receiving, by a user device, first information about a first hub device of a plurality of hub devices and second information about a second hub device of the plurality of hub devices; receiving, by the user device, a connection request from an accessory; receiving, from the accessory, accessory attribute information; comparing, by the user device, the accessory attribute information of the accessory against the first information about the first hub device and the second information about the second hub device; determining, based at least in part on the comparison, whether the accessory is to connect to the first hub device or the second hub device; and in accordance with a determination that the accessory is to connect to the first hub device, providing instructions to the first hub device to connect to the accessory. [0213] Clause 2. The method of clause 1, wherein the first information about the first hub device comprises at least one of a set of capabilities of the first hub device or a number of available connection slots of the first hub device, and wherein the second information about the second hub device comprises at least one of a set of capabilities of the second hub device or a number of available connection slots of the second hub device. [0214] Clause 3. The method of clause 2, wherein comparing the accessory attribute information against the first information about the first hub device and the second information about the second hub device comprises: generating a first metric for the accessory potentially connecting to the first hub device based at least in part on the accessory attribute information and the set of capabilities of the first hub device; multiplying the first metric times the number of available connection slots of the first hub device to generate a first connection score; generating a second metric for the accessory potentially connecting to the second hub device based at least in part on the accessory attribute information and the set of capabilities of the second hub device; and multiplying the second metric times the number of available connection slots of the second hub device to generate a second connection score. [0215] Clause 4. The method of clause 3, wherein determining whether the accessory is to connect to the first hub device or the second hub device comprises selecting which of the first connection score or the second connection score is higher. [0216] Clause 5. The method of clause 1, further comprising: receiving, by the user device, hub connectivity information about the first hub device; and determining, based at least in part on the hub connectivity information, that the first hub device is no longer connected to the accessory. [0217] Clause 6. The method of clause 5, further comprising, in accordance with the determination that the first hub device is no longer connected to the accessory: comparing, by the user device, the accessory attribute information against the second information about the second hub device and third information about a third hub device; determining, based at least in part on the comparison, whether the accessory is to connect to the second hub device or the third hub device; and providing instructions to either the second hub device or the third hub device to connect to the accessory according to the determination. [0218] Clause 7. The method of clause 1, further comprising: receiving, by the user device, information that identifies the user device as a leader hub device configured to manage connections between a plurality of hub devices and a plurality of accessory devices, the first hub device and the second hub device being of the plurality of hub devices, and the accessory being of the plurality of accessory devices. [0219] Clause 8. The method of clause 7, wherein the user device is one of the plurality of hub devices. [0220] Clause 9. The method of clause 8, further comprising: determining, by the user device, that the user device is no longer suitable to be the leader hub device; and in accordance with the determination, assigning hub leader responsibility to another hub device of the plurality of hub devices. [0221] Clause 10. The method of clause 9, wherein assigning hub leader responsibility to the another hub device comprises: transmitting, by the user device, a hub leader reassignment request to a server device configured to provide second information that identifies a second user device as the leader hub device. [0222] Clause 11. The method of clause 1, further comprising: receiving, by the user device, hub processor usage information about the first hub device; and determining, based at least in part on the hub processor usage information, that the first hub device is no longer capable of responding to the accessory within a threshold amount of time. [0223] Clause 12. The method of clause 11, further comprising, in accordance with the determination that the first hub device is no longer capable of responding to the accessory within a threshold amount of time: comparing, by the user device, the accessory attribute information against the second information about the second hub device and third information about a third hub device; determining, based at least in part on the comparison, whether the accessory is to connect to the second hub device or the third hub device; and providing instructions to either the second hub device or the third hub device to connect to the accessory according to the determination. [0224] Clause 13. The method of clause 1, further comprising: receiving, by the user device, functionality information about the first hub device; and determining, based at least in part on the functionality information, that the first hub device is no longer a best hub for the accessory. [0225] Clause 14. The method of clause 13, further comprising, in accordance with the determination that the first hub device is no longer a best hub for the accessory: comparing, by the user device, the accessory attribute information against the second information about the second hub device and third information about a third hub device; determining, based at least in part on the comparison, whether the accessory is to connect to the second hub device or the third hub device; and providing instructions to either the second hub device or the third hub device to connect to the accessory according to the determination. [0226] Clause 15. The method of clause 1, further comprising: receiving, by the user device, a second connection request from a second accessory; receiving, from the second accessory, second accessory attribute information; comparing, by the user device, the second accessory attribute information against the first information about the first hub device and the second information about the second hub device; determining, based at least in part on the comparison, whether the second accessory is to connect to the first hub device or the second hub device; and in accordance with a determination that the second accessory is to connect to the first hub device, providing instructions to the first hub device to connect to the second accessory. [0227] Clause 16. The method of clause 1, further comprising: receiving, by the user device, a second connection request from a second accessory of a plurality of accessory devices comprising at least the first accessory and the second accessory; receiving, from the second accessory, second accessory attribute information; comparing, by the user device, the second accessory attribute information against the first information about the first hub device and the second information about the second hub device; determining, based at least in part on the comparison, whether the second accessory is to connect to the first hub device or the second hub device; in accordance with a determination that the second accessory is to connect to the second hub device, providing instructions to the second hub device to connect to the second accessory; and in accordance with a determination that the second accessory is to connect to the first hub device, providing instructions to the first hub device to connect to the second accessory. [0228] Clause 17. The method of clause 16, further comprising: managing, by the user device, a first state of the accessory and a second state of the second accessory, the first state identifying that the accessory is connected to the first hub device, and the second state identifying that the accessory is connected to one of the first accessory or the second accessory. [0229] Clause 18. The method of clause 17, further comprising: managing, by the user device, a third state of a third accessory of the plurality of accessories, the third state identifying that the third accessory is not connected to any hubs of the plurality of hub devices. [0230] Clause 19. A user device, comprising: a memory configured to store computer-executable instructions; and a processor configured to connect to the memory and execute the computer- executable instructions to at least perform the method of any of clauses 1-18. [0231] Clause 20. A computer-readable storage medium configured to store computer- executable instructions that, when executed by a user device, cause the user device to perform the method of any of clauses 1-18. Techniques For Establishing Communications With Third-Party Accessories [0232] Embodiments of the present disclosure can provide techniques for establishing communications between accessory devices and cellular-capable devices. As a first example, consider a home environment corresponding to a home. A person within the home may want to make a telephone call using a voice command. The person may make a verbal request (e.g., “Computer, call Mom”) to an accessory device (e.g., a third-party accessory that is not manufactured or designed by the same entity that manufactured or designed a home device (e.g., a hub) or a cellular-capable device (e.g., a smart phone)). The accessory device can determine that the request was intended for the device and then transmit the received audio information to the hub device (e.g., a hub speaker). The hub device can process the audio information to determine the nature of the request and prepare a corresponding response (e.g., connect to the cell phone to place the call). Alternatively, or partly in combination with the above, the hub device may transmit some or all of the verbal request to a server computer (e.g., implementing a service provider), where the service provider can determine the nature of the request and/or prepare a corresponding response. The hub device can then communicate with the cellular-capable device to instruct the cellular-capable device to place the call and to establish a separate audio communication channel with the accessory. The hub device can then enter into a listening state to listen for a request from the user to end the phone call (e.g., “Computer, hang up.”). When the hub device receives the hang-up request, it can send instructions to the accessory device to terminate the call. The accessory device can then transmit information to the cellular-capable device to end the call. [0233] As an illustration of the example above, the home environment can include numerous “smart” devices, e.g., electronic devices with features allowing them to operate, to some extent, interactively and autonomously. The smart devices can have various functionality, including cameras, speakers, thermostats, headphones and headsets, phones, or media players. The smart devices can also have various network communication capabilities, including WiFi, Ethernet, Bluetooth, Zigbee, cellular, and the like. The devices can be produced by various manufacturers. In some instances, the smart devices may be categorized into hub devices and accessory devices. A hub device can be a resident device of the home (e.g., a smart speaker, a smart digital media player configured to control a television (TV), a mobile phone, etc.). While not always, in some examples, a resident device may be expected to reside within the home and not move (e.g., within the home or to outside of the home) often. A hub device can have capabilities equal to or exceeding the capabilities of an accessory device. For example, a hub device can be a mobile phone, which can include wireless (e.g., WiFi) and cellular communications capabilities, multimedia capabilities, and a device assistant. In this same example, an accessory device can be a smart speaker, which can include audio media and wireless communications capabilities but lack a device assistant. A device assistant can be a virtual assistant program configured to interact with a user. In these examples, depending on its capabilities, a smart speaker can be either a hub device or an accessory device. In some examples, if an accessory is manufactured by an entity different from the entity that manufactured the hub devices, the accessory may not initially be configured with the ability to communicate with the user devices. In some instances, the hub device manufacturer may provide an accessory development kit (“ADK”) for installation on the accessory that enables such communication either after the accessory is manufactured, sold, provisioned, or used. A controller device can be a hub device as described herein, and may include user interface features. In some embodiments, the controller device is a leader device selected from among the hub devices in the home environment. As used herein, the terms hub device, user device, leader device, and controller device can indicate one or more similar devices distinguished from the accessory devices. A cellular-capable device can be any device associated with the home environment that is capable of connecting to a cellular network. The cellular-capable device can be a hub device or an accessory device, in some embodiments. [0234] In some embodiments, the hub device can obtain information about the accessory devices present in the home environment. This information can be obtained by the hub device communicating directly with accessory devices sharing the same network within the home environment. In other embodiments, information about accessory devices can be sent to the hub device by a second hub device, a user device configured as a leader device, or a remote server device (e.g., a service provider). For example, a user in the home may add a new accessory device to the home environment. As part of this process, the user can interact with a second hub device (e.g., a mobile phone) to configure the new accessory device and send the new accessory device information to the first hub device. As another example, a leader device in the home environment can have information about a plurality of accessory devices in the home environment and report information about some or all of the accessory devices to the hub device. The hub device can then use the information to form an association with the corresponding accessory devices. The accessory information may be stored by the hub device. [0235] The hub device can associate with a plurality of accessory devices by creating an accessory interaction instance for each accessory device. The interaction instances can be software modules or processes configured to perform tasks at the hub device. In some embodiments, the interaction instances can each implement and/or communicate with a device assistant. For example, a hub device can receive information about an accessory smart speaker and a smart thermostat located in the home environment. The hub device can create two interaction instances corresponding to a device assistant, one for each of the smart speaker and the smart thermostat. The interaction instances can be duplicates of the device assistant in some embodiments, while in other embodiments the instances can be a collection of modules including the device assistant and other processes for carrying out tasks on the hub device. The interaction instances can comprise different modules or processes depending on the associated accessory and its capabilities. It should be understood that any suitable combination of processes running on the hub device can be included in an interaction instance corresponding to an accessory device. [0236] Continuing with the first example above, a user may voice a request to an accessory. For example, the user may speak into the microphone of a nearby smart speaker (or thermostat, light bulb, etc.), “Computer, call Mom?” In this example, the request (“call Mom”) may correspond to a portion of the of the user’s audio input into the smart speaker. The opening phrase (“Computer”) may correspond to a different portion of the user’s audio input and can be a trigger or wake word. In some embodiments, the smart speaker may perform speech recognition processing on the wake word. Based on the processing, the smart speaker can determine if the user’s speech was intended to be a request or command to which the speaker should respond. If so identified, the smart speaker can then transmit the user audio to a hub device running an accessory interaction instance corresponding to the smart speaker. In some embodiments, the accessory device can store a copy of the audio input temporarily for transmission to the user device after processing the wake word portion. In other embodiments, upon processing the wake word portion of the audio input, the accessory device can establish a streaming audio connection with the hub device to relay the portion of the user’s audio input that follows the wake word. In these embodiments, the accessory device can transmit a stored copy of the wake word portion of the audio input to the hub device for additional processing. [0237] Upon receiving an audio input from the smart speaker, the hub device can perform additional processing on both the wake word portion of the audio input and the portion corresponding to a request or command. For example, the hub device can perform natural language processing (“NLP”) on the wake word. Based on this wake word processing, the hub device can then process the portion of the audio corresponding to the request. If the hub device determines that the wake word portion was not, in fact, an accurate wake word, it can ignore the remaining portion of the audio or terminate the audio stream from the accessory. In some embodiments, the speech processing module on the hub device can be part of the accessory interaction instance. The interaction instance can also transmit all or a portion of the audio input to another device for analysis (e.g., to a service provider device). This service provider device can be a remote server computer or cloud device that can perform speech processing and parse the request for an appropriate response. In some cases, the hub device performs the processing of the wake word while the remaining portion of the audio is processed remotely. However, in other examples, the hub device can handle all the processing. Parsing the request includes determining the content and context of the user’s spoken audio and providing a response for the hub device to take action on. In the current example, the response could be to communicate with a cellular-capable device to place a call to Mom, which can be performed by the hub device using an appropriate process or by the remote server device, or combination of the two devices. In some embodiments, the hub device can relay instructions for establishing the call, including the identity of the selected cellular-capable device, to the accessory device. The accessory device can then establish communications with the cellular-capable device and send instructions to place the call. In another example, the hub device can relay instructions for establishing the call, including the identity of the accessory device, to the cellular-capable device, and then the cellular-capable device can establish communications with the accessory device and then place the call. Calling Mom can include accessing user information that identifies “Mom” within the context of the user making the request, for example by identifying the user and then accessing that user’s contacts information. Mom’s phone number can then be obtained and sent to the cellular-capable device. [0238] Once a response has been determined, the hub device can execute that response. This can include identifying a cellular-capable device and sending it instructions to place a call. The instructions can include information identifying the call recipient, including a phone number to dial out or a recipient’s identity stored locally at the cellular-capable device to provide the phone number at the cellular-capable device. For example, in one embodiment, the hub device can obtain Mom’s phone number as part of processing of the audio request and then instruct the cellular-capable device to dial that number. In another embodiment, the hub device can instruct the cellular-capable device to call “Mom” and let the cellular-capable device obtain the number using its own information about the identity of Mom. This latter embodiment is applicable in instances where the hub device can identify a cellular-capable device corresponding to the user making the call request, but is unable to access contacts information for that user, for example if the contacts are only stored at the cellular-capable device. The preparation and execution of the response can take place in the interaction instance corresponding to the accessory. A response that requires a particular action (e.g., placing the phone call) can be delegated as appropriate from the interaction instance to another process on the hub device or to another device with which the hub device can communicate. [0239] The hub device can also communicate with the accessory device to identify the cellular-capable device that is placing the call and instruct the accessory to establish a communications channel with the cellular-capable device. The communications channel can be a real time audio connection using Real-time Transport Protocol (“RTP”) or other suitable method. The audio channel can be used to send and receive audio between the accessory device and the cellular-capable device. In some embodiments, the accessory device can establish a second communications channel with the cellular-capable device to send phone control instructions to the cellular-capable device. These phone control instructions can be instructions to end the call based upon the accessory receiving information from the hub device that the user has requested to end the call. In some embodiments, the second communications channel can also be used by the accessory device to send instructions to the cellular-capable device to initiate the call in instances where the hub device does not communicate the call instructions directly to the cellular-capable device. [0240] Once the call has been established, the hub device can enter a call listening state at the accessory interaction instance corresponding to the accessory device. When in the call listening state, the hub device only listens for a “hang up” or “end call” or other similar command from the accessory device indicating that the user wishes to terminate the phone call. In this way, the device assistant and other processes associated with that accessory interaction instance do not inadvertently capture, record, or process audio information from the phone call. As an example, at the conclusion of the phone call, the user can say “Computer, hang up.” As with the call request described above, the “Computer” portion of this command can correspond to a wake word that indicates to the accessory device that the audio that follows the wake word may be a user command and not a part of phone conversation. The phrase “hang up” can be an end word. When in the call listening state, the accessory can receive the audio corresponding to the wake word and the end word. The wake word will be processed as with other wake words described herein. If the wake word is detected, then the accessory interaction instance can process the end word. Because the hub device is in the call listening state, the end word processing can be more limited than audio processing for other user requests received. For example, the accessory interaction instance may perform the end word detection locally without transmitting the audio to a remote service provider for NLP. In some embodiments, when in the call listening state, the accessory interaction instance at the hub device may only process a limited portion of an audio input following a wake word, such that the accessory interaction instance only receives a short piece of audio sufficient to contain an end word like “hang up” or “end call.” In this way, the accessory interaction instance does not capture user audio that does not correspond to an end word. [0241] The call listening state can be, in some embodiments, a state of the particular accessory interaction instance associated with the accessory device connected to a call. Other accessory interaction instances present at the hub device can function normally and may not be limited by the call listening state. For example, continuing with the user call above, the user may be on a phone call with Mom using the smart speaker. A second user in the home may make a request to the smart thermostat also associated with the hub device (e.g., “Computer, turn the heat up to 72° F”). The accessory interaction instance corresponding to the smart thermostat may not be in the call listening state and can process this second user request normally, instructing the thermostat to change its temperature set point in accordance with the request. This allows the hub device to retain its accessory management functionality while ensuring the data privacy of the first user and the external call recipient. [0242] FIG.19 is a simplified block diagram of an example embodiment. The process 1900 is an example high-level process flow for a system that includes an accessory device 1912 that can receive a call request and establish communications with a cellular-capable device 1930 via a controller device 1920. The diagram 1901 shows states of the system that correspond to the blocks of the process 1900. The process 1900 can be performed within a home environment containing multiple accessory devices, hub devices, and cellular-capable devices. As depicted here, the accessory device 1912 can be a smart speaker while the controller device 1920 can be a hub speaker. Although described as being a particular device, it should be apparent that the accessory device 1912 and the controller device 1920 can be several types of smart devices in various combinations and number. For example, a smartphone, media device (e.g., a smart TV), or tablet (either connected to a cellular network, to a local area network via WiFi of a home network, or to a wide area network (“WAN”)) can perform one or more of the operations of the process 1900. [0243] Turning to the process 1900 in more detail, at block 1902 the accessory device 1912 can receive a call request 1916 from a user 1914. In some embodiments, the call request 1916 can contain a portion of audio corresponding to the request (e.g., “place a call”) and a second portion corresponding to a wake word (e.g., “Computer”). The wake word need not be a single word and can be a word or phrase that signals to the system that the user has or is about to voice a request, command, or other audible interaction to the system. Upon receiving input containing a wake word, the accessory 1912 can process that portion of the call request 1916 at a first level to determine the presence of the wake word. The first level processing can be done in a time and resource efficient manner that determines that the wake word may be present. For example, the accessory 1912 can perform voice pattern matching using stored voice patterns corresponding to users speaking the wake word. The stored patterns can be associated with the users in a home environment containing the system or can be generic patterns that are applicable to a large number of possible users. In this way, the accessory device 1912 is not burdened with sophisticated speech detection processes but also does not respond to every extraneous audio input received by users or other sources in its vicinity. [0244] Moving down to block 1904, upon detecting the wake word, the accessory device 1912 can transmit the received call request 1916 to the controller device 1920 where it will be processed. As illustrated, the smart speaker 1916 has a corresponding accessory interaction instance 1922 on the controller device 1920, such that the accessory interaction instance 1922 manages the processing of the call request 1916 received from the smart speaker 1912. The accessory interaction instance 1922 can contain modules configured to process the call request 1916. For example, accessory interaction instance 1922 can include a speech detection module that can analyze the portion of the call request 1916 that corresponds to the wake word. This analysis can be at a second level that can confirm the presence of the wake word to a higher degree of probability than the wake word detection at the smart speaker 1912. In addition, in some embodiments, the speech detection module can determine a user’s language and perform the wake word detection based on the determined language. If the speech detection module of the accessory interaction instance 1922 does not detect the wake word, the controller device 1920 can ignore the audio input. [0245] The controller device 1920 may also have access to user profiles 1926, 1928. The user profiles 1926, 1928 may be stored at the controller device 1920 or another device like a server device. The user profiles 1926, 1928 can correspond to users within the home environment and comprise information that can be used to identify one or more cellular- capable devices associated with the users. For example, user profile 1926 can correspond to user 1914 and may identify that cellular-capable device 1930, depicted as a smartphone, is associated with user 1914. When processing the call request 1916, the accessory interaction instance 1922 may identify user 1914 as having made the call request 1916 and access user profile 1926 to determine an appropriate cellular-capable device to execute the call. Moreover, the user profile 1926 can also comprise information related to potential recipients of the call. For example, the user profile 1926 can include the user’s 1914 contacts list. The accessory interaction instance 1922 can use the contacts information when parsing the call request, for example to determine a dial-out phone number for the cellular-capable device 1930 to call when executing the call request 1916. In some embodiments, the user profiles 1926, 1928 can be stored at a remote server or other device and can be accessed by a remote service provider used to process the call request. [0246] Moving to block 1906, the controller device 1920 can process the call request to identify a cellular-capable device 1930 to place the call. As described above with reference to block 1904, the controller device 1920 may access user profiles 1926, 1928 to determine an appropriate cellular-capable device 1930. [0247] At block 1908, the controller device 1920 can instruct the cellular-capable device 1930 to place the call corresponding to the call request. In some embodiments, this can include determining a dial-out number for the cellular-capable device 1930 to dial when making the call. In other embodiments, the controller device 1920 can instruct the cellular- capable device 1930 to place the call based upon a label or other identifier contained within the call request 1916 (e.g., “Mom,” “the office,” etc.). In addition to sending instructions to the cellular-capable device 1930, the controller device 1920 can instruct the accessory device 1912 to establish a communications channel with the cellular-capable device 1930. This communications channel can be a real-time audio channel to send and receive the audio during the call. [0248] At block 1910, the accessory interaction instance 1922 at controller device 1920 can enter a call listening state to listen for a hang up command (e.g., “Computer, end call”). The hang up command can consist of a portion corresponding to a wake word (e.g., “Computer”) and a portion corresponding to an end word (e.g., “end call” or “hang up”). As with the wake word, the end word need not be a single word and can be any word or phrase identified to indicate the end of a phone call. When the user 1914 issues the hang up command, the accessory 1912 may process the wake word at the first level as described above with respect to block 1902. If the wake word is detected, the accessory 1912 can send the audio of the hang up command to the controller device 1920. The controller device 1920 can process the wake word at the second level as described with respect to block 1904. Upon confirming that the wake word is present, the accessory interaction instance 1922 can process the end word portion of the hang up command. Processing the end word can be performed in a limited manner, so that controller device 1920 does not receive or process additional audio information potentially captured from the ongoing phone call at the accessory device 1912. If the end word is detected, the controller device 1920 can transmit instructions to the accessory device 1912 to terminate the call. The accessory device 1912 can then issue a hang up command to the cellular-capable device 1930 to close the cellular connection at cellular- capable device 1930. Alternatively, in some embodiments, the controller device can instruct the cellular-capable device 1930 both to end the call directly and to transmit an indication to the accessory 1912 that the call has been successfully terminated. [0249] FIG.20 is a schematic of a home environment containing hub devices, accessory devices, and cellular-capable devices, according to some embodiments. Hub devices can include a hub speaker 2002 and a media player 2004. These hub devices can correspond to controller device 1920 from the embodiments described above with respect to FIG.19. The smartphone 2006 can be a cellular-capable device such as the cellular-capable device 1930 of FIG.19. In several embodiments, the smartphone 2006 can act as a hub device. Accessory devices can include smart speakers 2012, 2014, a smartwatch 2016, and a thermostat 2024. Similarly, these accessory devices can correspond to accessory device 1912 described with respect to FIG.19. All or some of these accessory devices may be third-party devices (e.g., not manufactured, programmed, or provisioned by the manufacturer, programmer, or provisioner of the hub devices or user devices). Because of this, they may not be automatically and/or initially compatible with the user devices. Each hub device in the home environment 2000 can be associated with zero, one, or more accessory devices. As illustrated by the long-dashed lines, hub speaker 2002 is associated with smart speakers 2012, 2014 and smartwatch 2016 while media player 2004 is associated with thermostat 2024. The smartphone 2006 is not associated with an accessory device. The devices within the home environment 2000 can be configured to communicate using one or more network protocols over one or more networks associated with the home environment 2000. For example, the home environment 2000 can be associated with a local area network (“LAN”), a WAN, a cellular network, a personal area network, or other network, and the devices can communicate using a WiFi connection, a Bluetooth connection, a Thread connection, a Zigbee connection, or other communication method. [0250] The arrangement of associations of accessory devices with hub devices can include various different combinations and can be modified by another device associated with the home environment, for example one of the hub devices or a user device. For example, a user device can associate a new accessory device to one of the hub devices in the home. In some embodiments, the assignment of accessory devices to hub devices can be based on a scoring algorithm applied by the user device. The user device can also use this scoring algorithm to transfer existing accessory devices from one hub device to another. This transfer can occur automatically based on information that the hub device receives about the home environment 2000, including, but not limited to, information that another hub device may be more suitable for association with one or more accessories or that accessories have been added to or removed from the home environment 2000. When an accessory is assigned to or associated with a hub device, the hub device can create an accessory interaction instance corresponding to each assigned accessory. Thus, the hub device can comprise a unique software ecosystem for each assigned accessory. The suitability of any particular hub device to associate with an accessory can be based at least in part on the capabilities of the hub device, the capabilities of the accessory device, the current processing load experienced by the hub device, the locations of the devices within the home environment, and the status of communications between the devices on a network. Many other criteria for rearranging device associations in a home environment are contemplated. [0251] In some embodiments, non-resident accessory devices and hub devices may also leave the home environment or lose network connectivity with the home environment. An accessory device that leaves the home environment can be disassociated by the previously associated hub device. Accessory devices associated with a hub device that loses network connectivity with the home environment can be reassigned by another hub device that retains network connectivity. In this case, the other hub device can receive information that the hub device is no longer able to communicate with the accessory device and reassign the accessory device. Some embodiments may have a hub device designated a leader device to manage the assignment of accessory devices among the hub devices within the home environment. In other embodiments, if hub devices and accessory devices are associated and leave the home environment and lose network connectivity, the hub devices can retain their associations with the accessory devices and perform the embodied methods described herein. [0252] As a hub device, smartphone 2006 can communicate with the other hub devices within the home environment, including receiving accessory assignments from a user device or leader device. As such, the other hub devices can communicate with smartphone 2006 to instruct it to place calls over a cellular network in response to a user call request. In some embodiments, smartphone 2006 may not be capable of acting as a hub device but remains known to the hub devices, user devices, or a leader device within the home such that call requests can be transmitted to the smartphone 2006 as a cellular-capable device. In other embodiments, the smartphone 2006 may be identifiable by a remote device (e.g., a server device in communication with one or more of the networks associated with the home environment). [0253] Continuing with FIG.20, a home environment 2000 can have multiple users 2030, 2034 making audio requests 2032, 2036 of accessories. The requests 2032, 2036 can occur separately or simultaneously and can be received by multiple accessory devices as depicted by the short-dashed lines. For example, request 2032 can be received by smart speaker 2014 or smartwatch 2016, while request 2036 can be received by smart speaker 2012 and thermostat 2024. As described previously, the arrangement of accessory devices and their associations can take various forms and can change over time. Thus, a user request may be received by multiple accessory devices associated with different hub devices. For example, user request 2036 is received by both thermostat 2024 associated with media player 2004 and by smart speaker 2012 associated with hub speaker 2002. As depicted, depending on their location in the home, user 2030 and user 2034 may not have direct access to a cellular- capable device to make a phone call. Moreover, each hub device may be assigned to more than one accessory device. The ability to pair an accessory device with a cellular-capable device, via the corresponding accessory interaction instance, to make a call allows the hub device to continue managing the functionality of other accessory devices while maintaining data privacy with regard to the ongoing call. [0254] As a specific example of the foregoing embodiments, consider the case where user 2030 makes a call request 2032. The receiving accessories, smart speaker 2014 and smartwatch 2016, may lack cellular communications capabilities. Likewise, hub speaker 2002 may not be a cellular-capable device. In some embodiments, accessory devices can coordinate with other accessory devices within the home environment 2000 to determine which accessory device should respond to a user request that is received by one or more accessory devices. For the purposes of this example, consider the case where smart speaker 2014 is the accessory device selected to process the call request 2032. Upon receiving the request 2032 and detecting the wake word, the smart speaker can transmit the request 2032 to hub speaker 2002. Hub speaker 2002 can process the call request 2032 and identify that smartphone 2006 is the appropriate cellular-capable device for executing the call. Hub speaker 2002 can then instruct smartphone 2006 to place the call and establish a communications channel with smart speaker 2014 for relaying the call audio. Alternatively, in some embodiments, the hub speaker 2002 can instruct the smart speaker 2014 to communicate with the smartphone 2006 to establish the call. The accessory interaction instance associated with smart speaker 2014 at hub speaker 2002 can then enter a call listening state and listen for user 2030 to speak the end word at smart speaker 2014. [0255] Continuing the above example, consider user 2034 making user request 2036 to ask what the current time is (e.g., “Computer, what time is it?”) during the time that user 2030 is conducting the phone call at smart speaker 2014. The request 2036 may be received by smart speaker 2012, which is associated with hub speaker 2002. Despite the accessory interaction instance associated with smart speaker 2014 at hub speaker 2002 being in the call listening state, the accessory interaction instance associated with smart speaker 2012 is not in a restricted state and can process the request 2036 normally and relay a response to smart speaker 2012 (e.g., “It is 10:30 p.m.). [0256] FIG.21 is another simplified block diagram illustrating a process 2100 of establishing communications between an accessory device and a cellular-capable device, according to some embodiments. In some embodiments, the accessory device 2102 can correspond to accessory devices described herein (e.g., accessory device 1912 of FIG.19). Similarly, a controller device 2104 can correspond to other controller devices or hub devices and the cellular-capable device 2106 can correspond to other cellular-capable devices as described herein. Controller device 2101, depicted here to be a hub speaker, can be a hub device, a leader device, a configuration device, or other device used to determine an appropriate cellular-capable device 2106 to place a call and direct the accessory device 2102 to connect to the cellular-capable device 2106. The controller device 2101 can be configured to communicate with other hub devices, the accessory device 2102, other accessories, and cellular-capable device 2106 over one or more networks described herein, including a LAN or a WAN. [0257] Multiple elements of the connection process 2100 are presented in more detail. The accessory device 2102 can comprise an ADK 2108. The ADK 2108 can be a software development kit (“SDK”) stored and configured to be executed or processed on the accessory device 2102. As used herein, an SDK can include application programming interfaces and related software libraries sufficient to enable the operation of other software within or associated with the SDK. In some embodiments, the ADK 2108 can be provided by an entity associated with the controller device 2104 (e.g., its manufacturer). The ADK 2108 can include a phone audio module 2110 and a phone control module 2112. The phone audio module 2110 can establish a real-time audio connection with the cellular-capable device 2106 to send and receive audio during a phone call. The phone control module 2112 can send and receive instructions and indications to and from the cellular-capable device 2106 corresponding to the device control of the phone connection. In some embodiments, the phone control module 2112 can, upon receiving a hang-up instruction from the controller device 2104, send a signal to the cellular-capable device 2106 to terminate the cellular connection to end the call. [0258] The controller device 2104 can comprise an accessory management module 2114, which can be a software process running on the controller device 2104. The accessory management module 2114 can, in some embodiments, receive, process, store, update, and transmit accessory management settings. For a particular user device, its accessory management settings can include a list of all accessories assigned to that controller device and other information related to the capabilities of those assigned accessories. The accessory management module can comprise user profile(s) 2116. These profile(s) 2116 can correspond to one or more users within a home environment and may contain information associating each user with one or more cellular-capable devices, including cellular-capable device 2106. The user profile(s) 2116 may also comprise information identifying one or more contacts or other information that can be used by the controller device 2104 to respond to a call request and direct the establishment of a call. The accessory management module 2120 can also comprise accessory interaction instance(s) 2118. The accessory interaction instance(s) 2118 can be created by the controller device 2104 for each accessory assigned to the controller device 2104. Each of the accessory interaction instance(s) 2118 may represent one or more distinct software ecosystems on the controller device. For example, the accessory interaction instance corresponding to accessory device 2102 may represent a first software ecosystem of the controller device while another accessory interaction instance corresponding to another accessory device may represent a second software ecosystem of the controller device. [0259] The cellular-capable device 2106 can comprise a media module 2120 and a phone control module 2122. The media module 2120 can, in some embodiments, send and receive media data, including phone audio, over one or more cellular networks to which the cellular- capable device 2106 can connect. The media module 2120 can also connect to the accessory device 2106 via a real-time audio or other channel through which the cellular-capable device 2106 can send and receive audio data corresponding to the phone audio. The phone control module 2122 can send and receive instructions and indications to and from the accessory device 2102 corresponding to the device control of the phone connection. In some embodiments, the phone control module 2122 can, upon receiving instructions from the controller device 2104, place a phone call by dialing a selected phone number or accessing contact information stored locally at the cellular-capable device and dialing a phone number associated with the contact information. [0260] Completing the detailed elements of FIG.21, process indicators 2130, 2140, 2150 represent data transmission between the accessory device 2102 and the controller device 2104, the controller device 2104 and the cellular-capable device 2106, and the accessory device 2102 and the cellular-capable device 2106, respectively. The process indicators 2130, 2140, 2150 can indicate communication over one or more networks between the various devices as described herein, including, but not limited to, a WiFi LAN, an Internet WAN. Process indicator 2130 indicates, in some embodiments, transmission of data corresponding to a user request to place a call at the accessory device 2102 and a subsequent response from the controller device 2104 providing an indication that the request was successfully processed. Similarly, process indicator 2140 indicates transmission of data including instructions to the cellular-capable device 2106 to place a call in response to the user request. In some embodiments, the cellular-capable device 2106 does not transmit any corresponding data or information back to the controller device 2104. Process indicator 2150 indicates transmission of data including the real-time audio of the phone call and phone control instructions or indications, including instructions to establish or terminate a call according to some embodiments. [0261] FIG.22 is a simplified block diagram 2200 illustrating at least some techniques for communicating between an accessory device 2201 and a cellular-capable device 2203 to place a phone call at the cellular-capable device 2203. The diagram 2200 includes some detailed architecture of representative devices as well as process flow arrows providing a general indication of the transfer of data or information. The process flow arrows are not intended to connote any specific architectural connections between the elements detailed herein. Each of the elements depicted in FIG.22 may be similar to one or more elements depicted in other figures described herein. For example, the accessory device 2201 may correspond to one or more of the accessories and accessory devices described herein, and so forth. In some embodiments, at least some of the elements in diagram 2200 may operate within the context of a home environment like the home environment 2000 of FIG.20. [0262] Turning to each element in further detail, accessory device 2201 can have audio input and output functionality, including an accessory audio input/output (“I/O”) 2204. The accessory audio I/O 2204 can include both hardware (e.g., speaker and microphone) and software/firmware necessary to provide audio input and output functionality. The accessory device 2201 also comprises an ADK 2206. The ADK 2206 may be similar to the ADK 2108 described above with respect to FIG.21. The ADK can include a wake word detection module 2208, an audio module 2210, and a phone control module 2212. The wake word detection module 2208 can perform a first processing of a portion of an audio input corresponding to a trigger or wake word. The wake word detection module can itself contain information about wake words and triggers, including, for example, triggering criteria and audio patterns corresponding to specific wake words. The audio module 2210 and phone control module 2212 can be similar to phone audio module 2110 and phone control module 2112, respectively, as described with reference to FIG.21. As shown by the process flow arrows, an audio input received at the accessory device 2201 can be processed by the wake word detection module 2208. If the wake word is detected, the accessory device can transmit the audio input to the controller device 2202 for further processing. The accessory device 2201 can continue to listen for the wake word during a phone call. Because the user will be speaking during the call, and the spoken audio transmitted from the audio module 2210 to the cellular-capable device 2203, the wake word detection module 2208 can allow the accessory device to distinguish user phone audio from audio intended to convey a request or command of the accessory device. [0263] The controller device can include a speech processing module 2214 comprising wake word detection module 2216. As depicted in FIG.22, the wake word detection module 2216 may have instances corresponding to each of the accessory interaction instances 2218, such that each instance of the wake word detection module 2216 is part of a separate software ecosystem at the controller device. The wake word detection module 2216 can process the wake word audio at a second level that can confirm the presence of the wake word to a higher degree of probability than the wake word detection module 2208 at the accessory device 2201. If the speech processing module 2214 does not detect the wake word, the controller device 2202 can ignore the audio input. If the wake word is detected, then the audio input can be further processed at the accessory interaction instances 2218. [0264] The accessory interaction instances 2218 can comprise a virtual device assistant 2220. During normal operation, the controller device 2202 can process the audio from a user request or other audio input that passes the wake word detection module 2216 by having the accessory interaction instances 2218 connect to a remote service and transmit a portion of the audio input to the remote service. NLP and other services used to process the audio input can comprise the remote service. During a call, however, the accessory interaction instance corresponding to accessory device 2201 can be in a call listening state. In this state, the device assistant 2220 may not process any other user audio except for an end word at end word detection module 2222. In some embodiments, the end word detection module can operate entirely within the corresponding accessory interaction instance, such that the device assistant 2220 does not transmit any of the phone call audio to a remote service or other device in the event that the wake word detection module 2216 indicates that the wake word was heard. In other embodiments, the device assistant 2220 can process only a limited portion of the audio input received after detecting the wake word. For example, the end word detection can process a short portion of audio sufficient to encompass end words “hang up” and “end call.” If the end word is detected, the accessory interaction instance can transmit a hang up command 2224 to the accessory device 2201. The accessory device 2201 can then signal to the cellular-capable device 2203 to end the call and terminate the audio between the devices. [0265] Cellular-capable device 2203 can comprise a media module 2230 that can be configured to send, receive, and process audio and video data. The media module can include a call module 2232. The call module 2232 can be configured to send, receive, and process the audio data of the phone call made via a cellular network 2250 to which the cellular-capable device is connected. The call module 2232 can transmit and receive audio data to and from the accessory device 2201 over an audio channel 2226, which can be a real-time audio channel using RTP or similar communication protocols. The cellular-capable device 2203 can also comprise a call services module 2234 that can be configured to perform processes including negotiating the phone call (e.g., dialing out) and receiving call instructions from the accessory device (e.g., terminate the call). The call services module 2234 can include a phone control module 2236 and an accessory discovery module 2238. The phone control module 2236 may be similar to the phone control module 2122 of FIG.21. The accessory discovery module 2238 can allow the cellular-capable device 2203 to discover and negotiate communications channels with accessory devices within the home environment. For example, in some embodiments, the cellular-capable device 2203 may receive instructions from the controller device 2202 to place a call and connect to accessory device 2201. The accessory discovery module 2238 can locate the accessory device 2201 within one of the networks of the home environment and, in conjunction with phone control module 2236, establish a communication connection with accessory device 2201, including call control channel 2228. [0266] FIG.23 is a simplified block diagram 2300 illustrating an example architecture of a system used to establish communications between an accessory device and a cellular capable device according to an embodiment. The diagram 2300 includes a controller device 2302, one or more accessory device 2304, a representative accessory device 2306, one or more network(s) 2308, a cellular-capable device 2310, and a cellular network 2312. Each of these elements depicted in FIG.23 may be similar to one or more elements depicted in other figures described herein. In some embodiments, at least some elements of diagram 2300 may operate within the context of a home environment (e.g. the home environment 2000 of FIG. 20). [0267] The accessory devices 2304 and representative accessory device 2306 may be any suitable computing device (e.g., smart speaker, smartwatch, smart thermostat, camera, etc.). In some embodiments, the accessory devices 2304, 2306 may perform any one or more of the operations of accessory devices described herein. Depending on the type of accessory device and/or location of the accessory device (e.g., within the home environment or outside the home environment), the accessory device 2306 may be enabled to communicate using one or more network protocols (e.g., a Bluetooth connection, a Thread connection, a Zigbee connection, a WiFi connection, etc.) and network paths over the network(s) 2308 (e.g., including a LAN or WAN), described further herein. [0268] In some embodiments, the controller device 2302 may correspond to any one or more of the controller devices or hub devices described herein. For example, the controller device 2302 may correspond to one or more of the hub devices of the home environment 2000 of FIG.20. The controller device may be any suitable computing device (e.g., a mobile phone, tablet, a smart hub speaker device, a smart media player communicatively connected to a TV, etc.). [0269] In some embodiments the one or more network(s) 2308 may include an Internet WAN and a LAN. As described herein, the home environment may be associated with the LAN, whereby devices present within the home environment may communicate with each other over the LAN. As described herein, the WAN may be external from the home environment. For example, a router associated with the LAN (and thus, the home environment) may enable traffic from the LAN to be transmitted to the WAN, and vice versa. [0270] As described herein, controller device 2302 may be representative of one or more controller devices or hub devices connected to one or more of the network(s) 2308. The controller device 2302 has at least one memory 2314, a communications interface 2316, one or more processing units (or processor(s)) 2318, a storage unit 2320, and one or more input/output (I/O) device(s) 2322. [0271] Turning to each element of controller device 2302 in further detail, the processor(s) 2318 may be implemented as appropriate in hardware, computer-executable instructions, firmware or combinations thereof. Computer-executable instruction or firmware implementations of the processor(s) 2318 may include computer-executable or machine executable instructions written in any suitable programming language to perform the various functions described. [0272] The memory 2314 may store program instructions that are loadable and executable on the processor(s) 2318, as well as data generated during the execution of these programs. Depending on the configuration and type of controller device 2302, the memory 2314 may be volatile (such as random access memory (“RAM”)) or non-volatile (such as read-only memory (“ROM”), flash memory, etc.). In some implementations, the memory 2314 may include multiple different types of memory, such as static random access memory (“SRAM”), dynamic random access memory (“DRAM”) or ROM. The controller device 2302 may also include additional storage 2320, such as either removable storage or non-removable storage including, but not limited to, magnetic storage, optical disks, and/or tape storage. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing devices. In some embodiments, the storage 2320 may be utilized to store data contents received from one or more other devices (e.g., other controller devices, cellular- capable device 2310, accessory devices 2304, or the representative accessory device 2306). [0273] The controller device 2302 may also contain the communications interface 2316 that allows the controller device 2302 to communicate with a stored database, another computing device or server, user terminals, or other devices on the network(s) 2308. The controller device 2302 may also include I/O device(s) 2322, such as for enabling connection with a keyboard, a mouse, a pen, a voice input device, a touch input device, a display, speakers, a printer, etc. [0274] The memory 2314 may include an operating system 2324 and one or more application programs or services for implementing the features disclosed herein, including a communications module 2326, a speech processing module 2328, and accessory interaction instance(s) 2330. The speech processing module 2328 further comprises a wake word module 2332 and the accessory interaction instance(s) 2330 further comprise a digital assistant 2334 and end word module 2336. [0275] The communications module 2326 may comprise code that causes the processor(s) 2318 to generate instructions and messages, transmit data, or otherwise communicate with other entities. For example, the communications module 2326 may, in conjunction with the digital assistant 2334, transmit and receive data associated with establishing a phone call to and from the accessory device 2306 and cellular-capable device 2310. As described herein, the communications module 2326 may transmit messages via one or more network paths of network(s) 2308 (e.g., via a LAN associated with the home environment or an Internet WAN). [0276] The speech processing module 2328 can comprise code that causes the processor(s) 2318 to receive and process an audio input corresponding to a spoken request to place a call or end a call, according to some embodiments. Processing the spoken audio can include, for example, NLP or audio pattern matching. In some embodiments, one or more of the operations of speech processing module 2328 may be similar to those described in reference to speech processing module 2214 of FIG.22. Wake word module 2332 can comprise code that causes processor(s) 2318 to receive and process a portion of an audio input corresponding to a trigger or wake word. In some embodiments, one or more of the operations of the wake word module 2332 may be similar to those described in reference to wake word detection module 2216 of FIG.22. For example, wake word module 2332 can analyze a portion of an audio input to determine the presence of a wake word. [0277] The accessory interaction instance(s) 2330 may comprise code that causes the processor(s) 2318 to receive and process a portion of an audio input corresponding to a user request. In some embodiments, one or more of the operations of accessory interaction instance(s) 2330 may be similar to those described in reference to accessory interaction instances 2218 of FIG.22. For example, the accessory interaction instance(s) 2330 can comprise a number of processes or services that can cause the processor(s) 2318 to send and receive data to a remote service, identify an appropriate cellular-capable device for placing a call according to the user request, or entering a call listening state that limits the functionality of a digital assistant 2334 while the call is ongoing. The accessory interaction instance(s) 2330 may comprise the digital assistant 2334 that can perform one or more of these example operations as well as additional operations related to the interaction between the accessory devices 2304, 2306 and the cellular-capable device 2310 as described herein. The accessory interaction instance(s) 2330 may also comprise an end word module 2336. When in the call listening state, the accessory interaction instance corresponding to the accessory device on the call may limit the speech processing functionality of its digital assistant 2334 to only detect a call end word (e.g., “hang up”). In those cases, the end word module 2336 can receive, after processing at the wake word module 2332, an audio input. The end word module 2336 can process this audio input to detect the end word. In some embodiments, the end word module 2336 performs the speech analysis similarly to the wake word module 2332. When the end word is detected, the digital assistant 2334, in conjunction with the communication module 2326, can send an instruction to the accessory device to end the call. [0278] Turning now to the details of the representative accessory device 2306, the accessory device 2306 can have, in some embodiments, at least one memory 2340, a communications interface 2342, processor(s) 2344, a storage unit 2346, and I/O devices 2348. As described herein with respect to the controller device 2302, these elements of the accessory device can have the same appropriate hardware implementations as their counterparts on the controller device 2302. [0279] The memory 2340 of the accessory device 2306 can include an operating system 2350 and one or more application programs or services for implementing the features disclosed herein, including communications module 2352, audio module 2354, and ADK 2356. As described herein with respect to the controller device 2302, the communications module 2352 can have similar appropriate functionality as its counterpart communications module 2326. [0280] The audio module 2354 may comprise code that causes the processor(s) 2344, in conjunction with the I/O devices 2348, to receive, process, and transmit audio signals. In some embodiments, one or more of the operations of the audio module may be similar to those described in reference to accessory audio module 2210 of FIG.22. For example, the audio module 2354 can receive a user utterance or other audio input at a microphone with the I/O devices 2348 and transmit that audio data to the controller device 2302 over a streaming audio channel or other suitable connection. The audio input can correspond to a wake word in conjunction with an end word. The audio module 2354 can also receive user audio at the microphone and relay that audio to the cellular-capable device as part of the phone call. Similarly, the audio module can receive audio from the cellular-capable device and play that audio at the speaker. [0281] The ADK 2356 may comprise code that causes the processor(s) 2344 to receive and process a portion of an audio input corresponding to a trigger or wake word. In some embodiments, one or more of the operations of the ADK 2356 may be similar to those described in reference to ADK 2206 of FIG.22. The ADK 2356 can comprise a wake word module 2358. Wake word module 2358 can comprise code that causes processor(s) 2344 to receive and process the wake word. In some embodiments, one or more of the operations of the wake word module 2358 may be similar to those described in reference to wake word detection module 2208 of FIG.22. For example, wake word module 2358 can analyze a portion of an audio input to determine the presence of a wake word. [0282] In some embodiments, the ADK 2356 can also include a phone control module 2360. The phone control module 2360 may comprise code that causes processor(s) 2344 to send and receive commands and indications to and from cellular-capable device 2310. For example, upon receiving an audio input containing the end word, the controller device 2302 can transmit instructions to the accessory device 2306 to end the call. The accessory device 2306, via its phone control module 2360, can then signal the cellular-capable device 2310 to end the call and close the audio connection between the two devices. [0283] Turning now to the details of cellular-capable device 2310, similar to the other device architectures diagrammed in FIG.23, cellular-capable device 2310 can have, in some embodiments, at least one memory 2362, a communications interface 2364, processor(s) 2366, a storage unit 2368, and I/O devices. As described herein with respect to the controller device 2302, these elements of the accessory device can have the same appropriate hardware implementations as their counterparts on the controller device 2302. [0284] The memory 2362 of the cellular-capable device 2310 can include an operating system 2372 and one or more application programs or services for implementing the features disclosed herein, including media module 2374, phone control module 2376, and accessory discovery module 2376. As described herein with respect to the accessory device 2306, the phone control module 2376 can have similar appropriate functionality as its counterpart phone control module 2360. [0285] The media module 2374 may comprise code that causes the processor(s) 2366 to send, receive, and process data contained in a telephone call. This data can be received from and transmitted to a server device or other device connected to a cellular network 2312. The media module 2374 can also send, receive, and process data corresponding to the real-time audio of the phone call sent over one of the network(s) 2308 to the accessory device 2306. In some embodiments, one or more of the operations of media module 2374 may be similar to those described in reference to media module 2230 of FIG.22. [0286] The accessory discovery module 2376 may comprise code that causes the processor(s) 2366 to receive information about the selected accessory device 2306 on one of the network(s) 2308 within the home environment to establish a communications channel for purposes of directing a call at the cellular-capable device 2310 from the accessory device 2306. In some embodiments, one or more of the operations of accessory discovery module 2376 may be similar to those described in reference to accessory discovery module 2238 of FIG.22. [0287] FIG.24 is a flow diagram illustrating a particular example process 2400 for requesting a phone call at an accessory 2401 and placing that phone call at a cellular-capable device 2403, according to an embodiment. Each of the elements and operations depicted in FIG.24 may be similar to one or more elements depicted in other figures described herein. For example, the user device 2402 may be similar to other user devices, controller devices, or hub devices, and so forth. In some embodiments, process 2400 may be performed within a home environment (e.g. the home environment 2000 of FIG.20). [0288] Process 2400, as well as processes 2500 and 2600 of FIGs.25 and 26 (described below) are illustrated as logical flow diagrams, each operation of which represents a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. 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 processes. [0289] Additionally, some, any, or all of the processes may be performed under the control of one or more computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors, by hardware, or combinations thereof. As noted above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium is non-transitory. [0290] At block 2404, the accessory 2401 can receive an audio input containing a wake word and a call request. For example, the audio input may be the user utterance “Computer, call Mom,” where “Computer” comprises the wake word and “call Mom” comprises the request. [0291] At block 2406, the accessory 2401 can process the wake word in a first pass to determine the presence of the wake word. The first pass processing can be done in a time and resource efficient manner that determines that the wake word may be present. At decision 2408, based upon the first pass processing, the accessory 2401 determines if the wake word is present. If not, then the process can terminate at endpoint 2410 by ignoring the user utterance. If the wake word is present according to the first pass processing, then the process continues to block 2412. [0292] At block 2412, the accessory 2401 can transmit the audio input via a streaming audio connection to user device 2402. This connection can occur over one of the networks to which the accessory 2401 and user device 2402 are connected, for example over a WiFi LAN. The streaming audio can use any number of methods or protocols, including, but not limited to AirPlay, Real-time Transport Protocol (“RTP”), Real Time Streaming Protocol (RTSP), or the like. [0293] At block 2414, the user device 2402 receives the wake word and can process it for a second pass. This processing can be at a second level that can confirm the presence of the wake word to a higher degree of probability than the first pass processing at block 2406 at the accessory 2401. At decision 2416, if the user device 2402 does not confirm the presence of the wake word, the process moves to endpoint 2418 and ignores the audio input by terminating the streaming audio connection with the accessory 2401. If the user device 2402 does confirm the presence of the wake word, then the process moves to block 2420 and processes the call request. In processing the call request, the user device 2402 can transmit some or all of the call request to a remote server device for speech analysis using NLP or other techniques. This analysis may determine the user making the call request. In identifying the user, the user device 2402 or the remote service device may access user profiles associated with users in the home environment. These user profiles may be stored at the user device 2402 or at the remote service device or other device accessible by the device performing the speech analysis. Processing the call request can ultimately result in identifying a call recipient (e.g., Mom). The call recipient may be a telephone number associated with the name or other label spoken by the user making the call request. In some embodiments, the call recipient may be identifiable by the cellular-capable device 2403 such that the portion of the call request identifying the recipient is sent to the cellular-capable device 2403 with the instructions to place the call. [0294] At block 2422, the user device 2402 can determine an appropriate cellular-capable device for making the call. This determination can be based upon information obtained about the requesting user from a user profile. In some embodiments, the appropriate cellular- capable device 2403 may be the user’s personal cellular phone. At block 2424, the user device 2402 can instruct the cellular-capable device to establish the call. This can include sending the cellular-capable device 2403 information identifying the call recipient and identifying the accessory 2401 to which the cellular-capable device 2403 should connect to relay the call audio. Although not depicted in FIG.24, in some embodiments the user device 2402 can alternatively instruct the accessory 2401 to communicate with the selected cellular- capable device 2403 and instruct the cellular-capable device 2403 to place the call. This scenario may occur in an environment where the user device 2402 can identify the appropriate cellular-capable device 2403 but is unable to communicate with it, for example because the devices do not have a trusted connection with one another. The user device 2402 may then enter a call listening state at endpoint 2426. While in the call listening state, the accessory interaction instance corresponding to accessory 2401 at user device 2402 can have limited speech processing with regard to analyzing received user requests from accessory 2401. Other accessory interaction instances corresponding to different accessories associated with user device 2402 may process user requests at those accessories as per normal. [0295] At block 2428, the cellular-capable device 2403 can place a call to the call recipient via cellular network 2430. At block 2432, the cellular-capable device 2403 can establish an audio channel with the accessory 2401. The accessory 2401 can then begin relaying audio to and from the cellular-capable device 2403 to constitute the phone conversation. While the call is ongoing, the user device 2402 may stay in the listening state at block 2426, in order to listen for an “end” word to terminate the call. However, in other examples, the accessory 2401 may be configured to also (or instead of the user device 2402) be in a listening state, in order to listen for the “end” word to terminate the call, or for other instructions (e.g., potentially, not related to the phone call). While both devices (e.g., the accessory 2501 and the user device 2502) may be capable of listening for the “end” word, the user device 2502 may be better suited for this task based on the fact that the detectors on the accessory 2501 may be poor in comparison to those of the user device 2502. [0296] FIG.25 is another flow diagram illustrating an example process 2500 for requesting the termination of a phone call at an accessory device 2501 and ending the call at a cellular- capable device 2503, according to an embodiment. Each of the elements and operations depicted in FIG.25 may be similar to one or more elements depicted in other figures described herein. Process 2500 can, in some embodiments, be a continuation of process 2400 described in FIG.24, above. Thus, accessory 2501 may correspond to accessory 2401, user device 2502 may correspond to user device 2402, and cellular-capable device 2503 may correspond to cellular-capable device 2403. [0297] While a call is ongoing between the cellular capable device 2503 and one of its associated accessories (e.g., accessory 2501), user device 2502 begins process 2500 in a call listening state 2504. The call listening state may be similar to the listening state described for endpoint 2426 of FIG.24, in some embodiments. Alternatively, the accessory 2501 may also be in a listening state (both for the wake word and/or for and “end” word). Accessory 2501 can receive a user audio input at block 2506. The audio input can consist of a wake word and an end word, for example “Computer, hang up.” The accessory 2501 can process the wake word and transmit the audio input to user device 2502 for further processing in blocks 2508– 2520. In some embodiments, one or more of the operations of blocks 2508–2520 may be similar to one or more operations described for blocks 2406–2418 in reference to FIG.24. [0298] At block 2518, if the user device 2502 detects the wake word, it can then process the end word portion of the audio input, at block 2522. The processing of the end word may be limited to only detecting and processing a specific end word (e.g., “hang up”) or small set of equivalent words (e.g., “end call,” “end,” etc.). At decision 2524, if the end word is not detected, the user device 2502 will ignore the audio input, and the process will end at endpoint 2526. Because the user device 2502 is in the call listening state (e.g., at block 2504), it will ignore all audio inputs that do not contain the end word, even if the inputs otherwise contain valid and determinable requests. In many embodiments, the user device 2502 may not process any portion of the audio input beyond the portion sufficient to contain the expected end word if the end word is not detected in that sufficient portion. In this way, the user device 2502 is not able to listen in on the call and/or record any portion of the call. [0299] At block 2528, if the end word is detected, the user device 2502 can instruct the accessory 2501 to end the call. The accessory, at block 2529, receives the instruction and communicates with the cellular-capable device 2503 to terminate the call. Alternatively, in some examples, the user device 2502 may instead instruct the cellular-capable device 2503 to end the call at block at 2528. In this example, block 2529 would be skipped, and the cellular- capable device 2503 would be instructed to end the call without going through the accessory 2501. At block 2530, the cellular-capable device 2503 can terminate the call connection with the cellular network 2532 and then close the communication channel with the accessory 2501, at endpoint 2534. [0300] FIG.26 is a flow diagram showing a process 2600 for a controller device to establish a connection between an accessory device and cellular-capable device, according to some embodiments. In some embodiments, one or more of the operations of process 2600 may be similar to those as described in reference to FIGs.24 and 25. [0301] At block 2602, a controller device may establish a first network connection with a cellular-capable device and a second network connection with an accessory device. The network connections can occur over one or more of the networks associated with a home environment. In the case of the accessory device, the second network connection can be the network connection over which the controller device communicates with the accessory device when responding to user requests at the accessory device. In some embodiments, one or more of the operations of block 2602 may be similar to one or more operations described for process indicators 2130 and 2140 in reference to FIG.21. [0302] At block 2604, the controller device can listen for an audio input from the accessory device over the second network connection. This listening behavior is the typical state of a controller device acting as a hub device for one or more associated accessories. When the accessory receives an audio input that contains a trigger or a wake word, the accessory can transmit that audio input to its associated hub device for further processing. [0303] At block 2606, the controller device can receive an audio input from the accessory device over the second network connection. The audio input can contain a wake word and a call request. The call request can correspond to a request for a cellular-capable device to make a telephone call. In some embodiments, one or more of the operations of block 2606 may be similar to one or more operations described for block 2420 in reference to FIG.24. [0304] At block 2608, upon receiving the call request, the controller device can transmit instructions to the cellular-capable device over the first network connection for the cellular- capable device to establish a third network connection with the accessory device and place a call. In some embodiments, one or more of the operations of block 2608 may be similar to one or more operations described for block 2424 in reference to FIG.24. [0305] At block 2610, the controller device can enter a call listening state. While in this state, the controller device can listen for a second audio input from the accessory device. In some embodiments, one or more of the operations of block 2610 may be similar to one or more operations described for blocks 2516 and 2522 in reference to FIG.25. [0306] At block 2612, if the controller device identifies an end word in the second audio input, then the controller device can transmit instructions to the cellular-capable device to end the call and close the connection with the accessory device. In some embodiments, one or more of the operations of block 2612 may be similar to one or more operations described for process indicator 2140 in reference to FIG.21. [0307] Illustrative techniques for communicating between an accessory device and a cellular-capable device are described above. Some or all of these techniques may, but need not, be implemented at least partially by architectures such as those shown at least in FIGS. 19–8 above. While many of the embodiments are described above with reference to server devices, accessory devices, user devices, and hub devices, it should be understood that other types of computing devices may be suitable to perform the techniques disclosed herein. Further, in the foregoing description, various non-limiting examples were described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the examples. However, it should also be apparent to one skilled in the art that the examples may be practiced without the specific details. Furthermore, well- known features were sometimes omitted or simplified in order not to obscure the example being described. [0308] Although specific example embodiments have been described, various modifications, alterations, alternative constructions, and equivalents are also encompassed within the scope of the disclosure. Embodiments are not restricted to operation within certain specific data processing environments, but are free to operate within a plurality of data processing environments. Additionally, although embodiments have been described using a particular series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly. [0309] As described above, one aspect of the present technology is the gathering and use of data available from specific and legitimate sources to improve the delivery to users of invitational content or any other content that may be of interest to them when updating firmware. The present disclosure contemplates that in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user’s health or level of fitness (e.g., vital signs measurements, medication information, and exercise information), date of birth, or any other personal information. [0310] The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to deliver targeted content that may be of greater interest to the user in accordance with their preferences. Accordingly, use of such personal information data enables users to have greater control of the delivered content. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. [0311] The present disclosure contemplates that those entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. In particular, such entities would be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. Such information regarding the use of personal data should be prominent and easily accessible by users, and should be updated as the collection and/or use of data changes. Personal information from users should be collected for legitimate uses only. Further, such collection/sharing should occur only after receiving the consent of the users or other legitimate basis specified in applicable law. Additionally, such entities should consider taking any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices. In addition, policies and practices should be adapted for the particular types of personal information data being collected and/or accessed and adapted to applicable laws and standards, including jurisdiction-specific considerations that may serve to impose a higher standard. For instance, in the US, collection of 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); whereas health data in other countries may be subject to other regulations and policies and should be handled accordingly. [0312] Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, such as in the case of advertisement delivery services, the present technology can be configured to allow users to select to “opt in” or “opt out” of participation in the collection of personal information data during registration for services or anytime thereafter. In another example, users can select not to provide mood-associated data for targeted content delivery services. In yet another example, users can select to limit the length of time mood-associated data is maintained or entirely block the development of a baseline mood profile. In addition to providing “opt in” and “opt out” options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon downloading an app that their personal information data will be accessed and then reminded again just before personal information data is accessed by the app. [0313] Moreover, it is the intent of the present disclosure that personal information data should be managed and handled in a way to minimize risks of unintentional or unauthorized access or use. Risk can be minimized by limiting the collection of data and deleting data once it is no longer needed. In addition, and when applicable, including in certain health related applications, data de-identification can be used to protect a user’s privacy. De-identification may be facilitated, when appropriate, by removing identifiers, controlling the amount or specificity of data stored (e.g., collecting location data at city level rather than at an address level), controlling how data is stored (e.g., aggregating data across users), and/or other methods such as differential privacy. [0314] Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed embodiments, the present disclosure also contemplates that the various embodiments can also be implemented without the need for accessing such personal information data. That is, the various embodiments of the present technology are not rendered inoperable due to the lack of all or a portion of such personal information data. For example, content can be selected and delivered to users based on aggregated non-personal information data or a bare minimum amount of personal information, such as the content being handled only on the user’s device or other non- personal information available to the content delivery services. [0315] The various embodiments further can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices or processing devices that can be used to operate any of a number of applications. User or client devices can include any of a variety of different types of computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system also can include a number of workstations running any of a variety of commercially-available operating systems and other known applications for purposes such as development and database management. These devices also can include other electronic devices, such as dummy terminals, thin-clients, gaming systems and other devices capable of communicating via a network. [0316] Most embodiments utilize at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of commercially- available 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. [0317] In embodiments utilizing a network server, the network server can run any of a variety of server or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server(s) also may be capable of executing programs or scripts in response requests from user devices, such as by executing one or more applications that may be implemented as one or more scripts or programs written in any programming language, such as Java^®, C, C# or C++, or any scripting language, such as Perl, Python or TCL, as well as combinations thereof. The server(s) may also include database servers, including without limitation those commercially available from Oracle^®, Microsoft^®, SAP^®, and IBM^®. [0318] The environment can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of embodiments, the information may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers or other network devices may be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus, the elements including, for example, at least one central processing unit (“CPU”), at least one input device (e.g., a mouse, keyboard, controller, touch screen or keypad), and at least one output device (e.g., a display device, printer or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as RAM or ROM, as well as removable media devices, memory cards, flash cards, etc. [0319] Such devices also can include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory as described above. The computer- readable storage media reader can be connected with, or configured to receive, a non- transitory computer-readable storage medium, representing remote, local, fixed, and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or browser. It should be appreciated that alternate embodiments may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets) or both. Further, connection to other computing devices such as network input/output devices may be employed. [0320] Non-transitory storage media and computer-readable storage media for containing code, or portions of code, can include any appropriate media known or used in the art such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of 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, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other medium that can be used to store the desired information and that can be accessed by the a system device. Based at least in part on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments. However, computer-readable storage media does not include transitory media such as carrier waves or the like. [0321] The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the disclosure as set forth in the claims. [0322] Other variations are within the spirit of the present disclosure. Thus, while the disclosed techniques are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the disclosure to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions and equivalents falling within the spirit and scope of the disclosure, as defined in the appended claims. [0323] The use of the terms “a,” “an,” and “the,” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected” is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening. The phrase “based at least in part on” should be understood to be open-ended, and not limiting in any way, and is intended to be interpreted or otherwise read as “based at least in part on,” where appropriate. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments of the disclosure and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure. [0324] Disjunctive language such as the phrase “at least one of X, Y, or Z,” unless specifically stated otherwise, is otherwise understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present. Additionally, conjunctive language such as the phrase “at least one of X, Y, and Z,” unless specifically stated otherwise, should also be understood to mean X, Y, Z, or any combination thereof, including “X, Y, and/or Z.” [0325] Preferred embodiments of this disclosure are described herein, including the best mode. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. It is expect that skilled artisans should be able to employ such variations as appropriate, it is intended for the disclosure to be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above- described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context. [0326] Examples of the described techniques can be illustrated by the below clauses: [0327] Clause 1. A method, comprising: establishing, by a controller device, a first network connection with a cellular- capable device and a second network connection with an accessory device; listening, by the controller device, for a first audio input from the accessory device via the second network connection; while listening, identifying, from the accessory device via the second network connection, the first audio input that at least includes a request to place a telephone call; transmitting, to the cellular-capable device via the first network connection or to the accessory device via the second network connection, instructions for establishing a call via a third network connection between the cellular-capable device and the accessory device; listening, during the call between cellular-capable device and the accessory device, for a second audio input from the accessory device via the second network connection; in accordance with a determination that the second audio input was identified, transmitting an instruction, to the cellular-capable device via the first network connection or to the accessory device via the second network connection, to end the call with the accessory device. [0328] Clause 2. The method of clause 1, wherein the second audio input comprises an end word configured to identify that the call is to be ended. [0329] Clause 3. The method of clause 2, wherein, during the call, the controller device only listens for the end word. [0330] Clause 4. The method of clause 2, wherein, during the call, the controller device does not process any audio received from the accessory device via the second network connection other than the end word. [0331] Clause 5. The method of clause 2, wherein the end word comprises at least one of “hang up,” or “end call.” [0332] Clause 6. The method of clause 1, further comprising: in accordance with the determination that the second audio input was identified, transmitting information to the accessory device, via the second network connection, that informs the accessory device that the call is to be ended. [0333] Clause 7. The method of clause 1, wherein the first audio input further includes at least a wake word. [0334] Clause 8. The method of clause 2, wherein the wake word indicates that a second portion of the first audio input identifies an action for the controller device to perform. [0335] Clause 9. The method of clause 8, wherein the action comprises the transmission of the instructions for establishing the call via the third network connection. [0336] Clause 10. The method of clause 2, wherein the wake word corresponds to a first software ecosystem of the controller device, and does not correspond to a second software ecosystem of the accessory device. [0337] Clause 11. The method of clause 1, wherein the accessory device is a third-party device that is built for a first entity that is different from a second entity for which the controller device is built. [0338] Clause 12. The method of clause 11, wherein the accessory device is configured to implement a software development kit provided by the second entity associated with the controller device. [0339] Clause 13. The method of clause 1, wherein the accessory device is not cellular capable. [0340] Clause 14. The method of clause 1, wherein the accessory device is configured with a speaker and a microphone. [0341] Clause 15. The method of clause 1, wherein the cellular-capable device is configured to relay the call from a service provider to the accessory device. [0342] Clause 16. The method of clause 1, wherein the controller device is one of a plurality of hub devices in a home environment. [0343] Clause 17. A controller device, comprising: a memory configured to store computer-executable instructions; and a processor configured to access the memory and execute the computer- executable instructions to at least perform the method of any of clauses 1-16. [0344] Clause 18. A computer-readable storage medium configured to store computer- executable instructions that, when executed by a controller device, cause the controller device to perform the method of any of clauses 1-16.

Claims

WHAT IS CLAIMED IS: 1. A method, comprising: receiving, by a user device, information that identifies a plurality of accessories configured to communicate with the user device; implementing, by the user device, respective accessory interaction instances for each accessory of the plurality of accessories; receiving a first audio input from a first accessory of the plurality of accessories and second audio input from a second accessory of the plurality of accessories; processing, by a first accessory interaction instance of the respective accessory interaction instances, at least a portion of the first audio input; receiving, by the first accessory interaction instance of the respective accessory interaction instances, a first response from a server computer, the first response corresponding to the processed portion of the first audio input; and transmitting, by the user device, the first response to the first accessory of the plurality of accessories.

2. The method of claim 1, wherein the processing, by the first accessory interaction instance of the respective accessory interaction instances, of the portion of the first audio input comprises: transmitting, by the first accessory interaction instance, the processed portion of the first audio input to the server computer.

3. The method of claim 2, wherein the processing, by the first accessory interaction instance of the respective accessory interaction instances, of the portion of the first audio input further comprises: delegating, by the first accessory interaction instance, an action to one or more other processes.

4. The method of claim 3, wherein the one or more other processes comprise at least one of a music service or a voice communication service, and wherein the action comprises instructions for the one or more other processes to provide audio content for the first accessory.

5. The method of claim 1, further comprising: determining, by the user device, whether at least a portion of the second audio input matches a wake word; and determining, by the user device, whether the second accessory is authorized to interact with a second accessory interaction instance of the respective accessory interaction instances.

6. The method of claim 5, further comprising: processing, by the second accessory interaction instance of the respective accessory interaction instances, at least a portion of the second audio input in accordance with at least one of the determination that the portion of the second audio input matches the wake word or the determination that the second accessory is authorized to interact with the second accessory interaction instance of the respective accessory interaction instances.

7. The method of claim 1, wherein each of the plurality of accessories are configured to implement a software development kit provided by an entity associated with the user device.

8. The method of claim 7, wherein each of the respective accessory interaction instances are configured to communicate with a corresponding software development kit of respective accessory of the plurality of accessories.

9. The method of claim 1, further comprising managing, by the user device, respective accessory settings for each of the plurality of accessories.

10. The method of claim 1, wherein the user device is a first user device, and wherein the information comprises at least one of: a request, from at least one of the accessories of the plurality of accessories, to connect to the first user device; or an instruction, from a second user device, to connect the first user device to at least one of the accessories of the plurality of accessories.

11. A user device, comprising: a memory configured to store computer-executable instructions; and a processor configured to connect to the memory and execute the computer- executable instructions to at least: receive information that identifies a plurality of accessories configured to communicate with the user device; implement respective accessory interaction instances for each accessory of the plurality of accessories; receive first audio input from a first accessory of the plurality of accessories and second audio input from a second accessory of the plurality of accessories; process, by a first accessory interaction instance of the respective accessory interaction instances, at least a portion of the first audio input; receive, by the first accessory interaction instance of the respective accessory interaction instances, a first response from a server computer, the first response corresponding to the processed portion of the first audio input; and transmit the first response to the first accessory of the plurality of accessories.

12. The user device of claim 11, wherein the processing, by the first accessory interaction instance of the respective accessory interaction instances, of the portion of the first audio input comprises at least one of: transmitting, by the first accessory interaction instance, the processed portion of the first audio input to the server computer; or delegating, by the first accessory interaction instance, an action to one or more other processes.

13. The user device of claim 11, wherein the processor is configured to execute the computer-executable instructions to at least: determine whether at least a portion of the second audio input matches a wake word; and determine whether the second accessory is authorized to interact with a second accessory interaction instance of the respective accessory interaction instances.

14. The user device of claim 13, wherein the processor is configured to execute the computer-executable instructions to at least: process, by the second accessory interaction instance of the respective accessory interaction instances, at least a portion of the second audio input in accordance with at least one of the determination that the portion of the second audio input matches the wake word or the determination that the second accessory is authorized to interact with the second accessory interaction instance of the respective accessory interaction instances.

15. The user device of claim 11, wherein each of the plurality of accessories are configured to implement a software development kit provided by an entity associated with the user device.

16. A computer-readable storage medium configured to store computer- executable instructions that, when executed by a user device, cause the user device to perform operations comprising: receiving information that identifies a plurality of accessories configured to communicate with the user device; implementing respective accessory interaction instances for each accessory of the plurality of accessories; receive first audio input from a first accessory of the plurality of accessories and second audio input from a second accessory of the plurality of accessories; process, by a first accessory interaction instance of the respective accessory interaction instances, at least a portion of the first audio input; receive, by the first accessory interaction instance of the respective accessory interaction instances, a first response from a server computer, the first response corresponding to the processed portion of the first audio input; and transmit the first response to the first accessory of the plurality of accessories.

17. The computer-readable storage medium of claim 16, wherein the processing, by the first accessory interaction instance of the respective accessory interaction instances, of the portion of the first audio input comprises at least one of: transmitting, by the first accessory interaction instance, the processed portion of the first audio input to the server computer; or delegating, by the first accessory interaction instance, an action to one or more other processes.

18. The computer-readable storage medium of claim 16, wherein the operations further comprise: determining, by the user device, whether at least a portion of the second audio input matches a wake word; and determining, by the user device, whether the second accessory is authorized to interact with a second accessory interaction instance of the respective accessory interaction instances.

19. The computer-readable storage medium of claim 18, wherein the operations further comprise: processing, by the second accessory interaction instance of the respective accessory interaction instances, at least a portion of the second audio input in accordance with at least one of the determination that the portion of the second audio input matches the wake word or the determination that the second accessory is authorized to interact with the second accessory interaction instance of the respective accessory interaction instances.

20. The computer-readable storage medium of claim 16, wherein each of the plurality of accessories are configured to implement a software development kit provided by an entity associated with the user device.