Patent Description:
Mobile apps have becomes part of everyday's life for most Smartphone users. They cover a wide range of applications, including social networking, media playing, content sharing, GPS navigation, online banking, gambling, videogames, news, sport, healthcare and wellbeing, notwithstanding the ones designed for business users. The list is virtually unlimited and new apps are launched on a regular basis. Consequently, it may be complicated for consumers or professionals to select the right app for an intended use, and app's designers are striving to make it more appealing and to reduce friction.

One early source of friction is the need to create an account. Account creation requires some time and effort (e.g. reading standard terms of use) and prospective users may be reluctant to provide contact details such as an email address or phone number. Others may not want to remember a password for an app they are not sure yet to adopt.

It is of course possible to let the user try the application in guest mode without registering, giving access to a limited set of features. Holding features behind the registration wall is an incentive to create an account. However it generally results in a poorer experience, and some frustration if the interaction history is not recorded. For instance, when visiting the app a second time, the transactions and unique profile created by a user may be lost. This is particularly annoying if he/she finally wants to register. Other users may prefer to continue as guest for a period of time, but still appreciate to retrieve tracks of their previous actions. Such users may be sent in-app messages calling for registration with a welcome gift after using the app in guest mode a number of times.

Enabling a guest mode in a mobile application may present information security risks. For instance, an attacker may want to impersonate a guest user in order to cause malfunction of the service, or capture personal data from legitimate (guest or registered) users. An attacker may also want to cause a DOS (denial of service) or DDOS (distributed denial of service) by simulating a huge number of guest users connecting at the same time. So a method is needed for uniquely and unambiguously identifying a guest user before he/she registers to a mobile application. The method shall ensure that the user is a real person using a real device, and not a malicious software simulating one or many visitors.

Examples of such methods exist in the field of network connectivity. Typically, a user wants to access resources on a wireless network when they are guests at a corporation with which they have no prior or permanent relation. For instance, <CIT> describes a system and method for enabling secure user connectivity to wireless and wired IP communication networks. The method includes an authentication interface accepting user credentials, and a validation entity for credential verification and access authorization. The user communicates through a laptop computer, or personal digital assistant or IP telephone with a web based authentication interface to provide his cellular telephone number. The validation entity will verify the existence of an account indexed by the cellular telephone number and transmit a password to the cellular telephone number of the user through SMS. The user enters both his cellular telephone number and received password into the web authentication interface. This method requires at least two different devices and may discourage the user from trying the application at all.

<CIT> discloses systems and methods for accessing protected data. A mobile device obtains a first token from an authorization service verifying user identity for a first application. The mobile device can then use the token to access protected data and services. The first token is stored in a shared storage area accessible to one or more applications. If the user attempts to access a web service using a second application, his/her identity may be verified using the first token, an identifier of the second application and a device identifier. However the user must be registered to the authorization service first, and access to protected data may not be granted to users acting or logging in as a guest. Such users will be considered as anonymous and will not retrieve tracks of their previous interactions with the app. Further example methods are disclosed in <CIT> and in <CIT>.

It is therefore an object of the invention to provide access to a mobile application in guest mode, while maintaining ease of use and a high level of information security and data privacy.

It is another object of the invention to facilitate the authentication and registration of users and retrieval of their previous interaction history whenever they decide to create a permanent account.

It is a further object of the invention to ensure that the user is a real person using a real device, and not an attacker or a malicious software simulating one or many visitors.

The objects are achieved by method for allowing unique and unambiguous identification of users, and re-identification of the same users and retrieval of their previous interactions during subsequent connections to the mobile application.

More particularly, the invention relates to a method for identifying as a guest a user of a mobile application installed on a mobile device of the user, comprising the steps of:.

Advantageously, the guest user ID is uniquely generated from the device token.

Preferably, the passcode is a one-time passcode that is generated from the guest user ID and a counter incremented at regular time intervals.

Advantageously, the method further includes the steps of generating by the web server, and sending to the mobile application, a session-based access token that is used for subsequent communications between the mobile application and the web server.

Preferably, the session-based access token includes the guest user ID and the session-based token is valid for a limited time period.

Advantageously, the method further includes the step of giving access to the user to the features of the mobile application available to guest users.

Preferably, the method further includes the steps of recording in the database the interactions of the user with the mobile application under the user account corresponding to the guest user ID.

Advantageously, the method further includes the step of erasing the passcode and guest user ID from a memory of the mobile application if the session is ended by the user, by closing the mobile application or not using it for a given period of time.

Advantageously, the method further includes the steps of retrieving in the database a history of the interactions recorded under the user account corresponding to the guest user ID and making it available to the user each time the user selects to use the mobile application in guest mode if the user account already exists.

A described embodiment also relates to a method of authenticating and registering a user of a mobile application installed on a mobile device already identified as a guest by a guest user ID in a database of a web platform operated by a provider of the mobile application, including the steps of:.

Advantageously, the method further includes the step of linking an interaction history corresponding to the guest user ID to the login information in the database.

Preferably, the method further includes the step of sending by the web server a confirmation message to the mobile application.

Advantageously, the method further includes the step of making additional features only available to registered users of the mobile application available to the user.

Preferably, the login information includes an email address or a phone number of the user and a password.

The invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

<FIG> is a schematic view of an identification system according to the invention.

A legitimate user <NUM> has downloaded and installed a mobile application <NUM> on his/her mobile device <NUM> and wants to use it in guest mode. The mobile application provider operates a web platform <NUM> including typically a web server <NUM> and a database <NUM>. The database contains a list of registered users, a list of guest users and an interaction history of both registered and guest users. The registered users are identified by a user ID associated with their login information (identifier, password). Guest users are identified by a guest user ID as will be described hereafter. Once successfully installed on the mobile device <NUM>, the mobile application <NUM> invokes web services available from the web server <NUM> though the Internet, allowing the user to perform various transactions, which may include payment for the services provided.

The identification system further involves a trusted provider <NUM> such as Apple Inc. or Google Inc. (depending on which operating system is running on the mobile device) which guarantees that the mobile device <NUM> is a legitimate device though its push notification service (Apple Push Notification Service and Google Cloud Messaging respectively). A push notification is an alert message that can be sent by the mobile application provider and received by the mobile device <NUM> whether the mobile application <NUM> is running or not. The alert can be related to a specific event, such as the expiration of a trial period, or trigger an application update whenever a new version becomes available. When the mobile application <NUM> is running, it can receive the alert message in silent mode, without the user <NUM> being aware of it.

After the application <NUM> has been installed, it sends a device token request to the trusted provider <NUM>, which generates a device token <NUM> and sends it to the mobile device <NUM> through its push notification service. A device token is a unique key for the app-device combination which is issued by the Apple or Google push notification gateways. It allows gateways and push notification providers to route messages and ensure the notification is delivered only to the unique app-device combination for which it is intended.

Apple/iOS device tokens are strings of <NUM> hexadecimal symbols. Here is a typical example:
740f4707 bebcf74f 9b7c25d4 8e335894 5f6aa01d a5ddb387 462c7eaf 61bb78ad.

Google/Android device token may be longer but usually less than <NUM> characters. Here is a typical example:
APA91bHLUfr71D6K7VTrRH3LGiLFxGNr3qRi3xOB_yN10fLYsqhlgYXxHzOhQ x2WKgqZI3sqxa1ZPORaO-5YBZ1_OFLm9cEg1bTh7wtrpCsHW91MSs2BMIXrHEqyjj2TeoVxnAzA5U8s.

Once the device token <NUM> is received by the mobile device <NUM>, it is saved by the mobile application <NUM> for further connections. Each time a guest user needs to be identified, the mobile application <NUM> will send the device token <NUM> to the mobile application provider web platform <NUM>. This device token <NUM> will be used by the mobile application provider each time he wants to send a message to the user <NUM>. The message goes through the Apple or Google push notification service, which relays it to the mobile device <NUM>, then to the mobile application <NUM> in silent mode. The present invention benefits from this mechanism to identify guest users in a secure manner, and block a potential attacker <NUM> trying to impersonate legitimate users from a computer <NUM>.

<FIG> shows a general flowchart of the method of the invention;.

The user <NUM> wants to use the mobile application <NUM> already installed on his mobile device <NUM>. At step <NUM>, the mobile application <NUM> sends an access request to the web server <NUM> including the device token <NUM>. At step <NUM> the web server <NUM> sends a passcode <NUM> along with the device token <NUM> to the trusted provider <NUM>, which relays the passcode <NUM> to the mobile device <NUM> through its push notification service at step <NUM>. The passcode <NUM> is then used by the mobile application <NUM> at step <NUM> to give access to the web services available from the web server <NUM> and enable the user <NUM> to perform the corresponding transactions. All these steps can be performed automatically without any user interaction. Subsequent communications between the mobile application <NUM> and the web server <NUM> also involve a guest user ID <NUM>, a session-based access token <NUM> and a verification code <NUM>, as will be described hereafter.

<FIG> shows a guest user identification process according to the method of the invention.

The first steps are basically the same as explained above. We assume that the user <NUM> has already installed the mobile application <NUM> on her/his device <NUM> and selects to use it for the first time in guest mode. The mobile application with typically show a virtual button with a text like "Use as Guest" or "Give it a try" next to the regular login or signup window.

Once the user <NUM> has pressed this virtual button in a step <NUM>, the mobile application <NUM> sends in a step <NUM> an access request to the web server <NUM> including the device token <NUM>. At step <NUM> the web server <NUM> generates a guest user ID <NUM> and a passcode <NUM>. The user ID <NUM> is uniquely generated from the device token <NUM> and can be regenerated each time the device token <NUM> is received by the web server <NUM>. The passcode <NUM> is preferably a one-time password that is generated from the guest user ID <NUM> and a counter with a secret key using an encryption algorithm. The counter is incremented at regular time intervals, for instance every five seconds, so that the web server <NUM> can easily check a previous password generated within a predefined validity time window using a verification algorithm.

At step <NUM>, the web server sends the passcode <NUM> along with the device token <NUM> to the trusted provider <NUM>. At step <NUM>, the web server sends the guest user ID <NUM> to the mobile application <NUM>. Alternatively step <NUM> and <NUM> may be performed in reverse order. All these communications happen over standard TCP/IP protocol.

At step <NUM>, the trusted provider <NUM> uses the device token <NUM> to relay the passcode <NUM> through its push notification service to the mobile device <NUM>, then to the mobile application <NUM>.

At step <NUM>, the mobile application <NUM> returns the passcode <NUM> along with the guest user ID <NUM> to the web server <NUM>. At step <NUM>, the web server <NUM> verifies that the passcode <NUM> matches the guest user ID <NUM>. In case of a positive match, the web server <NUM> checks at step <NUM> whether a user account corresponding to the guest user ID <NUM> already exists in the database <NUM> and, if it is not the case, creates a user account in the database <NUM> at step <NUM>, using the guest user ID <NUM> as identifier. All subsequent interactions of the user <NUM> with the mobile application <NUM> will be recorded in the database <NUM> under this user account. If a user account already existed, as may be the case for subsequent connections, the process would go directly from step <NUM> to step <NUM>.

An attacker <NUM> willing to impersonate a guest user, or simulate thousands of guest users to cause a denial of service will not pass the test of step <NUM> and will not be given access to the features of the mobile application <NUM> available to guest or registered users. Indeed, only a legitimate user <NUM> of the mobile device <NUM> recorded by the trusted provider <NUM> will receive the passcode <NUM> through the push notification service.

At step <NUM>, the web server generates a session-based access token <NUM>, including the guest user ID <NUM>, and sends it to the mobile application <NUM> at step <NUM>. The session-based access token <NUM> is preferably a web token issued from an industry standard such as RFC <NUM>. Here is a typical example:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NTY3ODkwIiwi bmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ. SflKxwRJSMeKKF2QT4fwpMe Jf36POk6yJV_adQssw5c.

At step <NUM>, the user <NUM> is given access to the features of the mobile application <NUM> available to guest users. The session-based access token <NUM> will be used at step <NUM> for all subsequent communications between the mobile application <NUM> and the web server <NUM> during that session. At a step <NUM>, the interactions of the user <NUM> with the mobile application <NUM> are recorded in the database <NUM> under the user account corresponding to the guest user ID <NUM>.

At step <NUM>, the session ends because the user <NUM> closes the mobile application <NUM> or has not used it for a certain period of time. The guest user ID <NUM> and the session-based access token <NUM> are preferably erased from a memory of the mobile application <NUM> at step <NUM>.

The session-based access token <NUM> may also be valid for a limited period of time of typically one hour, and the steps <NUM> to <NUM> are repeated once this period has expired without the user <NUM> being aware of it, even while he/she is using the mobile application <NUM>. As the user account already exists, the process will resume at step <NUM>.

The device token <NUM> is retrieved by the mobile application <NUM> and resent each time the user <NUM> selects to use the mobile application in guest mode. The steps <NUM> to <NUM> are repeated. The device token <NUM> is returned with a new access request from the mobile application <NUM> to the web server <NUM>, and a new passcode <NUM>' is generated. In this manner, the legitimacy of the user <NUM> is verified and a new session-based access token <NUM>' is generated at each connection. As the guest user ID <NUM> is unique to the device token <NUM>, the corresponding interaction history is retrieved from the database <NUM> and made available to the user <NUM>.

Preferably, the device token <NUM> may be stored in the database <NUM> along with the guest user ID <NUM>, for sending push notification messages to the user <NUM> for any other purpose. However it is not required to store it for the sole purpose of guest user identification as it will be resent each time the user <NUM> selects to use the mobile application <NUM> in guest mode.

It shall be noted that a new device token <NUM>' may be generated each time a user installs the mobile application on a new device, reinstalls the mobile application on the same device, restore the device data from a backup or clears the application data. In any of those cases, a new guest user ID will be generated and the previous interaction history will no longer be available to the user <NUM>, although it may be kept in the database <NUM> for analytics purposes and retrieved later on by a system administrator.

<FIG> shows a guest user authentication and registration process according to the method of the invention.

As explained above, some of the mobile application features (i.e. additional features) may only be available to registered users and not to guest users. After using the mobile application <NUM> in guest mode for some time, the user <NUM> may select to register. In the following, we assume that the session-based access token <NUM> is still valid and is used by the mobile application <NUM> to communicate with the web server <NUM>. As described above, the guest user ID <NUM> is included in the session-based access token <NUM>.

At step <NUM>, the user <NUM> enters login information, typically an email address and a password in the mobile application <NUM> and press a "Register" button (or alternatively press a register button before entering login information). At step <NUM>, the mobile application sends the login information to the web server <NUM>. At step <NUM>, the web server <NUM> generates a verification code <NUM> and sends it at step <NUM> to the email address of the user <NUM> through an external email server (not represented). The verification code <NUM> is typically a short <NUM>-digits string that can be easily read and keyed-in by the user <NUM>. The verification code <NUM> is preferably a one-time password generated from the login information using a similar encryption algorithm as in step <NUM>. Alternatively, the verification code may be generated from the guest user ID <NUM> included in the session-base access token <NUM>.

At step <NUM>, the user <NUM> receives the email and enters it at step <NUM> into the mobile application <NUM>, which returns it along with the login information to the web server <NUM> at step <NUM>.

At step <NUM>, the web server <NUM> verifies the verification code <NUM> against the login information (or alternatively the guest user ID <NUM>) to authenticate the user <NUM>. If this verification is successful, the user account corresponding to the guest user ID <NUM> is updated in the database <NUM> with the login information at step <NUM>. The user <NUM> becomes a registered user. The same guest user ID <NUM> may serve to identify the user <NUM> in subsequent interactions or a new user ID, based for instance on his/her login information, may be created.

If any of the steps <NUM> to <NUM> above fails, for instance because the email address is invalid, or the verification code <NUM> is not returned within a time period of typically five minutes, an error message is sent at step <NUM> by the web server <NUM> to the mobile application <NUM> and displayed to the user <NUM> at step <NUM>. The user <NUM> may then retry his/her registration by entering login information again or continue to use the mobile application <NUM> in guest mode.

Otherwise, the process continues and at step <NUM> the interaction history corresponding to the guest user ID <NUM> is linked to the login information in the database <NUM>. This will enable the user <NUM> to retrieve his/her previous interaction history when login with his/her email address and password. At step <NUM> a confirmation message is sent by the web server <NUM> to the mobile application <NUM> and displayed at step <NUM> for informing the user <NUM> that he/she is successfully registered. Finally, the user <NUM> is given access to the additional features of the mobile application <NUM> at step <NUM>.

Alternatively, if at step <NUM> the previous session-based access token <NUM> has expired, the mobile application <NUM> may retrieve the device token <NUM> and send a new access request. The steps <NUM> to <NUM> are repeated and a new session-based access token <NUM> is generated. The registration process will then resume at step <NUM>.

The steps <NUM> to <NUM> may also be repeated during a regular login session. In this manner, an attacker <NUM> having stolen the login information, but not in possession of the mobile device <NUM>, will be blocked from accessing the interaction history of the user <NUM>. However the latter may not be able either to retrieve his/her own account information from another device, unless it is unlocked and/or migrated by a system administrator. Similarly, the identification process of the invention may be used to limit the number of (guest or registered) user accounts that can be enabled on the same mobile device.

A phone number may be entered as part of login information instead of an email address, provided that it can be used to send the verification code <NUM> to the user <NUM>. Indeed, the mobile application provider may prefer to communicate with its users in this manner.

A temporary password may be used as the passcode <NUM> or the verification code <NUM> instead of a one-time password. In this case, it would have to be stored in the database <NUM> together with the guest user ID <NUM> or the login information until it can be verified by the web server <NUM> after being returned by the mobile application <NUM>.

Claim 1:
A method for identifying as a guest a user (<NUM>) of a mobile application (<NUM>) installed on a mobile device (<NUM>) of the user (<NUM>), comprising the steps of:
- following a selection of the user (<NUM>) to use the mobile application (<NUM>) in guest mode, sending by the mobile application (<NUM>) an access request to a web server (<NUM>) of a web platform (<NUM>) operated by a provider of the mobile application, including a device token (<NUM>) generated by a trusted provider (<NUM>) operating a push notification service,
- generating by the web server (<NUM>) a guest user ID (<NUM>) and sending the guest user ID (<NUM>) to the mobile application (<NUM>),
- generating by the web server (<NUM>) a passcode (<NUM>) and sending the passcode (<NUM>) along with the device token (<NUM>) to the trusted provider (<NUM>),
- relaying by the trusted provider (<NUM>) through the push notification service the passcode (<NUM>) to the mobile device (<NUM>) and then to the mobile application (<NUM>),
- returning by the mobile application (<NUM>) the passcode (<NUM>) along with the guest user ID (<NUM>) to the web server (<NUM>),
- verifying by the web server that the returned passcode matches the guest user ID (<NUM>) and, in case of positive match
- creating by the web server a user account in a database <NUM> of the web platform (<NUM>), using the guest user ID (<NUM>) as identifier if the user account does not already exist in the database (<NUM>).