PATENT DOCUMENT

Publication Number: US-11128610-B2
Application Number: US-201816147545-A
Country: US
Kind Code: B2

Title: Secure multiway calling

Abstract:
Techniques are disclosed relating to multiway communications. In some embodiments, a first electronic device initiates a multiway call between a plurality of electronic devices and exchanges a first secret with a first set of electronic devices participating during a first portion of the multiway call, the first secret being used to encrypt traffic between the first set of electronic devices. The first electronic device receives an indication that first set of participating electronic devices has changed and, in response to the indication, exchanges a second secret with a second set of electronic devices participating during a second portion of the multiway call, the second secret being used to encrypt traffic between the second set of participating electronic devices. In some embodiments, the indication identifies a second electronic device as leaving the multiway call, and the second secret is not exchanged with the second electronic device.

Claims:
What is claimed is: 
     
       1. A communication system comprising:
 a memory; and 
 at least one processor configured to:
 receive a request to facilitate a multiway call between a plurality of devices; 
 provide first notification information that identifies a first set of active devices participating in the multiway call, wherein the first notification information causes the first set of active devices to establish a first set of cryptographic keys used to communicate encrypted traffic of the multiway call; 
 determine that the active devices in the multiway call have changed; and 
 in response to the determination, provide a second notification information that identifies a second set of active devices participating in the multiway call, wherein the second notification information causes the second set of active devices to discontinue use of the first set of cryptographic keys and establish, at the second set of active devices, a second set of cryptographic keys used to communicate encrypted traffic of the multiway call. 
 
 
     
     
       2. The communication system of  claim 1 , wherein the at least one processor is further configured to:
 in response to the request, select one or more relay servers of a plurality of relay servers configured to relay traffic of the multiway call between the plurality of devices; and 
 provide indications of the selected one or more relay servers to the plurality of devices. 
 
     
     
       3. The communication system of  claim 2 , wherein the provided indications include at least one of: secrets used to encrypt traffic to the one or more relay servers, or tokens for authenticating with the one or more relay servers to cause the one or more relay servers to relay traffic of the multiway call. 
     
     
       4. The communication system of  claim 1 , wherein the at least one processor is further configured to determine that a first device of the plurality of devices is leaving the multiway call, and wherein the second set of cryptographic keys is established such that the first device does not possess any of the second set of cryptographic keys. 
     
     
       5. The communication system of  claim 4 , wherein the at least one processor is further configured to receive a request from a second device of the plurality of devices to remove the first device of the plurality of devices from the multiway call. 
     
     
       6. The communication system of  claim 1 , wherein the at least one processor is further configured to determine that a first device of the plurality of devices is joining the multiway call. 
     
     
       7. The communication system of  claim 1 , wherein the at least one processor is further configured to:
 store public keys of the plurality of devices; and 
 distribute, among the plurality of devices, the public keys; 
 encrypt, at the plurality of devices, secrets; and 
 use, at the plurality of devices, the secrets to derive the first and second sets of cryptographic keys. 
 
     
     
       8. A method comprising:
 establishing, by a first mobile device, a group communication session using a first communication modality; 
 during the group communication session using the first communication modality, exchanging, amongst devices in the group communication session, one or more keys to support using a second communication modality; 
 after the exchanging, determining to use the second communication modality for the group communication session; and 
 transitioning the group communication session to using the second communication modality, wherein the transitioning includes using the one or more keys to encrypt traffic associated with using the second communication modality. 
 
     
     
       9. The method of  claim 8 , wherein the first communication modality is a messaging modality, and wherein the second communication modality is a video conference modality. 
     
     
       10. The method of  claim 8 , wherein the exchanging includes:
 adding a public key to a message communicated via the first communication modality, wherein the public key is usable by second and third mobile devices participating in the group communication session to send encrypted traffic to the first mobile device; and 
 sending a single instance of the message to a server configured to relay a first instance of the message to the second mobile device and a second instance of the message to the third mobile device. 
 
     
     
       11. The method of  claim 8 , wherein the exchanging includes:
 sending a first instance of a key to a second mobile device participating in the group communication session, wherein the first instance of the key is encrypted with a public key of the second mobile device; 
 sending a second instance of the key to a third mobile device participating in the group communication session, wherein the second instance of the key is encrypted with a public key of the third mobile device; and 
 sending, to a server, a single message including the first and second instances of the key, wherein the server is configured to send a first message including the first instance of the key to the second mobile device and a second message including the second instance of the key to the third mobile device. 
 
     
     
       12. The method of  claim 8 , further comprising:
 determining to discontinue use of the one or more keys after a threshold time period; and 
 distributing one or more replacement keys prior to the determining to continue the group communication session. 
 
     
     
       13. The method of  claim 8 , wherein the first mobile device comprises a camera and a wireless interface, and the group communication session using the second communication modality includes capturing video by the camera and communicating the captured video via the wireless interface. 
     
     
       14. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
 receiving a request to facilitate a multiway call between a plurality of devices; 
 providing first notification information that identifies a first set of active devices participating in the multiway call, wherein the first notification information causes the first set of active devices to establish a first set of cryptographic keys used to communicate encrypted traffic of the multiway call; 
 determining that the active devices in the multiway call have changed; and 
 in response to the determining, providing a second notification information that identifies a second set of active devices participating in the multiway call, wherein the second notification information causes the second set of active devices to discontinue use of the first set of cryptographic keys and to establish, at the second set of active devices, a second set of cryptographic keys used to communicate encrypted traffic of the multiway call. 
 
     
     
       15. The non-transitory computer-readable medium of  claim 14 , wherein the operations further comprise:
 in response to receiving the request, selecting one or more relay servers of a plurality of relay servers configured to relay traffic of the multiway call between the plurality of devices; and 
 providing indications of the selected one or more relay servers to the plurality of devices. 
 
     
     
       16. The non-transitory computer-readable medium of  claim 15 , wherein the provided indications include at least one of: secrets used to encrypt traffic to the one or more relay servers, or tokens for authenticating with the one or more relay servers to cause the one or more relay servers to relay traffic of the multiway call. 
     
     
       17. The non-transitory computer-readable medium of  claim 14 , wherein the operations further comprise:
 determining that a first device of the plurality of devices is leaving the multiway call, wherein the second set of cryptographic keys is established such that the first device does not possess any of the second set of cryptographic keys. 
 
     
     
       18. The non-transitory computer-readable medium of  claim 17 , wherein the operations further comprise:
 receiving a request from a second device of the plurality of devices to remove the first device of the plurality of devices from the multiway call. 
 
     
     
       19. The non-transitory computer-readable medium of  claim 14 , wherein the operations further comprise:
 determining that a first device of the plurality of devices is joining the multiway call. 
 
     
     
       20. The non-transitory computer-readable medium of  claim 14 , wherein the operations further comprise:
 storing public keys of the plurality of devices; 
 distributing, among the plurality of devices, the public keys; 
 encrypting, at the plurality of devices, secrets; and 
 using, at the plurality of devices, the secrets to derive the first and second sets of cryptographic keys. 
 
     
     
       21. A device comprising:
 a memory; and 
 at least one processor configured to:
 establish a group communication session using a first communication modality; 
 during the group communication session using the first communication modality, exchange, amongst devices in the group communication session, one or more keys to support using a second communication modality; 
 after the exchange, determine to use the second communication modality for the group communication session; and 
 transition the group communication session to using the second communication modality, wherein the transition includes using the one or more keys to encrypt traffic associated with using the second communication modality. 
 
 
     
     
       22. The device of  claim 21 , wherein the first communication modality is a messaging modality, and wherein the second communication modality is a video conference modality. 
     
     
       23. The device of  claim 21 , wherein the at least one processor is further configured to:
 determine to discontinue use of the one or more keys after a threshold time period; and 
 distribute one or more replacement keys prior to the determining to continue the group communication session.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/565,910, entitled “Multi-Device Communication Management,” filed on Sep. 29, 2017, claims the benefit of U.S. Provisional Patent Application Ser. No. 62/668,191, entitled “Secure Multiway Calling,” filed on May 7, 2018, claims the benefit of U.S. Provisional Patent Application Ser. No. 62/679,898, entitled “Secure Multiway Calling,” filed on Jun. 3, 2018, and claims the benefit of U.S. Provisional Patent Application Ser. No. 62/715,267, entitled “Secure Multiway Calling,” filed on Aug. 6, 2018, each of which is hereby incorporated by reference in its entirety for all purposes. 
    
    
     TECHNICAL FIELD 
     The present description relates generally to communication management between multiple devices, including management of a group communication session between multiple devices. 
     BACKGROUND 
     Communication between multiple devices (e.g., multi-device communication) has been utilized more frequently over time. For example, multiple users may use their respective devices to participate in a group communication session to communicate with one another. With advancement of technologies, a range of tasks that may be performed by multiple devices communicating with each other has expanded over time. For example, multi-device communication may enable users to perform various tasks such as participating in an audio/video conference, sharing files, streaming media to another device, etc. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Certain features of the subject technology are set forth in the appended claims. However, for purpose of explanation, several embodiments of the subject technology are set forth in the following figures. 
         FIG. 1  illustrates an example network environment in which a multi-device communication management system may be implemented in accordance with one or more implementations. 
         FIG. 2  illustrates an example electronic device that may implement a multi-device communication management system in accordance with one or more implementations. 
         FIG. 3  illustrates an example server that may implement a multi-device communication management system in accordance with one or more implementations. 
         FIG. 4  illustrates an example server arranged in a distributed architecture that may implement a multi-device communication management system in accordance with one or more implementations. 
         FIG. 5  illustrates a flow diagram of an example process of a multi-device communication management system in accordance with one or more implementations. 
         FIGS. 6-14  illustrate flow diagrams of example processes of a multi-device communication management system in accordance with one or more implementations. 
         FIG. 15  illustrates a flow diagram of an example process of a multi-device communication management system in accordance with one or more implementations. 
         FIG. 16  illustrates a flow diagram of an example process of a multi-device communication management system in accordance with one or more implementations. 
         FIGS. 17 and 18  illustrate flow diagrams of example processes of a multi-device communication management system in accordance with one or more implementations. 
         FIGS. 19-23  illustrate flow diagrams of example processes of a multi-device communication management system in accordance with one or more implementations. 
         FIGS. 24-30  illustrate flow diagrams of example processes of a multi-device communication management system in accordance with one or more implementations. 
         FIG. 31  illustrates a flow diagram of an example process of a multi-device communication management system in accordance with one or more implementations. 
         FIG. 32  illustrates a flow diagram of an example process of a multi-device communication management system in accordance with one or more implementations. 
         FIG. 33  illustrates a flow diagram of an example process of a multi-device communication management system in accordance with one or more implementations. 
         FIG. 34-35  illustrate flow diagrams of example communications for key distributions in accordance with one or more implementations. 
         FIG. 36-38  illustrate diagrams of example communications for distributing multiple keys in accordance with one or more implementations. 
         FIG. 39  illustrates an example electronic system with which aspects of the subject technology may be implemented in accordance with one or more implementations. 
     
    
    
     DETAILED DESCRIPTION 
     The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology can be practiced. The appended drawings are incorporated herein and constitute a part of the detailed description. The detailed description includes specific details for the purpose of providing a thorough understanding of the subject technology. However, the subject technology is not limited to the specific details set forth herein and can be practiced using one or more implementations. In one or more implementations, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology. 
     With the advancement of device and communication technologies, group communication sessions may frequently include more than two devices. For example, an audio/video conference among a large number of people using their respective devices has become possible. However, communication between more than two devices may face challenges with respect to providing an optimal user experience to the user of each device. For example, poor communication conditions at one device may cause a delay and/or a suboptimal user experience at one or more of the other devices. Furthermore, when one user experiences more audio delay during an audio/video conference than one or more of the other users, it may be difficult for the user to participate in the audio/video conference. For example, by the time the user who experiences more audio delay hears a communication, another user (who received the communication with less delay) may have already started responding, and therefore the user who experiences more audio delay may not be able to effectively participate in the audio/video conference. 
     The subject system for multi-device communication management provides solutions to these and other problems by jointly managing/coordinating multiple different devices in a group communication session, while allowing a text based group communication session to be switched to an audio/video group communication session with minimal latency. For example, the subject system jointly coordinates the quality of the audio and/or video streams provided by the devices in the group communication session such that each device can access high quality audio and/or video streams from other devices while ensuring that any devices with bandwidth constraints have access to lower quality streams. Furthermore, the subject system jointly controls the audio delay experienced by the users in the group communication session such that no single user experiences significantly more audio delay than any other user. In addition, the subject system allows users to transition between devices during a group communication session, such that the users can seamlessly participate in the group communication session while switching between different devices. 
       FIG. 1  illustrates an example network environment  100  in which a multi-device communication management system may be implemented in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided. 
     The network environment  100  includes one or more electronic devices  102 A-D and one or more servers  110 , such as a cloud of servers, which for explanatory purposes may be collectively referred to as a server  110 . The electronic devices  102 A-D may be communicatively coupled to the server  110  by the communication links  122 A-D, respectively. In one or more implementations, one or more of the communication links  122 A-D may include, and/or may be communicatively coupled to, one or more wired or wireless network components, such as routers, switches, access points, base stations, and the like. In one or more implementations, the electronic devices  102 A-D may communicate with each other directly and/or via the server  110 , such as in a group communication session. 
     The electronic devices  102 A-D may be, for example, portable computing devices such as laptop/desktop computers, smartphones, tablet devices, wearable devices (e.g., watches, bands, etc.), or other appropriate devices that include one or more wired or wireless interfaces, such as one or more near field communication (NFC) radios, WLAN radios, Bluetooth radios, Zigbee radios, cellular radios, and/or other wireless radios. In  FIG. 1 , by way of example, the electronic device  102 A is depicted as a tablet device, the electronic device  102 B is depicted as a laptop device, the electronic device  102 C is depicted as a mobile device, and the electronic device  102 D is depicted as a desktop computer. One or more of the electronic devices  102 A-D may be, and/or may include all or part of, the electronic device discussed below with respect to  FIG. 2  and/or the electronic system discussed below with respect to  FIG. 34 . The server  110  may be, and/or may include all or part of, the server discussed below with respect to  FIGS. 3 and 4  and/or the electronic system discussed below with respect to  FIG. 34 . 
     In one or more implementations, the electronic device  102 A and the electronic device  102 D may be registered to a same user account, such as through the server  110 . Thus, a user associated with the user account may receive communications, e.g., messages, phone calls, notifications, etc., via one or both of the electronic devices  102 A,D. In one or more implementations, the electronic devices  102 A,D may also be connected via a local peer-to-peer connection, such as BTLE, when the electronic devices  102 A,D are located proximal to one another, such as within the BTLE transmission range. The user may also use one or more of the electronic devices  102 A,D, such as the electronic device  102 A, in a group communication session with one or more other devices, such as the electronic devices  102 B-C, which may each be associated with a different user account. In a group communication session, audio and/or video captured at the electronic device  102 A may be transmitted to the other electronic devices  102 B-C, e.g., via the server  110 . Similarly, the electronic device  102 A may receive audio and/or video streams corresponding to the other electronic devices  102 B-C via the server  110 . 
     In the subject system, the server  110  may facilitate securely forming a group communication session between one or more of the electronic devices  102 A-D, such as an audio/video conference, and/or securely transitioning between different communication modalities (e.g., messaging, audio, or video) for a given group communication session. For example, the users of one or more of the electronic devices  102 A-D may be participating in a group messaging exchange and may decide that they would like to transition from the group messaging exchange to an audio/video conference. The server  110  may facilitate transitioning the group communication session from the group messaging exchange to the audio/video conference. An example process for transitioning between different communication modalities for a given group communication session is discussed further below with respect to  FIG. 33 . In one or more implementations, the server  110  may also facilitate securely adding one or more of the electronic devices  102 A-D to an existing group communication session. Example processes of a server  110  securely forming a group communication session and/or securely adding one or more of the electronic devices  102 A-D to an existing group communication session are discussed further below with respect to  FIGS. 6-13 and 19-27 . 
     In the group communication session, such as an audio/video conference, the electronic devices  102 A-D may provide independent audio and/or video streams to each other. However, since the uplink/downlink bandwidth/network conditions of the communication links  122 A-D of the electronic devices  102 A-D may differ, the electronic devices  102 A-D and/or the server  110  may coordinate the quality of the audio and/or video streams provided and/or made available by the electronic devices  102 A-C for the group communication session to ensure that sufficiently low bit rate streams are available for one or more of the electronic devices  102 A-C that have a communication link that can only support low bit rate streams while still allowing others of the electronic devices  102 A-C to receive high bit rate streams, e.g., when their respective communication links can support high bit rate streams. Example processes of the server  110  managing the quality of the audio/video streams provided and received by the electronic devices  102 A-D in a group communication session are discussed further below with respect to  FIGS. 16 and 32 . 
     In one or more implementations, variations in network conditions of the communications links  122 A-D may result in different amounts of jitter occurring at one or more of the electronic devices  102 A-D. The different amounts of jitter may result in different jitter buffer levels and therefore different audio output delays across the electronic devices  102 A-D. In the subject system, the server  110  may coordinate the audio output delay resulting from the jitter buffer level variations at the electronic devices  102 A-D to ensure that the audio output delay is substantially uniform across the electronic devices  102 A-D, while also ensuring that the jitter buffers of the electronic devices  102 A-D do not experience buffer overruns or underruns. Example processes of the server  110  coordinating the audio output delay across the electronic devices  102 A-D is discussed further below with respect to  FIGS. 15 and 31 . 
     The server  110  may also facilitate allowing a user to seamlessly switch electronic devices  102 A,D while participating in a group communication session. For example, the user may initially use the electronic device  102 A to participate in a group communication session (or otherwise perform a task), and may switch to the electronic device  102 D (or another electronic device registered to the account of the user) to continue participating in the group communication session (or continue performing the task). Thus, when a user is participating in a group communication session (or performing another task) using the electronic device  102 A, the server  110  may coordinate preparing, or warming up, one or more other electronic devices  102 D registered to the account of the user, such that the group communication session (and/or other task) may be seamlessly and substantially instantly handed off to the one or more other electronic devices  102 D, e.g., upon receiving a user request therefor. Example processes of the server  110  coordinating the preparation of electronic devices  102 D for a seamless handoff of a group communication session (and/or other task) are discussed further below with respect to  FIGS. 5, 17, and 18 . 
     In one or more implementations, the subject system may allow a digital assistant to participate in, and/or assist, in a group communication session, such as an audio/video conference, a group messaging session, and the like. For example, a user of one of the electronic devices  102 A-C may request, e.g. verbally, that the digital assistant schedule a reminder for the participants in the call to discuss the topic again next week, to schedule a lunch with the participants in the call, share/email a document, and/or any other task. The digital assistant, which may be implemented by the server  110  and/or by one or more of the electronic devices  102 A-C, may then schedule the reminder, lunch, etc. for each of the user accounts associated with the electronic devices  102 A-C participating in the group communication session. 
     When the digital assistant is implemented centrally, such as by the server  110 , the server  110  may receive packets from the electronic devices  102 A-C that correspond to digital assistant activities/requests initiated on the respective electronic devices  102 A-C. The server  110  may process the digital assistant activities/requests and may broadcast resultant activities, such as scheduling a lunch, to each of the electronic devices  102 A-C. 
     In one or more implementations, a digital assistant on each of the electronic devices  102 A-C may be maintain a context and/or state associated with the group communication session during the group communication session. If, for example, the user of the electronic device  102 A switches to the electronic device  102 D during the group communication session, the context of the group communication session maintained by the digital assistant on the electronic device  102 A may be handed off to the digital assistant on the electronic device  102 D. In this manner, the interactions/history with the digital assistant on the electronic device  102 A can be continued on the electronic device  102 D. 
     In one or more implementations, the subject system may allow the server  110  to aggregate the video, audio, and or messaging communications for a given group communication session, and generate a summary of the group communication session, that may subsequently be provided to, and/or made available to, one or more of the electronic devices  102 A-C and/or other electronic devices. The summary may be, for example, a video summary, a transcript, a podcast, or the like. The summary may include the entirety of the group communication session, and/or may be condensed, sped-up, or otherwise processed version of the group communication session. 
       FIG. 2  illustrates an example electronic device  102 A that may implement the multi-device communication management system in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided. 
     The electronic device  102 A may include, among other components, a host processor  202 , a memory  204 , and a communication interface  206 . The host processor  202 , which may also be referred to as an application processor or a processor, may include suitable logic, circuitry, and/or code that enable processing data and/or controlling operations of the electronic device  102 A. In this regard, the host processor  202  may be enabled to provide control signals to various other components of the electronic device  102 A. 
     The host processor  202  may also control transfers of data between various portions of the electronic device  102 A. Additionally, the host processor  202  may enable implementation of an operating system or otherwise execute code to manage operations of the electronic device  102 A. The memory  204  may include suitable logic, circuitry, and/or code that enable storage of various types of information such as received data, generated data, code, and/or configuration information. The memory  204  may include, for example, random access memory (RAM), read-only memory (ROM), flash, and/or magnetic storage. 
     The communication interface  206  may be used by the host processor  202  to communicate via one or more communication protocols, such as Wi-Fi, cellular, Ethernet, Bluetooth, Zigbee, or NFC, or the like. In one or more implementations, the communication interface  206  may be, may include, and/or may be communicatively coupled to a first radio frequency (RF) circuit, such as a WLAN circuit, a cellular RF circuit, and/or a second RF circuit, such as a Bluetooth circuit and/or an NFC circuit, or the like. 
     In one or more implementations, one or more of the host processor  202 , the memory  204 , the communication interface  206 , and/or one or more portions thereof, may be implemented in software (e.g., subroutines and code), hardware (e.g., an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a state machine, gated logic, discrete hardware components, or any other suitable devices) and/or a combination of both. 
       FIG. 3  illustrates an example server  110  that may implement the multi-device communication management system in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided. 
     The server  110  may include, among other components, a processor  302 , a memory  304 , and a communication interface  306 . The processor  302  may include suitable logic, circuitry, and/or code that enable processing data and/or controlling operations of the server  110 . In this regard, the processor  302  may be enabled to provide control signals to various other components of the server  110 , and/or other servers/devices communicatively coupled thereto. 
     The processor  302  may also control transfers of data between various portions of the server  110 . Additionally, the processor  302  may enable implementation of an operating system or otherwise execute code to manage operations, such as server-side operations, of the server  110 . The memory  304  may include suitable logic, circuitry, and/or code that enable storage of various types of information such as received data, generated data, code, and/or configuration information. The memory  304  may include, for example, RAM, ROM, flash, and/or magnetic storage. 
     The communication interface  306  may be used by the processor  302  to communicate via a communication protocol, such as Wi-Fi, cellular, Ethernet, Bluetooth, Zigbee, or NFC, or the like. In one or more implementations, the communication interface  306  may be, may include, and/or may be communicatively coupled to a first radio frequency (RF) circuit, such as a WLAN circuit, a cellular RF circuit, and/or a second RF circuit, such as a Bluetooth circuit and/or an NFC circuit, or the like. 
     In one or more implementations, one or more of the processor  302 , the memory  304 , the communication interface  306 , and/or one or more portions thereof, may be implemented in software (e.g., subroutines and code), hardware (e.g., an ASIC, an FPGA, a PLD, a controller, a state machine, gated logic, discrete hardware components, or any other suitable devices) and/or a combination of both. 
       FIG. 4  illustrates an example server  110  arranged in a distributed architecture that may implement a multi-device communication management system in accordance with one or more implementations. Not all of the depicted components may be used in all implementations, however, and one or more implementations may include additional or different components than those shown in the figure. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional components, different components, or fewer components may be provided. 
     The server  110  may include multiple servers  412 ,  414 ,  416  that may be communicatively coupled to one another. The multiple servers  412 ,  414 ,  416  may include a relay server  412 , an allocator server  414 , and a notification server  416 . One or more of the servers  412 ,  414 ,  416  may be configured to communicate with one or more of the electronic devices  102 A-D, such as to facilitate a group communication session. For example, in some embodiments, one or more relay servers  412  are configured to relay encrypted traffic for the group communication session among devices  102 A-D. In some embodiments, allocator server  414  is configured to facilitate initiating a group communication session including selecting one or more relay servers  412  to relay traffic. In some embodiments, notification server  416  is configured to push notifications to devices  102 A-D, which may include notifications from devices  102  about a group communication session such as join notifications, leave notifications, and notifications including key information used to encrypt traffic. In one or more implementations, one or more of the servers  412 ,  414 ,  416  may not be communicatively coupled to one or more others of the servers  412 ,  414 ,  416 . 
       FIG. 5  illustrates a flow diagram of an example process  500  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the process  500  is primarily described herein with reference to the electronic devices  102 A,D and the server  110  of  FIG. 1 . However, the process  500  is not limited to the electronic devices  102 A,D and/or the server  110 . The electronic devices  102 A,D and the server  110  are also presented as exemplary devices and the operations described herein may be performed by any suitable devices. Further for explanatory purposes, the blocks of the process  500  are described herein as occurring in serial, or linearly. However, multiple blocks of the process  500  may occur in parallel. In addition, the blocks of the process  500  need not be performed in the order shown and/or one or more of the blocks of the process  500  need not be performed and/or can be replaced by other operations. In one or more implementations, one or more of the operations described as being performed at the server  110  may be performed at least in part at one or more of the electronic devices  102 A,D, and vice-versa. In one or more implementations, one or more of the communications between the electronic devices  102 A,D may be communicated via a peer-to-peer connection and/or one or more of the communications between the electronic devices  102 A,D may be relayed through the server  110 , such as over a network. 
     In the process  500 , the electronic device  102 A starts performing a task ( 512 ). For example, a user of the electronic device  102 A may initiate the task on the electronic device  102 A (e.g., audio/video conference, audio streaming, document presenting, voice call, etc.). In one or more implementations, the task may be performed in conjunction with the server  110 , such as participating in a group communication session, and/or the electronic device  102 A may notify the server  110  that it has initiated, and/or is engaging in, the task. In one or more implementations, the task may be a task that the user may wish, at some point, to handoff from one electronic device  102 A to another electronic device  102 D registered to the account of the user, such when the user is participating in an audio/video conference. 
     Device capabilities of electronic devices and/or user attention information may indicate that a particular electronic device is capable of having a particular task handed off to it, and/or that a user is intending to handoff a task to a particular electronic device. For example, if a user faces the electronic device  102 D, instead of the electronic device  102 A, the attention of the user on the electronic device  102 D may be an indication that the user would like to handoff the task to the electronic device  102 D. The direction the user is facing may be determinable, for example, from an image captured from a camera device, such as a camera device of the electronic device  102 A, the electronic device  102 D, and/or some other device. In another example, the user may wish to change devices based on the respective capabilities of the devices, e.g. the electronic device  102 D may have a larger screen than the electronic device  102 A. Thus, the server  110  (and/or the electronic device  102 A) may obtain information about device capabilities corresponding to the electronic devices  102 A,D, and/or user attention information corresponding to the electronic devices  102 A,D ( 514 ), and/or any other electronic devices that are registered to the same user account as the electronic device  102 A. 
     In one or more implementations, the server  110  may determine, based at least in part on the received information, a likelihood that the user will request to handoff the task from the electronic device  102 A to the electronic device  102 D, or another of the electronic devices associated with the account of the user. If the server  110  determines that there is a high likelihood that the user may request to handoff the electronic device  102 D and/or to another electronic device, the server  110  may transmit a task handoff preparation request ( 515 ) to the electronic device  102 D indicating that the electronic device  102 D should prepare to receive a possible handoff of the task. Thus, the task handoff preparation request may be received by the electronic device  102 D before a request to handoff the task has actually been received. 
     For example, the server  110  may determine that there is a high likelihood that the user may request to handoff the task to the electronic device  102 D when the user is located with a close proximity of the electronic device  102 D. The proximity of the user to the electronic device  102 D may be determinable from known locations of the electronic devices  102 A,D (e.g., from positioning systems), by identifying the user in images and/or audio captured by the electronic device  102 D, by determining that the electronic device  102 D is able to receive short range wireless signals from the electronic device  102 A, e.g. NFC and/or Bluetooth, and/or by any other positioning mechanisms. Alternatively, and/or in addition, the server  110  may determine that there is a high likelihood that the user may request to handoff the task when the user begins interacting with the electronic device  102 D while engaging in the task on the electronic device  102 A, such as when the user opens, unlocks, and/or logs into the electronic device  102 D, and/or conversely when the user closes, locks, and/or logs out of the electronic device  102 A. 
     In one or more implementations, when the electronic device  102 D receives the task handoff preparation request from the server  110 , the electronic device  102 D may perform one or more preliminary operations to prepare to receive a handoff of the task. The preliminary operations may include, for example, the allocation/join processes described above with respect to  FIGS. 6-13 , exiting a low power mode, powering on one or more transceivers, connection establishment, e.g. for an audio and/or video conference/call, connecting to a network with a particular quality of service and/or bandwidth, powering on audio and/or video encoders/decoders, powering on/preparing one or more audio and/or video output devices, launching an application associated with the task, reserving processor and/or memory resources for performing the task, and the like. For example, if the electronic device  102 D is engaged in a background operation that requires a significant amount of processing, memory, or network bandwidth, such as downloading an update, or the like, the electronic device  102 D may pause the background operation in anticipation of receiving a handoff of the task. 
     In one or more implementations, the server  110  may coordinate one or more security operations to prepare the electronic device  102 D to receive a handoff of the task. For example, the task may require authenticating with the server  110  and/or another server, and/or receiving one or more security keys for participating in the task, such as keys for joining/participating in an audio/video conference. Thus, the server  110  may coordinate obtaining the appropriate security keys and/or the performing the appropriate authentication protocols for the electronic device  102 D and/or any other electronic devices registered to the account of the user. 
     The server  110  may provide the electronic device  102 A with information regarding which other electronic devices the task can be handed off to, such as the electronic device  102 D. The electronic devices that the task can be handed off to may include, for example, other devices registered to the account of the user. When the user wishes to handoff the task to another electronic device, such as the electronic device  102 D, the electronic device  102 A may receive user input indicating a request to handoff the task ( 516 ). For example, the electronic device  102 A may display to the user a list of the electronic devices that the task can be handed off to, e.g. as indicated by the server  110 , and the user may select one of the electronic devices, such as the electronic device  102 D, to initiate handing off the task. 
     After receiving the request to handoff the task, the electronic device  102 A transmits a task handoff request to the electronic device  102 D that requests that the electronic device  102 D prepare to receive the task being performed at the electronic device  102 A ( 518 ). When the task handoff request is received by the electronic device  102 D, the electronic device  102 D prepares to receive the task being performed by the electronic device  102 A ( 520 ). In one or more implementations, when the server  110  has already transmitted the task handoff preparation request to the electronic device  102 D ( 515 ), the electronic device  102 D may already be prepared and/or substantially prepared to receive the handoff of the task when the task handoff request is received. Thus, the electronic device  102 D may be prepared to receive the handoff of the task with minimal or no latency upon receiving the task handoff request. 
     When the electronic device  102 D is ready to receive the handoff of the task (which may be immediately upon receiving the task handoff request), the electronic device  102 D may transmit a task handoff ready indication to the electronic device  102 A to indicate that the electronic device  102 D is ready to receive the handoff of the task ( 524 ). Upon receiving the task handoff ready indication ( 526 ), the electronic device  102 A may initiate handing off the task to the electronic device  102 D ( 528 ). The handoff of the task may include transferring task state information, such as application state information, to the electronic device  102 D, such as via the server  110 . In one or more implementations, the server  110  may coordinate handing off the task. For example, the server  110  may monitor/store state information corresponding to the task being performed at the electronic device  102 A and the server  110  may communicate the task state information to the electronic device  102 D. 
     The electronic device  102 D receives the task state information, e.g. from the electronic device  102 A and/or from the server  110 , and the electronic device  102 D continues the task. When the server had already transmitted the task handoff preparation request ( 515 ) to the electronic device  102 D prior to the electronic device  102 A transmitting the task handoff request ( 518 ), there may be little or no latency between the time when the user requests that the task be handed off ( 516 ) and the task continuing on the electronic device  102 D ( 530 ). Thus, the user may experience a seamless transition from performing the task using the electronic device  102 A to continuing the task using the electronic device  102 D. 
     In one or more implementations, when the electronic device  102 D initiates the continuation of the task, the electronic device  102 D may transmit, to the electronic device  102 A, a task handoff confirmation indicating that the electronic device  102 D has continued the task ( 532 ). The electronic device  102 A may stop performing the task when the task handoff confirmation is received ( 534 ). Thus, in one or more implementations, the task may be performed concurrently on the electronic device  102 A and the electronic device  102 D for a minimal amount of time during the handoff process. The server  110  may determine that the one of the electronic devices  102 A,D that the user is currently touching, typing, or interacting with is the active electronic device, and the server  110  may only transmit communications to the active electronic device. 
     In one or more implementations, both of the electronic devices  102 A,D may be concurrently considered the active electronic device. If a signal has been determined from the activity of the user that indicates that the user will likely no longer be engaging with one or more of the electronic device  102 A, e.g. logging out, locking, closing, powering down, etc., that electronic device may no longer be considered an active electronic device. 
       FIGS. 6-14  illustrate flow diagrams of example processes  600 - 1400  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the processes  600 - 1400  are primarily described herein with reference to the electronic devices  102 A-C, and the server  110  of  FIGS. 1-4 , where the server  110  may include and/or represent one or more of a relay server  412 , an allocator server  414 , or a notification server  416 . However, the processes  600 - 1400  are not limited to the electronic devices  102 A-C and/or the server  110 , and one or more blocks (or operations) of the processes  600 - 1400  may be performed by one or more other components of the electronic devices  102 A-C and/or the server  110 . The electronic devices  102 A-C and/or the server  110  are also presented as exemplary devices and the operations described herein may be performed by any suitable devices. In one or more implementations, the electronic devices  102 A-C may communicate with one another directly and/or via a server (e.g., the server  110 ). Further for explanatory purposes, the blocks of the processes  600 - 1400  are described herein as occurring in serial, or linearly. However, multiple blocks of the processes  600 - 1400  may occur in parallel. In addition, the blocks of the processes  600 - 1400  need not be performed in the order shown and/or one or more of the blocks of the processes  600 - 1400  need not be performed and/or can be replaced by other operations. 
     The process  600  illustrates allocation of a session, such as an audio/video communication session, for the electronic device  102 A. For example, the electronic device  102 A may be participating in a group messaging session with the electronic devices  102 B-C, and the electronic device  102 A may request that the group messaging session be transitioned to an audio/video communication session. 
     In the process  600 , the electronic device  102 A transmits an allocation request to the allocator server  414  ( 612 ), requesting allocation of a session, such as an audio/video communication session. The allocation request may include a request type indicating a multi-way allocation involving multiple electronic devices, a group identifier (ID) for the electronic device  102 A, a stable ID for the electronic device  102 A, a shared-session indicator, and/or a destination list. The group ID is an identifier that is assigned to the electronic device  102 A when the electronic device  102 A joins a group for group communication, such as a messaging communication group, and may expire when the electronic device  102 A leaves the group. The stable ID is a persistent identifier for the electronic device  102 A that does not change regardless of whether the electronic device  102 A joins or leaves a group. The destination list may identify other devices (e.g., the electronic devices  102 B and  102 C, and/or other devices associated with the same user account as the electronic device  102 B or  102 C) to receive an allocation response. 
     When the allocator server  414  receives the allocation request from the electronic device  102 A, the allocator server  414  determines whether a session (e.g., a quick relay (QR) session) exists that the electronic device  102 A may participate in, for example, if one or more of the electronic devices  102 B-C has already initiated a session. If there is no existing session, the allocator server  414  may allocate a new session. In some embodiments, this allocation may include selecting one or more relay servers  412  to be used for relaying session traffic between devices  102 A-D. Thus, in response to the allocation request, the allocator server  414  allocates a session and transmits, to the electronic device  102 A, an allocation response with the credential information needed for the electronic device  102 A to join the session ( 614 ). The allocator server  414  may also transmit an allocation response to each of the other electronic devices identified on the destination list. 
     Thus, the allocator server  414  may transmit, to the electronic device  102 B, an allocation response with the credential information needed for the electronic device  102 B (e.g., Laptop) to join the session ( 616 ) and may transmit an allocation response to another electronic device  602  (e.g., a phone) that is associated with the same user account as the electronic device  102 B ( 618 ). Further, the allocator server  414  may also transmit, to the electronic device  102 C, an allocation response with the credential information needed for the electronic device  102 C to join the session ( 620 ). Each allocation response may include the request type indicating the multi-way allocation, the group ID, the stable ID, and a participant ID for a corresponding electronic device, and a session ID identifying the session. The credential information included in each allocation response may include a session key and an access token for a corresponding electronic device. Each allocation response may also include an IP address and a TCP or UDP port number for contacting the selected one or more relay servers (shown in  FIG. 6  as relay-ip and relay-port). 
     The process  700  of  FIG. 7  may continue after the process  600 . The process  700  illustrates a process for the electronic device  102 A to join a session. The electronic device  102 A transmits, to the relay server  412 , an allocation bind request with the credential information of the electronic device  102 A ( 712 ), in order to join the session using the credential information. In some embodiments, the access token received in the allocation response is used to authenticate device  102 A and indicate that relaying encrypted traffic associated with device  102 A has been authorized by allocator server  414 . In some embodiments, the session key received in the allocation response is used to encrypt traffic with relay server  412  such as content of the allocation bind request. In response to the allocation bind request, the relay server  412  transmits an allocation bind success response to the electronic device  102 A ( 714 ), to indicate that the electronic device  102 A has joined the session. When the electronic device  102 A receives the allocation bind success response, the electronic device  102 A determines that the electronic device  102 A has joined the session ( 716 ). 
     When the electronic device  102 A has joined the session, the electronic device  102 A transmits a join notification to members of the group via the notification server  416 . In particular, the electronic device  102 A transmits a join notification to the notification server  416  ( 718 ). The notification server  416  transmits the join notification of the electronic device  102 A with a session ID to the electronic device  102 B ( 720 ), where the session ID identifies the session that the electronic device  102 A has joined. 
     When the electronic device  102 B receives the join notification, the electronic device  102 B transmits an information request to the relay server  412  to request information about the electronic device  102 A ( 722 ). The information request may include a session key and/or an access token, and a request for information on participants of the session identified by the session ID included in the join notification. The information request may also include a channel number for the session. In response, the relay server  412  transmits an information response to the electronic device  102 B ( 724 ), where the information response may include participant IDs identifying devices that are participating in the session (e.g., a participant ID of the electronic device  102 A). The information response may further include the channel number for the session. 
     Further, the notification server  416  transmits the join notification of the electronic device  102 A with the session ID to the electronic device  102 C ( 726 ), where the session ID identifies the session that the electronic device  102 A has joined. When the electronic device  102 C receives the join notification, the electronic device  102 C may transmit an information request to the relay server  412  to request information about the electronic device  102 A ( 728 ). The information request may include a session key and/or an access token, and a request for information on participants of the session identified by the session ID included in the join notification. The information request may also include a channel number for the session. In response, the relay server  412  transmits an information response to the electronic device  102 C ( 730 ), where the information response may include participant IDs identifying devices that are participating in the session (e.g., a participant ID of the electronic device  102 A). The information response may further include the channel number for the session. 
     The process  800  of  FIG. 8  may continue after the process  700 . The process  800  illustrates a process for the electronic device  102 B to join a session that the electronic device  102 A has joined. When the electronic device  102 B attempts to join a session that was initiated by the electronic device  102 A, the electronic device  102 B transmits an allocation bind request to the relay server  412  ( 812 ). The allocation bind request may include the session ID identifying the session and a session key and/or an access token used for joining the session. 
     The electronic device  102 B may perform an allocation process for joining the session. The electronic device  102 B transmits an allocation request to the allocator server  414  ( 822 ) for allocation of the session. In response, the allocator server  414  allocates the session and transmits, to the electronic device  102 B, an allocation response with the credential information needed for the electronic device  102 A to use to join the session ( 824 ). The allocation response may include a session ID and a participant ID of the electronic device  102 B. The allocator server  414  may transmit an allocation response to the electronic device  102 A ( 826 ), where the allocation response may include a participant ID of the electronic device  102 A. The allocator server  414  may also transmit an allocation response to the electronic device  102 D that is associated with the same user account as the electronic device  102 A ( 828 ), where the allocation response may include a participant ID of the electronic device  102 D. Therefore, the allocation process may be performed at both the electronic device  102 A and the electronic device  102 D, such that the session can be quickly handed off from the electronic device  102 A to the electronic device  102 D. Further, the allocator server  414  may transmit an allocation response to the electronic device  102 B ( 830 ). 
     In response to the allocation bind request, the relay server  412  transmits an allocation bind success response to the electronic device  102 B ( 832 ), to indicate that the electronic device  102 B has joined the session. When the electronic device  102 B receives the allocation bind success response, the electronic device  102 B determines that the electronic device  102 B has joined the session ( 834 ). 
     In one scenario, if the access token provided via the allocation bind request has expired, the relay server  412  denies the allocation bind request and transmits an allocation bind error response to the electronic device  102 B, where the allocation bind error response indicates that the access token has expired ( 842 ). Then, the electronic device  102 B may transmit another allocation bind request with an updated access token to the relay server  412  ( 844 ). If the relay server  412  authenticates the updated access token, the relay server  412  transmits an allocation bind success response to the electronic device  102 B, to indicate that the electronic device  102 B has joined the session ( 846 ). When the electronic device  102 B receives the allocation bind success response, the electronic device  102 B determines that the electronic device  102 B has joined the session ( 848 ). 
     The process  900  of  FIG. 9  may continue after the process  800 . The process  900  illustrates a process involving a join notification. When the electronic device  102 B has joined the session, the electronic device  102 B transmits a join notification to members of the group via the notification server  416 . In particular, the electronic device  102 B transmits a join notification to the notification server  416  ( 912 ). The notification server  416  transmits the join notification of the electronic device  102 B with the session ID to the electronic device  102 A ( 914 ), where the session ID identifies the session that the electronic device  102 B has joined. 
     When the electronic device  102 A receives the join notification, the electronic device  102 A transmits an information request to the relay server  412  to request information about the electronic device  102 B ( 916 ). The information request may include a session key and/or an access token, and a request for information on participants of the session identified by the session ID included in the join notification. The information request may also include a channel number for the session. In response, the relay server  412  transmits an information response to the electronic device  102 A ( 918 ), where the information response may include participant IDs identifying devices that are participating in the session (e.g., a participant ID of the electronic device  102 A). The information response may further include the channel number for the session. 
     Further, the notification server  416  transmits the join notification of the electronic device  102 B with the session ID to the electronic device  102 C ( 920 ), where the session ID identifies the session that the electronic device  102 B has joined. When the electronic device  102 C receives the join notification, the electronic device  102 C may transmit an information request to the relay server  412  to request information about the electronic device  102 B ( 922 ). The information request may include a session key and/or an access token, and a request for information on participants of the session identified by the session ID included in the join notification. The information request may also include a channel number for the session. In response, the relay server  412  transmits an information response to the electronic device  102 C ( 924 ), where the information response may include participant IDs identifying devices that are participating in the session (e.g., a participant ID of the electronic device  102 B). The information response may further include the channel number for the session. 
     The process  1000  of  FIG. 10  may continue after the process  900 . The process  1000  illustrates a key exchange process for the electronic device  102 B. An electronic device in the session may share a pre-key of the electronic device with active participants of the session. In the process  1000 , the active participants of the session are the electronic devices  102 A-C. The electronic device  102 B transmits a pre-key of the electronic device  102 B to the notification server  416  ( 1012 ). The notification server  416  may transmit a pre-key response to the electronic device  102 B to indicate that the pre-key has been received ( 1014 ). When the notification server  416  receives the pre-key, the notification server  416  forwards the pre-key to other electronic devices in the session. In particular, the notification server  416  forwards the pre-key to the electronic device  102 A ( 1016 ) and to the electronic device  102 C ( 1018 ). The notification server  416  may transmit a pre-key response to the electronic device  102 B to indicate that the pre-key has been received ( 1014 ). In some embodiments, the pre-key is a value used by devices  102 A-D to derive a corresponding cryptographic key—e.g., the pre-key is input into a key derivation function to generate a corresponding key used to encrypt traffic. In other embodiments, pre-keys are public keys of devices  102 A-D, which possess the corresponding private keys. In some embodiments, these public keys may be registered with notification server  416  and stored by server  416  prior to the group session being established. In other embodiments, server  416  temporarily stores the public keys in order to merely facilitate pushing them to other devices  102 A-D. 
     After transmitting the pre-key to the other electronic devices via the notification server  416 , the electronic device  102 B generates a master key based on the pre-key and transmits the master key to the notification server  416  ( 1020 ). In some embodiments, this generation includes providing the pre-key to a key derivation function to generate a master key. In other embodiments in which the pre-key is a public key of a device  102 , this includes device  102 B generating a master key for devices  102  and encrypting a copy of the master key with each device  102 &#39;s respective public key such that the decrypted master key can be obtained using the corresponding private key. The notification server  416  may transmit a master key response to the electronic device  102 B to indicate that the master key has been received ( 1022 ). 
     After the master key has been provided to the notification server  416 , the electronic device  102 B may encrypt data using the master key ( 1024 ). As used herein, the term “master key” refers to a cryptographic key for encrypting data or a secret used to derive one or more cryptographic keys for encrypting data—thus, while various description below may refer to encrypting data with the master key, it is also contemplated that the data may be encrypted with one or more cryptographic keys derived from the master key. Accordingly, references to using a master key to encrypt include encrypting data with the master key as well as deriving a cryptographic key to encrypt data. The electronic device  102 B may transmit the encrypted data to another device via the relay server  412 . For example, the electronic device  102 B may transmit the encrypted data to the relay server  412  ( 1026 ), and the relay server  412  may forward the encrypted data to the electronic device  102 A ( 1028 ). The electronic device  102 A may not yet have the master key to decrypt the encrypted data ( 1030 ). The notification server  416  transmits the master key to the electronic device  102 A ( 1032 ). Then, the electronic device  102 A may decrypt the encrypted data using the master key ( 1034 ). 
     When both of the electronic devices  102 A and  102 B have the master key, the electronic devices  102 A and  102 B may perform encrypted data communication with each other. For example, the electronic device  102 B may transmit another encrypted data to the relay server  412  ( 1036 ), and the relay server  412  may forward the encrypted data to the electronic device  102 A ( 1038 ). The electronic device  102 A may transmit another encrypted data to the relay server  412  ( 1040 ), and the relay server  412  may forward the encrypted data to the electronic device  102 B ( 1042 ). In some embodiments, devices  102  periodically discontinue the use of pre-keys and/or the master key. For example, in one embodiment, pre-keys may expire every hour, and master keys may expire every ten minutes. In such an embodiment, devices  102  distribute updated pre-keys and/or master keys prior to expiration so that communication can continue without interruption. 
     The process  1100  of  FIG. 11  may continue after the process  1000 . The process  1100  illustrates an allocation bind process for the electronic device  102 C. The electronic device  102 C may perform an allocation process for joining the session started by the electronic device  102 A. In particular, the electronic device  102 C transmits an allocation request to the allocator server  414  ( 1112 ). The allocator server  414  may transmit an allocation response to indicate that the allocator server  414  has received the allocation request ( 1114 ). In response to the allocation request, the allocator server  414  transmits, to the electronic device  102 C, an allocation response with the credential information needed for the electronic device  102 C to use to join the session ( 1116 ). The allocator server  414  may transmit, to the electronic device  102 A, an allocation response with the credential information needed for the electronic device  102 C to use to join the session ( 1118 ). Further, the allocator server  414  may transmit, to the electronic device  102 B, an allocation response with the credential information needed for the electronic device  102 C to use to join the session ( 1120 ). 
     The electronic device  102 C may transmit, to the relay server  412 , an allocation bind request with the credential information of the electronic device  102 C ( 1122 ), in order to join the session using the credential information ( 1122 ). In response to the allocation bind request, the relay server  412  transmits an allocation bind success response to the electronic device  102 C ( 1124 ), to indicate that the electronic device  102 C has joined the session. When the electronic device  102 C receives the allocation bind success response, the electronic device  102 C determines that the electronic device  102 C has joined the session ( 1126 ). 
     In one scenario, if the access token provided via the allocation bind request has expired, the relay server  412  denies the allocation bind request and transmits an allocation bind error response to the electronic device  102 C, where the allocation bind error response indicates that the access token has expired ( 1128 ). Then, the electronic device  102 C may transmit another allocation bind request with an updated access token to the relay server  412  ( 1130 ). If the relay server  412  authenticates the updated access token, the relay server  412  transmits an allocation bind success response to the electronic device  102 C, to indicate that the electronic device  102 C has joined the session ( 1132 ). When the electronic device  102 C receives the allocation bind success response, the electronic device  102 C determines that the electronic device  102 C has joined the session ( 1134 ). 
     The process  1200  of  FIG. 12  may continue after the process  1100 . The process  1200  illustrates a join process for the electronic device  102 C to become an active participant of a group communication started by one or more of the electronic devices  102 A and  102 B. The electronic device  102 C transmits a join message to the notification server  416  ( 1212 ). In response, the notification server  416  may transmit a join response to the electronic device  102 C to indicate that the notification server  416  has received the join message ( 1214 ). 
     The notification server  416  forwards the join message to the other electronic devices  102 A-D. In particular, the notification server  416  forwards the join message to the electronic device  102 A ( 1216 ). In response, the electronic device  102 A updates its active participant list to include the electronic devices  102 B and  102 C as active participants with the electronic device  102 A ( 1218 ). The notification server  416  forwards the join message to the electronic device  102 B ( 1220 ). In response, the electronic device  102 B updates its active participant list to include the electronic devices  102 A and  102 C as active participants with the electronic device  102 B ( 1222 ). 
     Further, to update the active participant list of the electronic device  102 C, the other devices may send active participant notifications to the electronic device  102 C. In particular, the electronic device  102 A transmits an active participant notification to the notification server  416  ( 1224 ). The notification server  416  may transmit an active participant notification response to the electronic device  102 A to indicate that the notification server  416  has received the active participant notification ( 1226 ). The notification server  416  forwards the active participant notification to the electronic device  102 C ( 1228 ). Then, the electronic device  102 C updates its active participant list to indicate that the electronic device  102 A is an active participant with the electronic device  102 C ( 1230 ). 
     Subsequently, the electronic device  102 B transmits an active participant notification to the notification server  416  ( 1232 ). The notification server  416  may transmit an active participant notification response to the electronic device  102 B to indicate that the notification server  416  has received the active participant notification ( 1234 ). The notification server  416  forwards the active participant notification to the electronic device  102 C ( 1236 ). Then, the electronic device  102 C updates its active participant list to indicate that the electronic devices  102 A and  102 B are active participants with the electronic device  102 C ( 1238 ). 
     The process  1300  of  FIG. 13  may continue after the process  1200 . The process  1300  illustrates a key exchange process for the electronic device  102 C. An electronic device in the session may share a pre-key of the electronic device with the active participants. In the process  1200 , the active participants are the electronic devices  102 A-C, and thus the electronic device  102 C may share a pre-key of the electronic device  102 C with the electronic devices  102 A-B. In particular, the electronic device  102 C transmits the pre-key of the electronic device  102 C to the notification server  416  ( 1312 ). In response, the notification server  416  may transmit a pre-key response to the electronic device  102 C to indicate that the notification server  416  has received the pre-key ( 1314 ). The notification server  416  forwards the pre-key of the electronic device  102 C to the electronic device  102 A ( 1316 ) and to the electronic device  102 B ( 1318 ). 
     The electronic device  102 C generates a master key based on a pre-key of the electronic device  102 A and sends the master key to the notification server  416  ( 1320 ). As noted above, in embodiments in which a pre-key is a public key, this may include generating a master key and encrypting copies of the master key with the public keys of other devices  102 , which can decrypt the copies with the corresponding private keys. In response, the notification server  416  may transmit a master key response to the electronic device  102 C to indicate that the notification server  416  has received the master key ( 1322 ). The electronic device  102 C generates a master key based on a pre-key of the electronic device  102 B and sends the master key to the notification server  416  ( 1324 ). In some embodiments, messages  1320  and  1324  may be combined into one message as will be discussed below with respect to  FIG. 34 . In response, the notification server  416  may transmit a master key response to the electronic device  102 C to indicate that the notification server  416  has received the master key ( 1326 ). Master keys, however, may be exchanged differently than shown in  FIG. 13  as will be discussed below with respect to  FIGS. 36-38 . 
     The electronic device  102 C may encrypt data using the master key of the electronic device  102 C ( 1328 ). The electronic device  102 C may transmit the encrypted data to the relay server  412  ( 1330 ), and the relay server  412  then forwards the encrypted data to the electronic device  102 A ( 1332 ) and to the electronic device  102 B ( 1334 ). The notification server  416  transmits, to the electronic device  102 A, the master key of the electronic device  102 C based on the pre-key of the electronic device  102 A ( 1336 ). The electronic device  102 A decrypts the encrypted data using the master key ( 1338 ). The notification server  416  transmits, to the electronic device  102 B, the master key of the electronic device  102 C based on the pre-key of the electronic device  102 B ( 1340 ). The electronic device  102 B decrypts the encrypted data using the master key ( 1342 ). 
     After distributing the master key, the electronic devices  102 A-C may perform encrypted communication with one another. For example, the electronic device  102 B transmits an encrypted data to the relay server  412  ( 1344 ), and the relay server  412  then forwards the encrypted data to the electronic device  102 A ( 1346 ) and to the electronic device  102 C ( 1348 ). For example, the electronic device  102 A transmits an encrypted data to the relay server  412  ( 1350 ), and the relay server  412  then forwards the encrypted data to the electronic device  102 B ( 1352 ) and to the electronic device  102 C ( 1354 ). 
     The process  1400  of  FIG. 14  may continue after the process  1300 . The process  1400  illustrates a process when the electronic device  102 C is requested to leave the group communication. The electronic device  102 A may request the electronic device  102 C to leave the group communication, which prompts the electronic device  102 C to transmit an unbind allocation request to the relay server  412  ( 1412 ). In response, the relay server  412  transmits an unbind allocation response to the electronic device  102 C ( 1414 ) to indicate that the electronic device  102 C is no longer in the session for the group communication. In some embodiments, relay server  412  may also convey an unbind allocation response to the remaining devices  102  participating in the session in order to make them aware that device  102 C is disconnecting. In another embodiments, devices  102  may receive an indication of device  102 C being kicked from device  102 A. Then, the electronic device  102 C disconnects the link for the group communication with the electronic devices  102 A and  102 B ( 1416 ) 
     After an electronic device leaves the session, other electronic devices in the session may update, or roll, the master key, and/or any other shared keys, such that the electronic device that is no longer in the session will not be able to join the session or communicate with the other devices. In the process  1400 , the notification server  416  transmits, to the notification server  416 , an updated master key of the electronic device  102 A. The notification server  416  may transmit a master key response to the electronic device  102 A to indicate that the updated master key has been received ( 1420 ). The electronic device  102 A may encrypt data using the updated master key ( 1422 ). The notification server  416  forwards the updated master key to the electronic device  102 B ( 1424 ). The electronic device  102 B may encrypt data with the updated master key ( 1426 ). In such an embodiment, device  102 C does not receive the updated master key in order to prevent it from decrypting any encrypted traffic of the session after it leaves the session. 
     Thus, the electronic devices  102 A and  102 B may use the updated master key to encrypt data for communication with each other. For example, the electronic device  102 A transmits an encrypted data to the relay server  412  ( 1428 ), and the relay server  412  then forwards the encrypted data to the electronic device  102 B ( 1430 ). For example, the electronic device  102 B transmits an encrypted data to the relay server  412  ( 1432 ), and the relay server  412  then forwards the encrypted data to the electronic device  102 A ( 1434 ). 
     The electronic device  102 C may notify the group that the electronic device  102 C has left. In particular, the electronic device  102 C transmits a leave notification to the notification server  416  ( 1436 ). The notification server  416  may transmit a leave notification response to the electronic device  102 C ( 1438 ) to indicate that the notification server  416  has received the leave notification. Then, the notification server  416  forwards the leave notification to the electronic device  102 A ( 1440 ). In response to the leave notification, the electronic device  102 A updates the active participant list to remove the electronic device  102 C from the active participant list ( 1442 ). The notification server  416  also forwards the leave notification to the electronic device  102 B ( 1444 ). In response to the leave notification, the electronic device  102 A updates the active participant list to remove the electronic device  102 C from the active participant list ( 1446 ). 
     Although process  1400  is described within the context of kicking a device  102 , similar processes are also contemplated in which a device  102  leaves the session and causes an update of the master key being used to encrypt traffic for continuing the session after the device  102 &#39;s departure. For example, in some embodiments, process  1400  may begin with steps  1436 - 1446  in which a disconnecting device  102  provides an indication of its upcoming departure via notification server  416  to the other devices  102  participating in the session and causes them to perform  1418 - 1432  to update the master key for the session. As another example, in some embodiments, if device  102 C is no longer sending traffic to relay server  412  (or server  412  is unable to deliver traffic to device  102 C), relay server  412  may send notifications to the other devices  102  to indicate that device  102 C has dropped from the session and to cause master key to be updated. In some embodiments, key updates may be performed each time a device  102  leaves or joins a session (such as joining of device  102 C discussed above with respect to  FIG. 13 ). In some embodiments, key updates are performed each time a new device  102  is registered with a user&#39;s account, which may be an account associated with a cloud service. For example, if device  102 A is registered to a particular user&#39;s account and during a communication session device  102 D is added to that account, all devices  102  participating in the session update their pre-keys and/or master key. In various embodiments, key updates may also occur periodically as discussed above. 
     In one or more implementations, one or more of the messages and/or requests described above in  FIGS. 6-14  may be, and/or may include, an array. For example, identity requests/queries may be transmitted as an array, such that multiple identity requests can be packaged/transmitted in a consolidated format via a single array, thereby reducing the amount of time and/or overhead required for session setup/establishment. Thus, to send identity requests corresponding to four different entities/devices, the electronic device  102 A only needs to send one array containing four different identity requests, instead of sending four separate identity requests. For example, the destination list of the allocation request may be an array that stores identifiers of each of the other electronic devices  102 B-C, thereby allowing the electronic device  102 A to transmit a single allocation request to initialize the session with multiple other electronic devices  102 B-C. 
       FIG. 15  illustrates a flow diagram of an example process  1500  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the process  1500  is primarily described herein with reference to the electronic devices  102 A-C, and the server  110  of  FIGS. 1-3 . The electronic devices  102 A-C and the server  110  are also presented as exemplary devices and the operations described herein may be performed by any suitable devices. The electronic devices  102 A-C may communicate with one another directly and/or via a server (e.g., the server  110 ). Further for explanatory purposes, the blocks of the process  1500  are described herein as occurring in serial, or linearly. However, multiple blocks of the process  1500  may occur in parallel. In addition, the blocks of the process  1500  need not be performed in the order shown and/or one or more of the blocks of the process  1500  need not be performed and/or can be replaced by other operations. 
     In the process  1500 , the electronic devices  102 A-C may be participating in, or preparing to participate in, and audio/video group communication session. One or more of the electronic devices  102 A-C and/or the server  110 , such as the electronic device  102 A, receives buffer level report(s) from the other electronic devices  102 B-C in the group communication session ( 1512 ,  1514 ). A buffer level report may include, for example, information regarding one or more buffers, such as one or more jitter buffers at a given electronic device  102 B. For example, the electronic device  102 B may maintain a jitter buffer for audio and/or video packets received from the electronic device  102 A, as well as a separate jitter buffer for audio and/or video packets received from the electronic device  102 C. The jitter buffer may be used to avoid buffer underruns due to jitter and/or propagation delays. The information regarding the one or more buffers may include, for example, the current target buffer level being maintained, a range of the high and low buffer levels for a given period of time, and the like. 
     In one or more implementations, the current target buffer level being maintained by a given electronic device  102 B for audio and/or video packets received from another electronic device  102 A may be indicative of the audio and/or video output delay experienced by the user of the electronic device  102 B with respect to the audio and/or video stream corresponding to the user of the electronic device  102 A. For example, the higher the current target buffer level is, the greater the audio and/or video output delay may be, since a larger number of audio and/or video packets are being buffered. In one or more implementations, the electronic devices  102 B-C may provide the buffer level reports to the electronic device  102 A on a continuous and/or periodic basis. 
     The electronic device  102 A may process the buffer level reports to determine a group target buffer level, and/or a group target buffer level range, to be implemented by each of the electronic devices  102 A-C for each of the jitter buffers ( 1518 ). In this manner, the target buffer level, and corresponding audio and/or video output delay, will be substantially the same for each of the electronic devices  102 A-C, thereby ensuring fairness in the communications of the audio/video group communication session, e.g., since each of the users will hear/see a given audio/video stream at approximately the same time and therefore have an equal opportunity to respond. 
     The electronic device  102 A may determine the group target buffer level, for example, such that the group target buffer level is within, or above, the range of high and low buffer levels indicated by each of the electronic devices  102 B-C, as well as the range of high and low buffer levels of the electronic device  102 A. In one or more implementations, the electronic device  102 A may determine the group target buffer level with an upper bound such that the audio and/or video delay experienced by the users of the electronic devices  102 A-C is not excessively long. 
     The electronic device  102 A may transmit an indication of the group target buffer level to the electronic device  102 B ( 1520 ) and the electronic device  102 C ( 1522 ). The electronic device  102 A may subsequently receive one or more downlink communications from the electronic device  102 B ( 1524 ), and one or more downlink communications from the electronic device  102 C ( 1526 ), and the electronic device  102 A may implement the group target buffer level ( 1528 ) for the received communications. 
     Similarly, the electronic device  102 B may receive one or more downlink communications from the electronic device  102 A ( 1530 ) and the electronic device  102 C ( 1532 ), and the electronic device  102 B may implement the group target buffer level ( 1534 ) for the received communications. The electronic device  102 C may receive one or more downlink communications from the electronic device  102 A ( 1536 ) and the electronic device  102 B ( 1538 ), and the electronic device  102 C may implement the group target buffer level ( 1540 ) for the received communications. 
     In one or more implementations, the server  110  may receive the buffer level reports from the electronic devices  102 A-C, and the server  110  may determine the appropriate group target buffer level for the electronic devices  102 A-C. In one or more implementations, the group target buffer level may be indicated as a percentage of the buffer that is occupied with data, a number of bytes in the buffer, etc. 
     In one or more implementations, the group target buffer level may be implemented as a function of the audio delay experienced at each of the electronic devices  102 A-C. For example, the electronic devices  102 A-C may share their audio delays with each other, and the electronic devices  102 A-C may agree on an group audio delay. For example, the electronic devices  102 A-C may agree to implement an audio delay that is equal to the greatest audio delay being experienced by one of the electronic devices  102 A-C, such as the electronic device  102 A. Thus, the electronic device  102 A may not implement any additional audio delay, while the electronic devices  102 B-C may implement an additional audio delay so that their total audio delay equals the audio delay experienced by the electronic device  102 A. 
       FIG. 16  illustrates a flow diagram of an example process  1600  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the process  1600  is primarily described herein with reference to the electronic devices  102 A-C and the server  110  of  FIGS. 1-3 . However, the electronic devices  102 A-C and the server  110  are presented as exemplary devices and the operations described herein may be performed by any suitable devices. The electronic devices  102 A-C may communicate with one another directly and/or via a server (e.g., the server  110 ). Further for explanatory purposes, the blocks of the process  1600  are described herein as occurring in serial, or linearly. However, multiple blocks of the process  1600  may occur in parallel. In addition, the blocks of the process  1600  need not be performed in the order shown and/or one or more of the blocks of the process  1600  need not be performed and/or can be replaced by other operations. 
     In the process  1600 , the electronic devices  102 A-C may be participating in, or preparing to participate in, and audio/video group communication session, such as in coordination with the server  110 . The server  110  may receive downlink condition reports from electronic devices  102 A-C ( 1612 ,  1614 ,  1616 ) and determine a quality of the audio and/or video streams to be transmitted by each of the electronic devices  102 A-C to each of the other electronic devices  102 A-C for the audio/video group communication session ( 1622 ). 
     The downlink condition reports may indicate a downlink condition from the server  110  to the respective electronic devices  102 A-C, such as downlink bandwidth, downlink signal to noise ratio (SNR), downlink bit error rate (BER), downlink received signal strength indication (RSSI), and the like. In one or more implementations, the downlink condition reports may be, and/or may include Real-time Transport Protocol (RTP) Control Protocol (RTCP) reports. The server  110  may also generate uplink condition reports for the uplink channels between the electronic devices  102 A-C and the server  110 . In one or more implementations, the uplink and downlink channels may be asymmetrical. For example, the electronic device  102 A may have a downlink via Wi-Fi and have an uplink via cellular. Thus, the uplink and downlink channel conditions/bandwidths may differ for a given electronic device  102 A. 
     Based on the downlink channel reports received by the server  110 , and the uplink channel reports generated by the server  110 , the server may determine appropriate tiers of audio and/or video streams to be transmitted and/or made available by each of the electronic devices  102 A-C. For example, the server  110  may determine a number of tiers of quality levels of audio and/or video streams, such as three tiers, for each of the electronic devices  102 A-C to provide and/or make available to the other electronic devices  102 A-C. 
     The tiers for each of the electronic devices  102 A-C may be determined by the server  110  such that high quality audio and/or video streams are made available to the electronic devices  102 A-C that have the downlink bandwidth to support the high quality audio and/or video streams while also making low quality audio and/or video streams available to the electronic devices  102 A-C that have downlink bandwidth constraints. In addition, the server  110  may account for the uplink channel conditions from a given electronic device  102 A to the server  110  when determining the quality tiers for the given electronic device  102 A. For example, the server  110  may determine the different quality tiers for the electronic device  102 A such that the electronic device  102 A has sufficient uplink bandwidth to support concurrently transmitting the streams at all three quality levels. 
     The server  110  may then transmit indications of the determined quality tiers to the electronic devices  102 A-C, respectively ( 1624 ,  1626 ,  1628 ). The electronic devices  102 A-C may then transcode and/or encode their audio and/or video streams to reflect each of the indicated quality tiers. For example, the electronic device  102 A may encode a first video stream for a first tier at 1080P resolution, a second video stream for a second tier at 720P resolution, and a third video stream for a third tier at 480i resolution. Thus, the bit rates of the tiers may differ to account for the varying downlink conditions for each of the other electronic devices  102 B-C. The electronic device  102 A may then transmit all of the tiers of the audio and/or video streams to the server  110  and the server  110  may relay the appropriate streams to the other electronic devices  102 B-C, such as based on the downlink channel conditions of each of the other electronic devices  102 B-C. In one or more implementations, the server  110  may transmit an indication to the electronic device  102 A indicating which of the audio and/or video streams will be forwarded to the other electronic devices  102 B-C, and the electronic device  102 A may only transmit the indicated audio and/or video streams to the server  110 , and/or directly to the other electronic devices  102 B-C. 
     In one or more implementations, the electronic devices  102 A-C may exchange downlink and uplink channel reports to each other independent of the server  110 . The electronic devices  102 A-C may then each determine, e.g. independent of the server  110 , the appropriate tiers of quality levels to make available to the other electronic devices  102 A-C. In one or more implementations, the electronic devices  102 A-C may advertise to the different quality tiers they have available to each other. For example, the electronic device  102 A may broadcast, and/or publish to the server  110 , a manifest file to the electronic devices  102 B-C that lists the audio and/or video profiles of the audio and/or video streams that the electronic device  102 A can provide. The profiles may include information such as bit rate, codec, resolution, frame rate, and the like. The other electronic devices  102 B-C may receive the manifest and may transmit a message to the electronic device  102 A requesting one of the available audio and/or video streams. The electronic device  102 A may transmit the requested audio and/or video streams to the electronic devices  102 B-C, such as directly or through the server  110 . 
     In one or more implementations, the server  110  and/or the electronic devices  102 A-C may continuously monitor the uplink and/or downlink channel reports and may dynamically and/or adaptively change the tiers of the quality levels being made available by one or more of the electronic devices  102 A-C. Thus, as the network conditions change, or more electronic devices join the group communication session, the tiers of the quality levels are dynamically and/or adaptively adjusted. 
     In one or more implementations, the server  110  and/or the electronic devices  102 A-D may cap the number of audio and/or video streams being received by a given electronic device  102 A at any given time. For example, if the electronic device  102 A has very little downlink bandwidth available, the server  110  may only transmit a single audio and/or video stream to the electronic device  102 A, such as an audio and/or video stream corresponding to the user who is currently speaking or communicating. The electronic device  102 A may display static images for the other users in the audio/video group communication session. 
     In one or more implementations, if the electronic device  102 A only has sufficient bandwidth to receive an audio stream, e.g. without a video stream, the electronic device  102 A may animate an images (or avatars) of the users associated with the other electronic devices  102 B-C to coincide with when the users associated with the other electronic devices  102 B-C are speaking. Thus, the mouths of the users in the images (and/or the mouths of the avatars) may open and close in synchronicity with the words being spoken by the other users. 
     In one or more implementations, the electronic device  102 A may move from a first network (e.g., WLAN) that provides high uplink transmission rate to a second network (e.g., cellular network) that provides lower uplink transmission rate. In such an example, the electronic device  102 A may be configured to transmit high quality audio and/or video streams via uplink communication while in the first network, and to transmit data of low quality audio and/or video streams via uplink communication while in the second network. In one example, even if the electronic device  102 A is capable of transmitting a higher quality audio and/or video streams while in the second network, the electronic device  102 A may be configured to transmit the low quality audio and/or video streams regardless of the uplink condition, in case the uplink condition deteriorates to a point where the higher quality audio and/or videos streams cannot be reliably transmitted in the uplink communication and/or in case downlink conditions/bandwidth to the other electronic devices  102 B-C are not sufficient for communication of the higher quality audio and/or videos streams. 
       FIGS. 17 and 18  illustrate flow diagrams of example processes  1700  and  1800  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the processes  1700  and  1800  are primarily described herein with reference to the electronic device  102 A of  FIGS. 1-2 . However, the processes  1700  and  1800  are not limited to the electronic device  102 A, and one or more blocks (or operations) of the processes  1700  and  1800  may be performed by one or more other components of the electronic device  102 A. The electronic device  102 A also is presented as an exemplary device and the operations described herein may be performed by any suitable device, such as one or more of the other electronic devices  102 B-D. Further for explanatory purposes, the blocks of the processes  1700  and  1800  are described herein as occurring in serial, or linearly. However, multiple blocks of the processes  1700  and  1800  may occur in parallel. In addition, the blocks of the processes  1700  and  1800  need not be performed in the order shown and/or one or more of the blocks of the processes  1700  and  1800  need not be performed and/or can be replaced by other operations. 
     The process  1700  describes a handoff of a task from the perspective of the electronic device  102 A that is handing off the task. In the process  1700 , the electronic device  102 A transmits, to the server  110 , information corresponding to at least one of a task in progress, device capability, or user attention ( 1702 ). For example, the electronic device  102 A may transmit information regarding a task in progress, e.g. a task for which a handoff request may subsequently be received from the user, information regarding the capabilities of the electronic device  102 A, and/or user attention information that is obtainable and/or determinable at the electronic device  102 A. 
     The electronic device  102 A may receive, from the server  110 , an indication of the electronic devices that are registered to the same user account as the electronic device  102 A and are available to receive a handoff of the task ( 1703 ). The electronic device  102 A may provide the user with a list of the other electronic devices that are available to have a task handed off to. 
     The electronic device  102 A may receive a request to handoff a task to a second electronic device, such as the electronic device  102 D ( 1704 ). For example, the electronic device  102 A may receive a request from the user to handoff the task to the electronic device  102 D. Upon receiving the request to handoff the task ( 1704 ), the electronic device  102 A transmits, to the second electronic device, such as the electronic device  102 D, a task handoff request requesting that the second electronic device to prepare to receive a handoff of the task ( 1706 ). 
     Once the second electronic device is ready to receive the task, the electronic device  102 A receives a task handoff ready indication from the second electronic device, such as the electronic device  102 D ( 1710 ). When the second electronic device is prepared to receive the handoff of the task, the electronic device  102 A initiates the handoff of the task to the second device ( 1714 ). 
     The electronic device  102 A determines whether the second electronic device has initiated the continuation of the task ( 1716 ). In one or more implementations, the electronic device  102 A determines whether the second electronic device has initiated the continuation of the task by determining whether a task continuation confirmation has been received from the second electronic device, the task continuation confirmation indicating that the second electronic device has initiated the continuation of the task. The electronic device  102 A may be configured to determine that the second electronic device has initiated the continuation of the task when the task continuation confirmation is received. If the second electronic device has initiated the continuation of the task ( 1716 ), the electronic device  102 A may stop performing the task ( 1718 ). If the second electronic device has not initiated the continuation of the task ( 1716 ), the electronic device  102 A continues to perform the task ( 1720 ) at least until determining that the second electronic device has initiated the continuation of the task. 
     The process  1800  describes a handoff of a task from the perspective of the electronic device  102 D that is receiving the handoff of the task. In the process  1800 , the electronic device  102 D may transmit, to the server  110  (and/or the electronic device  102 A), information corresponding to at least one of a capability of the electronic device  102 D or user attention information ( 1802 ). The electronic device  102 D receives, from the server  110  (and/or the electronic device  102 A), a task handoff preparation request ( 1804 ). The task handoff preparation request may be received by the electronic device  102 D in anticipation of a task being handed off to the electronic device  102 D but before a handoff of the task has been requested. In response receiving the task handoff preparation request, the electronic device  102 D performs preliminary preparations for receiving a possible handoff of the task from the electronic device  102 A ( 1806 ). 
     The electronic device  102 D determines whether a task handoff request has been received, such as from the electronic device  102 A and/or the server  110  ( 1808 ). When the task handoff request is received ( 1808 ), the electronic device completes any remaining preparations for receiving a handoff of the task. For example, the task handoff request may include information, such as task state information and/or application state information that was not available when the task handoff preparation request was received. Thus, in one or more implementations, the electronic device  102 D may complete any remaining preparations for receiving the handoff of the task based at least in part on information received in the task handoff request. 
     When the electronic device  102 D has completed the preparations to receive the handoff of the task, the electronic device  102 D may transmit, to the electronic device  102 A and/or the server  110 , a task handoff ready indication indicating that the electronic device  102 D is ready to receive the handoff of the task ( 1810 ). The electronic device  102 D receives a handoff of the task from the electronic device  102 A and/or the server  110  ( 1812 ). The handoff of the task may include task and/or application state information that may be used by the electronic device  102 D to initiate the continuation of the task ( 1814 ). After initiating the continuation of the task, the electronic device  102 D may transmit, to the server  110  and/or the electronic device  102 A, a task continuation confirmation ( 1816 ). 
       FIGS. 19-23  illustrate flow diagrams of example processes  1900 - 2300  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the processes  1900 - 2300  are primarily described herein with reference to the electronic device  102 A of  FIGS. 1-3 . However, the processes  1900 - 2300  are not limited to the electronic device  102 A, and one or more blocks (or operations) of the processes  1900 - 2300  may be performed by one or more other components of the electronic device  102 A. The electronic device  102 A also is presented as an exemplary device and the operations described herein may be performed by any suitable device, such as one or more of the other electronic devices  102 B-D and/or the server  110 . Further for explanatory purposes, the blocks of the processes  1900 - 2300  are described herein as occurring in serial, or linearly. However, multiple blocks of the processes  1900 - 2300  may occur in parallel. In addition, the blocks of the processes  1900 - 2300  need not be performed in the order shown and/or one or more of the blocks of the processes  1900 - 2300  need not be performed and/or can be replaced by other operations. 
     In the process  1900 , the electronic device  102 A transmits, to an allocator server  414 , an allocation request requesting allocation of a session ( 1902 ). The allocation request may include a group ID of the electronic device  102 A for the session, a stable ID of the electronic device  102 A. The allocation request may further include a destination device list identifying the one or more second devices to receive an allocation response. The allocation request may further include a session ID of the session and a participant ID of the electronic device  102 A. 
     The electronic device  102 A receives, from the allocator server  414 , an allocation response in response to the allocation request, the allocation response including credential information for the electronic device  102 A to use to join the session ( 1904 ). The credential information may include at least one of a session key or an access token for the electronic device  102 A. 
     The electronic device  102 A transmits, to a relay server  412 , an allocation bind request with the credential information to join the session using the credential information ( 1906 ). The allocation bind request may include a session ID of the session and the credential information. The electronic device  102 A receives, from the relay server  412 , an allocation bind success response in response to the allocation bind request, the allocation bind success response indicating that the electronic device  102 A has joined the session ( 1908 ). The electronic device  102 A transmits a join notification to one or more other electronic devices  102 B-C via a notification server  416  to notify the one or more other electronic devices  102 B-C that the electronic device  102 A has joined the session ( 1910 ). 
       FIG. 20  illustrates a flow diagram of an example process  2000  of the multi-device communication management system in accordance with one or more implementations, continuing from  FIG. 19 . At  1912 , the electronic device  102 A continues from  1912  of  FIG. 19 . The electronic device  102 A receives a second join notification from at least one of the other electronic devices  102 B-C ( 2002 ), where the second join notification notifies the electronic device  102 A that the at least one of the other electronic devices  102 B-C has joined the session. The electronic device  102 A transmits, to the relay server  412 , an information request requesting information on the at least one of the other electronic devices  102 B-C ( 2004 ). The electronic device  102 A receives, from the relay server  412 , an information response including the information on the at least one of the other electronic devices  102 B-C in response to the information request ( 2006 ). 
       FIG. 21  illustrates a flow diagram of an example process  2100  of the multi-device communication management system in accordance with one or more implementations, continuing from  FIG. 19 . At  1912 , the electronic device  102 A continues from  1912  of  FIG. 19 . The electronic device  102 A receives a pre-key from at least one of the one or more other electronic devices  102 B-C ( 2102 ). The electronic device  102 A receives a master key from the at least one of the one or more other electronic devices  102 B-C, the master key being based on the pre-key ( 2104 ). 
     The electronic device  102 A communicates data with the at least one of the one or more other electronic devices  102 B-C using the master key, where the data is encrypted with the master key ( 2106 ). For example, the electronic device  102 A may encrypt data with the master key and transmit the encrypted data to the at least one of the one or more other electronic devices  102 B-C. For example, the electronic device  102 A may receive encrypted data from the at least one of the one or more other electronic devices  102 B-C, and decrypt the encrypted data using the master key. 
       FIG. 22  illustrates a flow diagram of an example process  2200  of the multi-device communication management system in accordance with one or more implementations, continuing from  FIG. 19 . At  1912 , the electronic device  102 A continues from  1912  of  FIG. 19 . The electronic device  102 A transmits a pre-key to at least one of the one or more other electronic devices  102 B-C that has joined the session ( 2202 ). The electronic device  102 A generates a master key based on the pre-key ( 2204 ). The electronic device  102 A transmits the master key to the at least one of the one or more other electronic devices  102 B-C ( 2206 ). 
     The electronic device  102 A communicates data with the at least one of the one or more other electronic devices  102 B-C using the master key, where the data is encrypted with the master key ( 2208 ). For example, the electronic device  102 A may encrypt data with the master key and transmit the encrypted data to the at least one of the one or more other electronic devices  102 B-C. For example, the electronic device  102 A may receive encrypted data from the at least one of the one or more other electronic devices  102 B-C, and may decrypt the encrypted data using the master key. 
       FIG. 23  illustrates a flow diagram of an example process  2300  of the multi-device communication management system in accordance with one or more implementations, continuing from  FIG. 19 . At  1912 , the electronic device  102 A continues from  1912  of  FIG. 19 . The electronic device  102 A transmits, to the relay server  412 , an allocation unbind request to leave the session ( 2302 ). The electronic device  102 A receives, from the relay server  412 , an allocation unbind response in response to the allocation unbind request to indicate that the electronic device  102 A has left the session ( 2304 ). The electronic device  102 A transmits a leave notification to the one or more other electronic devices  102 B-C that have joined the session via the notification server  416  ( 2306 ). The leave notification notifies the one or more other electronic devices  102 B-C that the electronic device  102 A has left the session. 
       FIGS. 24-27  illustrate flow diagrams of example processes  2400 - 2700  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the processes  2400 - 2700  are primarily described herein with reference to the server  110  of  FIGS. 1 and 3-4 . However, the processes  2400 - 2700  are not limited to the server  110 , and one or more blocks (or operations) of the processes  2400 - 2700  may be performed by one or more other components of the server  110 . The server  110  also is presented as an exemplary device and the operations described herein may be performed by any suitable device. Further for explanatory purposes, the blocks of the processes  2400 - 2700  are described herein as occurring in serial, or linearly. However, multiple blocks of the processes  2400 - 2700  may occur in parallel. In addition, the blocks of the processes  2400 - 2700  need not be performed in the order shown and/or one or more of the blocks of the processes  2400 - 2700  need not be performed and/or can be replaced by other operations. 
     In the process  2400 , the server  110  receives, from a first electronic device  102 A, an allocation request requesting allocation of session ( 2402 ). The allocation request may include a group ID of the first electronic device  102 A for the session, a stable ID of the first device. The allocation request may further include a destination device list identifying one or more second electronic devices  102 B-C to receive an allocation response. The allocation response may further include a session ID of the session and a participant ID of the first electronic device  102 A. 
     The server  110  transmits an allocation response to the first electronic device  102 A and one or more second electronic devices  102 B-C in response to the allocation request, the allocation response including credential information for the first electronic device  102 A to use to join the session ( 2404 ). The credential information may include at least one of a session key or an access token for the first electronic device  102 A. 
     The server  110  receives, from the first electronic device  102 A, an allocation bind request with the credential information to join the session using the credential information ( 2406 ). The allocation bind request may include a session ID of the session and the credential information. The server  110  transmits, to the first electronic device  102 A, an allocation bind success response in response to the allocation bind request, the allocation bind success response indicating that the first electronic device  102 A has joined the session ( 2408 ). 
       FIG. 25  illustrates a flow diagram of an example process  2500  of the multi-device communication management system in accordance with one or more implementations, continuing from  FIG. 24 . At  2410 , the server  110  continues from  2410  of  FIG. 24 . The server  110  receives, from the first electronic device  102 A, a join notification notifying that the first electronic device  102 A has joined the session ( 2502 ). The server  110  forwards the join notification to the one or more second electronic devices  102 B-C ( 2504 ). The server  110  receives, from at least one of the one or more second electronic devices  102 B-Cs, an information request requesting information on the first electronic device  102 A ( 2506 ). The server  110  transmits, to the at least one of the one or more second electronic devices  102 B-C, an information response including the information on the first electronic device  102 A in response to the information request ( 2508 ). 
       FIG. 26  illustrates a flow diagram of an example process  2600  of the multi-device communication management system in accordance with one or more implementations, continuing from  FIG. 24 . At  2410 , the server  110  continues from  2410  of  FIG. 24 . The server  110  receives a pre-key from at least one of the one or more second electronic devices  102 B-C ( 2602 ). The server  110  forwards the pre-key to the first electronic device  102 A ( 2604 ). The server  110  receives a master key from the at least one of the second electronic devices  102 B-C, the master key being based on the pre-key ( 2606 ). The server  110  forwards the master key to the first electronic device  102 A ( 2608 ). The server  110  manage communication between the first electronic device  102 A and the at least one of the one or more second electronic devices  102 B—C based on the master key, where the communication is encrypted with the master key ( 2610 ). 
       FIG. 27  illustrates a flow diagram of an example process  2700  of the multi-device communication management system in accordance with one or more implementations, continuing from  FIG. 24 . At  2410 , the server  110  continues from  2410  of  FIG. 24 . The server  110  receives, from the first electronic device  102 A, an allocation unbind request to leave the session ( 2702 ). The server  110  transmits, to the first electronic device  102 A, an allocation unbind response in response to the allocation unbind request to indicate that the first electronic device  102 A has left the session ( 2704 ). The server  110  transmits a leave notification to the one or more second electronic devices  102 B-C that have joined the session, the leave notification notifying that the electronic device  102 A has left the session ( 2706 ). 
       FIGS. 28-30  illustrate flow diagrams of example process of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, these processes are primarily described herein with reference to the electronic device  102 A-D and servers  110  of  FIGS. 1-16 . However, these processes are not limited to these devices, and one or more blocks (or operations) of these process may be performed by one or more other components of these electronic devices. The electronic devices also are presented as an exemplary device and the operations described herein may be performed by any suitable device. Further for explanatory purposes, the blocks of these processes are described herein as occurring in serial, or linearly. However, multiple blocks of the processes may occur in parallel. In addition, the blocks of the processes need not be performed in the order shown and/or one or more of the blocks of the processes need not be performed and/or can be replaced by other operations. 
       FIG. 28  illustrates a flow diagram of an example process  2800  of the multi-device communication management system in accordance with one or more implementations. In process  2800 , a first electronic device  102 A initiates a multiway call between a plurality of electronic devices  102  ( 2802 ). In some embodiments, the multiway call includes video captured by a camera included the first electronic device and communicated via a wireless interface of the first electronic device. In some embodiments, the first electronic device  102 A contacts an allocation server  414  configured to allocate at least one of a plurality of relay servers  412  for relaying encrypted traffic of the multiway call. In some embodiments, in response to the contacting, the first electronic device receives a token (e.g., access token-a in  FIG. 6 ) from the allocation server  414  and provides the token to the relay server to indicate that relaying the provided encrypted traffic has been authorized by the allocation server. In some embodiments, in response to the contacting, the first electronic device receives a session key (e.g., session key-A) from the allocation server and uses the session key to encrypt a communication (e.g., allocbind request at  712  in  FIG. 7 ) including the provided token to the relay server. 
     The first electronic device  102 A exchanges a first secret (e.g., master keys MKM-b in  FIG. 10  or MKM-c in  FIG. 13 ) with a first set of electronic devices participating during a first portion of the multiway call, the first secret being used to encrypt traffic between the first set of electronic devices ( 2804 ). In some embodiments, exchanging the first secret includes the first electronic device sending a public key of the first electronic device to a second one of the plurality of electronic devices and receiving, from the second electronic device, the first secret encrypted with the public key. 
     The first electronic device  102 A receiving an indication that first set of participating electronic devices has changed ( 2806 ). In some embodiments, the indication identifies a second electronic device as leaving the multiway call, and the second secret is not exchanged with the second electronic device to prevent the second electronic device from participating during the second portion of the multiway call. In such an embodiment, this may be an indication that electronic device  102 A is kicking device  102 C from the call, an indication from device  102 C that it is leaving the call, an indication from server  412  that device  102 C has disconnected from the call, etc. In some embodiments, the indication identifies a second electronic device as joining the multiway call (e.g., join pushes at  1216  and  1220  in  FIG. 12 ), and the second electronic device supplies the second secret. 
     In response to the indication, the first electronic device exchanges a second secret (e.g., master keys MKM-c in  FIG. 13  or MKM-a in  FIG. 14 ) with a second set of electronic devices participating during a second portion of the multiway call, the second secret being used to encrypt traffic between the second set of participating electronic devices ( 2808 ). 
       FIG. 29  illustrates a flow diagram of an example process  2900  of the multi-device communication management system in accordance with one or more implementations. In process  2900 , a communication system (e.g., implemented by servers  412 - 416 ) receives a request (e.g., allocate request at  612  in  FIG. 6 ) to facilitate a multiway call between a plurality of devices  102  ( 2902 ). In some embodiments, in response to the request, the communication system selects one or more of a plurality of relay servers  412  configured to relay traffic of the multiway call between the plurality of devices  102  and provides indications (e.g., allocate response pushes at  614 - 620 ) of the selected one or more relay servers to the plurality of devices. In some embodiments, the provided indications include tokens (e.g., access tokens at  614 - 620 ) for authenticating with the one or more relay servers to cause the one or more relay servers to relay traffic of the multiway call. In some embodiments, the provided indications include secrets (e.g., session keys at  614 - 620 ) used to encrypt traffic to the one or more relay servers. 
     The communication system provides first notification information (e.g., allocate response pushes at  616  and  618  in  FIG. 6 , join notification push at  915  in  FIG. 9 , info response at  918 , etc.) that identifies a first set of active devices participating in the multiway call ( 2904 ). The first notification information causes the first set of active devices to establish a first set of one or more cryptographic keys (e.g., keys based on master key MKM-c in  FIG. 13 ) used to communicate encrypted traffic of the multiway call. In some embodiments, the communication system stores public keys of the plurality of devices and distributes, among the plurality of devices, the public keys to encrypt secrets used to derive the first and second sets of cryptographic keys. 
     The communication system determines that the active devices in the multiway call have changed ( 2906 ). In some embodiments, the determining includes determining that a first of the plurality of devices is leaving the multiway call, and the second set of cryptographic keys is established such that the first device does not possess any of the second set of cryptographic keys. In some embodiments, the determining includes receiving a request from a second of the plurality of devices to kick the first device from the multiway call. In some embodiments, the determining includes determining that a first of the plurality of devices is joining the multiway call. 
     In response to the determining, the communication system provides a second notification information that identifies a second set of active devices participating in the multiway call, the second notification information causing the second set of active devices to discontinue use of the first set of cryptographic keys and establish a second set of one or more cryptographic keys (e.g., master key MKM-a in  FIG. 14 ) used to communicate encrypted traffic of the multiway call ( 2908 ). 
       FIG. 30  illustrates a flow diagram of an example process  3000  of the multi-device communication management system in accordance with one or more implementations. In process  3000 , a first electronic device  102 A joins a multiway call between a plurality of mobile devices ( 3002 ), the joining including exchanging a first secret (e.g., master key MKM-c in  FIG. 13 ) used to communicate encrypted traffic of the multiway call between the plurality of mobile devices. The first mobile device receives an indication associated with a second device  102 C of the plurality of mobile devices disconnecting from the multiway call ( 3004 ). As discussed above, this may be an indication that electronic device  102 A is kicking device  102 C from the call, an indication from device  102 C that it is leaving the call, an indication from server  412  that device  102 C has disconnected from the call, etc. In response to the indication, the first mobile device discontinues use of the first secret ( 3006 ) and establishes a second secret (e.g., master key MKM-a in  FIG. 14 ) with ones of the plurality of mobile devices to continue the multiway call without the second device being able to decrypt traffic of the continued multiway call ( 3008 ). In some embodiments, the first mobile device generates the second secret, encrypts the second secret using a public key of a third mobile device to exchange the second secret with the third mobile device, and based on the second secret, derives a cryptographic key used to encrypt traffic of the multiway call directed to the third mobile device. In some embodiments, the first mobile device exchanges the first and second secrets via a first server system (e.g., notification server  416 ) and relays encrypted traffic of the multiway call via a second server system (e.g., relay server  412 ) distinct from the first server system. In some embodiments, the first mobile device receives the indication via the first server system. 
       FIG. 31  illustrates a flow diagram of an example process  3100  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the process  3100  is primarily described herein with reference to the electronic device  102 A of  FIGS. 1-3 . However, the process  3100  is not limited to the electronic device  102 A, and one or more blocks (or operations) of the process  3100  may be performed by one or more other components of the electronic device  102 A. The electronic device  102 A also is presented as an exemplary device and the operations described herein may be performed by any suitable device, such as one or more of the other electronic devices  102 B-D, and/or the server  110 . Further for explanatory purposes, the blocks of the process  3100  are described herein as occurring in serial, or linearly. However, multiple blocks of the process  3100  may occur in parallel. In addition, the blocks of the process  3100  need not be performed in the order shown and/or one or more of the blocks of the process  3100  need not be performed and/or can be replaced by other operations. 
     The electronic device  102 A receives buffer level reports from the other electronic devices  102 B-C, respectively, that are participating in an audio and/or video group communication session ( 3102 ). In one or more implementations, the buffer level reports may indicate the current target buffer levels of each of the electronic devices  102 A-C. The electronic device  102 A determines a group target buffer level to equalize audio delays across the electronic devices  102 A-C based at least in part on the received buffer level reports and the current target buffer level of the electronic device  102 A ( 3106 ). 
     The electronic device  102 A transmits an indication of the group target buffer level to each of the other electronic devices  102 B-C ( 3108 ). The electronic device  102 A receives downlink communications from the other electronic devices  102 B-C ( 3110 ), and the electronic device  102 A applies the group target buffer level to the buffers, such as jitter buffers, corresponding to the downlink communications received from the other electronic devices  102 B-C ( 3112 ). In one or more implementations, the electronic device  102 A may perform the process  3100  repeatedly, or continuously, throughout the audio and/or video group communication session. 
       FIG. 32  illustrates a flow diagram of an example process  3200  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the process  3200  is primarily described herein with reference to the server  110  of  FIGS. 1-3 . However, the process  3200  is not limited to the server  110 , and one or more blocks (or operations) of the process  3200  may be performed by one or more other components of the server  110 . The server  110  also is presented as an exemplary device and the operations described herein may be performed by any suitable device, such as one or more of the electronic devices  102 A-D. Further for explanatory purposes, the blocks of the process  3200  are described herein as occurring in serial, or linearly. However, multiple blocks of the process  3200  may occur in parallel. In addition, the blocks of the process  3200  need not be performed in the order shown and/or one or more of the blocks of the process  3200  need not be performed and/or can be replaced by other operations. 
     In the process  3200 , the server  110  receives downlink condition reports from the electronic devices  102 A-C, respectively, each downlink condition report indicating a downlink channel bandwidth and/or a downlink channel condition corresponding to the respective electronic device ( 3202 ). In one or more implementations, the electronic devices  102 A-C may be participating in, or may be about to participate in, an audio and/or video group communication session. The server  110  may determine uplink conditions with respect to the electronic devices  102 A-C ( 3204 ). For example, the server  110  may request that the electronic devices  102 A-C transmit a measurement packet to the server  110  and/or otherwise participate in a protocol for determining uplink channel conditions. 
     The server  110  determines the appropriate quality tiers for the audio and/or video streams to be provided by each of the electronic devices  102 A-C ( 3206 ). The server  110  transmits indications of the determined quality tiers to each of the respective electronic devices  102 A-C ( 3208 ). In one or more implementations, the server  110  may transmit to one or more of the electronic devices  102 A-C, such as the electronic device  102 A, an indication of the quality tiers to be provided by the electronic device  102 A, as well as indications of the quality tiers to be provided by the other electronic devices  102 B-C. In this manner, the electronic device  102 A is made aware of the quality tiers that are available from the other electronic devices  102 B-C. 
     The server  110  receives the audio and/or video streams from the electronic devices  102 A-C at the indicated quality tiers ( 3210 ), and the server  110  relays one of the quality tiers of an audio and/or video stream from each of the electronic devices  102 A-C to each of the other electronic devices  102 A-C ( 3212 ). 
       FIG. 33-38  illustrate flow diagrams of example processes  3300 - 3800  of the multi-device communication management system in accordance with one or more implementations. For explanatory purposes, the processes  3300 - 3800  are primarily described herein with reference to the server  110  and the electronic devices  102 A-B of  FIG. 1 . However, the processes  3300 - 3800  are not limited to the server  110  and/or the electronic devices  102 A-B of  FIG. 1 , and one or more blocks (or operations) of the processes  3300 - 3800  may be performed by one or more other components of the server  110  and/or the electronic devices  102 A-B. The server  110  and the electronic devices  102 A-B also are presented as exemplary devices and the operations described herein may be performed by any suitable device, such as one or more of the other electronic devices  102 C-D. Further for explanatory purposes, the blocks of the processes  3300 - 3800  are described herein as occurring in serial, or linearly. However, multiple blocks of the processes  3300 - 3800  may occur in parallel. In addition, the blocks of the processes  3300 - 3800  need not be performed in the order shown and/or one or more of the blocks of the processes  3300 - 3800  need not be performed and/or can be replaced by other operations. 
     In process  3300 , two or more of the electronic devices  102 A-D, such as the electronic devices  102 A-B, may establish a group communication session utilizing a first communication modality, such as one or more of messaging, audio (e.g. phone call), and/or video (e.g., an audio/video conference) ( 3302 ). In one or more implementations, the server  110  may facilitate the electronic devices  102 A-B with establishing the group communication session, e.g., in the manner described above with respect to  FIGS. 6-14 , such as to establish a logical and/or physical infrastructure for the group communication session (establishing participant identifiers, security keys, and the like). The two or more electronic devices  102 A-B may engage in the group communication session utilizing the first communication modality as well as utilizing at least one of: the participant identifiers or the security keys. 
     One or more of the electronic devices  102 A-B, and/or the server  110 , may decide that the group communication session should utilize a second communication modality, such as one or more of messaging, audio, and/or video that is not being utilized as the first communication modality ( 3304 ). For example, a user interacting with one or more of the electronic devices  102 A-B may provide an indication, such as by a verbal command, interfacing with a user interface, etc., indicating that a messaging conversation should transition to an audio/video conference. In one or more implementations, one or more of the electronic devices  102 A-B and/or the server  110  may determine based on one or more factors (e.g., available bandwidth, number of participants, etc.) that the group communication session should utilize the second communication modality, and the electronic devices  102 A-B and/or the server may adaptively initiate the transition to utilizing the second communication modality, e.g., with or without confirmation from one or more of the users of the electronic devices  102 A-B. 
     The electronic devices  102 A-B, e.g., with or without facilitation from the server  110 , may transition the group communication session to utilize the second communication modality, such as to an audio/video conference ( 3306 ). The group communication session may utilize the second communication modality in lieu of, or in addition to, the first communication modality. In one or more implementations, the group communication session may be transitioned to utilizing the second communication modality without having to re-establish the infrastructure for the group communication session. Thus, the electronic devices  102 A-B may continue to use the participant identifiers, security keys, etc., established for the group communication session utilizing the first communication modality, e.g. messaging, while engaging in the group communication session utilizing the second communication modality, e.g., an audio/video conference. 
     In some embodiments, devices  102  distribute one or more keys to support using the second communication modality while the group communication session is still using the first communication modality. For example, devices  102  may distribute the pre-keys and/or master keys discussed above prior to any user requesting transitioning to the second communication modality in anticipation that a user may make such a request in the future. In embodiments in which the first communication modality uses messaging, devices  102  may include keys as payloads in the messages being exchanged between devices  102 . In some embodiments, one or more keys may be included an initial message being sent and included in subsequent messages periodically as the earlier communicated keys expire. For example, if a pre-key is valid for one hour, device  102 A may include its pre-key in an initial message to device  102 B and include an updated pre-key if the user of device  102 A happens to send another message from device  102 A to device  102 B after the one-hour threshold. Master keys may also be added to messages in a similar manner. In another embodiment, one or more keys may be appended for each message conveyed. In still another embodiment, if two devices  102  have transitioned to using the second communication modality while a third device participating in the group communication session has not yet transitioned, two devices  102  may exchange messages including keys with the third device  102  in anticipation that a user of the third device  102  wants the third device to transition to using the second communication modality. In other embodiments, other criteria may be used to determine when to append keys to messages. In many instances, exchanging keys in anticipation of the group communication session using the second communication modality allows the transition to occur more quickly once a determination to transition has been made. Still further, as will be discussed next, a given device  102  may send a single message with a key to a relay server that fans out the message to the other devices  102 —i.e., creates multiple instances of the message and sends the instances to the devices  102 . Such an exchange may reduce a device&#39;s data consumption and/or be less time consuming than a device  102  sequentially sending a respective message to each device  102 . 
       FIG. 34  illustrates a flow diagram of an example process  3400  for distributing keys in accordance with one or more implementations. As noted above, in some embodiments, devices  102  may include pre-keys and/or master keys used for a second communication modality prior to transitioning a group communication session to using the second communication modality. Accordingly, in the illustrated embodiment, process  3400  begins at  3412  with device  102 A sending a single message including its pre-key to a server  110  (specifically relay server  412  in some embodiments). In response to receiving the message, server  110  may send a first instance of the message to device  102 B at  3414  and a second instance of the message to device  102 C at  3416  so that devices  102 B and  102 C are in possession of devices  102 A&#39;s pre-key. In some embodiments, device  102 B or  102 C may use the pre-key to send a master key to device  102 A. In the illustrated embodiment, however, device  102 A sends a master key to devices  102 B and  102 C via the server  110 . In particular, devices  102 A sends a single message that includes a first instance of the master key encrypted with device  102 B&#39;s pre-key and a second instance of the master key encrypted with device  102 C&#39;s pre-key. In response to receiving this message, the server  110  may separate the two instances of the master key and send them in respective messages to devices  102 B and  102 C. In particular, as shown, server  110  may send a first message at  3422  including the first instance of the master key to device  102 B and a second message at  3424  including the second instance of the master key to device  102 C. Devices  102 B and  102 C may then decrypt the master key using their respective private keys and then, in some embodiments, apply a key derivation function to the master key to obtain the cryptographic keys to be used for the second communication modality once a transition occurs. Although described within the context of transitioning from the first communication modality to the second communication modality, keys may be distrusted in a similar manner as discussed with process  3400  after transition has occurred. Accordingly, process  1300  discussed above with respect to  FIG. 13  may fan out distribution of keys as discussed with process  3400 . 
       FIG. 35  illustrates a flow diagram of an example process  3500  of the multi-device communication management system in accordance with one or more implementations. In process  3500 , a first mobile device (e.g., device  102 A) establishes a group communication session using a first communication modality ( 3502 ). In some embodiments, the first communication modality is a messaging modality. 
     During the group communication session using a first communication modality, the first mobile device exchanges one or more keys to support using a second communication modality ( 3504 ). In some embodiments, the second communication modality is a video conference modality. In various embodiments, the exchanging includes the first mobile device adding a public key (e.g., a pre-key) to a message communicated via the first communication modality, the public key being usable by second and third mobile devices participating in the group communication session to send encrypted traffic to the first mobile device. In some embodiments, the first mobile device sends a single instance of the message (e.g., message with pre-key at  3412 ) to a server configured to relay a first instance of the message to the second mobile device and a second instance of the message to the third mobile device (e.g., messages at  3414  and  3416 ). In various embodiments, the exchanging includes the first mobile device sending a first instance of a key (e.g., a master key) to a second mobile device participating in the group communication session, the first instance of the key being encrypted with a public key of the second mobile device. The exchanging further includes the first mobile device sending a second instance of the key to a third mobile device participating in the group communication session, the second instance of the key being encrypted with a public key of the third mobile device. In some embodiments, the first mobile device sends, to a server, a single message (e.g., message with master key at  3420 ) including the first and second instances of the key, and the server is configured to send a first message (e.g., message at  3422 ) including the first instance of the master key to the second mobile device and a second message (e.g., message at  3424 ) including the second instance of the key to the third mobile device. 
     After the exchanging, the first mobile device decides to use the second communication modality for the group communication session ( 3506 ) and transitions the group communication session to using the second communication modality, wherein the transitioning includes using the one or more keys to encrypt traffic associated with using the second communication modality ( 3508 ). In various embodiments, the first mobile device determines to discontinue use of the one or more keys after a threshold time period and distributes one or more replacement keys prior to the determining to continue the group communication session. 
     In various embodiments, multiple master keys may be distributed to facilitate encryption of different portions of traffic being communicated between devices  102  during a multiway call. For example, in some embodiments, each device  102  may generate a respective master key, which is used to encrypt traffic sent from that device  102  and is distributed to other devices  102  to enable them to decrypt traffic received from that device  102 . As will be discussed below with respect to  FIGS. 36-38 , a device  102  may distribute its master key to other devices  102  along with the master keys received from other devices  102 . In doing so, devices  102  may more quickly disseminate master keys among devices  102  and reduce the number of communications to distribute master keys between devices  102 . In such an embodiment, master keys may still be distributed in a manner that ensures newly added devices  102  and/or recently departed devices  102  are not able to decrypt traffic when the device  102  is not a member of the call. 
       FIG. 36  illustrates a flow diagram of an example process  3600  for distributing multiple keys in accordance with one or more implementations. In various embodiments, process  3600  is performed to set up a multiway call between devices  102  and may be performed as additional devices  102  join the call. In some embodiments, process  3600  is also performed as pre-keys and/or master keys are updated/rolled as discussed above. 
     As shown, process  3600  may begin with an exchange of pre-keys ( 3610 ), which, as noted above, may be public keys used to encrypt subsequently exchanged master keys. In various embodiments, the exchange of pre-keys in process  3600  occurs as discussed above with respect to  FIG. 34  and other figures. In some embodiments, however, pre-keys may be exchanged in a similar manner as master keys discussed below. 
     After device  102 B has received the pre-key for device  102 A, device  102 B sends, via servers  110 , a message ( 3620 ) with its encrypted master key (shown as master key B or MKM-b in earlier FIGS.) in order enable device  102 A to decrypt subsequent traffic from device  102 B that has been encrypted with master key B. In some embodiments, the message also includes an active participant list identifying devices  102  known to device  102 B as actively participating in the multiway call. For example, this list may merely identify devices  102 A and  102 B as device  102 B may not yet be aware of device  102 C if it recently joined—and also not possess device  102 C&#39;s master key. 
     Responsive to receiving the message from device  102 B, device  102 A stores the received the master key B and the active member list in a local cache ( 3622 ) discussed in greater detail below with respect to  FIG. 37 . Device  102 A then sends an acknowledgment message ( 3624 ) to make device  102 B aware that it successfully received the message—and thus possess the master key B to begin decrypting encrypted traffic from device  102 B. 
     At some point, device  102 A may determine to send its master key (shown as master key A and MKM-a in other FIGS.) to device  102 C. Before doing so, device  102 A may examine the contents of its cache to determine what other master keys are in its possession. Device  102 A then sends, to device  102 C, a message including its master key A along with cached master key B and its cached active participant list ( 3630 ). (Although not shown, a similar message may also be conveyed to device  102 B). Device  102 C may then store the received keys and active participant list in its cache ( 3632 ) and respond with an acknowledgment message to device  102 A ( 3634 ). 
     In various embodiments, acknowledgement messages are used to control when a device  102  transitions to using a newly disseminated master key in order to prevent devices  102  from receiving traffic before they possess the master keys to decrypt that traffic. In particular, a device  102  sending its master key may wait until it receives an acknowledgment from every device  102  to which it sent its master key. In doing so, the device  102  can be confident in knowing when every device possesses its master key—or at least every participating device  102  that the sending device  102  is aware of at the time. Accordingly, if a particular device  102  sent a master key has not yet responded with an acknowledgement, the sending device  102  may initially delay transitioning to the newly sent key and continue to use an older key that is known to be possessed by each of the other devices  102  in the multiway call. In some embodiments, if a threshold amount of time has passed since sending the master key (e.g., 30 seconds) and an acknowledgement has not been received from the particular device  102 , the sending device  102  transitions to using the newly sent master key and causes the particular device  102  to be dropped from the call. The particular device  102 , however, can still rejoin the call. If the device  102  does rejoin, the sending device  102  may resend its key to the rejoining device  102  along with any other cached keys and the active participant list. In other embodiments, devices  102  may alternatively transition to using newly distributed keys after some threshold amount of time (e.g., five seconds after sending a master key), but this may result in some devices  102  receiving encrypted traffic before they possess decrypted copies of the appropriate master keys. 
     Although not shown, process  3600  may further continue with device  102 C sending, to devices  102 A and  102 C, messages including its master key C along with master keys A and B and its active participant list. Thus, device  102 B may be made aware of master key A, the joining of device  102 C, and master key C from a single message—as opposed to three distinct messages. 
       FIG. 37  illustrates a block diagram of an example cache  3700  for storing keys in accordance with one or more implementations. In the illustrated embodiment, cache  3700  includes one or more master keys  3710  and an active participant list  3720 , which may include one or more participant identifiers  3722 . In some embodiments, cache  3700  may also include an invited member list  3730  although list  3730  is depicted separately in the illustrated embodiment. In some embodiments, cache  3700  also includes received pre-keys. 
     Master keys  3710 , in various embodiments, are cached master keys received from other devices  102  participating in the multiple call. In such an embodiment, a key  3710  in cache  3700  may be accessed when a device  102  wants to decrypt newly received from traffic encrypted with that key  3170 . Keys  3710  may also be accessed to determine what keys  3710  to include when a device  102  is sending a message with its master key to another a device  102  as discussed above. In some embodiments, a device  102  may include its master key as one of keys  3710  in cache  3700 . 
     Active participant list  3720 , in various embodiments, is a list of each device  102  known to be participating in the multiway and, in some embodiments, corresponds to the device  102  having keys  3710  in cache  3700 . Accordingly, list  3720  may be updated when a device  102  joins or leaves a call. Continuing with the example above, device  102 B&#39;s list may include device  102 A and  102 B, but not include device  102 C even though device  102 C may be a newly joining participant if device  102 B has not yet to be notified of the joining. In contrast, device  102 A&#39;s list may include devices  102 B and  102 C. As shown, list  3720  may include a set of participant identifiers  3722 . In some embodiments, identifiers  3722  directly identify the devices  102  participating in the call. In other embodiments, identifiers  3722  indirectly identify devices  102  by identifying the users of the devices  102 —e.g., identifiers  3722  may include the phone numbers, email addresses, etc. of the users having devices  102  participating in the calls. In various embodiments, list  3720  may be accessed by a device  102  to determine what keys  3710  are included in cache  3700 . List  3720  may also be accessed to determine what devices  102  should receive keys when keys are to be periodically updated/rolled (e.g., every ten minutes). As noted above, a device  102 &#39;s active participant list  3720  may be included in a message when it sends its master key and cache keys  3710 . 
     In some embodiments, active participant list  3720  is also accessed by a device  102  to determine when cache  3700  should be updated. In particular, when a message with master keys and a list  3720  is received, a device  102  may compare it with the list  3720  in its cache  3700 . If the received list  3720  is a superset of the cached list  3720 , the device  102  may replace the cached keys  3710  and list  3720  with the received keys  3710  and list  3720 . If the received list  3720  is a subset of the cached list  3720 , no updates may be performed as the received list  3720  may be considered stale. If the received list  3720  and cached list  3720  are the same, cached keys  3710  may be updated with received keys (or no updates may occur). In some embodiments, if the received list  3720  and cached list  3720  differ and are not a subset or superset, no updates are performed; however, in other embodiments, missing participants in the cached list  3720  may be added to the cached list  3720  along with their keys  3710  to cache  3700 . 
     Invited member list  3730 , in various embodiments, is a listed of known invited members, which may not yet have joined the call or have left the call—thus, list  3730  may be a superset of list  3720 . Accordingly, if a person has been invited to join the call, the person (or the person&#39;s devices in some embodiments) may be added to the list  3730 . Similarly, if a person has been kicked or declines the invite, in some embodiments, the person (or the person&#39;s devices) may be removed from list  3730 . In some embodiments, list  3730  may include identifiers similar to identifiers  3722 . 
     In various embodiments, invited member list  3730  may be used to determine when the contents of cache  3700  should be flushed/cleared in order to prevent a device from receiving master keys for decrypting traffic communicated before a user has been invited to join the call and/or after a user has been kicked from (or declined the invitation to join) the call. Accordingly, if a member has been added to list  3730  by a user of the device including cache  3700  or by a user of another participating, device  102  may clear cache  3700  and distribute new keys. In various embodiments, device  102  also clears cache  3700  periodically as keys  3710  expire (e.g., every ten minutes) and redistributes new keys. Clearing cache  3700  in this manner may prevent a device  102  for inadvertently sending cached keys  3710  that are no longer valid and may enable to an unwanted device  102  to decrypt traffic. 
       FIG. 38  illustrates a flow diagram of an example process  3800  of the multi-device communication management system in accordance with one or more implementations. In process  3800 , a first electronic device (e.g., device  102 A) joins a multiway call between a plurality of members ( 3802 ). 
     The first electronic device generates a first secret (e.g., master key A  3710 ) usable to decrypt traffic communicated by the first electronic device during the multiway call ( 3804 ). In some embodiments, the first electronic device derives a first cryptographic key based on the first generated secret and sends traffic encrypted with the first cryptographic key. 
     The first electronic device receives, from a second electronic device (e.g., device  102 ), a second secret (e.g., master key B  3710 ) usable to decrypt traffic communicated by the second electronic device during the multiway call. In some embodiments, the first electronic device maintains a cache (e.g., cache  3700 ) that includes secrets received from ones of the plurality of electronic devices and examines the cache to determine what secrets to send to a third electronic device. In some embodiments, the first electronic device stores, in the cache, a list of members (e.g., active participant list  3720 ) participating in the multiway call. In some embodiments, the first electronic device receives an indication (e.g., an update to invited member list) that a member of a fourth electronic device has been invited to join the multiway call and, in response to the indication, clears the cache to prevent the fourth electronic device from receiving secrets stored in the cache. In some embodiments, the first electronic device stores the secrets in the cache for a predetermined amount of time (e.g., ten minutes) and clears the cache after the predetermined amount of time. 
     The first electronic device sends the first and second secrets to a third electronic device (e.g., device  102 C) to enable the third electronic device to decrypt traffic communicated by the first and second electronic devices during the multiway call. In some embodiments, the first electronic device sends, with the first and second secrets, the list of participating members stored in the cache to the third electronic device. In various embodiments, the first and second secrets are sent to the third electronic device in response to receiving an indication that the third electronic device has joined the multiway call. In various embodiments, the first and second secrets are sent to the third electronic device to replace secrets that are expiring after a predetermined amount of time. 
     In various embodiments, the first electronic device sends the first secret to a plurality of electronic devices associated with the multiway call and waits to use the first secret to encrypt traffic until each of the plurality of electronic devices has responded with an acknowledgment of the first secret being received. In some embodiments, the first electronic device determines that a third electronic device has not acknowledged the first secret being received and causes the third electronic device to be dropped from the multiway call. In some embodiments, the first electronic device receives an indication that the third electronic device has rejoined the multiway call and, in response to the indication, resends the first and second secrets to the third electronic device. 
       FIG. 39  illustrates an electronic system  3900  with which one or more implementations of the subject technology may be implemented. The electronic system  3900  can be, and/or can be a part of, one or more of the electronic devices  102 A-D and/or the server  110  shown in  FIG. 1 . The electronic system  3900  may include various types of computer readable media and interfaces for various other types of computer readable media. The electronic system  3900  includes a bus  3908 , one or more processing unit(s)  3912 , a system memory  3904  (and/or buffer), a ROM  3910 , a permanent storage device  3902 , an input device interface  3914 , an output device interface  3906 , and one or more network interfaces  3916 , or subsets and variations thereof. 
     The bus  3908  collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system  3900 . In one or more implementations, the bus  3908  communicatively connects the one or more processing unit(s)  3912  with the ROM  3910 , the system memory  3904 , and the permanent storage device  3902 . From these various memory units, the one or more processing unit(s)  3912  retrieves instructions to execute and data to process in order to execute the processes of the subject disclosure. The one or more processing unit(s)  3912  can be a single processor or a multi-core processor in different implementations. 
     The ROM  3910  stores static data and instructions that are needed by the one or more processing unit(s)  3912  and other modules of the electronic system  3900 . The permanent storage device  3902 , on the other hand, may be a read-and-write memory device. The permanent storage device  3902  may be a non-volatile memory unit that stores instructions and data even when the electronic system  3900  is off. In one or more implementations, a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) may be used as the permanent storage device  3902 . 
     In one or more implementations, a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) may be used as the permanent storage device  3902 . Like the permanent storage device  3902 , the system memory  3904  may be a read-and-write memory device. However, unlike the permanent storage device  3902 , the system memory  3904  may be a volatile read-and-write memory, such as random access memory. The system memory  3904  may store any of the instructions and data that one or more processing unit(s)  3912  may need at runtime. In one or more implementations, the processes of the subject disclosure are stored in the system memory  3904 , the permanent storage device  3902 , and/or the ROM  3910 . From these various memory units, the one or more processing unit(s)  3912  retrieves instructions to execute and data to process in order to execute the processes of one or more implementations. 
     The bus  3908  also connects to the input and output device interfaces  3914  and  3906 . The input device interface  3914  enables a user to communicate information and select commands to the electronic system  3900 . Input devices that may be used with the input device interface  3914  may include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output device interface  3906  may enable, for example, the display of images generated by electronic system  3900 . Output devices that may be used with the output device interface  3906  may include, for example, printers and display devices, such as a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a flexible display, a flat panel display, a solid state display, a projector, or any other device for outputting information. One or more implementations may include devices that function as both input and output devices, such as a touchscreen. In these implementations, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. 
     Finally, as shown in  FIG. 39 , the bus  3908  also couples the electronic system  3900  to one or more networks and/or to one or more network nodes, such as a cellular base station or a wireless access point. In this manner, the electronic system  3900  can be a part of a network of computers (such as a LAN, a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet. Any or all components of the electronic system  3900  can be used in conjunction with the subject disclosure. 
     Implementations within the scope of the present disclosure can be partially or entirely realized using a tangible computer-readable storage medium (or multiple tangible computer-readable storage media of one or more types) encoding one or more instructions. The tangible computer-readable storage medium also can be non-transitory in nature. 
     The computer-readable storage medium can be any storage medium that can be read, written, or otherwise accessed by a general purpose or special purpose computing device, including any processing electronics and/or processing circuitry capable of executing instructions. For example, without limitation, the computer-readable medium can include any volatile semiconductor memory, such as RAM, DRAM, SRAM, T-RAM, Z-RAM, and TTRAM. The computer-readable medium also can include any non-volatile semiconductor memory, such as ROM, PROM, EPROM, EEPROM, NVRAM, flash, nvSRAM, FeRAM, FeTRAM, MRAM, PRAM, CBRAM, SONOS, RRAM, NRAM, racetrack memory, FJG, and Millipede memory. 
     Further, the computer-readable storage medium can include any non-semiconductor memory, such as optical disk storage, magnetic disk storage, magnetic tape, other magnetic storage devices, or any other medium capable of storing one or more instructions. In one or more implementations, the tangible computer-readable storage medium can be directly coupled to a computing device, while in other implementations, the tangible computer-readable storage medium can be indirectly coupled to a computing device, e.g., via one or more wired connections, one or more wireless connections, or any combination thereof. 
     Instructions can be directly executable or can be used to develop executable instructions. For example, instructions can be realized as executable or non-executable machine code or as instructions in a high-level language that can be compiled to produce executable or non-executable machine code. Further, instructions also can be realized as or can include data. Computer-executable instructions also can be organized in any format, including routines, subroutines, programs, data structures, objects, modules, applications, applets, functions, etc. As recognized by those of skill in the art, details including, but not limited to, the number, structure, sequence, and organization of instructions can vary significantly without varying the underlying logic, function, processing, and output. 
     While the above discussion primarily refers to microprocessor or multi-core processors that execute software, one or more implementations are performed by one or more integrated circuits, such as ASICs or FPGAs. In one or more implementations, such integrated circuits execute instructions that are stored on the circuit itself. 
     Those of skill in the art would appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application. Various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology. 
     It is understood that any specific order or hierarchy of blocks in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes may be rearranged, or that all illustrated blocks be performed. Any of the blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. 
     As used in this specification and any claims of this application, the terms “base station”, “receiver”, “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms “display” or “displaying” means displaying on an electronic device. 
     As used herein, the phrase “at least one of” preceding a series of items, with the term “and” or “or” to separate any of the items, modifies the list as a whole, rather than each member of the list (i.e., each item). The phrase “at least one of” does not require selection of at least one of each item listed; rather, the phrase allows a meaning that includes at least one of any one of the items, and/or at least one of any combination of the items, and/or at least one of each of the items. By way of example, the phrases “at least one of A, B, and C” or “at least one of A, B, or C” each refer to only A, only B, or only C; any combination of A, B, and C; and/or at least one of each of A, B, and C. 
     The predicate words “configured to”, “operable to”, and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be used interchangeably. In one or more implementations, a processor configured to monitor and control an operation or a component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation. Likewise, a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code. 
     Phrases such as an aspect, the aspect, another aspect, some aspects, one or more aspects, an implementation, the implementation, another implementation, some implementations, one or more implementations, an embodiment, the embodiment, another embodiment, some embodiments, one or more embodiments, a configuration, the configuration, another configuration, some configurations, one or more configurations, the subject technology, the disclosure, the present disclosure, other variations thereof and alike are for convenience and do not imply that a disclosure relating to such phrase(s) is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. A disclosure relating to such phrase(s) may apply to all configurations, or one or more configurations. A disclosure relating to such phrase(s) may provide one or more examples. A phrase such as an aspect or some aspects may refer to one or more aspects and vice versa, and this applies similarly to other foregoing phrases. 
     The word “exemplary” is used herein to mean “serving as an example, instance, or illustration”. Any embodiment described herein as “exemplary” or as an “example” is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, to the extent that the term “include”, “have”, or the like is used in the description or the claims, such term is intended to be inclusive in a manner similar to the term “comprise” as “comprise” is interpreted when employed as a transitional word in a claim. 
     All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. § 112, sixth paragraph, unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for”. 
     The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more”. Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the subject disclosure. 
     As described above, one aspect of the present technology is the gathering and use of data available from specific and legitimate sources to improve providing multiway calling to a user. 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&#39;s health or level of fitness (e.g., vital signs measurements, medication information, exercise information), date of birth, or any other personal information. 
     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 suggest a participant for a multiway call 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 multiway calling. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. For instance, health and fitness data may be used, in accordance with the user&#39;s preferences to provide insights into their general wellness, or may be used as positive feedback to individuals using technology to pursue wellness goals. 
     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 prominently 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 which 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. 
     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, in the case of multiway calling, 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 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. 
     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&#39;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. 
     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, suggested participants for a multiway call 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&#39;s device or other non-personal information available to the multiway calling system.

Metadata:
Filing Date: 20180928
Publication Date: 20210921
Grant Date: 20210921
Priority Date: 20170929
Inventors: YANG, YAN
PARK, JIN HYUNG
ABUAN, JOE S.
TUNG, BERKAT S.
DEVLIN, Sean P.
CHIEM, VU H.
LOZANO HINOJOSA, Jose A.
DEVANNEAUX, THOMAS P.
GOUPENKO, VLADIMIR
SHIANG, HSIEN-PO
POLLACK, DANIEL B.
XUE, Mark M.
STEELE, DAVID J.
XING, YU
BAKER, RYAN W.
GARRIDO, CHRISTOPHER M.
JIN, MING
Assignee: APPLE INC
CPC Classifications: [{"code": "H04L12/1822", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L65/403", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2463/062", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L63/0428", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/0435", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/0807", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/1069", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/0428", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2463/062", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L12/1818", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L12/1822", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/403", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/065", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L12/1818", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/065", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L12/1818", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L12/1822", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/403", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/1069", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/0435", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/065", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L63/0428", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2463/062", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L63/0807", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 65898054