Method and apparatus for minimizing application delay by pushing application notifications
A method for minimizing application initialization delay comprising sending, from a privileged application executing on a mobile device, a registration message to a server, receiving, at the privileged application, a response message from the server, extracting, from the response message, application information and notifying the mobile device of the application information.
Latest Vonage America Inc. Patents:
- Systems and methods of providing communications services
- Systems and methods for supplementing real-time exchanges of instant messages with automatically updateable content
- Systems and methods of assigning and using virtual telephone numbers
- Systems and methods for dynamic operation of electronic devices based on detection of one or more events
- Systems and methods for establishing a language translation setting for a telephony communication
This application is a continuation of co-pending U.S. patent application Ser. No. 13/901,224, filed May 23, 2013, which is incorporated herein by reference in its entirety.
BACKGROUND OF THE INVENTION1. Field of the Invention
Embodiments of the present invention generally relate to a voice over internet protocol (VoIP) service, and more specifically, to a method and apparatus for minimizing application initialization delay by pushing application notifications.
2. Description of the Related Art
When an application moves from the background to the foreground of a mobile device, i.e., the application goes from being unused to being used by a user of the mobile device, the application may need to send one or more requests to one or more servers. For example, applications, i.e., mobile applications, may check for configuration changes, updates, whether a user account is still active, updating a contacts list, changes to licensing agreements, change to fees and charges, or the like. These application requests create a delay wherein the user of the mobile device cannot fully use the application while the requests are pending. Typically, the application will send an application programming interface (API) request for each check and the application will block other actions while waiting for a response, causing considerable delay perceptible by the user.
Therefore, there is a need in the art for a method and apparatus for reducing application update delay when moving the application to the foreground of a device in accordance with exemplary embodiments of the present invention.
SUMMARY OF THE INVENTIONEmbodiments of the present invention relate to a method and apparatus for minimizing application initialization delay comprising sending, from a privileged application executing on a mobile device, a registration message to a server, receiving, at the privileged application, a response message from the server, extracting, from the response message, application information and notifying the mobile device of the application information.
Further embodiments of the present invention relate to a method for providing update information in a response message comprising receiving, at a registration service, a registration message from a mobile device, communicating with one or more third party services to determine if application information is updated for applications on the mobile device and forming a response message and appending the application information to the response message.
So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
Embodiments of the present invention generally relate to a method for minimizing delay in mobile application initialization. According to one embodiment, an application with special privileges is stored in the memory of a mobile device. The operating system of the mobile device allows the privileged application to execute as a background process, and provides the privileged application with one or more handlers for handling incoming communication and a timer for periodically sending notifications to an external server while a non-privileged application may not execute as a background process and cannot perform any activity during hibernation. According to this embodiment, the privileged application periodically sends a registration message to a remote server and receives a response.
According to the present invention, the privileged application may also embed a request for updated data on behalf of non-privileged applications and receive an embedded update in the response message from the server to avoid an extraneous round-trip communication with a server from the non-privileged application as the non-privileged application is brought to the foreground. The privileged application extracts application notification information from the response and stores the information in a shared data store of the mobile device. Accordingly, non-privileged applications executing on the mobile device can selectively choose which updates to request from an external server based on the application notification information when they are brought to the foreground, minimizing the delay required after it is brought to the foreground.
The memory 103, or computer readable medium, stores non-transient processor-executable instructions and/or data that may be executed by and/or used by the processor 102. These processor-executable instructions may comprise firmware, software, and the like, or some combination thereof. Modules having processor-executable instructions that are stored in the memory 103 comprise one or more privileged application 104, and applications 110, comprising one or more applications 1 . . . N. The device 100 may be programmed with one or more operating systems 120, which may include OS/2, Java Virtual Machine, Linux, SOLARIS, UNIX, HPUX, AIX, WINDOWS, IOS, and ANDROID among other known platforms.
The memory 103 and the memory 103 may include one or more of the following random access memory, read only memory, magneto-resistive read/write memory, optical read/write memory, cache memory, magnetic read/write memory, and the like, as well as signal-bearing media as described below.
The operating system 120 gives special privileges to a privileged application. For example, in APPLE IOS, only privileged applications, for example, voice over internet protocol (VoIP) applications, may execute as background processes allowing the privileged applications to perform tasks in the background, while another application is in the foreground. For example, if a user of the device 100 initially executes the VoIP application on device 100, the VoIP application will be in the foreground. However, when the user switches back to a home screen of the device 100, the device 100 places the VoIP application in the background, with privileged access.
Conversely, if the user initially executed a non-privileged application on device 100, such as a game (i.e., application 1), and subsequently switches back to the home screen, the operating system 120 of the device 100 will cause the game to hibernate. In hibernation state, the game cannot perform any background tasks such as checking an external server for game updates, score updates, contact updates or the like. However, when the user launches the game again, the operating system 120 of the device 100 will release the game from hibernation state and execute the game as a foreground process.
The privileged application 104 handles incoming communications even as a background process. The privileged application 104 may be programmed to send local notifications for alerting the user of the device 100, or handle notification information and go back to a suspended state, waiting for incoming communication. Alternatively, the privileged application 104 may execute a periodic communication to an external server through the client registration service 106. For example, if the privileged application 104 is a VoIP application, the VoIP application will send a registration message to a VoIP server through network 101, to registration service 130. According to some embodiments of the present invention, the registration message is a Session Initiation Protocol (SIP) REGISTER message, comprising information related to the internet protocol (IP) address of the device 100.
The registration service 130 is a remote service executing on a server, such as a VoIP server. The registration service 130 receives the registration message indicating the location of the device 100 and sends a response in return through the network 101 back to the device 100 through the I/O interface 107. According to exemplary embodiments of the present application, the update module 132 of the registration service 130 may also retrieve updates from third party service 150, third party service 152 and third party service 154, on behalf of applications 1 . . . N stored in device 100. Accordingly, the applications 1 . . . N will not have to contact remote servers to retrieve update information. In some embodiments, the update module 132 only includes flags indicating that a change has occurred. The applications 1 . . . N then may only make server requests corresponding to the flagged updates and do not perform server requests on items which are not flagged.
According to some embodiments, the updates may include checking for new configuration parameters, missed calls, system message waiting, determining whether a user or account is still active with the third party service, updating a contact list, changes to licensing or service, changes to the privacy policy, modifications to service rates, or the like. The update module 132 subsequently inserts proprietary headers into the server response from the registration service 130. According to exemplary embodiments, the server response is a 200 OK SIP response, and the update module 132 appends headers to the response corresponding to the application notification flags.
The I/O interface 107 couples the response to the client registration service 106 of the privileged application 104. The notification service 108 of the privileged application 104 extracts the headers from the response and extracts and application notification flags indicating which updates should be requested by any third party applications. Once the flags are extracted by the notification service 108, the privileged application 104 goes into a suspended state, and, as described above, will be woken periodically to perform registration and to acquire any new application flags.
For example, if the user launches the game application (application 1) once more, the game application requests a list of updated application flags relating to the game application from the operating system 120. If the notification service 108 retrieved any update flags from the registration service 130, the notification service 108 will store those flags in memory 103 of the device 100. According to one embodiment, the notification service 108 stores the application information in a shared data store of a device. According to one embodiment, whenever an application is launched, the notification service 108 intercepts server requests and only permits those service requests for which flags have been saved in memory 103.
According to another embodiment, the application from applications 1 . . . N determines on launch which server update request to perform based on the application flags stored in memory 103. According to yet another embodiment, the application flags contain the updated information, and the application 1, for example, retrieves the information from the memory 103 of device 100, instead of sending a request to a remote server. The application 1 may then launch, or move to the foreground of device 100, and allow the user to use the application 1 without an update delay.
According to an alternate embodiment, the notification service 108 may write the application flag data to shared data area of the device 100. For example, the notification service 108 may write data to a dummy contact, or a calendar entry, named “Application 1”. Application 1 of the applications 110 will be programmed to access the “Application 1” contact, for example, to access its application flags, or its updated data. Application 2 will similarly extract the update data from the application information from contact “Application 2”. According to embodiments of the present invention, the data may be shared with applications 110 by writing the data to any shared data store in memory 103, such as e-mail, text message or the like as understood by those of ordinary skill in the art.
The method 200 begins at step 202 and proceeds to step 204. At step 204, a privileged application 104 executing on a device 100, such as a mobile phone, tablet or the like, uses client registration service 104 to send a register message to the registration service 130 through network 101. The privileged application 104 may be a VoIP application and the client registration service 106 may be a component of the VoIP application, or may be implemented as a separate service and stored in memory 103. The registration message may be a SIP REGISTER message used in VoIP applications, or may be any message that is periodically sent to a server. The privileged application 104 sends the registration message during the periodic timer assigned to privileged applications by the operating system 120, while the privileged application 104 is executing as a background process.
The method proceeds to step 206, where the client registration service 106 receives a response from the registration service 130. According to some embodiments, the response is an SIP 200 “OK” response to the registration message; though one of ordinary skill would recognize that any other response messages may be used.
The method then proceeds to step 208, where the notification service 108 extracts application information from the response received from the registration service 130. The application information may indicate which applications need to initiate an update, or may indicate a portion of updates that a particular application has to update.
According to some embodiments, updated application content may be embedded along with the application flags. For example, a third party service may, in one instance, provide a flag indicating that application configuration information such as a server address has changed. According to another instance, the third party service may send the registration service 130 the server address instead of the flag, thereby obviating the need for an application to request the new server address.
The method 200 then proceeds to step 210. At step 210, the notification service 108 notifies the mobile device 100 via the operating system 120. According to exemplary embodiments, the notification service 108 sends a message to the operating system 120 according to the norms of the operating system 120. In other instances, the notification service 108 may create or update contacts, calendar entries, emails, or the like, each associated with a particular Application of application 110 with the flag information.
For example, Application 1 may only check the contacts for a contact named “Application 1” for any application flags. When the user of device 100 brings Application 1 into the foreground, i.e. launches Application 1, or switches to Application 1, Application 1 initially checks the contact named “Application 1” to determine which parameters of Application 1 need to be updated. In contact “Application 1”, three application flags are listed: “update configuration”, “update score server to NEWSERVERADDRESS” and “subscription has changed”.
Application 1 will only request the updated configuration, the new score server address and the user's subscription level, instead of requesting all updates which Application 1 would normally request, thereby minimizing the initialization delay of Application 1. The user is able to use Application 1 quickly after the user launches Application 1 without sensing a delay before the user interface reacts to the user's input. Subsequently, the method terminates at step 212.
The method 300 begins at step 302 and proceeds to step 304. At step 304, the registration service 130 receives a registration message from a device. According to exemplary embodiments, the device may be a VoIP device, and the registration message may be a SIP REGISTER message from the VoIP device. In other instances, the registration message may be any form of messaging sent to a server for registering location. The registration message may be an HTTP request or the like, as known to those of ordinary skill in the art. The device may be a non-VoIP device such as a mobile phone, executing a VoIP application.
The method then proceeds to step 306, where the update module 132 of the registration service 130 waits for an update from one or more third party services to determine if there is any application information available to update. For example, one or more of the third party services (for example, GOOGLE contacts) may notify the update module 132 that updated contact information is available. If the service has updated data, then according to one embodiment, the update module 132 will set a flag indicating that contact data is updated. According to another embodiment, the update module 132 will receive the updated contact data.
At step 308, the registration service 130 forms a response message and appends the application information, e.g., the contact flag, to a response to the registration message. According to some embodiments, the response is any SIP response, for example, an SIP 200 “OK” response. In some embodiments, the flag information is embedded into additional headers in the response message. According to other embodiments, the update data is embedded into the headers of the response message
The method proceeds to step 310, where the registration service 130 sends the formed response to the device of origination. The method then terminates at step 312.
While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
Claims
1. A method for providing application information updates in a response message, comprising:
- receiving, at a registration service, a registration message directly from a device;
- receiving application information updates from one or more third party services related to applications on the device;
- forming, in response to receiving the registration message, a response message comprising at least the application information updates;
- adding the application information updates into the response message, wherein the application information updates comprise updated content from the one or more third party services; and
- sending the formed response message to the device, wherein the response message enables the device to update information in the application.
2. The method of claim 1, wherein the application information updates are embedded into one or more headers of the response message.
3. The method of claim 1, wherein the formed response message to the registration message is an Session Initiation Protocol (SIP) 200 “OK” message.
4. The method of claim 1, wherein the registration service is a VoIP registration service, and wherein the registration message is a Session Initiation Protocol (SIP) REGISTER message.
5. The method of claim 4, wherein the formed response message to the registration message is an SIP 200 “OK” message.
6. The method of claim 5, wherein the application information updates are embedded into one or more headers of the SIP 200 “OK” message.
7. The method of claim 1, further comprising:
- embedding application flag information into the response message, wherein the application flag information comprises flags indicating application information to be updated.
8. An apparatus for providing application information updates in a response message, comprising:
- a registration service configured to:
- receive a registration message directly from a device;
- receive application information updates from one or more third party services related to applications on the device;
- form, in response to receiving the registration message, a response message comprising at least the application information updates;
- add the application information updates into the response message, wherein the application information updates comprise updated content from the one or more third party services; and
- send the formed response message to the device, wherein the response message enables the device to update information in the application.
9. The apparatus of claim 8, wherein the registration service is further configured to embed the application information updates into one or more headers of the response message.
10. The apparatus of claim 8, wherein the registration service is a VoIP registration service, and wherein the registration message is a Session Initiation Protocol (SIP) REGISTER message.
11. The apparatus of claim 10, wherein the registration service is further configured to send a SIP 200 “OK” message as the response message to the registration message.
12. The apparatus of claim 11, wherein the registration service is further configured to embed the application information updates into one or more headers of the response message.
13. The apparatus of claim 8, wherein the registration service is further configured to send a SIP 200 “OK” message as the response message to the registration message.
14. The apparatus of claim 8, wherein the registration service is further configured to embed application flag information into the response message, and wherein the application flag information comprises flags indicating application information to be updated.
| 6490450 | December 3, 2002 | Batni et al. |
| 7424538 | September 9, 2008 | Igarashi et al. |
| 7885925 | February 8, 2011 | Strong |
| 8055255 | November 8, 2011 | Inoue |
| 8082580 | December 20, 2011 | Desai et al. |
| 8249554 | August 21, 2012 | Mack |
| 8505033 | August 6, 2013 | Jonnagadla |
| 20020131395 | September 19, 2002 | Wang |
| 20030018704 | January 23, 2003 | Polychronidis et al. |
| 20050249238 | November 10, 2005 | Haumont |
| 20050272451 | December 8, 2005 | Ho et al. |
| 20070015498 | January 18, 2007 | Giacalone et al. |
| 20070223523 | September 27, 2007 | Montpetit |
| 20080059640 | March 6, 2008 | Oka et al. |
| 20080172486 | July 17, 2008 | Danne |
| 20080267174 | October 30, 2008 | Mahalank et al. |
| 20080301670 | December 4, 2008 | Gouge |
| 20090041058 | February 12, 2009 | Ikeda et al. |
| 20090103524 | April 23, 2009 | Mantripragada et al. |
| 20090106768 | April 23, 2009 | Ramanathan |
| 20090225746 | September 10, 2009 | Jackson |
| 20090296567 | December 3, 2009 | Yasrebi et al. |
| 20090307300 | December 10, 2009 | Guedalia et al. |
| 20090307678 | December 10, 2009 | Wu |
| 20090318124 | December 24, 2009 | Haughn |
| 20100029251 | February 4, 2010 | McConnell et al. |
| 20100177671 | July 15, 2010 | Qiu et al. |
| 20100189094 | July 29, 2010 | Gray et al. |
| 20100217837 | August 26, 2010 | Ansari |
| 20100272250 | October 28, 2010 | Yap et al. |
| 20100275246 | October 28, 2010 | Le Rouzic et al. |
| 20100279662 | November 4, 2010 | Kuusinen et al. |
| 20100290361 | November 18, 2010 | Kim et al. |
| 20100312897 | December 9, 2010 | Allen |
| 20100329243 | December 30, 2010 | Buckley |
| 20110029671 | February 3, 2011 | Deprun |
| 20110128954 | June 2, 2011 | Veenstra et al. |
| 20110138462 | June 9, 2011 | Kim et al. |
| 20110141920 | June 16, 2011 | Yasrebi et al. |
| 20110177793 | July 21, 2011 | Kiiski |
| 20110216759 | September 8, 2011 | Qian et al. |
| 20110283185 | November 17, 2011 | Obasanjo et al. |
| 20110295996 | December 1, 2011 | Qiu et al. |
| 20120002674 | January 5, 2012 | Murakami |
| 20120005276 | January 5, 2012 | Guo |
| 20120005373 | January 5, 2012 | Nitta |
| 20120014381 | January 19, 2012 | Dwyer |
| 20120021727 | January 26, 2012 | Kelly |
| 20120069774 | March 22, 2012 | DuPertuis et al. |
| 20120157098 | June 21, 2012 | Singh et al. |
| 20120213347 | August 23, 2012 | Rosenberg et al. |
| 20120216108 | August 23, 2012 | Yambal et al. |
| 20120263168 | October 18, 2012 | Petrack |
| 20120278457 | November 1, 2012 | Yasrebi et al. |
| 20120314699 | December 13, 2012 | Qiu et al. |
| 20120324061 | December 20, 2012 | Parsons et al. |
| 20130023275 | January 24, 2013 | Mutya et al. |
| 20130024812 | January 24, 2013 | Reeves et al. |
| 20130072150 | March 21, 2013 | Williamson et al. |
| 20130103686 | April 25, 2013 | Sisneros |
| 20130117381 | May 9, 2013 | Garcia et al. |
| 20130132573 | May 23, 2013 | Lindblom |
| 20130139143 | May 30, 2013 | Rauma |
| 20130159377 | June 20, 2013 | Nash |
| 20130159711 | June 20, 2013 | Kaal |
| 20130165185 | June 27, 2013 | Guo et al. |
| 20130177146 | July 11, 2013 | Schneider et al. |
| 20130185445 | July 18, 2013 | Larkin |
| 20130212166 | August 15, 2013 | Willig |
| 20130225145 | August 29, 2013 | Cherian et al. |
| 20130244636 | September 19, 2013 | Shukla et al. |
| 20130314238 | November 28, 2013 | Li et al. |
| 20140254574 | September 11, 2014 | Schreuder |
| 20140379925 | December 25, 2014 | Kang |
| 20150026786 | January 22, 2015 | Alexander |
| 20150043429 | February 12, 2015 | Kim |
| 20150207867 | July 23, 2015 | Igarashi |
| 20150237077 | August 20, 2015 | Suryavanshi |
Type: Grant
Filed: Aug 28, 2014
Date of Patent: Sep 6, 2016
Patent Publication Number: 20140372622
Assignee: Vonage America Inc. (Holmdel, NJ)
Inventor: Tzahi Efrati (Hoboken, NJ)
Primary Examiner: Alina N Boutah
Application Number: 14/471,970
International Classification: G06F 15/16 (20060101); H04L 29/06 (20060101); H04L 29/08 (20060101);
