OA18677A - Asynchronous application data access system and method - Google Patents

Abstract

An asynchronous application data access system and method are provided. In one implementation, the system and method may be used to provide data connectivity to geographie areas with limited bandwidth or connectivity so that those géographie areas will have access to a range of modem applications that use digital data including for example an email application, such as Gmail, a social networking application, such as Facebook, and Linkedln and various other applications. In sorae implementations, an SMS network may be used as one of the variety of transport mechanisms of the system.

Description

ASYNCHRONOUS APPLICATION DATA ACCESS SYSTEM AND METHOD

Axel Starck Olivier Rousseau

Priority Claim/Related Applications

This application daims the benefit under 35 USC 119(e) and priority under 35 USC 120 to U.S. Provisional Patent Application Serial No. 62/072,949 filed on October 30, 2014 and entitled “Asynchronous Application Data Access System And Method”, the entirety of which is incorporated herein by reference.

Fîeld

The discio sure relates generally to a System and method for digital data access using different networks and protocols.

Background

Current wireless 3G and 4G Systems provide a good level of data connectivity to wireless devices, and, typically, in first-world countries, hâve a large amount of backhaul capacity, connecting access points to the larger Internet. Over this infrastructure, applications running on mobile devices typically access a variety of application programing interfaces (APIs) that are provided using known HTTP REST endpoints. In addition, specialized applications using such REST endpoints provide access to a variety of services, including services such as email or social services such as Facebook.

However, in developing countries, backhaul Systems are frequently congested, hâve limited bandwîdth, and are many hops away from servers on the western Internet. Worse, the direct connection to the mobile device is made using older 2 G technology, which offers limited data networking capabilities. Furthermore, even in first-world countries, there may be particular géographie areas in which the same issues of limited bandwîdth or limited data networking capabilities exist. Thus, it is désirable to provide these areas with Internet connectivity and access to a range of modem applications, such as email applications like Gmail and social networking applications, such as Facebook, and Twitter.

' -2Furthermore, even if a first-world country has good bandwidth or good data networking capabilities, a user may be on a limited data plan in which the user can only download a certain amount of digital data during a particular time period, such as a month. It would be désirable to provide a way in which the user could download the digital data and access the applications without always using the allotted data of the limited data plan.

In addition, wireless network operators are continually facing challenges to provide the level and quantity of data access for some fïrst-world countries. In particular, they either cannot build out their network infrastructure quickly enough to keep up with the user demand for data or do not want to expend the resources to build out their network infrastructure. It would be désirable to provide a way in which the network operator can provide the digital data access and access to the applications using other data networking resources.

Brief Description of the Drawings

Figure 1 illustrâtes an example of an implémentation of a system for asynchronous application data access;

Figure 2 illustrâtes more details of the system for asynchronous application data access;

Figure 3 illustrâtes more details of each computing device of the system for asynchronous application data access;

Figure 4 illustrâtes more details of the backend component of the System for asynchronous application data access;

Figure 5 illustrâtes a method for asynchronous application data access;

Figure 6 illustrâtes a screen of a typical computing device;

Figure 7 illustrâtes an example of a home screen for a computing device having asynchronous application data access;

-3Figures 8A and 8B illustrate an example of a weather sub-application data access using the asynchronous application data access;

Figure 9 illustrâtes an example of the SMS received on the computing device for the weather sub-application;

Figure 10 illustrâtes an example of a JSON response to a request for weather data request by the weather sub-application;

Figure 11 illustrâtes an example of a look-up table that may reduce the number of bytes communicated between the backend component and the computing device; and

Figure 12 illustrâtes an example of the compression and uuencoding of an SMS message in the System.

Detailed Description of One or More Embodiments

The disclosure is particularly applicable to a System and method for providing data connectivity to géographie areas with limited bandwidth or connectivity using a 2G network or a short message System (SMS) network (either being a secondary network) and it is in this context that the disclosure will be described. It will be appreciated, however, that the System and method has greater utility, such as to using other communication protocols and/or other data networks to provide data connectivity to géographie areas with limited bandwidth or connectivity. Furthermore, the system and method may be used to provide a way in which the user could download the digital data and access the applications without always using the allotted data of the limited data plan or used to allow a network operator to provide digital data access and access to the applications using other data networking resources.

The advantage of providing data connectivity to géographie areas with limited bandwidth or connectivity is that those géographie areas will hâve access to a range of modem applications that use digital data including for example an email application, such as Gmail, a social networking application, such as Facebook, and or a RS S reader and varions other applications.

-4To address this need, a System and method are provided for provîdîng asynchronous access to the Internet across a variety of transport mechanisms, including SMS in one exemplary embodiment of the System.

Figure 1 shows an example of an implémentation of a System 100 for asynchronous application data access that uses a client server type computer System architecture. The System 100, however, also may be implemented using other architectures or models that are within the scope of the disclosure. For example, the System 100 may be implemented using a cloud computing architecture, a software as a service model as well as other models and architectures.

The System 100 may hâve one or more computing devices 102, such as the smartphone device example shown in Figure 1 and a backend component 106 that may be known as a receiver. Each computing device may couple to and access/interact with the backend component 106 over a communications path 104 that allows each computing device to gain data access to application data over a variety of communication paths 104 using the backend component 106 as described below. Each computing device 102 may be a processor based device that has at least one processor, memory such as DRAM, persistent storage, such as flash memory or a hard disk drive, a display, an input device such as a keyboard, a touchscreen, a mouse, etc. and one or more circuits that allow the computing device to couple to a variety of different communication paths. For example, each computing device 102 may be a smartphone device, such as an Android® operating System based device, a personal computer, a tablet computer or a laptop computer. Furthermore, each computing device 102 may be any other device in which it is désirable to be able to gain data access to application data over a variety of communication paths 104 using the backend component 106 as described below.

Each computing device 102 may hâve a Be-Bound component 108 that interacts with the backend component 106 over the variety of communication paths 104. The Be-Bound component 108 may be implemented in software (as shown in Figures 1-2 and 4) or hardware. When the Be-Bound component 108 is implemented in software, the component 108 may be a plurality of lines of computer code as described below in more detail. When the Be-Bound component 108 is implemented in hardware, the component 108 may be a separate hardware device that couples to the computing device, such as a memory stick, a dongle, etc. to împlement

-5the data access over the variety of communication paths 104 or it may be a circuit/device that is part of the computing device 102, such as an application spécifie integrated circuit, an integrated circuit, a programmed logic device, a microcontroller and the like.

In a software implémentation, each computing device 102 may hâve a Be-Bound application 108 that is the plurality of lines of computer code that may be executed by the processor of the computing device. The Be-Bound application 108 may be stored in the persistent storage or memory of the computing device or it may be downloaded onto the computing device from a remote source. In general, the Be-Bound application 108 may include a plurality of sub-applications with spécifie functionality and the system is used to access data for those sub-applications. Each sub-applicatîon may be any application that requires data access to provide its full functionality. For example, each sub-application may be an email application, an information application such as news application or weather application, a social networking application or a game application. In some embodiments of the system, the Be-Bound application 108 may be used with applications already résident on the computing device or capable of being downloaded to the computing device. Those applications, that may include third party applications, may then use an interface to internet with the core components of the BeBound application.

The backend component 106 may be one or more computing resources that host and house the functional components of the backend component as described below. The one or more computing resources may be one or more server computers (as shown in the example in Figures 1 -4) or one or more cloud computing resources. The one or more computing resources may include one or more processors, memory, persistent storage and communications circuits that host or store or execute the components that make up the backend component 106. The backend component 106 and the components of the backend component 106 may be implemented in software (as shown in Figures 1-2 and 4) or hardware. When the backend component 106 and the components of the backend component 106 are implemented in software, each component may be a plurality of lines of computer code résident in the one or more computing resources and executed by at least one processor of the one or more computing resources. When the components are implemented in hardware, each component may be a

-6separate hardware device such as a memory stick, a dongle, an application spécifie integrated circuit, an integrated circuit, a programmed logic device, a microcontroller and the like. The backend component 106 may also include one or more service content providers that provide the content data that is subsequently sent to each computing device 102. The one or more service content providers may be part of the system 100 or may be third party Systems that may be accessed using APIs.

The communications path 104 between each computing device and the backend component 106 may use a variety of communication protocols and data protocols. For example, the communications path 104 may include a 2G network, a WiFi network, a short messaging system (SMS) network or other non-data networks, a 3G data network, a 4G data network, other higher speed data networks and the like. When the communications path 104 is not a data network, the SMS network (or other non-data networks) may be used in this embodiment. As shown in Figure 1, when a data network is being used, the computing device 102 and the backend component 106 may communicate with each other using the known HTTP or HTTP S protocol. Altematively, as shown in Figure 1, when the SMS network is being used, the computing device 102 and the backend component 106 may communicate with each other using the known Short Message Peer-to-Peer (SMPP) protocol or a short message service center (SMSC) protocol. It is important to note that each computing device 102, when it couples to and interacts with the backend component 106 may use a different communications path 104. For example, computing device A may hâve 3 G data network access and thus use that data network while computing device B may only hâve SMS access and thus use the SMS network.

In the software implémentation of the system, the Be-Bound application 108 communicates to the backend component 106 using SMS or HTTP, dépendent on the type of connection available to each particular computing device. HTTP is used in the case where a high or low bandwidth data connection is available. When there is only an SMS system available, however, SMS may be used and the SMS data may be split and compressed into multiple textual SMS messages which keeping the length as short as possible. The backend component 106 may communicate over HTTP S to a variety of HTTP REST endpoints provided by external service/content providers.

. -7Now, further details of the System are described with référencé to Figures 2-4 that show more details of the System 100. As shown in Figure 2 and in more detail in Figure 3, each computing device 102 may hâve the Be-Bound component 108 that is hosted on, provided to or , executed on the computing device 102. The Be-Bound component 108 may hâve a cote portion 5 200 and an application container 202. Thus, the System utilizes a meta-application paradigm in which the application container 202 résident on the computing device 102 contains a number of sub-applications. The sub-applications may be developed and connected to the Be-Bound System or may be third party applications. In one implémentation, the sub-applications provide functionalîty such as email, Facebook or weather information. The System, however, is not limited to the particular set of applications shown in the figures as the System may be used for any application that requires data access to provide füll functionalîty to the user. Each subapplication may hâve its own user interface with which the user can interact.

The access to the data for each sub-applîcation may be provided by a number of application programming interfaces (API’s) (“Stubs”) typically one per service, although a 15 service can utilîze multiple API's if it needs. Each service may be, for example, a weather service that provides weather data, an email service that provides email data and the like. The stubs may be constructed in a semi-automatic fashion from an IDL-like interface description language. This language describes the input and output format for a particular extemal server exposing a REST API or from a set of components résident in the backend component 106 (internai components).

Based on the compilation of this language for each service, a server stub (résident on the backend component 106) and a corresponding client stub (résident on each computing device 102) may be constructed that allow a particular sub-application on the computing device 102 to receive data from a particular content service provider, This pattern is typical to the construction of conventional RPC service classes using IDL, but has one notable différence. In the conventional 25 RPC case, the IDL defines the interface between the client and server stubs, and the data flowing across the connection. In the system 100, the IDL describes a previously build REST API together with restrictions and contractions of data flowing in and out of it, and the client and server stubs are constructed automatically from the description. The system thus semiautomatically generates a remote interface to the web service, with the appropriate proxying : -8code. However, unlike a true proxy, the system 100 deals with the problem of selectively . transporting éléments of the data from the API across a low bandwidth link whereas a true proxy would simply resend ail the data from the end point.

When the user requests data for one of the sub-applications, e.g.: 'Wcathcr for Paris', â réquest is made to the appropriate API stub. The IDL generated API càll passes the call to the application core 200, which selects an available transport layer (using an available communication pâth) to communicate with the backend component 106 and composes the appropriate message to transport to the remote endpoînt. The message includes an API identifier, which is used by the backend component 106 to route the message to thé appropriate server sidé stub, as well as parameters for the message to pass through to the REST API invocation.

The Transport layer uses data transmission via HTTP S or SMS to communicate with the backend component 106. For HTTPS, the communications path may be a Data mobile network or via Wi-Fi network, while SMS (or another non-data network) may be selected when no data connection is available. If SMS is used, then the SMS messages may be encrypted, compréssed and uuencoded as shown in Figure 3.

Figures 2 and 4 illustrate more details of the backend component 106 of the system. The backend component 106 may hâve a data access component 204 and one or more service content providers 206 that provide the content that is communicated to each computing device. For example, as shown in Figure 4, the one or more service content providers 206 may include an 20 email service content provider 206a, such as Gmail, Yahoo mail, Exchange server and the like, a social network service content provider 206a, such as Facebook, a weather service content provider 206c and other service content providers 206n. Each service content provider may be a third party system that provides an API or it may be a service content system that is part of the backend component 106.

The data access component 204 may further comprise a core component 302 and one or more modules 304, In operation, on the backend component 106, the request message for data from each computing device may be analyzed by the core component 302. If the message is received via SMS, the message may be uudecoded, uncompressed and decrypted by the core

-9component 302. Based on the sub-application identifier embedded in the message (as described above) a corresponding server module 304 may be invoked (e.g.: the Weather module), or an extemal REST API may be called.

The sub-application on the computing device, the server modules 304, and potential extemal REST APTs provide together a service. Each service uses an encoding that is spécifie for this service, and is designed to use minimal bandwidth.

Typically, the modules 304 may fetch the requested data from a related content service provider 206. Depending on the service, the data may be filtered so that only the most important parts remain thus reducing the bandwidth. The System can perform this service in two ways, automatically, for simple cases, as specified by the ISL définition, or manually, in which case the module perforais the filtering/culling. The filtered data, the resuit, may be encoded according to the transport layer used in the request, and transmitted to the meta-application core 302. The core 302 handles the decoding and sends the resuit to the sub-application 202 on the computing device 102 for display.

The backend component 106 may also perform caching and partial response.

Specifîcally, the backend component 106 may cache data received from an extemal content service provider. This information can later be delivered to the sub-application 202 on subséquent calls. For example, a call to the mailbox of a user may retum the email header information of the user’s mailbox. When SMS as a transport is used, not ail the information is sent back in the response to save bandwidth. In such a case, the information is cached on the server and in the response it is indicated to the client that more data is available, leaving it to the user to ask for more data. The backend component 106 may also hâve a pre-populated cache of data objects corresponding to invocations to the API with spécifie parameters so that the above partial response process may be used.

The System described above allows people with no data access or very limited data access on their computing devices 102, such as in certain géographie régions, to use well known popular Internet services. In addition, the System may also be used by a user to reduce his data network usage by routing some of the requests over the SMS network or other non-data network. This

-10may be particularly advantageous for a user who has a limited data access plan. Furthermore, the System may be used by a network carrier to reduce the data bandwidth issues on their network by again routing some of the requests over the SMS network or other non-data network. In both of the latter cases, the user may hâve data network access, but chooses to re-route some of the requests and data that would otherwise travel over the data network. In each case, the system provides a variety of different communication paths over which the data may be accessed.

The System thus has a meta-application, which is a single application containing multiple sub-applications, each of which has a spécifie function. For example, one sub-application might represent data from Facebook to the user, while another sub-application might access weather and another sub-application may access email information. To the user, applications are accessed via an “application container” application.

The system is a communications service that provides remote data access to the subapplications when data access is not otherwise available or being used. The system also is a system and method for encoding API calls made to the communications service into compact messages suitable for transmission across a low-bandwidth link. The APIs and message formats may be generated using a service descriptor, expressed in an IDL like language, which represents the API of an internai server module, or an external REST API server. The system may also compress, encrypt and encode the messages according to the data needed by the API calls expressed using the IDL language.

The system is also a transmission system that selects a transmission media, for example TCP, HTTP, or SMS based on an examination the device’s available transport layer system. A backend component may receive a message from the client system via the transmission media. The backend component may hâve a décoder that décodés, décompresses and decrypts the messages into API calls on a remote system, the remote system having a plurality of API's representing different services or a plurality of Systems having separate API's. The remote System may hâve a set of supporting services accessible via the API calls that perform spécifie fiinctions, and retum data.

-11The backend component may include a System for selectively processing and culling data from the API calls, encoding these pièces of data as a message or sériés of messages a similar for to the outgoing messages, based on information provided by an IDL language. The backend component may then send and delîver the message(s) to each computing device. Each computing device may hâve a System for decoding and mapping the message data to API calls on the computing device.

The System may encode the message(s) into uuencoded base64 messages. An example of such a message is shown in Figure 12. The message(s) may be sent using the SMS protocol. The APIs on the backend component may be HTTP REST APIs. The System may hâve a prepopulated cache of data objects corresponding to invocations to the API with spécifie parameters. The data objects may be commonly used web format objects, such as PNG or JPG images. The backend component may hâve a purchasing component in which each transmitted messages has a “crédit cost” which is débited from an account of the user on the backend component maintained balance of crédits, crédits being purchased by the user as needed.

Figure 5 illustrâtes a method 500 for asynchronous application data access using the BeBound application 108 résident on a computing device, the backend component 108 and, when exchanging SMS messages, a short message service center (SMSC) 502. The method may involve a request for data access 1 so that an SMS message (MO SMS) is communicated from the computing device to the SMSC 502 that contains the data access request. An example of request may be a request for weather data, examples of which are shown in Figures 7-10. The SMSC may then send an SMS message (using SMPP protocol) to the backend components 106. The backend components 106 may then sent a web request to the relevant content provider for the particular data access request, such as a weather service for a weather data request or a mail System for an email data access request. The request is processed and a web response is generated (an example of which is shown in Figure 10). The processing of the web response may include filtering, etc. (as shown in Figure 10) and/or a look up table (as shown in Figure 11 in which the look up table allows a number to be sent for a weather sub-application instead of the textual weather descriptions that would require more bits) to reduce the data to be sent back to

-12the computing device that made the data access request. Then, an SMS message (MT SMS) is sent back to the SMSC with the response and the SMS message with the response is passed back to the computing device. An example of that SMS message is shown in Figure 9.

Figure 6 illustrâtes a screen of a typical computing device when that computing device does not hâve digital data access. As shown, the application, such as a browser, that requires data access is unable to operate. However, as shown in Figure 7, even when no digital data access is available, the user is able to use the sub-applications to access data over the non-digital data access network as described above. Figures 8A and 8B illustrate an example of a weather sub-application data access using the asynchronous application data access. In particular, Figure 8 A shows a user interface of a weather sub-application when the data access request is being made while Figure 8B shows the user interface after the weather sub-application has received the data.

For the request and data being communicated over the SMS network, the System may encrypt the messages using both Elliptic Curve Cryptograhy (ECC) and symmetric cryptography (AES). These standards encryption algorithms are customized to the constraints of using only 140 bytes in SMS and to avoid adding too much overhead. For tire encryption, when the user registers for the first time to the application, ECC is used to define symmetric keys between the application and the backend component 106. The trade-off between security and extra payload results in the use of 256 bit keys. Then, these keys are used for AES communications between the application and the backend component 106. To increase security but avoid adding too much overhead, keys are renewed each time an internet connection is available. A ratchet algorithm may be used to renew keys and will be integrated and adjusted with the sequence numbering of the BE-BOUND SMS format.

While the foregoing has been with reference to a particular embodiment of the invention, it will be appreciated by those skilled in the art that changes in this embodiment may be made without departing from the principles and spirit of the disclosure, the scope of which is defined by the appended daims.

Claims (31)

1. An apparatus, comprising:

a receiver component that receives a request for digital content over a secondary network comprising one of a short message System (SMS) network and a 2G network;

the receiver generating a request for digital content from a remote source by translating the request for data received over the secondary network; and the receiver receiving the requested digital content from the remote source based on the request and converting the requested digital content from the remote source into a response transmitted over the secondary network so that a device that uses the secondary network is able to access the digital content.

2. The apparatus of claim 1, wherein the secondary network further comprises a short message System (SMS) network and a 2G network.

3. The apparatus of claim 1 further comprising a computing device that sends the request for data over the secondary network, the computing device having a meta-application that has a plurality of sub-applications to be accessed by the computing device over the secondary network.

4. The apparatus of claim 1, wherein the receiver further comprises an encoder component that encodes an application programming interface (API) call into a message compatible with the secondary network.

5. The apparatus of claim 4, wherein the message is encoded into a uuencoded base64 message.

6. The apparatus of claim 4, wherein the encoder generates the API call and message using a service descriptor.

7. The apparatus of claim 1, wherein the receiver compresses and encrypts the response.

8. The apparatus of claim 1, wherein the receiver selects a secondary network based on a transport layer System of a computing device that made the request.

9 The apparatus of claim 1, wherein the receiver further comprises a décoder component that décodés, décompresses and decrypts the response into a call to a remote server for the content.

10. The apparatus of claim 9, wherein the call to a remote server is an HTTP REST APL

11. The apparatus of claim 1, wherein the receiver has a cache of data objects wherein each data object corresponds to an API call with one or more spécifie parameters.

12. The apparatus of claim 11, wherein the data objects is one of a PNG image and a JPG image.

13. A client, comprising:

a computing device having a processor that executes a client application;

the client application generating a request for digital content in a message and sending the message over a secondary network to a backend component, the secondary network comprising one of a short message System (SMS) network and a 2G network; and the client application receiving a message over the secondary network with the requested digital content from the backend component, the client application converting the message over the secondary network into the requested digital content.

14. The client of claim 13 wherein the client application décodés and maps the message to application programming interface (API) calls.

15. The client of claim 13, wherein the message is encoded into a uuencoded base64 message.

16. The client of claim 13, wherein the secondary network is a short message system (SMS) network.

. : -15-

17. The client of claim 13, wherein each message has a crédit cost that is debited from a crédit balance.

18. A method for data exchange using a backend System and a computing device capable of communicating over a secondary network, the method comprising:

generating, by a computing device, a request for digital content message;

transmitting the request for digital content message over a secondary network to a backend System, the secondary network comprising one of a short message System (SMS) network and a 2G network;

generating, at the backend System, a request for digital content from a remote source by transi ating the request for digital content message received over the secondary network;

receiving, by the backend System, the requested digital content from the remote source;

converting, by the backend System, the requested digital content into a message sent over the secondary network back to the computing device so that the computing device that uses the secondary network is able to access the digital content.

19. The method of claim 18, wherein the secondary network further comprises a short message System (SMS) network and a 2G network.

20. The method of claim 18, wherein converting the requested digital content into a message sent over the secondary network further comprises encoding an application programming interface (API) call into a message compatible with the secondary network.

21. The method of claim 20, wherein the message is encoded into a uuencoded base64 message.

22. The method of claim 21, wherein encoding further comprises generating the API call and message using a service descriptor.

23. The method of claim 18, wherein encoding further comprises compressing and encrypting the message.

24. The method of claim 18 further comprising selecting, by the backend system, a secondary network based on a transport layer System of a computing device that made the request.

25. The method of claim 18, wherein generating the request for digital content further comprises decoding, decompressing and decrypting the message into a call to a remote server for the content.

26. The method of claim 25, wherein the call to a remote server is an HTTP REST APL

27. The method of claim 18 further comprising caching, in a cache of data objects in the backend System, one or more data objects wherein each data object corresponds to an API call with one or more spécifie parameters.

28. The method of claim 27, wherein the data objects is one of a PNG image and a JPG image.

29. The apparatus of claim 1, wherein the secondary network is SMS and wherein the requested digital content is split and compressed into a plurality of textual SMS messages transmitted over the secondary network.

30. The client of claim 13, wherein the client application receives a plurality of textual SMS messages over the secondary network, wherein the plurality of textual SMS messages comprises the requested digital content split and compressed into the plurality of textual SMS messages.

31. The method of claim 18, wherein converting the requested digital content further comprising splitting and compressing the requested digital content into a plurality of textual SMS messages transmitted over the secondary network.