System architecture for accessing secure data from a mobile device in communication with a remote server

Systems, methods, and computer-readable storage devices to enable secured data access from a mobile device executing a native mobile application that operates in connection with a server executing a headless browser are disclosed.

BACKGROUND

As mobile devices become commonplace, users elect to perform more and more day-to-day tasks using mobile devices. For example, users may use mobile devices to work on projects that were typically reserved for desktop or laptop computers, such as editing documents and spreadsheets, creating drawings or graphic designs, generating multimedia content, etc. For a mobile device to perform certain tasks, the mobile device may need access to secured user data. However, due to security considerations and pre-existing back-end systems, providing mobile devices access to such secured user data may be challenging.

To illustrate, one day-to-day task in which mobile devices may be used is mobile banking. Increasingly, banking customers prefer to use a mobile device application to manage their money. As a result, banks are deploying mobile banking applications. For small and mid-size banks, it may be prohibitively expensive to develop a customized and full-featured mobile banking application (e.g., via in-house development or by hiring a third party development team), including setting up back-end security features and data integrations that enable such an application to access secured data, such as pre-existing account data, data stored in data warehouses, etc. To provide mobile banking for small and mid-size banks, some vendors use account aggregation, which involves storing user credentials for a bank on an intermediary server and then accessing the bank via the intermediary server. However, the account aggregation approach does not function properly if the bank blocks such accesses from third-party servers for security reasons. To illustrate, if the bank is able to identify multiple accesses coming from the same internet protocol address, the bank may block all accesses from the internet protocol address, thereby preventing the account aggregation technique from functioning. Storing user access credentials on intermediary servers (e.g., in the cloud) can also be a security risk. Additionally, processing power and battery life of some mobile devices can lead to challenges in creating mobile banking applications. For example, some devices, such as computerized watches, may lack sufficient processing resources and battery power to support a full-featured mobile banking application.

DETAILED DESCRIPTION

The present disclosure enables read and write access to secured data by a mobile device that executes a “native” mobile application (alternatively referred to herein as a “mobile app”) and that is supported by a back-end server executing a “headless” browser. As used herein, a “native” mobile app is an application that is designed and coded for a specific device platform, such as for a specific mobile device operating system. Because native apps are created for a specific platform, native apps typically have the same “look and feel” as the underlying operating system and provide more reliable and faster performance than non-native apps. Native apps may also have access to device functionality that is unavailable to non-native apps. In addition, many mobile platform vendors offer storefronts from which users can download native apps. To encourage native app development, platform vendors often offer standardized software development kits (SDKs).

As used herein, a “headless browser” is an instance of a web browser that is executed by a device without display of a graphical user interface (GUI). Thus, while the headless browser may be used to send and receive web data (e.g., via hypertext transfer protocol (HTTP) GET commands, POST commands, etc.), the headless browser itself may not display such web data. Instead, as further described herein, a headless browser may serve as a web access mechanism for a native app on a mobile device.

In particular aspects, the systems and methods of the present disclosure enable a mobile device and one or more back-end servers to access secured data, such as bank account data, without requiring a provider of the data (e.g., a bank) to implement a technology integration between a mobile solutions provider (e.g., a developer or vendor of a mobile app) and an internet banking software/website provider. Such integrations, which may involve establishing security protocols, data encryption, standards-compliant application programming interfaces (APIs), and/or coordination between different vendors while maintaining compatibility with legacy banking systems, can be complex and expensive. Although various aspects are described herein in the context of banking and financial operations, such descriptions are for illustration only and are not to be considered limiting. The techniques of the present disclosure may additionally or alternatively be used to enable mobile device access to secured data other than banking/financial data, such as healthcare data, enterprise data, etc.

In accordance with the described techniques, a mobile device and a server may work in tandem to access secured data from a remote server, such as a remote banking server. To illustrate, a mobile device may utilize a native application to provide mobile banking functionality. In a particular implementation, the native application communicates with a server (e.g., a back-end server) via a secure connection to enable the server to access a website hosted by a remote server (e.g., a remote banking server) and to appear as though only the mobile device is accessing the remote server. For example, the mobile device may host a configurable network service that is configured to act as an intermediary between the server and the remote server, such as by receiving messages or commands (e.g., HTTP GET and HTTP POST commands, as non-limiting examples) from the server and providing the messages or commands to the remote server after modifying the messages or commands such that the messages or commands appear to have originated at the mobile device. In this manner, the remote server may be unaware of the operation of the back-end server, and thus may allow the messages to proceed unblocked.

To further illustrate, the server (e.g., the back-end server) may execute a headless browser that communicates over a secure connection (e.g., an encrypted network tunnel) with the configurable network service. The server may receive requests or commands from the mobile device executing the native application. For example, the native application may generate a request to logon to the website based on user input, and the request is sent from the mobile device to the server. The server may instantiate a headless browser and inject application programming interface (API) fingerprint data based on the website into the headless browser. The API fingerprint data may indicate service pathways and other elements that map elements of the native application to elements of the website. For example, the API fingerprint data may indicate service pathways and elements associated with a logon to the website. The server may utilize the headless browser to send a request to logon to the website by sending the request to the configurable network service of the mobile device. The configurable network service receives the request and modifies the request such that the request appears to originate at the mobile device before sending the request to the remote server (e.g., a third-party server, such as a remote banking server). When the mobile device receives a response to the request, the configurable network resource forwards the response to the server (e.g., the back-end server) for processing via the headless browser. After processing the response, the server sends information to the native application at the mobile device that the logon is complete. In this manner, the server (e.g., the back-end server) operates “through” the configurable network resource of the mobile device to access the website. Because the access appears to come from the mobile device (e.g., from a customer of the bank that operates the remote server), the bank is not likely to block the mobile device for security reasons, as compared to blocking the back-end server if the back-end server attempted to access the website directly.

In this manner, the native mobile application at the mobile device may communicate with the back-end server to enable access to secured data and to enable various features associated with a website, such as an internet banking website. For a native mobile banking application, the native application may enable features such as account balance reporting, viewing transaction history per account, transferring funds between accounts, performing remote check deposits, paying bills, etc. In some examples, the native mobile banking application may have an API to enable integration with (and thereby enable access to) other software and functionality, such as software for peer-to-peer funds transfers, contact-less automated teller machine (ATM) authentication, loan applications, etc.

In some aspects, an API may link the native app at the mobile device to the headless browser at the back-end server to provide a consistent way of implementing customer-facing features and reading/writing data between the native app and servers (e.g., servers associated with a provider of the native app, third party servers, servers hosting an internet banking website, etc.). The native mobile app, the headless browser, and the API may create a personalized data integration, such as for a particular user's bank account, directly from the app.

In some aspects, user access credentials and other access data (such as personal identification numbers (PINs), multi-factor authentication codes, etc.) may be input into the native app and then passed to the headless browser by way of an embedded API. This API may include: (1) a common set of functions and data for user authentication or account information, which may be standardized across financial institutions; and (2) the specific website for the financial institution, including specific page layout, hypertext markup language (HTML), cascading style sheets (CSS), and/or JavaScript content that would typically be interpreted by a personal computer (e.g., non-mobile) browser and presented to a user as an internet banking website. The API may be based on API fingerprint data that is embedded (e.g., injected) into the headless browser to enable the headless browser to pass user interactions and data back and forth with the website (or the remote server hosting the website) via the mobile device (e.g., via the configurable network resource executed at the mobile device). Thus, the headless browser at the back-end server may be used to emulate operations performed by a non-headless browser on a desktop or laptop computer or by a non-headless mobile browser directly accessing the website.

In some examples, the API fingerprint data may be configured on a per-app basis so that mappings between banking features in the native app and their corresponding internet banking elements on the website may be established, such as via screen-scraping. Thus, the techniques of the present disclosure may enable an embedded API to be configured for each version of internet banking services/websites to reach a large population of bank users. Configuring embedded APIs in this manner may be simpler than building custom native apps and integrations for each financial institution, because there may only be a few dozen versions of internet banking services/website, whereas there are over 14,000 financial institutions in the United States alone. The systems and methods described herein may provide a technique for end-users to securely and efficiently access internet banking capabilities via a native mobile banking app while leveraging a secure real-time connection to internet banking rather than requiring access to a dedicated, expensive, or limited integration specific to the app. Moreover, the present disclosure may enable operations to be off-loaded from the mobile device to a server, which may reduce processing resources used by the mobile device in executing the native mobile app, which may reduce power consumption at the mobile device.

Although aspects of the present disclosure are described in the context of mobile banking, such description is not limiting. In other implementations, the systems and methods described herein enable access to any type of secured data. As a particular example, aspects of the present disclosure may enable a mobile device and back-end server to access secured data with an online merchant, such as an online retailer. The secured data may include account balances, order histories, current orders, or other information. As another particular example, aspects of the present disclosure may enable a mobile device and back-end server to access secured data on a private network, such as an employer's private network. Thus, aspects of the present disclosure enable access to multiple types of secure data.

Referring toFIG. 1, an illustrative aspect of a system is shown and generally designated100. The system100includes a mobile device110, such as a mobile phone, a tablet computer, a personal digital assistant, a wearable computing device, a portable media player, a computing device of a vehicle, etc. The mobile device110includes a memory that stores processor-executable instructions and data corresponding to one or more applications (“apps”). For example, the mobile device110may include a native app112. The mobile device110also includes a processor configured to execute the processor executable instructions. The mobile device110also includes a wireless transceiver configured to communicate with one or more other devices.

In some examples, as further described herein, the native app112may be a “branded” version of a mobile banking application that is specific to a financial institution, such as a specific bank or a specific credit union. In a particular aspect, a user of the mobile device110may download the native app112from an app storefront. In some examples, the native app112may be generated based on a generic native app template by adding branding components, such as names, logos, color schemes, typeface schemes, etc. For mobile banking, the native app112may be configured to perform banking operations such as an account balance operation, a fund transfer operation, a credit card payment operation, a deposit operation, a withdrawal operation, a bill pay operation, a transaction history operation, etc.

The system100includes a back-end server120. The back-end server120(which may correspond to multiple back-end servers in alternative examples) is configured to interact with the mobile device110to support the native app112. For example, the back-end server120may execute a headless browser122that provides back-end integration and supports functionality for the native app112, as further described herein. To further illustrate, information generated by the headless browser122may be passed from the back-end server120to the mobile device110for transmission to another device, as further described herein. The headless browser122does not include a GUI displayed to a user, although the native app112may have a GUI113displayed to a user. The back-end server120includes a processor and a memory that stores processor-executable instructions to perform one or more of the operations described herein. The back-end server120also includes a transceiver configured to communicate with one or more devices, such as the mobile device110or a third-party server, via one or more networks, such as the Internet.

The system100also includes a web server130located remote to the mobile device110. The web server130(which may correspond to multiple web servers in alternative examples) may be configured to host a website132. In particular examples, the website132may be an internet banking website. In some aspects, the website132may be a “desktop” version of an internet banking website. To illustrate, the website132may deliver content that is formatted for presentation on a desktop or laptop computer, rather than a mobile version of such content that is formatted for presentation on a mobile device. Thus, in some aspects, the website132may typically be used by users at computers, such as an illustrative computer150, to log in to their financial institution and perform internet banking functions. In other aspects, the website132may have content formatted for presentation on a mobile browser. The website132may enable a user of the computer150to access secured data140, such as information regarding bank accounts. As another example, the website132may enable a user of the computer150to view account balances, transaction histories, and credit card information. As yet another example, the website132may enable a user of the computer150to transfer funds between accounts.

During operation, the mobile device110and the back-end server120may work together to use the website132to access the secured data140, even if the website132includes content that is not formatted for mobile devices. To illustrate, the native app112may launch a configurable network service115to enable communications between the back-end server120and the website132(or the web server130). The configurable network service115is configurable to receive information or user interactions from the mobile device110and to pass the information or user interactions to the web server130while modifying the information or user interactions to appear as though they originated at the mobile device110. For example, a header of a message may be modified to indicate the mobile device110as the originator of the message instead of the back-end server120. To illustrate, an IP address or other identifying information associated with the back-end server120may be replaced with an IP address or other identifying information associated with the mobile device110. Thus, the configurable network service115may provide anonymity to the back-end server120. The configurable network service115also receives responses or data from the web server130and forwards the responses or data to the back-end server120, as further described herein.

The native app112is configured to launch the configurable network service115upon startup (e.g., execution). After initializing the configurable network service115, the native app112generates registration data124as part of a registration process with the back-end server120. The registration data124indicates an application identifier (e.g., a unique app ID) associated with the native app112. The registration data124also indicates address data associated with the configurable network service115. For example, the registration data124may indicate an internet protocol (IP) address and port assigned to the configurable network service115. The mobile device110sends the registration data124to the back-end server120to register the native app112with the back-end server120. In some implementations, the registration data124includes credential data that indicates one or more credentials (e.g., a username, a password, etc.) that enable secure access to the configurable network service115. The credential data may be used to authenticate the back-end server120(or other associated back-end servers) during setup of a secure connection between the back-end server120and the configurable network service115. Other devices lack the credential data and are unable to connect to the configurable network service115. In a particular implementation, the credential data indicates a randomly generated combination of random strings that are passed to the back-end server120as part of the registration data124. In other implementations, the registration data124does not include the credential data and other methods are used to authenticate devices that attempt to establish a connection with the configurable network service115. As a non-limiting example, a secure handshaking protocol may be used to authenticate the back-end server120during setup of a secure connection with the configurable network service115.

The back-end server120is configured to use the registration data124to launch the headless browser122. For example, the back-end server120may instantiate an instance of the headless browser122based on the registration data124. To illustrate, the back-end server120may instantiate the headless browser122and may associate the headless browser122and relevant information, such as cookies, caches, and the address information with the application identifier. By using the application identifier to associate the headless browser122with the other information, the back-end server120is enabled to associate the headless browser122with the mobile device110without storing any personal or identifiable information about a user of the mobile device110. For example, the registration data124(including the optional credential data) is distinct from access credential data, such as a username and password, used to access the website132. Storing such personal information may require heightened security, in accordance with one or more regulations or other rules.

The back-end server120initiates a secure connection between the headless browser122and the configurable network service115based on the registration data. For example, the back-end server120may initiate a secure connection between an IP address and port at the back-end server and the IP address and port corresponding to the configurable network service115(and indicated by the registration data124). In a particular implementation, the secure connection is an encrypted network tunnel. To illustrate, the encrypted network tunnel may be created using the secure shell (ssh) protocol, thereby encrypting the network tunnel (e.g., by use of ssh). The secure connection is initiated upon the back-end server120receiving a first request from the native app112. The secure connection may be initialized using the registration data124(e.g., the credential data) to provide security (e.g., to prevent unauthorized devices from accessing the configurable network service115). Once the secure connection is established, the secure connection remains configured to use the configurable network service115until the native app112is closed, at which time the secure connection is “torn down” (e.g., disabled). In a particular implementation, upon change of the IP address or port associated with the mobile device110and the configurable network service115, the native app112updates the registration data124, and the secure connection is reconfigured based on the updated registration data124.

When a user of the mobile device110interacts with the native app112, the native app112may issue a request125. For example, a user of the mobile device110may attempt to login to the user's bank using the native app112. The native app112may generate the request125for logging on to the website132. Although a request for login is described, the request125may be any type of request, such as a request for data from a particular webpage or a request for a command to be performed, such as a request to perform a transaction (e.g., a bill-pay request, a funds-transfer request, etc.).

In a particular implementation, the request is a request to login to the website132. In this implementation, the request125includes access credential data114. To illustrate, the native app112may send a username and password of the user to the back-end server120. In some examples, the access credential data114is received via a user input device of the mobile device110, such as a touchscreen. Alternatively, the access credential data114may be retrieved from a memory of the mobile device110.

The request125is sent from the mobile device110to the back-end server120. The back-end server120receives the request125and the headless browser122generates a second request126based on the request125. For example, the headless browser122may generate a request for information or may initiate performance of a requested command. To illustrate, the back-end server120may use the headless browser122to emulate a request to login to the website132from a non-headless browser, such as a browser of a computer (e.g., the computer150) in the case of a desktop internet banking website, or a browser of the mobile device110in the case of a mobile internet banking website. The second request126includes a first header127that indicates the back-end server120is the originator of the second request126. As described above, in a particular implementation, the second request126is a request to login to the website132. In this implementation, the second request126indicates the access credential data114. To illustrate, the request125from the native app112may cause the headless browser122to request a login page of the website132and send the username and password to the website132, such as by using HTTP GET/POST commands or other commands. The access credential data114(e.g., the username and password) is only used to generate the second request126and afterwards is discarded. In a particular implementation, the access credential data114is not stored at the back-end server120. This may improve security of the user, because the access credential data114is not stored and therefore is not possible to be retrieved by a malicious intruder. In alternate implementations, the back-end server120implements a secure storage, in accordance with one or more guidelines or regulations, and the access credential data114is stored at the back-end server120.

The headless browser122may access application programming interface (API) fingerprint data121to generate the second request126. The API fingerprint data121includes data that indicates a mapping between the website132and the native app112. For example, the API fingerprint data for the website132indicates mappings between features of the website132and one or more elements (buttons, fields, screens) of the GUI113of the native app112. As an illustrative example, the API fingerprint data121indicates a mapping between the website132and the native app112for a username, a password, a login button, or a combination thereof. The API fingerprint data121may also identify the address (e.g., a uniform resource locator (URL) address) of the website132or a particular page of the website132, such as a login page. The API fingerprint data121also may include a “fingerprint” of the internet banking service pathways used for a user to log in, authenticate, and take other actions possible with internet banking. To further illustrate, the API fingerprint data121may indicate service pathways used during a multi-factor authentication, if such authentication is used to enable access to the website132. The API fingerprint data121may be used to form an “embedded” (or “injected”) API between the native app112(through the headless browser122) and the website132(e.g., even though there is no actual API between the native app112and the website132). For example, the API fingerprint data121enables the native app112to communicate, through the headless browser122, with the website132as though the native app112was designed for use with the website132.

In some implementations, a database of API fingerprint data (including the API fingerprint data121) is accessible to the back-end server120, and the back-end server120retrieves particular API fingerprint data based on an identifier associated with the website132, such as a name (or partial name) of a financial institution or an address of the website132, as non-limiting examples. Alternatively, the back-end server120may be configured to generate the API fingerprint data121by performing one or more screen scraping operations, one or more Javascript injection operations, one or more operations in accordance with another programming language, one or more document object model (DOM) inspection operations, or a combination thereof, on data that is retrieved from the website132. The data may be retrieved from the website132, as further described herein.

After generating the second request126, the back-end server120sends the second request126to the configurable network service115of the mobile device110for transmission to the web server130. The second request126corresponds to the website132. As a particular example, the second request126may include a request to login to the website132. However, instead of sending the second request126directly to the web server130, the back-end server120sends the second request126to the mobile device110(e.g., to the configurable network service115). For example, the back-end server120may send the second request126via the secure connection between the headless browser122and the configurable network service115.

The mobile device110receives the second request126(e.g., a first data packet) from the back-end server120. The mobile device110modifies the second request126to generate a third request136(e.g., a modified first data packet). For example, the configurable network service115may modify the first header127to generate a second header137of the third request136. The second header137indicates the mobile device110as the originator of the third request136. To further illustrate, the configurable network service115modifies the first header127to remove any address (e.g., IP address) or identifying information associated with the back-end server120and replace such information with an address of the mobile device110(or other identifying information).

The mobile device110initiates formation of a secure connection from the configurable network service115to the website132. In a particular implementation, the secure connection is a secure sockets layer (SSL) connection. After forming the secure connection, the mobile device110sends the third request136to the website132.

The web server130receives the third request136and processes the third request136. In a particular implementation, the third request136is a request to login to the website132and indicates the access credential data114. The web server130may receive the access credential data114from the native app112for verification. To illustrate, the web server130may include software configured to compare the access credential data114to previously-stored access credential data. Alternatively, the web server130may forward the access credential data114to an authentication server. In some specific implementations the access credential data is stored in the device secure element (keychain or key store) and sent to the web server for a brief period to proceed with the logon operation. After the access credential data114is verified, the web server130may transmit web page data134to the configurable network service115. For example, the web page data134may correspond to the web page of the website132that would be sent to the computer150after a user of the computer150completed a login process of the website132. Thus, the web page data134may include user-specific data, such as the user's name, the user's account number(s), account balance(s), and/or other information corresponding to one or more of the user's checking accounts, savings accounts, credit card accounts, money market accounts, loan accounts, investment accounts, etc.

The configurable network service115receives the web page data134and forwards the web page data134to the back-end server120for parsing by the headless browser122. For example, the configurable network service115may send the web page data134to the headless browser122via the secured connection. The back-end server120receives the web page data134from the mobile device110(e.g., from the configurable network service115) and processes the web page data134. For example, the back-end server120, using the headless browser122, may parse the web page data134to identify user-specific data. To further illustrate, the back-end server120may include a parsing and mapping component123that is configured to parse web page data to identify user-specific data and to identify elements to be mapped to the native app112. For example, the parsing and mapping component123may perform screen scraping or web scraping operations on the web page data134to identify user-specific data, such as the user's name, the user's account number(s), account balance(s), or other information. In some examples, the headless browser may access mappings (e.g., the API fingerprint data121) between various web pages and features of the website132and corresponding GUI elements (e.g., fields, buttons, screens, etc.) of the native app112. To illustrate, such mappings may be determined using a screen-scraping operation. Thus, different versions of the native app112may be deployed for different financial institutions, different internet banking websites or services, etc. Although illustrated as external to the headless browser122, the parsing and mapping component123may use the headless browser122to perform operations, such as screen scraping operations, web scraping operations, or Javascript injection operations, as non-limiting examples. Thus, the parsing and mapping component123may be internal to the headless browser122, in some implementations.

After identifying the user-specific information, the back-end server120sends the user-specific information to the native app112for display in the GUI113of the native app112. For example, the GUI113may display the user's name, the user's account number(s), account balance(s), or other information. In this manner, the mobile device110and the back-end server120are able to provide mobile banking functionality at the mobile device110via the native app112. Although a login operation has been described, other types of operations may proceed in a similar manner. For example, responsive to receiving a command to perform a transaction (e.g., to pay a bill, to transfer funds, etc.), the native app112sends transaction data to the headless browser122at the back-end server120. The headless browser122sends the transaction data to the configurable network service115for transmission to the web server130. Prior to sending the transaction data, the configurable web server modifies the transaction data such that the transaction data appears to originate from the mobile device110. After the modification, the configurable network service115at the mobile device110sends the transaction data to the website132for processing. If additional web page data (e.g., a confirmation) is received in response to sending the transaction data, the configurable network service115passes the addition web page data to the headless browser122at the back-end server120for parsing, and any user-specific data (or other displayable data) is provided from the back-end server120to the native app112for display via the GUI113. Thus, the native app112is able to support various online banking functionality by working together with the back-end server120.

During operation of the headless browser122at the back-end server120, persistent state data129may be generated. The persistent state data129includes one or more cookies associated with a logon to the website132. The persistent state data129may also include caches (or other temporarily stored data), such as user transaction data, images, and/or metadata. This information may be stored in a database when the native app112is closed such that the next time the native app112is launched, the information may be retrieved and loaded into the session of the headless browser122to avoid a login process (which may include multi-factor authentication) or to avoid the multi-factor authentication on login (since after the first login, the mobile device110will be a known device for a given user) with the website132. For example, the back-end server120may receive, from the mobile device110, an indication that the native app112is closed. Responsive to the receiving the indication, the back-end server120stores the persistent state data129in a browser state database128. In a particular implementation, the browser state database128is external to and accessible to the back-end server120. In other implementations, the browser state database128is stored at the back-end server120. In some implementations, the data stored in the browser state database128is encrypted prior to storage.

The stored persistent state data129may be used when the native app112is launched again. For example, when the native app112is launched, the native app112sends the registration data124to the back-end server120. After receiving the registration data124, the back-end server120accesses the browser state database128to determine whether persistent state information is found for a particular application identifier associated with the native app112(and indicated by the registration data124). Responsive to the persistent state data129being found (e.g., responsive to a match between the application ID indicated by the registration data124and an application ID associated with the persistent state data129), the persistent state data129is retrieved and loaded into the instance of the headless browser122. Because the persistent state data129includes one or more cookies associated with a logon to the website132, the persistent state data129enables the headless browser122to connect (via the configurable network service115) to the website132without having to perform an authentication process, which may include a multi-factor authentication process, or a multi-factor authentication process after a first login may be skipped because, after the first successful login, the mobile device110is a known device for a given user. For example, a user may be logged out of the website132after a particular time period (e.g., 10 to 15 minutes) of inactivity, and upon logging back in to the website132, the user may skip a multi-factor authentication because the headless browser122uses the cookie(s) to cause re-authentication of the mobile device110by the web server130. Additionally, if there are multiple back-end servers, a headless browser session can be recreated on a different back-end server at a later time through use of the persistent state data129.

In an alternate implementation, the persistent state data129is stored at the mobile device110. For example, the back-end server120sends the persistent state data129to the mobile device110after receiving the indication that the native app112is to be closed, and the mobile device110stores the persistent state data129at a memory. In this alternate implementation, the mobile device110may provide the persistent state data129to the back-end server120the next time the native app112is launched.

It will be appreciated that by emulating a computer login to the website132and displaying user-specific information in the GUI113, the native app112(interacting with the headless browser122at the back-end server120) may enable read access to the secured data140by a user of the mobile device110. The techniques of the present disclosure are not limited to read-only access. For example, during operation of the native app112, the native app112may receive a user command, such as a command to transfer funds between two accounts, as an illustrative non-limiting example. In response, based on information from the native app112, the headless browser122sends transaction data to the configurable network service115for transmission to the website132via a secured connection, where the transaction data indicates a modification to be made to the secured data140. For example, the transaction data may correspond to HTTP command(s) that would be issued by the computer150when requesting a funds transfer operation on the website132. Thus, from the perspective of the website132, there is no difference between transaction data originating from a computer and the transaction data sent by the configurable network service115at the mobile device110. Upon receiving the transaction data, the web server130may take action to modify the secured data140(e.g., may initiate the funds transfer operation). After the modification to the secured data140is performed, the website132may transmit a transaction confirmation to the mobile device110to confirm the modification to the secured data140(e.g., completion of the funds transfer operation), and the transaction confirmation may be provided to the back-end server, processed by the back-end server, and optionally sent to the mobile device110for display in the GUI113of the native app112. The new balances of the user's accounts may also be displayed in the GUI113the next time the native app112(in combination with the back-end server120) performs a read operation on the secured data140.

In some examples, the native app112may enable access to additional software and functionality that is not typically available via the internet banking website132. For example, the native app112may include separate capabilities or integrations to interact with other software and the underlying hardware of the mobile device110, or with third party service(s) or device(s) via hardware/software interfaces on the mobile device110. To illustrate, the native app112may have an integration with an automated teller machine (ATM) software provider or network and may utilize a short-range wireless transceiver of the mobile device110to perform contactless authentication with an ATM.

As another example, the native app112may access the internet via a secure network connection and may interact with an external service, such as a peer-to-peer fund transfer service, directly rather than relying on an API to communicate with the internet banking website132. To illustrate, consider two users that have native apps on their mobile devices, where the native apps operate in accordance with the present disclosure. The native apps may be for the same financial institution or may be for (and thus including branding associated with) different financial institutions. Each user may interact with the native app on their mobile device, where the native app is integrated with a third party peer-to-peer fund transfer service (although the peer-to-peer fund transfer service does not have an integration with the bank(s)). The native apps may have access to each user's account information, such as clearinghouse/routing and/or debit/credit card information. For example, such information may previously have been provided by the users or may have been determined from using a headless browser to interact with the banking websites of the bank(s). This information and the native apps may be used to facilitate transfer of money by way of the third party peer-to-peer service. In some aspects, having the two mobile devices in close proximity may be used for a secure and local discovery option in lieu of requiring entry of account information. To illustrate, for mobile devices in close proximity that are executing their respective native mobile banking apps, authentication may be automatic. If the mobile devices are not executing the apps, the apps may nonetheless “discover” each other via a device feature or service, global positioning system (GPS), short-range wireless networking, application-level handshaking, etc. To illustrate, the native app may request the mobile device to “show all users that are have compatible mobile banking apps in discovery mode, have registered with a third party server in the last thirty seconds, and have GPS coordinates within one meter of me”).

The system100ofFIG. 1may thus enable read and write access to the secured data140by the native app112without requiring a dedicated back-end integration between the native app112and legacy banking systems. Because some operations (e.g., operations of the headless browser122) are offloaded from the mobile device110to the back-end server120, the native app112may use less processing resources than implementations where all the operations are performed by the mobile device110, which reduces power consumption at the mobile device110. Due to the reduced power consumption, the native app112may be executable at devices having more stringent power requirements, such as computerized watches or other devices. Additionally, because the configurable network service115provides anonymity to the back-end server120(e.g., because accesses to the website132appear to originate at the mobile device110instead of at the back-end server120), an institution that provides the website132is unlikely to block accesses by the mobile device110. An additional benefit is improved security as compared to systems that store the access credential data114at the back-end server120. Further, performance and/or a user experience may be improved by virtue of utilizing the native app112instead of a web app, hybrid app, or conventional web page accesses (e.g., as would be performed by the computer150).

FIG. 2illustrates another aspect of a system200that supports secured data access from a mobile device executing a native application that is integrated with a server executing a headless browser. The system200includes a mobile device202, a first back-end server220, a second back-end server224, and a third party web server240. In a particular implementation, the mobile device202includes or corresponds to the mobile device110, the first back-end server220and the second back-end server224include or correspond to the back-end server120, and the third party web server240includes or corresponds to the web server130ofFIG. 1. Although two back-end servers220and224are illustrated, in other implementations, more than two back-end servers may be included in the system200, or a single back-end server may perform all the operations described with reference to the back-end servers220and224.

The mobile device202is configured to execute a native mobile app203. In a particular implementation, the native mobile app203includes or corresponds to the native app112ofFIG. 1. The native mobile app203includes user interface (UI)/presentation code204, a configurable network service206, an app/service registering component208, and a remote API access component210. The first back-end server220includes an app/service directory service222, and the second back-end server224includes an API/web API226, a headless browser management API228, and a headless browser230. In a particular implementation, the configurable network service includes or corresponds to the configurable network service115and the headless browser230includes or corresponds to the headless browser122ofFIG. 1. Each of the UI/presentation code204, the configurable network service206, the app/service registering component208, and the remote API access component210may include processor-executable instructions that cause a processor of the mobile device202to perform the operations described herein. In alternate implementations, one or more of the UI/presentation code204, the configurable network service206, the app/service registering component208, and the remote API access component210may be implemented in hardware, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

The UI/presentation code204is configured to generate displays, such as via a GUI (e.g., the GUI113ofFIG. 1) and other visual content, in addition to providing user interface elements of the native mobile app203. For example, the UI/presentation code204is responsible for generating the display of the native mobile app203, including elements such as buttons, fields, boxes, and textual information, such as user-specific information including user name, account number(s), account balance(s), or other information. The UI/presentation code204is also configured to access a headless browser230at the second back-end server224in order to access secured data from the third party web server240, as further described herein.

The configurable network service206is configured to receive requests from the second back-end server224(e.g., from the headless browser230executed by the second back-end server224) and to forward the requests to the third party web server240. For example, the configurable network service206may receive HTTP or HTTPS requests, as non-limiting examples, and may send the requests to the third party web server240. Prior to sending the requests, the configurable network service206modifies the requests so that the requests appear to originate from the mobile device202instead of the second back-end server224. For example, the configurable network service206may monitor headers of the requests to indicate the mobile device202as the originators of the requests. The configurable network service206is configurable to form a secure connection with the headless browser230executed by the second back-end server224, as further described herein, to enable the configurable network service206to securely route requests from the headless browser230to the third party web server240and to route responses from the third party web server240to the headless browser230for processing.

The app/service registering component208is configured to register the native mobile app203with the back-end servers220and224. For example, when the native mobile app203is launched, the app/service registering component208generates registration data that is sent to the first back-end server220. The registration data includes a native mobile app ID of the native mobile app203(e.g., an ID that is unique to each instance of the native mobile app203on any device) in addition to an IP address and port assigned to the configurable network service206. The registration data also optionally includes credential data that indicates one or more credentials (e.g., a username and password, etc.) that are used to provide security for the secure connection between the configurable network service208and the headless browser230. The credential data is distinct from access credential data (e.g., a different username and a different password) used to login to the website242. For example, the credential data may be generated by the native mobile app203independent of a user, whereas the access credential data includes a username and a password that are established by the user for accessing mobile banking features at the website242. In a particular implementation, the credential data is randomly generated by the native mobile app203and passed to the first back-end server220as part of the registration data. The registration data is used by the headless browser management API228to setup a new headless browser instance, such as when a first request is sent from the remote API access component210to the second back-end server224. The app/service registering component208is also configured to refresh (e.g., update) the registration data whenever an IP address change occurs at the mobile device202. For example, if the mobile device202transitions from a cellular network (e.g., an LTE network) to a Wi-Fi network, or if an internet service provider (ISP) dynamically changes an assigned IP address, the app/service registering component208updates the registration data to indicate the new IP address (or any other change) and sends the updated registration data to the first back-end server220.

The remote API access component210is configured to pass requests from the UI/presentation code204to the second back-end server224. To illustrate, the remote API access component210may be in charge of sending requests to the second back-end server224and receiving responses from the second back-end server224in order to provide the UI/presentation code204with data that is needed to generate the display of the native mobile app203.

The app/service directory service222is configured to maintain storage of registration data for one or more native mobile apps (e.g., for one or more mobile devices). For example, the registration data may indicate the native mobile app ID in addition to the IP address and port assigned to the configurable network service206. The app/service directory service222may store the registration data, indexed by the native mobile app ID, in a memory of the first back-end server220. In some implementations, the app/service directory service222is configured to create a secure connection (e.g., an encrypted network tunnel) between the IP address and port associated with the configurable network service206and an IP address and port of the second back-end server224that is used by the headless browser230. This may simplify setup and use of the secure connection because the secure connection (e.g., the encrypted network tunnel) from the second back-end server224can be authenticated using IP address (e.g., the IP address where the headless browser instance is running in one of the back-end servers) instead of a username and password (or other means of authentication) to access the configurable network service206running at the mobile device202. Alternatively, the registration data may include credential data that is used to authenticate the second back-end server224during a setup process of the secure connection. The credential data is distinct from (e.g., is not related to) a username and password used to access the website242. Thus, because access credential data (e.g., a username and password associated with a login to the website242) is not used to establish the secure connection (and is not included in the registration data), the access credential data is not stored on the back-end servers220and224, which improves security as compared to systems that store personal identifiable information (e.g., the access credential data) at back-end servers.

The API/web API226is configured to forward requests or responses from the remote API access component210to the headless browser management API228for processing with the headless browser230. The API/web API226may be a standard server/client API, such as a web API of a web server. For example, a request generated by the UI/presentation code204may be passed to the remote API access component210and sent to the API/web API226. The API/web API may pass the received request to the headless browser management API228for operation with the headless browser230. Similarly, a response to the request that is received by the headless browser230may be passed from the headless browser management API228may be passed to the API/web API226and sent to the remote API access component210, which passes the response to the UI/presentation code204for display to the user via a GUI of the native mobile app203.

The headless browser management API228is configured to receive requests forwarded from the UI/presentation code204to take action based on the requests or to fetch data on a given web page of a website242hosted by the third party web server240. The headless browser management API228is also configured to create (e.g., instantiate) and destroy instances of the headless browser230. To instantiate an instance (e.g., a session) of the headless browser230, the headless browser management API228accesses the app/service directory service222to retrieve the IP address and port and credential data assigned to the configurable network service206(for setting up the secure connection to the configurable network service206).

The headless browser management API228is also configured to access a browser state database234to determine whether any persistent state data is stored. For example, the headless browser management API228may determine whether persistent state data is stored for the native mobile app ID indicated by the stored registration data from the app/service directory service222. The persistent state data may include one or more cookies, local storage, cached data, or a combination thereof, from a previous session of the headless browser230. The browser state database234may be stored in a memory of the second back-end server224or may be external to the second back-end server224. For example, the browser state database234may be stored in the cloud (e.g., at one or more external servers). If persistent state data is found for the native mobile app ID, the persistent state data is retrieved and used to recreate a previous session of the headless browser230. If no persistent state data is found for the native mobile app ID, a new instance of the headless browser230is instantiated to process one or more requests received by the headless browser management API228from the API/web API226.

The headless browser230is a web browser without a displayed GUI that is used to process the requests received from the native mobile app203(e.g., from the UI/presentation code204via the remote API access component210). Additionally, the headless browser230is configured to communicate with the website242via the configurable network service206. For example, the headless browser230may generate an HTTP or HTTPS request, as a non-limiting example, that is sent to the configurable network service206for transmission to the third party web server240.

API fingerprint data232that corresponds to the website242may be embedded in (e.g., injected in) the headless browser230to enable the headless browser230to communicate with the website242(via the configurable network service206). For example, the systems and methods of the present disclosure may create a “fingerprint” of the internet banking service pathways used for a user to log in, authenticate, and take other actions possible with internet banking. This unique service fingerprint may be stored (e.g., at the second back-end server224or in the cloud) and may be loaded (e.g., at runtime) into the headless browser230as an embedded (e.g., injected) API component that configures headless browser interaction with the native mobile app203and the website242. This fingerprint may also enable identification of changes that occur to the internet banking software (e.g., the website242). These changes may trigger automated validation processes that verify that user accounts can (continue to) be accessed correctly. In the event that there is a change detected in the API fingerprint for a given bank or credit union, a process may be triggered to update the fingerprint to incorporate changes so that normal operations can be restored. For each bank or credit union, there may be a unique fingerprint ID to configure how the API interacts between the headless browser230and the internet banking software. It may be possible for the API system to load more than one fingerprint per application, thereby enabling the native mobile app203to directly access internet banking software for more than one bank or credit union on behalf of a user that has valid credentials at multiple institutions. This also enables the native mobile app203to be independently branded and enables consumers to access any fingerprinted internet banking system. If configured in this manner, users may select their financial institution from among multiple fingerprinted organizations prior to initial login. Alternatively, a different instance of the headless browser230may be instantiated for each different bank or credit union.

In some aspects, the native mobile app203uses the headless browser230to send and receive information to and from the internet banking system (via the configurable network service206) through an established interface. Once a system for a bank or credit union is fingerprinted for use by an embedded API, the native mobile app203may provide access credential data, such as username, password, and any additional information needed to authenticate (e.g., multi-factor authentication code, etc.). The need to pass in additional authentication information would be determined by the headless browser230parsing the initial response to the application passing in the username/password. If the website242responds in a way that was previously fingerprinted as being associated with a multi-factor authentication request, the native mobile app203may prompt the user to enter such information, which may be obtained via an out-of-band channel, such as e-mail or text message. Similarly, if the web site242responds to an authentication attempt with a multi-factor authentication challenge, a fingerprint may indicate how to respond to such a challenge, and the headless browser230may parse the challenge so that the challenge can be relayed to the mobile device202for display to the user in the GUI of the native mobile app203. The resulting response from the user would then be passed back through the embedded API into the headless browser230and then relayed from the headless browser230via the configurable network service206to the third party web server240hosting the internet banking website.

Alternatively, the third party web server240may reject/fail the authentication and provide an error status/page. In this scenario, the error/status page may have been pre-mapped and fingerprinted. The error status would be parsed and passed back to the native mobile app203by the embedded API for display to the user, so that the user can take action (e.g., by re-entering the correct information, etc.). The embedded API may thus function as a mapping of all potential interactions and responses between the website242/third party web server240/internet banking pages and the actions that the user can take in the native mobile app203.

During operation, the native mobile app203registers with the first back-end server220. For example, the app/service registering component208sends registration data, such as the registration data124ofFIG. 1, to the first back-end server220. The registration data may include a native mobile app ID of the native mobile app203and an IP address and port assigned to the configurable network service206. In some implementations, the registration data also includes credential data used to setup a secure connection between the headless browser230and the configurable network service206. The app/service directory service222at the first back-end server220stores the registration data for later use in establishing the secure connection between the headless browser230and the configurable network service206. Additionally, the UI/presentation code204generates the GUI of the native mobile app203for display to a user. When a user interacts with the GUI, such as by selecting a bank to login to and entering access credentials (e.g., a username and password) for logging on to the website242, the UI/presentation code204generates a request, such as the request125ofFIG. 1. The request is passed to the remote API access component210, and the remote API access component210sends the request to the API/web API226at the second back-end server224. The API/web API226receives the request and passes the request to the headless browser management API228.

The headless browser management API228initiates launch of the headless browser230based on receiving the request. In a particular implementation, the headless browser management API228access the browser state database234to determine whether persistent state data exists for the native mobile app ID. If persistent state data for the native mobile app ID is stored at the browser state database234, the persistent state data is retrieved and loaded into the headless browser230to recreate a previous headless browser session. Multi-factor authentication challenges may be facilitated by session and cookie-handling of the headless browser230, leveraging security protocols for internet banking that are already in place. Alternatively, if no persistent state data is found, the headless browser management API228instantiates a new session of the headless browser230. Additionally, the headless browser management API228may access the app/service directory service222to initiate formation of a secure connection between the headless browser230and the configurable network service206. For example, a secure connection (e.g., an encrypted network tunnel) may be created between the IP address and port of the configurable network service206and an IP address and port at the second back-end server224. As part of the process of creating the secure connection, the second back-end server224may be authenticated based on credential data included in the registration data managed by the app/service directory service222.

The headless browser management API228may also determine the API fingerprint data232that corresponds to the website242and embed (e.g., inject) the API fingerprint data232into the headless browser230such that an API between the website242and the native mobile app203is formed. For example, the API fingerprint data232may indicate mappings between elements, such as a login button, of the native mobile app203and the website242. Based on the API fingerprint data232, the headless browser230generates a request, such as the second request126ofFIG. 1, to login to the website242. The request is sent via the secure connection to the configurable network service206. The configurable network service206receives the request and generates a new request, such as the third request136ofFIG. 1, that appears to the website242(or the third party web server240) to originate at the mobile device202. For example, the configurable network service modifies a header of the request prior to sending the request, and the modified header indicates the mobile device202as the originator of the request (e.g., the third request136ofFIG. 1). In this manner, the configurable network service206anonymizes the second back-end server224, and it appears to the third party web server240that all requests come from the mobile device202.

After sending the request, the configurable network service206may receive web page data, such as the web page data134ofFIG. 1, from the website242. The configurable network service206forwards the web page data134to the second back-end server224for processing via the headless browser230. For example, the headless browser230may be used to parse the web page data to identify user-specific data, such as account number(s), account balance(s), etc. The user specific information may be passed by the headless browser management API228to the API/web API226for transmission to the remote API access component210. The remote API access component210receives the user-specific data and passes the user-specific data to the UI/presentation code for display to the user via the GUI of the native mobile app203.

In this manner, the mobile device202operates with the back-end servers220and224to access secured data at the website242while appearing as though the access originates at the mobile device202, and not the second back-end server224. To illustrate, the headless browser230may act as an integration layer that presents a unique, distributed, secure web browsing session in real-time or near-real-time to the internet banking system. In contrast to other approaches, access by the headless browser230on behalf of the native mobile app203directly relates to authorized user activity on behalf of the financial institution and is identical in terms of access traffic to a mobile browser login originating from the same device. This has substantial security, performance, integration, operational and business benefits. By leveraging headless browser technology, this approach enables direct interaction in real-time or near-real-time for both “read” and “write” activity for a user's accounts without requiring a direct mobile integration interface (e.g., a direct mobile integration, such as a customized mobile application created by a financial institution).

It should be noted that unlike other systems which may utilize a headless browser, the techniques of the present disclosure do not execute the user interface in the headless browser and then translate a resulting experience to a client. Rather, the “client” native mobile app may have a fixed user interface that does not vary in presentation based on a server-side website. Instead, the client user interface may be defined at the point the native app is published to an app store. Moreover, in the techniques of the present disclosure, the headless browser is used to create a secure, standards-based browser session with internet banking. Before the native app is published, an embedded API configuration is created for a bank or credit union, and the embedded API configuration defines the internet banking functions available and the expected methods in HTML/JavaScript for reading/writing that information to the internet banking site. This configuration may be different for different banks/credit unions and may correspond to items, such as username or password, transaction information, etc. Each such item may be pre-mapped in the configuration against the banking application API, which may be standardized across all branded “versions” of the native app. Thus, in some aspects, a particular native app may only be compatible for use on a specific website and/or a specific version of internet banking software. In the systems and methods of the present disclosure, the headless browser does not rely on translation between the website's interface and the banking app. Instead, the headless browser may be used as a secure pipe over an open network interface.

Referring toFIG. 3, an illustrative aspect of a method300of operation at a server is shown. In particular examples, the method300may be performed by the back-end server120ofFIG. 1or the back-end servers220,224ofFIG. 2.

The method300includes receiving, at a server, registration data from a mobile device that executes a native application and that hosts a configurable network service for connecting to a website hosted by a remote server, at302. For example, the back-end server120ofFIG. 1receives the registration data124from the mobile device110. The registration data indicates an application identifier associated with the native application and address data associated with the configurable network resource. For example, the registration data124includes an application identifier (e.g., a unique identifier) of the native app112and an IP address and port assigned to the configurable network service115ofFIG. 1. In some implementations, the registration data optionally includes credential data associated with establishing a secure connection with the configurable network service. In a particular implementation, the credential data is randomly (or pseudo randomly) generated.

The method300includes establishing a secure connection between a headless browser executed by the server and the configurable network service based on the registration data, at304. For example, the back-end server120establishes a secure connection between the headless browser122at the back-end server120and the configurable network service115at the mobile device110. The headless browser includes a web browser not having a corresponding displayed graphical user interface.

The method300includes receiving a first request from the native application of the mobile device, at306. For example, the back-end server120receives the request125from the native app112of the mobile device110.

The method300includes sending a second request from the headless browser to the configurable network service of the mobile device for transmission to the remote server, at308. The second request is for information corresponding to the website. For example, the back-end server120sends the second request126to the configurable network service115at the mobile device110, and the configurable network service115modifies the second request126before forwarding the modified second request (e.g., the third request136) to the web server130.

The method300also includes receiving first webpage data from the configurable network service of the mobile device, at310. The first webpage data originates at the remote server. For example, the back-end server120receives the web page data134from the configurable network service115of the mobile device110. The web page data originates at the web server130.

In a particular implementation, the method300includes receiving access credential data from the mobile device at the server and generating the second request based on the access credential data and based on application programming interface (API) data associated with the website. For example, the request125ofFIG. 1may include or indicate access credential data and the back-end server120ofFIG. 1may generate the second request126based on the API fingerprint data121. The method300may also include connecting to the remote server via the configurable network service based on the access credential data and generating persistent state data based on a state of the headless browser after connecting to the remote server. For example, the configurable network service115of the mobile device110may operate to connect the back-end server120to the web server130while preserving anonymity of the back-end server120(e.g., to the web server130, the access appears to be the same as an access that would be generated by a web browser of the mobile device110). Additionally, the back-end server120ofFIG. 1generates the persistent state data129and stores the persistent state data129at the browser state database128when an indication that the native app112has been closed is received. In a particular implementation, the access credential data is not stored at the back-end server.

Referring toFIG. 4, an illustrative aspect of a method400of operation at a mobile device is shown. In particular examples, the method400may be performed by the mobile device110ofFIG. 1or the mobile device202ofFIG. 2.

The method400includes receiving, at a mobile device from a headless browser executed on a first server, a first data packet, at402. The first data packet includes a header and a request for data from a website hosted by a second server. The header indicates the first server as an originator of the first data packet. For example, the mobile device110ofFIG. 1receives the second request126from the back-end server120.

The method400includes modifying the header of the first data packet to generate a modified data packet, at404. A header of the modified first data packet indicates the mobile device as the originator of the first packet. For example, the mobile device110modifies the first header127of the second request126to generate a modified first data packet (e.g., the third request136ofFIG. 1). The second header137of the third request136indicates the mobile device110as the originator of the third request136.

The method400sending the modified first data packet to the second server, at406. For example, the mobile device110ofFIG. 1sends the third request136to the web server130.

The method400includes receiving first data from the second server responsive to the request for data, at408. For example, the mobile device110receives the web page data134from the web server130.

The method400also includes sending the first data to the first server for parsing by the headless browser, at410. For example, the mobile device110ofFIG. 1sends the web page data134to the back-end server120for parsing by the headless browser122.

In a particular implementation, the method400includes, responsive to executing the native application, generating registration data and sending the registration data to the first server. The registration data includes an application identifier associated with the native application, address information associated with a configurable network service that communicates with the second server, and credential data associated with establishing a secure connection with the configurable network service. For example, the mobile device110ofFIG. 1generates and sends the registration data124to the back-end server120. The registration data124ofFIG. 1includes an application identifier associated with the native app112, an IP address and port (e.g., address information) assigned to the configurable network service115, and credential data indicative of credentials (e.g., a username and password, etc.) used to secure the connection between the headless browser122and the configurable network service115. In a particular implementation, the credential data is randomly (or pseudo randomly) generated by the native app112. The method400may also include establishing a secure connection between the configurable network service and the headless browser. For example, a secure connection, such as an encrypted network tunnel, may be established between the headless browser122at the back-end server120and the configurable network service115at the mobile device110. Establishing the secure connection may include authenticating the back-end server120based on the credential data included in the registration data124.

In another particular implementation, the method400includes receiving persistent state data from the first server and storing the persistent state data at a memory of the mobile device. For example, the mobile device110ofFIG. 1may receive the persistent state data129and may store the persistent state data129at a memory. After launching the native app112, the persistent state data129may be sent to the back-end server120for use in setting up the headless browser122.

It is to be understood that in alternative aspects, one or more steps of the methods300,400ofFIGS. 3-4may be performed in a different order, may be combined or performed at least partially concurrently, or may be omitted. Further, one or more other steps may be added.

Referring toFIG. 5, an illustrative example of a mobile device502is shown. The mobile device502may be configured to perform one or more of the functions and methods described above with reference toFIGS. 1-4. In a particular implementation, the mobile device502may include or correspond to the mobile device110ofFIG. 1or the mobile device202ofFIG. 2.

The mobile device502includes a computer-readable storage device506, one or more processors508(e.g., a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), etc.) and a memory510. The storage device506may be implemented as read-only memory (ROM), random access memory (RAM), and/or persistent storage, such as a hard disk drive, a flash memory device, or other type of storage device. The memory510is configured to store instructions512executable by the processor508to perform one or more of the functions or methods described above with reference toFIGS. 1-4. As non-limiting examples, the memory510may be configured to store the native app112ofFIG. 1or the native mobile app203ofFIG. 2. The computer-readable storage device506is not a signal.

The mobile device502also includes a location device516(e.g., a GPS transceiver) and one or more wireless transceivers514that enable the mobile device502to exchange signals with (e.g., receive signals from and/or send signals to) other devices. Each wireless transceiver514may include or be coupled to radio frequency (RF) circuitry517, a controller518, and/or an antenna519. In illustrative examples, the wireless transceivers514include a third generation (3G) transceiver, a fourth generation (4G) transceiver, a Wi-Fi transceiver, a near field communication (NFC) transceiver, a BLUETOOTH (BLUETOOTH is a registered trademark of Bluetooth SIG, Inc. of Kirkland, Wash., USA) or BLUETOOTH low energy (BLE) transceiver, or any combination thereof. In the example ofFIG. 5, the mobile device502is configured to utilize one or more of the wireless transceivers514for direct peer-to-peer communication and communication via one or more networks524, such as the internet. To illustrate, the mobile device502may communicate with an external device526(e.g., an automated teller machine (ATM) for contact-less ATM authentication) via a peer-to-peer wireless channel (e.g., BLUETOOTH, BLE, or NFC) and may communicate with the web server130hosting the website132via a cellular or Wi-Fi wireless channel.

In the example ofFIG. 5, the mobile device502includes or is coupled to input devices and output devices. For example, the mobile device502may include or may be coupled to a display device532, a microphone534, a speaker536, and/or a user input device538(e.g., a touchscreen). It should be noted that, while illustrated as outside of the mobile device502, one or more of the devices532-538may be integrated into a housing of the mobile device502, such as in the case of a mobile phone or tablet computer.

Referring toFIG. 6, an illustrative example of a server602is shown. The server602may be configured to perform one or more of the functions and methods described above with reference toFIGS. 1-4. In a particular implementation, the server602includes or corresponds to the back-end server120ofFIG. 1or the back-end servers220,224ofFIG. 2.

The server602includes a computer-readable storage device606, one or more processors608(e.g., a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), etc.) and a memory610. The storage device606may be implemented as read-only memory (ROM), random access memory (RAM), and/or persistent storage, such as a hard disk drive, a flash memory device, or other type of storage device. The memory610is configured to store instructions612executable by the processor608to perform one or more of the functions or methods described above with reference toFIGS. 1-4. The computer-readable storage device606is not a signal.

The server602also includes one or more transceivers614that enable the server602to exchange signals with (e.g., receive signals from and/or send signals to) other devices. In some implementations, the transceivers614are wireless transceivers, and each transceiver614may include or be coupled to radio frequency (RF) circuitry, a controller, and/or an antenna. In illustrative examples, the transceivers614include a third generation (3G) transceiver, a fourth generation (4G) transceiver, a Wi-Fi transceiver, a near field communication (NFC) transceiver, a BLUETOOTH or BLUETOOTH low energy (BLE) transceiver, a wired transceiver, or any combination thereof. In the example ofFIG. 6, the server602is configured to utilize one or more of the transceivers614for communication via one or more networks624, such as the internet. To illustrate, the server602may communicate with mobile device110via the internet.

The server602optionally includes a location device616(e.g., a GPS transceiver). In the example ofFIG. 6, the server602also optionally includes or is coupled to input devices and output devices. For example, the server602may optionally include or may be coupled to a display device632, a microphone634, a speaker636, a user input device638(e.g., a touchscreen), or a combination thereof.

In conjunction with the described aspects, a server includes a transceiver configured to communicate with a mobile device configured to execute a native application and configured to host a configurable network service for connecting to a website hosted by a remote server. The server includes a processor. The server also includes a memory storing instructions that are executable by the processor to perform operations including receiving registration data from the mobile device. The registration data indicates an application identifier associated with the native application and address data associated with the configurable network service. The operations include initiating establishment of a secure connection between a headless browser and the configurable network service based on the registration data. The headless browser includes a web browser not having a corresponding displayed graphical user interface. The operations include receiving a first request from the native application of the mobile device. The operations include initiating sending of a second request from the headless browser to the configurable network service of the mobile device for transmission to the remote server. The second request is for information corresponding to the website. The operations also include receiving first webpage data from the configurable network service of the mobile device. The first webpage data originates at the remote server.

In conjunction with the described aspects, a method includes receiving, at a server, registration data from a mobile device that executes a native application and that hosts a configurable network service for connecting to a website hosted by a remote server. The registration data indicates an application identifier associated with the native application and address data associated with the configurable network service. The method includes establishing a secure connection between a headless browser executed by the server and the configurable network service based on the registration data. The headless browser includes a web browser not having a corresponding displayed graphical user interface. The method includes receiving a first request from the native application of the mobile device. The method includes sending a second request from the headless browser to the configurable network service of the mobile device for transmission to the remote server. The second request is for information corresponding to the website. The method also includes receiving first webpage data from the configurable network service of the mobile device. The first webpage data originates at the remote server.

In conjunction with the described aspects, a computer-readable storage device stores instructions that, when executed by a processor, cause the processor to perform operations including receiving, at a server, registration data from a mobile device that executes a native application and that hosts a configurable network service for connecting to a website hosted by a remote server. The registration data indicates an application identifier associated with the native application and address data associated with the configurable network service. The operations include establishing a secure connection between a headless browser executed by the server and the configurable network service based on the registration data. The headless browser includes a web browser not having a corresponding displayed graphical user interface. The operations include receiving a first request from the native application of the mobile device. The operations include sending a request from the headless browser to the configurable network service of the mobile device for transmission to the remote server. The second request is for information corresponding to the website. The operations also include receiving first webpage data from the configurable network service of the mobile device. The first webpage data originates at the remote server.

In conjunction with the described aspects, a mobile device includes a wireless transceiver configured to communicate with a first server and a second server. The first server is configured to execute a headless browser. The second server is configured to host a website. The mobile device includes a display device. The mobile device includes a processor coupled to the wireless transceiver and the display device. The mobile device also includes a memory coupled to the processor and storing a native application that is executable by the processor to perform operations including receiving, from the headless browser, a first data packet. The first data packet includes a header and a request for data from the website. The header indicates the first server as an originator of the first data packet. The operations include modifying the header of the first data packet to generate a modified first data packet. A header of the modified first data packet indicates the mobile device as the originator of the first data packet. The operations include initiating sending of the modified first data packet to the second server via the wireless transceiver. The operations include receiving first data from the second server via the wireless transceiver responsive to the request for data. The operations include initiating sending of the first data to the first server for parsing by the headless browser.

In conjunction with the described aspects, a method includes receiving, from a headless browser executed at a first server, a first data packet. The first data packet includes a header and a request for data from a web site hosted by a second server. The header indicates the first server as an originator of the first data packet. The method includes modifying the header of the first data packet to generate a modified first data packet. A header of the modified first data packet indicates the mobile device as the originator of the first data packet. The method includes sending the modified first data packet from the mobile device to the second server. The method includes receiving first data from the second server at the mobile device responsive to the request for data. The method also includes sending the first data from the mobile device to the first server for parsing by the headless browser.

In conjunction with the described aspects, a computer-readable storage device stores instructions that, when executed by a processor, cause the processor to perform operations including receiving, from a headless browser executed at a first server, a first data packet. The first data packet includes a header and a request for data from a website hosted by a second server. The header indicates the first server as an originator of the first data packet. The operations include modifying the header of the first data packet to generate a modified first data packet. A header of the modified first data packet indicates the mobile device as the originator of the first data packet. The operations include sending the modified first data packet from the mobile device to the second server. The operations include receiving first data from the second server at the mobile device responsive to the request for data. The operations also include sending the first data from the mobile device to the first server for parsing by the headless browser.

The illustrations and aspects of the disclosure described herein are intended to provide a general understanding of the disclosure and are not intended to exhaustively illustrate all possible aspects, some of which may incorporate substitute arrangements to achieve the same or similar objectives. The present disclosure covers any and all subsequent adaptations or variations of aspects described herein.

It is to be understood that the figures may not be drawn to scale, and the Abstract is not to be used to interpret or limit the scope or meaning of the claims. In addition, the use of the terms invention, embodiment, aspect, or example do not require that the described features be grouped together. The disclosure is not to be interpreted as intending any claimed aspect, example, or embodiment to require more elements than recited in a claim.

The subject matter described herein is thus illustrative rather than restricting, and the claims are intended to cover all falling within the scope of the present disclosure. To the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims (which are hereby incorporated into the detailed description) and their equivalents, and shall not be restricted or limited by the foregoing detailed description.