Source: https://patents.google.com/patent/US20150350362A1/en
Timestamp: 2019-07-16 21:40:14
Document Index: 707871910

Matched Legal Cases: ['Application No. 62', 'Application No. 62', 'Application No. 62', 'Application No. 62', 'Application No. 62', 'Application No. 62', 'Application No. 62', 'Application No. 62']

US20150350362A1 - Proxied push - Google Patents
Proxied push Download PDF
US20150350362A1
US20150350362A1 US14/475,060 US201414475060A US2015350362A1 US 20150350362 A1 US20150350362 A1 US 20150350362A1 US 201414475060 A US201414475060 A US 201414475060A US 2015350362 A1 US2015350362 A1 US 2015350362A1
US14/475,060
US9654581B2 (en
Gokul P. Thirumalai
2014-09-02 Priority to US14/475,060 priority patent/US9654581B2/en
2014-09-03 Assigned to APPLE INC. reassignment APPLE INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: THIRUMALAI, GOKUL P., POLLACK, DANIEL B.
2015-12-03 Publication of US20150350362A1 publication Critical patent/US20150350362A1/en
2016-10-13 Priority claimed from US15/293,076 external-priority patent/US20170034676A1/en
2017-05-16 Publication of US9654581B2 publication Critical patent/US9654581B2/en
A system and method are described for establishing two-way push communication between an intermediate or companion device and a mobile device. Mobile devices register to listen for push notifications delivered through a push notification service from a specified set of providers. The presence of the mobile devices is delivered to the push notification service that maps the mobile devices to connections made between their respective companion devices and the push notification service. If the push notification service determines that a mobile device is “online,” in response to receiving a push notification for the mobile device, a current network connection over which a companion device is listening for push notifications is identified and the push notification is forwarded to the companion device. The companion device then can deliver the push notification to the mobile device.
This application claims the benefit of and priority to U.S. Provisional Application No. 62/005,325, filed May 30, 2014 and entitled “PROXIED PUSH,” the entire disclosure of which is hereby incorporated by reference for all purposes.
This application is related to the following U.S. patent applications: U.S. Provisional Application No. ______ filed May 30, 2014 and entitled “ANSWER AND HOLD WITH CLIENT AND HOST” by Rauenbuehler et al. (Ref. No. P23172USP1); U.S. Provisional Application No. ______ filed May 30, 2014 and entitled “ANSWERING A CALL WITH CLIENT THROUGH A HOST” by Rauenbuehler et al. (Attorney Ref. No. P23171USP1); U.S. Provisional Application No. 62/005,606 filed May 30, 2014 and entitled “CLIENT APPLICATIONS COMMUNICATING VIA A USER TUNNEL” by Tung et al. (Ref. No. P23188USP1); U.S. Provisional Application No. 62/005,336, filed May 30, 2014 and entitled “SMS PROXYING” by Circosta et al. (Ref. No. P23192USP1); U.S. Provisional Application No. 62/005,505 filed May 30, 2014 and entitled “MANAGING CONNECTIONS OF A USER DEVICE” by Schobel et al. (Ref. No. P23295USP1); U.S. Provisional Application No. 62/005,565 filed May 30, 2014 and entitled “APPLICATION-LEVEL ACKNOWLEDGEMENTS” by Pollack et al. (Ref. No P23189USP1); U.S. Provisional Application No. 62/005,586 filed May 30, 2014 and entitled “MESSAGES WITH ATTENUATING RETRANSMIT IMPORTANCE” by Pollack et al. (Ref. No. P23190USP1); U.S. Provisional Application No. filed May 30, 2014 and entitled “UNIFIED MESSAGE DELIVERY BETWEEN PORTABLE ELECTRONIC DEVICES” by Pollack et al. (Ref: P22929USP1); U.S. Provisional Application No. 62/005,990 filed May 30, 2014 and entitled “USER INTERFACE FOR PHONE CALL ROUTING AMONG DEVICES” by Coffman et al. (Ref. No. P23298USP1); and U.S. Provisional Application No. 62/505,799 filed May 30, 2014 and entitled “PROTOCOL SWITCHING IN INTER-DEVICE COMMUNICATION” by Prats et al. (Ref. No. P22319USP1), which are commonly owned and are hereby incorporated by reference for all purposes. The present application is also related to U.S. Provisional Application 61/953,591, entitled “DYNAMIC LINK ADAPTATION FOR IMPROVED LINK MARGIN,” by Liu et al., filed Mar. 14, 2014, which is hereby incorporated by reference for all purposes.
The present disclosure relates generally to communications between electronic devices and in particular to two-way delivery of content using proxy and proxied devices.
Mobile electronic devices, such as laptops, palmtops, mobile phones, smart phones, multimedia phones, portable media players, GPS units, mobile gaming systems, etc., have become quite popular. Many users carry a device almost everywhere they go and use their device for a variety of purposes, including making and receiving phone calls, sending and receiving text messages and emails, navigation (e.g., using maps and/or a GPS receiver), purchasing items in stores (e.g., using contactless payment systems), and/or accessing the Internet (e.g., to look up information). A user's mobile device can be carried or worn and perform a variety of smart functions in addition to traditional functions formerly implemented by a single application-specific device.
Mobile devices can have applications that access a variety of content, such as email and websites, streaming audio/video, social media, and the like. Some applications can periodically receive notifications from services that new content is available. Such applications can include “push” e-mail services (e.g., MobileMe, Microsoft Exchange, ActiveSync, Push-IMAP, Yahoo! Push, etc.), or other push services (e.g., update/upgrade services, news services, web blog services, podcast services, social networking services, or other types of services where notification messages may be sent). Notification messages typically represent events of interest, which are typically defined by the applications (e.g., new e-mail indicator, new news item indicator, new podcast indicator, change of on-line status of a social networking friend, etc.).
The increase in the use of mobile devices magnifies the complexity of routing notification messages to these devices. One problem is that many users more frequently carry around multiple mobile devices almost everywhere they go increasing the complexity of routing content to the right devices. Another problem is that users use their devices for a variety of overlapping and non-overlapping purposes making it more difficult to determine which of a users' two mobile devices having the same application installed is the intended destination of content. Furthermore, given that some mobile devices are not inherently addressable, it is difficult to route messages to these mobile devices, particularly on a large scale when multiple devices per user are in use, when it is not known how to contact the devices.
Accordingly, what is desired is to solve problems relating to coordinating and handling the delivery of content to and from user devices, some of which may be discussed herein. Additionally, what is desired is to reduce drawbacks relating to power management and efficiency when delivering content to and from user devices while also extending the functionality and accessibility of these devices, some of which may be discussed herein.
A system and method are described for establishing two-way communication between a content delivery service and mobile devices. As it can be power inefficient for mobile devices (acting as proxied devices) to maintain a persistent connection with the service in order to receive push content from a specified set of providers, the “online” presence of each of the mobile devices can be asserted to the service using companion devices (acting as proxy devices). In various embodiments, mobile devices initially register to have push content delivered through the service. The service can map registered mobile devices to connections made between their respective companion devices and the service upon receiving assertions of presence from the mobile devices (e.g., provided through the companion devices). In response to receiving push content for a registered mobile device, the service determines whether the mobile device is “online” using its mappings. If so, a current network connection is identified over which its corresponding companion device is listening for its own push content. The service can forwarded the push content to the companion device over the companion device's connection instructing the companion device to deliver the push content to the mobile device.
Certain embodiments of the invention relate to communicating between a wearable device (as a proxied device) and a host device (as a proxy device). For example, a wearable device can establish a wireless communications link with the host device (e.g., via a pairing process or the like). The wearable device can determine the most power efficient manner of communicating with the host device. The wearable device can chose one type of wireless communication over another if one consumes more power at the mobile device than the other. Accordingly, an intermittent and non-persistent link can be chosen in order to maximize power consumption, reduce interface, or satisfy other predetermined criteria while also allowing two-way communication.
In some embodiments, to receive push content from a content delivery service, the wearable device can assert its “online” presence to the service over a predetermined wireless communication link with the host device. The host device participates in interactions between the wearable device and the service to ensure successful delivery of the push content to and from the mobile device. The wearable device can receive push content from the service as the host device acts on its behalf sending and receiving messages with the service using its own persistent connection to the service. The wearable device can forward push content to the service as the host device acts on its behalf sending and receiving messages with the service using its own persistent connection to the service.
In some embodiments, a companion device to a mobile device can detect that an established wireless communication link with the companion device is unsuitable for communication. The companion device can determine that the link is of too poor a quality for communication or that link has been severed or otherwise terminated, either intentionally by the mobile device or due to the lack of interacting with the mobile device across the link for a predetermined period of time. When certain conditions are met, the companion device can assert an “offline” presence to a content delivery service over its own link to the service that instructs the service to mark the mobile device as being “offline.” In various embodiments, the service can disassociate the mobile device from the persistent connection of the companion device queuing push content for later delivery.
In some embodiments, a mobile device can connect directly to a content delivery service and retrieve any queued push content. In one embodiment, an assertion of “online” presence by the mobile device directly to the service can cause the service to update its mappings of its own accord. The service can disassociate the mobile device from its mappings to the connections of any companion devices.
FIG. 3 is a flowchart of a method for performing proxied push notification according to one embodiment.
FIG. 4 is a block diagram illustrating how a push notification service manages proxy/proxied presences according to one embodiment.
FIG. 5 is a flowchart of a method performed by a companion device acting as a proxy device for delivering push content received from a push notification service to a mobile device acting as a proxied device according to one embodiment.
FIG. 6 is a message sequence chart that illustrates establishment of proxy and proxied presence for a push notification service according to various embodiments.
FIG. 7 is a message sequence chart that illustrates sending push content from a push notification service to a proxy device for delivery to a proxied device according to various embodiments.
FIG. 8 is a flowchart of a method performed by a companion device acting as a proxy device for handing proxied push content according to one embodiment.
FIG. 9 is a flowchart of a method performed by a mobile device acting as a proxied device for receiving proxied push content according to one embodiment.
FIG. 10 is a message sequence chart illustrating sending push content from a mobile device acting as a proxied device to a push notification service by a companion device acting as a proxy device according to one embodiment.
FIG. 11 shows a protocol stack for communicating data according to embodiments of the present invention
FIG. 12 is a block diagram of a portable electronic device or mobile device according to an embodiment.
Systems and methods are described for establishing two-way communication between a content delivery service and mobile devices. As it can be power inefficient for mobile devices (acting as proxied devices) to maintain a persistent connection with the service in order to receive push content from a specified set of providers, the “online” presence of each of the mobile devices can be asserted to the service using companion devices (acting as proxy devices). In various embodiments, mobile devices initially register to have push content delivered through the service. The service can map registered mobile devices to connections made between their respective companion devices and the service upon receiving assertions of presence from the mobile devices (e.g., provided through the companion devices). In response to receiving push content for a registered mobile device, the service determines whether the mobile device is “online” using its mappings. If so, a current network connection is identified over which its corresponding companion device is listening for its own push content. The service can forwarded the push content to the companion device over the companion device's connection instructing the companion device to deliver the push content to the mobile device.
FIG. 1 is a block diagram of a device management and content delivery ecosystem 100 according to various embodiments. FIG. 1 and other figures are merely illustrative of an embodiment or implementation of an invention disclosed herein should not limit the scope of any invention as recited in the claims. One of ordinary skill in the art may recognize through this disclosure and the teachings presented herein other variations, modifications, and/or alternatives to those embodiments or implementations illustrated in the figures. The devices in system 100 can include hardware and/or software elements.
FIG. 2 is a block diagram of content delivery system 200 in device management and content delivery ecosystem 100 of FIG. 1 200 that provides push notification services according to various embodiments. System 200 may be implemented in various embodiments using a single server computer system or may include multiple server computer systems, web servers, application servers, networks, interconnects, and the like. System 200 can be embodied as content infrastructure of FIG. 1 in various embodiments.
II. Proxied Push Notifications
In various embodiments, content sent through a push notification service (e.g., PNS 220) that is destined for a mobile device can be forwarded to another device that acts as a companion to the mobile device using connection information previously established by the companion device with the service. The companion device acts as a proxy device to send and receive signals on behalf of other proxied devices. Additionally, the service maintains relationships between proxy devices, proxied devices, and how to connect the proxied devices through the proxy devices. Accordingly, companion devices act as main or intermediary devices for the service to route push content to and from proxied devices.
FIG. 3 is a flowchart of method 300 for performing proxied push notification according to one embodiment. Processing in method 300 depicted in FIG. 3 may be performed by software (e.g., instructions or code modules) when executed by a central processing unit (CPU or processor) of a logic machine, such as a computer system or information processing device, by hardware components of an electronic device or application-specific integrated circuits, or by combinations of software and hardware elements.
In step 310, presence information for a companion device is received at a push notification service via a first connection of the companion device. The presence information can include a UID, certificate, token, or other information associated with or about the companion device. The first connection can be a persistent connection to the service using wireless or wired means. The service (e.g., PNS 220) to which a companion device (e.g., companion device 120) connects can establish the identity of the companion device through TLS peer-to-peer authentication in order for the companion device to assert an “online” presence. In the course of this procedure, the companion device can initiate a TLS connection with a server or other endpoint associated with the service. The service can return its own server certificate that can be used by the companion device to validate the service (or at least the server or endpoint).
The companion device can also sends its own device certificate to the service. The device certificate may be one issued when the companion device registered to use the service, i.e., one returned by identity management server 215 during an initial registration of companion device 120 in order to become a managed entity. The service can validate the device certificate and if the validation is successful, allow the companion device to establish a persistent connection with the server or other endpoint.
In step 320, a mapping is created at the service between the companion device and the first connection. The mapping can include a correspondence between a UID, token, or other identifier of the companion device and connection information describing the first connection or how the companion device is reachable through the service using the first connection. This mapping, link, or correspondence can be embodied as connection information 245 of device interface 240 and back propagated to gateway 230 to form presence information 235 as discussed above.
In step 330, presence information for a mobile device is received at the companion device via a second connection of the companion device. As will be discussed in further detail below, the companion device can forward this presence information of the mobile device to the server or other endpoint of the service to which the companion device maintains a persistent connection. The service can validate the device certificate of the mobile device. If the validation is successful, in step 340, a mapping is created between the companion device, the mobile device, and the first connection. The mapping can include an association between a UID, token, or other identifier of the mobile device and connection information describing the first connection or how the companion device is reachable through the service using the first connection. In some embodiments, an association can be made to an existing mapping or correspondence established previously when the companion device established its own persistent connection to the service.
In various embodiments, the companion device can proxy push notifications for the mobile device using its own a persistent connection to the service as the mobile device may not maintain any connection with the service as well as only an intermitted or non-persistent connection with the companion device. The companion device can proxy push notifications for the mobile device both for the purposes of sending and receiving push content as well as for other purposes. Accordingly, the mobile device may be each embodied as a wearable device, such as a smart watch or an optical head-mounted display (OHMD). A user of both the mobile device and the companion device can pair the two devices in order to establish proxy communication. Although in some embodiments the mobile device can be configured to directly connect to the service, most of the time in these examples, the mobile device optimizes power consumption by connecting intermittently to the companion device (i.e., using a low-power connection Bluetooth connection). Thereby, one mobile device can more effectively manage power consumption while utilizing a persistent connection of another device that likely has a larger battery or constant power source.
Referring again to FIG. 3, in step 350, a push notification for the mobile device is received at the service from a provider. The push notification can identify the mobile device using a UID, device token, or other identifier. In step 360, a mapping between the companion device, the mobile device, and the first connection is identified at the service. In one embodiment, the service can utilize a lookup table that maps a device token for the mobile device to connection information that is also mapped to or otherwise associated with the a device token of the companion device.
In step 370, the push notification is sent to the companion device using the first connection. Therefore, a companion device can proxy push notifications for a mobile device using its own a persistent connection to the service both for the purposes of sending and receiving push content as well as for other purposes. In several aspects, thus, one mobile device can utilizing a persistent connection of another device that acts on its behalf to send and receive push content.
FIG. 4 is a block diagram illustrating how content infrastructure 110 manages proxy/proxied presences according to one embodiment. In this example, companion device 120 includes processor 402 having connection module 404, memory 406 in which device token T1 is stored, one or more applications 408, transmitter 410, and receiver 412. Processor 140 includes connection module 404 for managing connections, such as to device interface 240 and to mobile device 115. Memory 406 stores device token T1. Upon initial connection with device interface 240 at the request of one or more applications 408 in order to receive push content, connection module 404 can transmit using transmitter 410 registration information and receive device token T1 from PNS 220 using receiver 412. Once device token T1 has been generated, transmitter 410 transmits, or sends, device token T1 to various provider applications either through device interface 240 or directly to the provider applications using, for example, the Internet. As discussed above, the provider applications can use device token T1, or include the token, with any notification message so that it can be appropriately forwarded back to companion device 120.
Connection module 404 further can manage the sending and receiving on behalf of mobile device 115. For example, connection module 404 can manage the forwarding of presence information associated with mobile device 115 using transmitter 410 to device interface 240. Connection module 404 can manage the delivery to mobile device 115 of a message received from device interface 240 using receiver 412 that includes device token T2 associated with mobile device 115. Connection module 404 can manage the delivery to device interface 240 of a message received from mobile device 115 using receiver 412 that includes a device token associated with another device.
Mobile device 115 includes processor 414 having connection module 416, memory 418 in which device token T2 is stored, one or more applications 420, transmitter 422, and receiver 424. Processor 414 includes connection module 416 for managing connections, such as to device interface 240 and to companion device 120. Memory 418 stores device token T2. Upon initial connection with device interface 240 at the request of one or more applications 420 in order to receive push content, connection module 416 can transmit using transmitter 422 registration information and receive device token T2 from PNS 220 using receiver 424. Once device token T2 has been generated, transmitter 422 transmits, or sends, device token T2 to various provider applications.
Connection module 416 further can manage the sending and receiving to companion device 120 to establish proxied presence. For example, connection module 416 can manage the forwarding of presence information associated with mobile device 115 using transmitter 422 to companion device 120. Connection module 416 can manage the delivery to applications 420 of a message received using receiver 424 that includes device token T2 associated with mobile device 115. Connection module 416 can also manage the forwarding to companion device 120 of a message using transmitter 422 that includes a device token associated with another device in order to have companion device 120 forward the message to device interface 240.
In this example, a message (e.g., a push or notification message) identified by token T2 associated with mobile device 115 is received from a provider via provider interface 225. Gateway 230 receives the message from provider interface 230. In various embodiments, having received the message from an authenticated provider via provider interface 225, gateway 230 determines the destination for the message using device token T2. Using presence information 235, gateway 230 determines whether any devices associated with device token T2 are “online.” Gateway 230 can extract the device token T2 or otherwise obtain device token T2 and consult its mappings in presence information 235 to see whether device token T2 is mapped to connection information.
In these embodiments, FIG. 4 illustrates that presence information 235 includes a set of device identifiers and a set of connection descriptions. Each device identifier in the set is mapped or otherwise has a corresponding connection description. Specifically, a device identifier as represented by device token T1 as well a device identifier as represented by device token T2 are mapped, correlated, or otherwise in correspondence with a connection description as represented by PI-CD1. A device identifier as represented by token T3 is mapped with a connection description as represented by PI-CD2. Device identifiers as represented by tokens T4, T5, and T6 are mapped with a connection description as represented by PI-CD3. A device identifier as represented by token T7 is mapped with a connection description as represented by PI-CD4. A device identifier as represented by token T8 is mapped with a connection description as represented by PI-CD5.
Device interface 240 also maintains its own connection information 245 for each device to which it is connected. In these embodiments, FIG. 4 illustrates that connection information 245 includes a set of device identifiers and a set of connection descriptions. Each device identifier in the set is mapped or otherwise has a corresponding connection description. Specifically, a device identifier as represented by token T1 and a device identifier as represented by token T2 are mapped, correlated, or otherwise in correspondence with a connection description as represented by CI-CD1. A device identifier as represented by token T3 is mapped with a connection description as represented by CI-CD2. As discussed above, device interface 240 can back-propagate connection information 245 to gateway 230 allowing gateway 230 to generate or update presence information 235.
In various embodiments, gateway 230 forwards the message identified by token T2 associated with mobile device 115 to device interface 240 based on its mapping in presence information 235. Device interface 240 then forwards the message to companion device 120 based on its mapping in connection information 240—a network connection as described by connection description CI-CD1. Here, companion device 120 is a proxy device that can act and send signals on behalf of mobile device 115 (a proxied device). Upon receive the message, companion device 120 determines that the message it received from device interface 240 includes device token T2 (or is otherwise addressed to mobile device 115) and forwards the message to mobile device 115 using its connection to mobile device 115.
FIG. 5 is a flowchart of method 500 for proxying push notification according to one embodiment. Processing in method 500 depicted in FIG. 5 may be performed by software (e.g., instructions or code modules) when executed by a central processing unit (CPU or processor) of a logic machine, such as a computer system or information processing device, by hardware components of an electronic device or application-specific integrated circuits, or by combinations of software and hardware elements.
In step 510, a presence command is generated for a companion device (e.g., companion device 120) acting as a proxy device. The presence command can include a device token issued when an application of the companion device registered to receive push content through a push notification service and a device certificate issued when the companion device registered with an identity management service that manages the push notification service. The device certificate can be used to validate the device token. Other information can be included with the presence command. In step 520, the presence command is sent to the push notification service via a first connection associated with the companion device to create a mapping between a companion device identifier of the companion device and the first connection. The first connection can be a persistent connection maintained between the companion device and the push notification service, such as via the Internet, cellular connection, etc.
In step 530, a presence command is generated for a mobile device (e.g. mobile device 115). As above, the presence command can include a device token for the mobile device and a device certificate for the mobile device that can be used to validate the device token. The presence command can be generated by the mobile device and sent to the companion device via a second connection. The second connection may be an intermitted or non-persistent connection between the mobile device and the companion device. The information received via the second connection can be a simple connect or another presence command. The presence command can also be generated by the companion device (i.e., directly or based on information received from the mobile device). In step 540, the presence command is sent to the push notification service via the first connection to create a mapping between the companion device identifier, a mobile device identifier, and the first connection.
In contrast to traditional proxy techniques were entities behind a proxy are shielded from entities in front of the proxy, embodiments facilitate the mapping of proxied devices behind proxy devices to appropriate connections in order to deliver push content. In various embodiments, the mapping provides a link between the device token for the mobile device and a connection means to deliver push content having the device token for the mobile device to the mobile device via the first connection of the companion device. In one embodiment, the mapping includes a lookup table providing a correspondence between a set of device tokens associated with proxy and proxied devices and a description of how to reach proxy devices in the set that are known to be in communication with one or more of the proxied devices. In some embodiments, a connection tree can be formed that indicates how to connect to breaches or series of intermediate devices in order to reach a proxied device.
In step 550, a push notification for the mobile device is received from the push notification service via the first connection. The push notification can be in the form of a message command. The message command can identify the type of message, the destination of the message (i.e., a device or app token), and/or a payload. In step 560, the destination of the push notification is determined to be the mobile device. As discussed above, a base destination field may be used to facilitate a determination of whether a notification is intended for a proxy device or any proxied devices. Because the push notification was determined to be destined for the mobile device, in step 570, the push notification is sent to the mobile device using the second connection.
B. Establishing Presence
FIG. 6 is a message sequence chart that illustrates establishing proxy and proxied presence according to various embodiments. In these examples, to establish a proxy presence, companion device 120 of FIG. 2 acting on its own or as a proxy device sends to device interface 240 at the very least a presence command for device token T1 (or when sent without a device token, device token T1 can be generated) at 605. Companion device 120 can have multiple connections to device interface 240. For example, companion device 120 can have a wifi connection as well as a cell connection. A presence command can be sent up on both connections to device interface 240. In some aspects, device interface 240 includes logic to use a highest priority available connection to deliver the message to companion device 120.
At 610, data passed to device interface 240 in the presence command for device token T1 can be validated using a variety of pre-specified criteria. When everything is successfully validated, device interface 240 further generates a mapping between device token T1 and connection information describing how companion device 120 is connected to device interface 240. At 615, device interface 240 sends status OK back (along with a new generated token if no token was provided). If validation fails for some reason, device interface 240 can send a connected with status invalid back to companion device 120 at 615.
After a successful exchange asserting the presence command for device token T1, companion device 120 can begin acting as a proxy device thereby sending and receiving commands for proxied devices. To establish proxied presence, mobile device 115 generates a presence command for device token T2 at 620. The presence command can include device token T2, an X509 DER-encoded certificate of mobile device 115, a nonce (e.g., that consists of version, timestamp of when it was generated in milliseconds, and 8 bytes of randomly generated data), and a signature of the nonce data (e.g., a SHA1 of the nonce data encrypted with a private key issued to mobile device 115). A device token for a proxied device can be sent as a part of a presence command when the proxied device already knows its token. Otherwise, a new token can be generated and returned back to the proxied device. At 625, mobile device 115 sends the presence command for device token T2 to companion device 120.
At 630, companion device 120 prepares the presence command for device token T2 for delivery to device interface 240. In some embodiments, companion device 120 prepares the presence command for device token T2 by creating its own message command with the presence command for device token T2 as a payload. In some embodiments, companion device 120 forwards the presence command for device token T2 untouched or includes one or more additional pieces of information. At 635, the presence command for device token T2 is passed to device interface 140 from companion device 120.
At 640, data passed to device interface 240 in the presence command for device token T2 is validated similarly as described above. If validation fails for some reason, device interface 240 can send a connected with status invalid back to companion device 120 at 645. When everything is successfully validated, device interface 240 can send status OK back (along with a new generated token if no token was provided) at 645. Device interface 240 can at this point generate a mapping between device token T2 and connection information describing how mobile device 115 is connected to device interface 240. In some embodiments, after companion device 120 receives the status OK, companion device 120 can send a filter command for each specific proxy token and thus allow the presence of each proxied device to be established at 650. In one aspect, the device token for each proxied device is explicitly mentioned in the filter command. Device interface 240 can at this point generate the mapping between device token T2 and connection information describing how mobile device 115 is connected to device interface 240.
As discussed above, mapping between device token T2 and connection information describing how mobile device 115 is connected to device interface 240 can be an association of device token T2 to how companion device 120 is connected to device interface 240. In some embodiments, device interface 240 can maintain separate unique mappings according to device tokens having common connection information.
At 655, although not required, companion device 120 can communicate a status or acknowledgment command to mobile device 115 that an “online” presence has been established.
C. Forward Push—Sending Messages to Proxy/Proxied Device
FIG. 7 is a message sequence chart that illustrates sending push content from a push notification service to a proxy device for delivery to a proxied device according to various embodiments. In these embodiments, device interface 240 receives a message command having a destination field that specifies or otherwise is indicative of device token T2 or mobile device 115. At 710, device interface 240 prepares the message command for delivery to its destination. In some embodiments, device interface 240 consults its mappings and determines the connection information associated mobile device 115. That can mean that connection information for companion device 120 is identified using an association of device token T2 to a mapping between device token T1 and a network connection to companion device 120. In some embodiment, device interface 240 prepares a base destination field to be used for different types of tokens that may be included in messages, such as per app tokens that are based off alias tokens. When a base destination field is not present in a message command, companion device 120 can handle the message command without further process for proxied devices.
In various embodiments, device interface 240 places the message into a queue of messages waiting for acknowledgement at 710. Whenever an acknowledge command is received from an acknowledging device, device interface 240 looks at a destination field of the acknowledgment command to know what queue to use and removes the message from its queue. When device interface 240 sends a message for a proxied device, device interface 240 can get two commands back from a corresponding proxy device.
For example, at 720, companion device 120 generates a transport acknowledge command as a first type of acknowledge command. A transport acknowledgment command tells device interface 240 that a proxy device received a message and optionally is in the process of forwarding it to a proxied device. At 725, companion device 120 sends the transport acknowledgment command to device interface 240. Device interface 240 can decide not to remove the sent message from its queue at this point.
A second type of acknowledgment command that device interface 240 expects to get back in this example is an acknowledge command from a main or proxy device on behalf of a proxied device. Sending of this second acknowledgment command might be delayed. For example, at 730, companion device 120 prepares the message command for delivery to mobile device 115. As alluded to above, mobile device 115 may maintain a non-persistent or intermittent connection with companion device 120—such as to save power. Companion device 120 may have to wait for mobile device 115 to “wake up” in order to re-establish a connection. In some embodiments, companion device 120 determines which a suitable link to connect to mobile device 115. Once a connection is established, companion device 120 sends the message command to mobile device 115 at 735.
At 740, mobile device 115 may optionally send an acknowledgement command to companion device 120 in response to receiving the message command. This may not be required as there may be other means for determining guaranteed delivery or a successful delivery may not be needed. At 745, companion device 120 sends an acknowledgment command of the second type to device interface 240 either explicitly or indirectly on behalf of mobile device 115. At 750, device interface 240 processes the acknowledgement command. Device interface 240 can remove the message from its queue at this point.
In various embodiments, a transport acknowledge command is optional. If companion device 120 is in a position to deliver a message to mobile device 120 fast enough, companion device 120 can decide to skip the transport acknowledge command and send one acknowledge command (i.e., the second type of acknowledgment command) to device interface 240. Companion device 120 can implement a variety of techniques for sending acknowledgment commands for each proxied device that account for the order in which messages were received.
FIG. 8 is a flowchart of method 800 performed by a companion device acting as a proxy device for handing proxied push content according to one embodiment. Processing in method 800 depicted in FIG. 8 may be performed by software (e.g., instructions or code modules) when executed by a central processing unit (CPU or processor) of a logic machine, such as a computer system or information processing device, by hardware components of an electronic device or application-specific integrated circuits, or by combinations of software and hardware elements.
In step 810, a push notification for a mobile device is received at a companion device from a push notification service. The push notification can be received via a persistent connection the companion device maintains with the service. In step 820, a transport acknowledgment is generated. In step 830, the transport acknowledgment is send to the service from the companion device.
In step 840, the push notification is sent to the mobile device from the companion device. The push notification can be sent to the mobile device using an intermitted or non-persistent connection with the mobile device. Such a link can be chosen by either the companion device or the mobile device to maximize power consumption, data throughput, link stability, or the like. In step 850, a determination is made whether the push notification was received by the mobile device.
Based on a determination in step 850 that the push notification was received by the mobile device, an acknowledgement is generated in step 860. Based on a determination in step 850 that the push notification was not received by the mobile device, an “offline” message is generated in step 870. In step 880, a response is sent from the companion device to the service. The response can include either the acknowledgment generated in step 860 or the “offline” message generated in step 870.
FIG. 9 is a flowchart of method 900 performed by a mobile device acting as a proxied device for receiving proxied push content according to one embodiment. Processing in method 900 depicted in FIG. 9 may be performed by software (e.g., instructions or code modules) when executed by a central processing unit (CPU or processor) of a logic machine, such as a computer system or information processing device, by hardware components of an electronic device or application-specific integrated circuits, or by combinations of software and hardware elements.
In step 910, a presence command for a mobile device is generated. In step 920, the presence command is sent to a companion device via a first connection in order for the companion device to have a push notification service create a mapping between a companion device identifier, a mobile device identifier, and a second connection. The second connection can be the persistent connection maintained between the companion device and the push notification service. In step 930, a push notification for the mobile device is received from the companion device. In step 940, an acknowledgement command is sent to the companion device using the first connection.
D. Redelivery
In some embodiments, due to an unsuccessful delivery of the message command to a proxied device (e.g., mobile device 115) and without receiving an acknowledgement command of the second type from a corresponding proxy device (e.g., companion device 120), a push notification service (e.g., via device interface 240) can attempt to redeliver the message command at a later time. As discussed above, one option due to an unsuccessful delivery of the message command to a mobile device is that a companion device can send an “offline” presence command to the service. The service may attempt redelivery of the message command upon receiving a new “online” presence command from the mobile device or can simply remove the message command from its queue.
In various embodiments, when there are duplicate presence assertions that exist in the presence information of the service such as PNS 220, a presence command with status “offline” can be sent to device interface 240 if its connection information 240 is out of date. When device interface 240 receives the presence command, device interface 240 clears out the queue of messages waiting for acknowledgement. Device interface 240 can do this by sending a redeliver message command for each message in its queue back to gateway 230. For proxy presences, when device interface 240 receives the presence command from gateway 230 for the presence associated with a proxy device, device interface 240 may clear out message queue for the proxy device by sending a redeliver message command for each message in the queue back to gateway 230 and send a presence command with status “offline” for each presence associated with this device back to gateway 230.
An “offline” presence may be also be sent in the following scenario where regular device A sends an online presence to a push notification service. Proxied device P sends an online proxy presence through A's connection to the server. Regular device B sends an online presence. Note that B is NOT the same device as A (different push token and cert). Proxied device P sends online proxy presence through B's connection. The service can tear down any outdated connections maintain in its presence/connection information.
E. Device Connection Tear Down
When a device connection is explicitly terminated, device interface 240 may send a presence command to gateway 230 with status “offline” for each presence established on the device connection (i.e., main, proxy, alias, proxy alias). The messages that are still in the acknowledgement queue for companion device 120 and mobile device 115 can be sent back to gateway 230 with a delivery status of “offline.”
F. Reverse Push—Sending Messages from Proxy/Proxied Device
FIG. 10 is a message sequence chart illustrating sending push content from a mobile device acting as a proxied device to a push notification service by a companion device acting as a proxy device according to one embodiment. In this example, mobile device 115 acting as a proxied device generates a message command at 1005. The message command can include one or more items each identified by an item identifier and having a payload. One item can be a token that identifies the destination of the message command. At 1010, mobile device 115 sends the message command to companion device 120. Mobile device 115 may select from multiple ways of connecting to companion device 120 in order to maximize power efficiency, ensure reliable delivery, or the like.
At 1015, companion device 120 prepares the message commend for deliver to its destination. In various embodiments, companion device 120 may simply forward the message command as received. In other embodiments, companion device may add additional data or generate a new message command. Companion device 120 can determine that it is not the destination of the message command and send the message command to device interface 240 at 1020.
Data passed to device interface 240 in the message command can be validated using a variety of pre-specified criteria at 1025. When everything is successfully validated, device interface 240 can send status OK back at 1030 in an optional acknowledgement process. At 1035, companion device 120 receives the status OK and sends the status OK back to mobile device 115 at 1035. If validation fails for some reason, device interface 240 can send a status invalid back to companion device 120 at 1030. At 1035, although not required, companion device 120 can communicate some type of status or acknowledgment to mobile device 115 that the message command has been received, sent, and/or acknowledged.
G. Proxied Push Protocol
Serial Presence Command Table
Item Length Notes
Certificate Any X509 DER-encoded certificate of the proxied
device establishing this presence
Nonce 17 Nonce generated by the client device. Nonce
can consists of the following fields:
1) 1 byte version (0)
2) 9 bytes timestamp in network byte order
3) 9 bytes random number
Signature Any Signature generated by the client device by
generating SHA1 of the nonce and signing it with
the private key belonging to the proxy device
Carrier Any String representing carrier
Software Any String representing device software version
Software Any String representing device software build
Hardware Any String representing device hardware version
Serial Acknowledge Command Table
Destination 32 bytes Destination token of the original
Serial Transport Acknowledge Command Table
Command Command Id
Transport Pre-assigned value
In various embodiments, a message command that is sent from courier to device is changed when a destination token is a per app token. In this case, additional field can be specified such as the base destination, which can be a base token that a per app token was generated from.
Message Command Table
Base Destination 32 bytes Base destination token
When a device issues a serial presence command that contains a nonce with a timestamp that is not within the expected window, a server timestamp can be added to a connected response (with invalid status). This allows devices with bad clocks to retry and recover.
Connected Command Table
Server 8 bytes Server epoch time in milliseconds in
Time network byte order
FIG. 11 shows a protocol stack 1100 for communicating data according to embodiments of the present invention. Various modules in protocol stack 1100 can be omitted, or other modules added. The software modules can be run on a same processor or different processors. Although only a few communication protocols are listed, numerous wireless protocols can be used. For example, Bluetooth protocols can include Basic Rate (BR), Enhanced Data Rate (EDR), and Low Energy (LE) options. Bluetooth BR/EDR is also referred to as Classic Bluetooth.
In some embodiments, a client application 1105 on the device (e.g., mobile device 115) can request data to be sent to another device (e.g., companion device 120). The request can specify the other device via any suitable identifier, e.g., an account name, an IP address, a MAC address, etc. The request can be before or after the device determines that the other device is within communication, e.g., as determined by initial signaling, such as a handshake. The data (e.g., in a message or a stream) can be sent any suitable application layer protocol, such as HTTP, RTP, SMTP, MGCP, etc. The other device can be any device, including another device of the user. The request can made be in response to an action by the user, an internal event (e.g., based on time or other criteria) that may be in a same or other application (e.g., a calendar app), or an external event (e.g., in response to a message from another device). An example of an event is a syncing event.
Before sending data, client application 1105 can submit an open socket request (e.g., in a streaming example). The socket request can use information from an identity services (IDS) framework 1115, which can provide an address (or other type of ID) for the other device. For example, client application 1105 can know account information for the second device (e.g., account information of a different or same user), and IDS framework 1115 can store a list of device IDs for a particular account. IDS framework 1115 can be in communication with identity management infrastructure 105 to obtain the list. Thus, IDS framework 1115 can store or otherwise obtain device IDs (e.g., addresses) for all devices that a user has registered with identity management infrastructure 105. For example, IDS framework 1115 can request via an IDS daemon to identity management infrastructure 105 to obtain the device IDs. In one implementation, the socket request can be made to kernel 1110.
In a messaging example, the request to send data can go to IDS framework 1115 to obtain a device ID, which can be sent to message a message controller 1120 and a user tunnel (UTUN) controller 1125. UTUN controller 1125 can establish a mapping between the device ID and an IP address (e.g., a virtual IP address) when the device ID is not an IP address. A socket can be created between message controller 1120 (which assigns a device ID to the socket) and kernel 1110 (which can assigns an address to the socket, such as a virtual IP address). UTUN controller 1120 can be used to create the socket connection between message controller 1120 and kernel 1110. In this manner, the send-date request from client application 1105 does not need to include a device ID, but can specify an account, which can then be cross-referenced by IDS framework 1115 with known devices of the account and their capabilities (e.g., if the request requires certain capabilities). Given that a device ID can be obtained, a pairing does not need to occur prior to creating the socket.
In various embodiments, IDS framework 1115 can receive a particular port/service at the other device from client application 1105, determine the port/service based on information obtained from identity management infrastructure 105, or determine the port/service from a token sent in the request. IDS framework 1115 can then communicate a device ID and other header information to message controller 1120 and/or UTUN controller 1125. IDS framework 1115 and UTUN controller 1125 can communicate via cross process communication (XPC). UTUN controller 1125 can be part of an IDS daemon, and can receive a device ID from identity management infrastructure 105.
As mentioned above, UTUN controller 1125 can create a virtual address that corresponds to the actual device address, where the virtual address can be used to create a virtual socket. A virtual socket can also be created using any device ID (e.g., an actual address of a device or other ID). As an example, a socket can be created for communication between client application 1105 and kernel 1110 (e.g., in a streaming context), where kernel 1110 can have various sockets open with various client applications. Kernel 1110 can have a single connection to UTUN controller 1125 for the other device and multiplex (mux) the data from various client applications into the single connection. Instead or in addition, UTUN controller 1125 can also perform the muxing, e.g., if multiple socket exist between kernel 1110 and UTUN controller 1125 for various client applications to the other device. Incoming data can be demultiplexed (demuxed) for sending to the destination client application.
As another example, a socket can be created between kernel 1110 and message controller 1120 (e.g., in a messaging context), where a socket can be created for each destination device, with different sockets to a same device potentially having different priorities. Thus, a particular virtual socket can be associated with a particular device and a particular priority (e.g., high and low). Message controller 1120 can have various connections to various client applications. Thus, message controller 1120 can provide mux/demux capabilities.
UTUN controller can create a primary socket with the other device. When UTUN controller 1125 receives data using a virtual connection associated with the second device, it can then map the virtual connection to the primary socket for communicating with the other device. All data for the other device can then be sent out through the primary socket. The virtual address for a virtual socket can be passed back to client application 1115, e.g., in the stream context. In one embodiment, a virtual socket involving kernel 1110 is a TCP socket. The virtual address can have a same format as a regular address, e.g., an IPv6 address. A mux module can include any combination of kernel 1110, message controller 1120, and UTUN controller 1125.
When client application 1105 sends data, client application 1105 can use the virtual socket to send data to kernel 1110. For example, the data can be sent using TCP via the virtual socket. Kernel 1110 can implement an UTUN interface for communicating with UTUN controller 1125. Kernel 1110 would pass the data (e.g., with a TCP header) and the virtual socket identifying the virtual address to UTUN controller 1125, which would then use the virtual address to resolve the device address for determining the device socket.
When sending to the data over the device socket, a link manager 1130 can determine which link to use. A link can be a particular combination of a wireless interface protocol (e.g., Bluetooth or Wi-Fi), a transport protocol (e.g., TCP, UDP, etc), and a destination device. In this manner, UTUN controller 1125 does not need to know how the data is being sent, but instead can simply send the data to link manager 1130.
In various embodiments, the determination by link manager 1130 can be made per data packet, per set of data packets, per device socket, and may change from one data packet to another. Link manager 1130 may then select a link for sending the data. In the example shown, a Wi-Fi link 1135 provides software drivers for communicating with one or more Wi-Fi protocols, and BLTE link 1140 provides software drivers for communicating with Blutooth LE. Wi-Fi link 1135 is in communication with Wi-Fi hardware 1170, and BLTE link 1140 is in communication with BTLE hardware 1165. Wi-Fi link 1135 can be used for various Wi-Fi protocols, such as infra-WiFi (infrastructure WiFi). In one embodiment, link manager 1130 can try all links to determine whether any of the links can contact the other device, and then use a connected link with a highest predetermined rank or dynamic rank.
Hardware 1165-1170 can be in communication with links assigned to various devices. For example, links 1135, 1140, and 1145 can be assigned for communication with a second device. And, other links that are assigned for communication with a third device can also be in communication with hardware 1165-1170. When a particular hardware receives data, software can identify a particular sending device and then determine the corresponding link, e.g., using header information to determine the link corresponding to the sending device and transport protocol.
In some embodiments, a combined link 1145 can include an interface 1155 for communicating with link manager 1130 and a selector 1150 that selects a particular protocol to use. The protocols can be the same or different than that available to link manager 1130. Selector 1150 can perform similar functions as link manager 1130 in that a particular link is selected. However, link manager 1130 and selector 1150 can use different criteria for determining which link to use. For example, link manager 1130 can determine to use combined link 1145, and selector 1150 can then determine that BTLE hardware 1165 is to be used. The hardware can be contained on a same or separate chips.
One or more protocols can be only available via combined link 1145, such as classic Bluetooth hardware 1150. Link manager 1130 and selector 1150 can use various criteria for determining which link to use, such as power usage of a link, speed of a link (e.g., real-time data rate), and signal strength of a link. A goal of the optimization for selecting a link can be to provide a minimal data rate at a lowest possible energy.
FIG. 12 is a block diagram of a portable electronic device or mobile device 1200 according to an embodiment. Mobile device 1200 generally includes computer-readable medium 1202, a processing system 1204, an Input/Output (I/O) subsystem 1206, wireless circuitry 1208, and audio circuitry 1210 including speaker 1212 and microphone 1214. These components may be coupled by one or more communication buses or signal lines 1203. Mobile device 1200 can be any portable electronic device, including a handheld computer, a tablet computer, a mobile phone, laptop computer, tablet device, media player, personal digital assistant (PDA), a key fob, a car key, an access card, a multi-function device, a mobile phone, a portable gaming device, or the like, including a combination of two or more of these items.
It should be apparent that the architecture shown in FIG. 12 is only one example of an architecture for mobile device 1200, and that mobile device 1200 can have more or fewer components than shown, or a different configuration of components. The various components shown in FIG. 12 can be implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and/or application specific integrated circuits.
Wireless circuitry 1208 is used to send and receive information over a wireless link or network to one or more other devices' conventional circuitry such as an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, memory, etc. In some embodiments, wireless circuitry 1208 is capable of establishing and maintaining communications with other devices using one or more communication protocols, including time division multiple access (TDMA), code division multiple access (CDMA), global system for mobile communications (GSM), Enhanced Data GSM Environment (EDGE), wideband code division multiple access (W-CDMA), Long Term Evolution (LTE), LTE-Advanced, WiFi (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11g and/or IEEE 802.11n), Bluetooth, Wi-MAX, voice over Internet Protocol (VoIP), near field communication protocol (NFC), a protocol for email, instant messaging, and/or a short message service (SMS), or any other suitable communication protocol, including communication protocols not yet developed as of the filing date of this document. A mobile device can include wireless circuitry that can communicate over several different types of wireless networks depending on the range required for the communication. For example, a short-range wireless transceiver (e.g., Bluetooth), a medium-range wireless transceiver (e.g., WiFi), and/or a long range wireless transceiver (e.g., GSM/GPRS, UMTS, CDMA2000 1x/EV-DO and LTE/LTE-Advanced) can be used depending on the type of communication or the range of the communication.
Wireless circuitry 1208 is coupled to processing system 1204 via peripherals interface 1216. Interface 1216 can include conventional components for establishing and maintaining communication between peripherals and processing system 1204. Voice and data information received by wireless circuitry 1208 (e.g., in speech recognition or voice command applications) is sent to one or more processors 1218 via peripherals interface 1216. One or more processors 1218 are configurable to process various data formats.
Peripherals interface 1216 couple the input and output peripherals of device 1200 to the one or more processors 1218 and computer-readable medium 1202. One or more processors 1218 communicate with computer-readable medium 1202 via a controller 1220. Computer-readable medium 1202 can be any device or medium that can store code and/or data for use by one or more processors 1218. Medium 1202 can include a memory hierarchy, including cache, main memory and secondary memory. The memory hierarchy can be implemented using any combination of RAM (e.g., SRAM, DRAM, DDRAM), ROM, FLASH, magnetic and/or optical storage devices, such as disk drives, magnetic tape, CDs (compact disks) and DVDs (digital video discs). In some embodiments, peripherals interface 1216, one or more processors 1218, and memory controller 1220 can be implemented on a single chip, such as processing system 1204. In some other embodiments, they can be implemented on separate chips.
Mobile device 1200 also includes a power system 1222 for powering the various hardware components. Power system 1222 can include a power management system, one or more power sources (e.g., battery, alternating current (AC)), a recharging system, a power failure detection circuit, a power converter or inverter, a power status indicator (e.g., a light emitting diode (LED)) and any other components typically associated with the generation, management and distribution of power in mobile devices.
In some embodiments, mobile device 1200 includes a camera 1224. In some embodiments, mobile device 1200 includes sensors 1226. Sensors can include accelerometers, compass, gyrometer, pressure sensors, audio sensors, light sensors, barometers, and the like. Sensors 1226 can be used to sense location aspects, such as auditory or light signatures of a location. In some embodiments, mobile device 1200 can include a GPS receiver, sometimes referred to as a GPS unit 1228. A mobile device can use a satellite navigation system, such as the Global Positioning System (GPS), to obtain position information, timing information, altitude, or other navigation information. In some embodiments, mobile device 1200 can include external port 1230 (e.g., USB, FireWire, Lightning connector, 120-pin connector, etc.). External port 1230 can be adapted for coupling directly to other devices or indirectly over a network (e.g., the Internet, wireless LAN, etc.).
One or more processors 1218 run various software components stored in medium 1202 to perform various functions for device 1200. In some embodiments, the software components include operating system 1232, communication module (or set of instructions) 1234, and other applications (or set of instructions) 1236. Operating system 1232 can be any suitable operating system, including iOS, Mac OS, Darwin, RTXC, LINUX, UNIX, OS X, WINDOWS, or an embedded operating system such as VxWorks. The operating system can include various procedures, sets of instructions, software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates communication between various hardware and software components.
Communication module 1234 facilitates communication with other devices over one or more external ports 1230 or via wireless circuitry 1208 and includes various software components for handling data received from wireless circuitry 1208 and/or external port 1230.
The one or more applications 1236 on mobile device 1200 can include any applications installed on the device 1200, including without limitation, a browser, address book, contact list, email, instant messaging, social networking, word processing, keyboard emulation, widgets, JAVA-enabled applications, encryption, digital rights management, voice recognition, voice replication, a music player (which plays back recorded music stored in one or more files, such as MP3 or AAC files), etc.
I/O subsystem 1206 can be coupled to a display system (not shown), which can be a touch-sensitive display. The display displays visual output to the user in a GUI. The visual output can include text, graphics, video, and any combination thereof. Some or all of the visual output can correspond to user-interface objects. A display can use LED (light emitting diode), LCD (liquid crystal display) technology, or LPD (light emitting polymer display) technology, although other display technologies can be used in other embodiments.
In some embodiments, I/O subsystem 1206 can include a display and user input devices such as a keyboard, mouse, and/or trackpad. In some embodiments, I/O subsystem 1206 can include a touch-sensitive display. A touch-sensitive display can also accept input from the user based on haptic and/or tactile contact. In some embodiments, a touch-sensitive display forms a touch-sensitive surface that accepts user input. The touch-sensitive display/surface (along with any associated modules and/or sets of instructions in medium 1202) detects contact (and any movement or release of the contact) on the touch-sensitive display and converts the detected contact into interaction with user-interface objects, such as one or more soft keys, that are displayed on the touch screen when the contact occurs. In some embodiments, a point of contact between the touch-sensitive display and the user corresponds to one or more digits of the user. The user can make contact with the touch-sensitive display using any suitable object or appendage, such as a stylus, pen, finger, and so forth. A touch-sensitive display surface can detect contact and any movement or release thereof using any suitable touch sensitivity technologies, including capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with the touch-sensitive display.
Further, I/O subsystem 1206 can be coupled to one or more other physical control devices (not shown), such as pushbuttons, keys, switches, rocker buttons, dials, slider switches, sticks, LEDs, etc., for controlling or performing various functions, such as power control, speaker volume control, ring tone loudness, keyboard input, scrolling, hold, menu, screen lock, clearing and ending communications and the like. In some embodiments, in addition to the touch screen, device 1200 can include a touchpad (not shown) for activating or deactivating particular functions. In some embodiments, the touchpad is a touch-sensitive area of the device that, unlike the touch screen, does not display visual output. The touchpad can be a touch-sensitive surface that is separate from the touch-sensitive display or an extension of the touch-sensitive surface formed by the touch-sensitive display.
at a proxied device having one or more processors and a communications interface:
establishing via the communications interface a non-persistent link between the proxied device and a proxy device having a persistent link with a service in order to send a message to the proxy device asserting to the service presence information for the proxied device that instructs the service to associate the proxied device with an existing mapping between the proxy device and a persistent link that the proxy device maintains with the service;
terminating the non-persistent link;
re-establishing via the communications interface the non-persistent link in order to receive a push notification associated with the proxied device from the proxy device, the push notification routed by the service to the proxy device using the association between the proxied device and the existing mapping between the proxy device and the persistent link that the proxy device maintains with the service; and
storing the push notification in the memory.
sending the message to the proxy device asserting to the service presence information for the proxied device using the non-persistent link between the proxied device and the proxy device.
3. The method of claim 2 wherein the presence information for the proxied device includes one or more of a device token or application token.
4. The method of claim 1 wherein establishing via the communications interface the non-persistent link between the proxied device and the proxy device comprises establishing a Bluetooth lower energy connection with the proxy device.
5. The method of claim 1 wherein terminating the non-persistent link comprises sending a message to the proxy device indicating an offline status for the proxied device.
6. The method of claim 1 wherein terminating the non-persistent link comprises reducing communications with the proxied device for a predetermined period of time.
receiving the push notification associated with the proxied device from the proxy device.
8. The method of claim 7 wherein the push notification represents an email notification, an instant message notification, a short message service (SMS) notification, a multimedia message service (MMS) notification, or a content status notification.
sending information to the proxy device indicating delivery of the push notification at the proxied device.
establishing a persistent connection between the proxied device and the service that instructs the service to disassociate the proxied device with the existing mapping between the proxy device and the persistent link that the proxy device maintains with the service; and
receiving one or more push notifications using the persistent connection between the proxied device and the service.
generating a display of the push notification that includes a visual representation of a type associated with the push notification.
terminating any non-persistent links with the proxy device; and
establishing via the communications interface a non-persistent link with a second proxy device in order to receive push notifications associated with the proxied device from the second proxy device.
13. The method of claim 1 wherein the proxied device or proxy device comprises a mobile media player, a smart phone, a wearable device, a tablet, a gaming device, a laptop, or a desktop computer.
14. A computer program product embodied within a non-transitory computer-readable medium storing code executable by one or more processors of a proxied device having a communications interface for proxied communications, the non-transitory computer-readable medium comprising:
code for establishing via the communications interface a non-persistent link between the proxied device and a proxy device having a persistent link with a service;
code for sending, using the non-persistent link, a message to the proxy device asserting to the service presence information for the proxied device that instructs the service to associate the proxied device with an existing mapping between the proxy device and a persistent link that the proxy device maintains with the service;
code for terminating the non-persistent link;
code for re-establishing via the communications interface the non-persistent link;
code for receiving a push notification associated with the proxied device from the proxy device in response to re-establishing the non-persistent link, the push notification routed by the service to the proxy device using the association between the proxied device and the existing mapping between the proxy device and the persistent link that the proxy device maintains with the service; and
code for performing one or more actions based on the push notification.
15. The non-transitory computer-readable medium of claim 14 wherein the code for sending the message to the proxy device comprises code for sending one or more of a device token or application token.
16. The non-transitory computer-readable medium of claim 14 wherein the code for establishing or re-establishing via the communications interface the non-persistent link between the proxied device and the proxy device comprises code for establishing a Bluetooth lower energy connection with the proxy device.
17. The non-transitory computer-readable medium of claim 14 wherein the push notification represents an email notification, an instant message notification, a short message service (SMS) notification, a multimedia message service (MMS) notification, or a content status notification.
18. The non-transitory computer-readable medium of claim 14 further comprising:
code for establishing a persistent connection between the proxied device and the service that instructs the service to disassociate the proxied device with the existing mapping between the proxy device and the persistent link that the proxy device maintains with the service; and
code for receiving one or more push notifications using the persistent connection between the proxied device and the service.
establish via the communications interface a non-persistent link between the mobile device and a companion device having a persistent link with a content delivery service;
send, using the non-persistent link, a message to the companion device asserting to the content delivery service presence information for the mobile device that instructs the content delivery service to associate the mobile device with an existing mapping between the companion device and a persistent link that the companion device maintains with the content delivery service;
terminate the non-persistent link based on one or more power metrics; and
periodically re-establish via the communications interface the non-persistent link in order to receive push notifications associated with the mobile device from the companion device, the push notifications routed by the content delivery service to the companion device using the association between the mobile device and the existing mapping between the companion device and the persistent link that the companion device maintains with the content delivery service.
20. The mobile device of claim 19 wherein the set of instructions further cause the processor to:
establish via the communications interface a non-persistent link with a second companion device; and
receive one or more push notifications associated with the mobile device from the second companion device.
21. The mobile device of claim 19 wherein the set of instructions further cause the processor to:
establish a persistent connection with a second communications interface between the mobile device and the content delivery service that instructs the content delivery service to disassociate the mobile device with any mappings between an companion devices and any persistent link that the companion devices maintain with the content delivery service; and
receive one or more push notifications using the persistent connection between the mobile device and the content delivery service.
22. The mobile device of claim 19 wherein the set of instructions further cause the processor to perform one or more actions based on receiving a push notification associated with the mobile device from the companion device.
23. The mobile device of claim 22 wherein the set of instructions cause the processor to perform the one or more actions to update a user interface with a visual representation of a type associated with the push notification.
24. The mobile device of claim 22 wherein the set of instructions cause the processor to perform the one or more actions to provide haptic feedback to a user of the mobile device.
25. The mobile device of claim 22 wherein the set of instructions cause the processor to perform the one or more actions to initiate one or more applications hosted on the mobile device that retrieve content from the content delivery service.
US14/475,060 2014-05-30 2014-09-02 Proxied push Active 2035-04-17 US9654581B2 (en)
US14/475,060 US9654581B2 (en) 2014-05-30 2014-09-02 Proxied push
PCT/US2015/032477 WO2015183829A1 (en) 2014-05-30 2015-05-26 Proxied push
EP15730323.1A EP3149919A1 (en) 2014-05-30 2015-05-26 Proxied push
CN201580028398.2A CN106464729A (en) 2014-05-30 2015-05-26 Proxied push
US15/594,391 US20180013851A1 (en) 2014-05-30 2017-05-12 Proxied push
US15/594,391 Continuation US20180013851A1 (en) 2014-05-30 2017-05-12 Proxied push
US20150350362A1 true US20150350362A1 (en) 2015-12-03
US9654581B2 US9654581B2 (en) 2017-05-16
ID=53442962
US14/475,060 Active 2035-04-17 US9654581B2 (en) 2014-05-30 2014-09-02 Proxied push
US15/594,391 Pending US20180013851A1 (en) 2014-05-30 2017-05-12 Proxied push
US (2) US9654581B2 (en)
EP (1) EP3149919A1 (en)
CN (1) CN106464729A (en)
WO (1) WO2015183829A1 (en)
CN105721162A (en) * 2016-01-30 2016-06-29 飞天诚信科技股份有限公司 Method and device for automatically importing digital certificate to application program
US10200486B2 (en) 2015-02-26 2019-02-05 Urban Airship, Inc. Mobile event notifications for network enabled objects
US10084865B2 (en) * 2015-02-26 2018-09-25 Urban Airship, Inc. Mobile event notifications
CN105827706A (en) * 2016-03-24 2016-08-03 努比亚技术有限公司 Information push device and method
US10064025B2 (en) * 2016-05-17 2018-08-28 Google Llc Offline peer-assisted notification delivery
US20140016554A1 (en) * 2012-07-10 2014-01-16 Empire Technology Development Llc Push management scheme
US20140115125A1 (en) * 2011-12-27 2014-04-24 Huawei Device Co., Ltd. Method for Receiving Data, Method for Sending Data, Mobile Terminal, and Server
EP2847874A4 (en) 2012-05-09 2016-01-27 Empire Technology Dev Llc Digital relay for out of network devices
2014-09-02 US US14/475,060 patent/US9654581B2/en active Active
2015-05-26 EP EP15730323.1A patent/EP3149919A1/en active Pending
2015-05-26 WO PCT/US2015/032477 patent/WO2015183829A1/en active Application Filing
2015-05-26 CN CN201580028398.2A patent/CN106464729A/en active Search and Examination
2017-05-12 US US15/594,391 patent/US20180013851A1/en active Pending
WO2015183829A1 (en) 2015-12-03
CN106464729A (en) 2017-02-22
US20180013851A1 (en) 2018-01-11
US9654581B2 (en) 2017-05-16
EP3149919A1 (en) 2017-04-05
CN1554176A (en) 2004-12-08 System and method for secure message key caching in a mobile communication device
AU2014269271A1 (en) 2015-11-26 Electronic device using logical channels for communication
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:POLLACK, DANIEL B.;THIRUMALAI, GOKUL P.;SIGNING DATES FROM 20140825 TO 20140826;REEL/FRAME:033657/0446