Systems and methods for multi-layer binding and authentication for a mobile device

Abstract

Use of an application on a mobile device is prone to user identity fraud and data theft. Systems and methods for multi-layer binding and authentication using an application on mobile device are provided. Within a session initiated by the application, a user account is data bound to a phone number of the mobile device using a session ID of the session: the phone number is data bound to a subscriber identity module (SIM) using a silent network authentication: a passkey is data bound to the user of the application using a biometric authentication executed by the mobile device; and the passkey is data bound to the phone number by associating the public key with the phone number.

Description

SYSTEMS AND METHODS FOR MULTI-LAYER BINDING AND AUTHENTICATION FOR A MOBILE DEVICECROSS-REFERENCE TO RELATED APPLICATION

[0001] The patent application claims priority to United States Patent Application No. 63 / 633,004, filed on April 11 , 2024, and titled “SYSTEMS AND METHODS FOR MULTILAYER BINDING AND AUTHENTICATION FOR A MOBILE DEVICE”, the entire contents of which are herein incorporated by reference.TECHNICAL FIELD

[0002] The disclosed exemplary embodiments relate to computer-implemented and mobile device implemented systems and methods for user authentication and, in particular, to multi-layer binding and authentication systems, devices and methods that include subscriber identity module (SIM) based authentication of a mobile device.BACKGROUND

[0003] Online user account creation and verification poses a technical challenge for software engineers and system architects. Many companies implement solutions that are very easy for the user and have to regard the risk of fraud or fake accounts as part of the cost of doing business. Many more secure methods have been proposed but suffer from the drawback that increasing the numbers of barriers leads to genuine users deciding not to proceed with the account creation. The resultant loss of customers can be greater than the losses due to fraud.

[0004] One traditional model of online identity - the combination of a username / email and password - has long outlived its usefulness where more security is required. It is known that many users use the same password or passwords for many accounts and forcing users to regularly change passwords simply results in them writing them down. A common improvement is to use multi-factor authentication or two-factor authentication (MFA or 2FA) in which a Short Message Service (SMS) passcode is sent to a mobilephone number. This approach addresses some of the vulnerabilities of authentication dependent on a single, knowledge-based factor, and is increasingly popular.

[0005] However, bad actors have also quickly learned how to exploit this verification method, leading to the problem of SIM swap fraud, in which typically, a bad actor finds out an individual’s mobile number and some personal information via a phishing scam, social engineering, or by buying information from other criminals. This information is then used to impersonate the victim to his or her mobile network operator (MNO) and to request the number be moved to a new SIM card. The MNO agent then issues a new SIM card with the user’s mobile number mapped to it, or moves the number to a bad actor’s SIM or eSIM. Once the SIM card goes live in the bad actor’s mobile phone, the original SIM stops working. Before this is noticed, the criminal can quickly log in to banking apps, social media and email, intercept the SMS codes and start stealing the user’s data and digital assets. The terms “app” and “application” are herein interchangeably used.SUMMARY

[0006] The following summary is intended to introduce the reader to various aspects of the detailed description, but not to define or delimit any invention.

[0007] In at least one broad aspect, a system and a method are provided that can utilize a software app on a mobile device to facilitate using a mobile phone number to authenticate a person and to establish multi-layer binding that in some cases includes: a user account, a digital ID of a mobile device (e.g., a phone number), a SIM card, a passkey, and a user or a characteristic known or provided by the user. These elements, including the passkey, can be used in subsequent instances for accessing a protected online resource (e.g., a secure database, a secure API, etc.), or for executing a protected online action (e.g., transmitting secure data, providing confirmation for a data action, transferring data values from one data account to another data account, etc.).

[0008] In some cases, the software app is a native mobile app, or a web browser, or both the native mobile app and the web browser are used to on the mobile device to perform the binding and verification.

[0009] In some cases, a silent network authentication is used to authenticate the mobile phone number by interacting with a MNO server over a mobile data network. In some other cases, the silent network authentication may be possible without the mobile device being on the mobile data network, depending on MNO implementation. In some cases, mobile phone number verification can be done without switching to mobile data.

[0010] In some cases, the passkey is synchronized and available across multiple devices by a cloud-based password / passkey manager. The phone number of the mobile device is bound to the passkey, of which the passkey private key is stored in the hardware- backed security storage device of the mobile device (“device-bound passkey”). In some cases, the phone number is bound to the passkey, in which the passkey private key is stored in the user secured cloud storage, and is synchronized between the users’ devices (“synched passkey”). In some cases, this binding is verified using a public key that is stored in association with the phone number on the authentication module (which in some cases resides on the authentication server).

[0011] In at least another broad aspect, a mobile device for multi-layer binding and authentication, is provided. The mobile device comprises: a memory storing an application and instructions; a communication interface; and one or more processors coupled to the memory and the communication interface. The one or more processors are configured to execute the instructions to: initiate a session using the application, the session identified by a session ID; and during the session: send, using the application, a phone number of the mobile device, which is receivable by a client server; send, using the application, the phone number, which is receivable by the client server; execute a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; receive, using the application, a message that a user account is verified, the user account associated with the application and the phone number, and the message transmittable by the client server;create, using the application, a passkey and store the passkey on the mobile device; and send, using the application, a public key of the passkey for storage, the public key receivable by an authentication server.

[0012] In some cases, during the session, the user account, the phone number, the passkey, the SIM, and a user of the mobile device are data bound together and are authenticated.

[0013] In some cases, the user account is data bound to the phone number using the session ID; the phone number is data bound to the SIM using the silent network authentication; the passkey is data bound to the user using a biometric authentication executed by the mobile device; and the passkey is data bound to the phone number by associating the public key with the phone number in the session.

[0014] In some cases, the user account, the phone number, the passkey, the SIM, and the user of the mobile device are used in a subsequent authentication process in a new session.

[0015] In some cases, the subsequent authentication process is computed before accessing a protected online resource, or wherein the subsequent authentication process is computed before executing a protected online action.

[0016] In some cases, the one or more processors are further configured to: receive an update message, using the application, indicating the passkey is verified, the update message transmittable by the authentication server; and, end the session using the application.

[0017] In some cases, during the session, and before initiating the SIM verification session, the application initiates creating the user account and linking the user account to the phone number.

[0018] In some cases, the communication interface comprises a cell network radio and a WIFI radio, and during at least a portion of the silent network authentication, the mobile device communicates with the MNO and the authentication server using only the cell network radio.

[0019] In some cases, the WIFI radio is deactivated prior executing the at least the portion of the silent network authentication.

[0020] In some cases, the silent network authentication with the MNO occurs without using a cell network radio.

[0021] In some cases, the user account is associated with at least a second mobile device; both the mobile device and the second mobile device are configured to communicate with a cloud-based passkey database; and mobile device sends a private key of the passkey to the cloud-based passkey database for storage and synchronization with the second mobile device.

[0022] In some cases, during the session, the one or more processors are further configured to: initiate, using the application, a subscriber identity module (SIM) verification sub-session, and, during the SIM verification sub-session: send the phone number, execute the silent network authentication with the MNO; receive the message that the user account is verified; and initiate, using the application, a passkey verification subsession, and, during the passkey verification sub-session: create the passkey and store the passkey on the mobile device, and send the public key of the passkey for storage.

[0023] In at least another broad aspect, a method is provided for multi-layer binding and authentication, which is executable by a mobile device. The method comprising: initiating a session using an application on the mobile device, the session identified by a session ID; and, during the session: sending, using the application, a phone number of the mobile device, which is receivable by a client server; sending, using the application, the phone number, which is receivable by the client server; executing a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; receiving, using the application, a message that a user account is verified, the user account associated with the application and the phone number, and the message transmittable by the client server;creating, using the application, a passkey and store the passkey on the mobile device; and sending, using the application, a public key of the passkey for storage, the public key receivable by an authentication server.

[0024] In at least another broad aspect, a server system is provided for multi-layered binding and authentication in a data network. The server system comprising one or more servers configured to communicate with a mobile device, and the one or more servers are configured to at least: engage in a session with an application of the mobile device, the session identified by a session ID; and, during the session: obtain a phone number of the mobile device; execute a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; verify a user account, which is associated with the phone number and the application; store a public key of a passkey, the passkey generated by the mobile device; and data bound together in a data store of the one or more servers, the user account, the phone number, the public key of the passkey, the SIM, and an indication of a user of the mobile device.

[0025] In some cases, the indication of the user of the mobile device is a biometric indication or verification, which is executed at the mobile device.

[0026] In some cases, the user account, the phone number, the passkey, the SIM, and the indication of the user of the mobile device are used in a subsequent authentication process in a new session.

[0027] In some cases, the subsequent authentication process is computed before accessing a protected online resource, or wherein the subsequent authentication process is computed before executing a protected online action.

[0028] In some cases, the user account is data bound to the phone number using the session ID; the phone number is data bound to the SIM using the silent network authentication; the passkey is data bound to the indication of the user using a biometricauthentication executed by the mobile device; and the passkey is data bound to the phone number by associating the public key with the phone number in the session.

[0029] In some cases, during at least a portion of the silent network authentication, the one or more servers or the MNO, or both, communicate with the mobile device using a cellular network, which is accessible by a cell network radio of the mobile device.

[0030] In some cases, a portion of the session is performed over a WiFi data network between the one or more servers and the mobile device, and the mobile device initiates switching from the WiFi data network to the cellular network during the session.

[0031] In some cases, the silent network authentication with the MNO occurs without using a cell network radio of the mobile device.

[0032] In some cases, the user account is associated with at least a second mobile device; the one or more servers comprises a cloud-based passkey database; and, when the cloud-based passkey database receives and stores a private key of the passkey from the mobile device, the one or more servers synchronizes the passkey with the second mobile device.

[0033] In at least another broad aspect, a method is provided for multi-layered binding and authentication in a data network, the method executable by a server system, and the method comprising: engaging in a session with an application of a mobile device, which is in communication with the server system, the session identified by a session ID; and, during the session: obtain a phone number of the mobile device; execute a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; verify a user account, which is associated with the phone number and the application; store a public key of a passkey, the passkey generated by the mobile device; anddata bound together in a data store of the one or more servers, the user account, the phone number, the public key of the passkey, the SIM, and an indication of a user of the mobile device.

[0034] According to some aspects, the present disclosure provides a non-transitory computer-readable medium storing computer-executable instructions. The computerexecutable instructions, when executed, configure a processor to perform any of the methods described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The drawings included herewith are for illustrating various examples of articles, methods, and systems of the present specification and are not intended to limit the scope of what is taught in any way. In the drawings:FIG. 1 is a schematic diagram of a system for authentication of a mobile device application, including a mobile device, a mobile network operator server, an authorization server, an app server, and a client server, in accordance with at least some embodiments;FIG. 2 is a block diagram of a computer in accordance with at least some embodiments;FIG. 3 is a block diagram of a mobile device in accordance with at least some embodiments;FIG. 4A is a flowchart diagram of an example method of a multi-layer identity binding and authentication process in accordance with at least some embodiments;FIG. 4B is a flowchart diagram of the example method that is part of the multi-layer identity binding and authentication process of FIG. 4A, specifically in cases when a passkey does not exist, in accordance with at least some embodiments;FIG. 4C is a flowchart diagram of the example method that is part of the multi-layer identity binding and authentication process of FIG. 4A, specifically in cases when a passkey does exist, in accordance with at least some embodiments;FIGs. 5A and 5B is a flowchart diagram of an example of a silent network authentication process that may be used in the multi-layer identity binding and authentication process, in accordance with at least some embodiments;FIG. 6 is a schematic diagram of data components that have been data bound and authenticated with each other to form multiple layers of binding and authentication, in accordance with at least some embodiments;FIGS. 7 A, 7B, 7C, 7D, 7E and 7F are a sequence of GUIs on an app on a mobile device for verifying a phone number to establish a passkey in accordance with at least some embodiments; andFIGs. 8A, 8B and 8C are a sequence of GUIs on the client app on the mobile device for logging in using the passkey in accordance with at least some embodiments.DETAILED DESCRIPTION

[0036] A system is provided that can utilize a software application (“app”) on a mobile device to facilitate using a mobile phone number to authenticate a person and to establish multi-layer binding that in some cases includes: a user account, a digital ID of a mobile device (e.g., a phone number), a Subscriber Identity Module (SIM) card, a passkey, and a user or a characteristic known or provided by the user. These elements, including the passkey, can be used in subsequent instances for accessing a protected online resource, or for executing a protected online action.

[0037] In some cases, an app is used to initiate a data session to establish a passkey, for example, if a passkey linked to a mobile device running the app has not yet been established. When establishing the passkey, other data elements are established or verified, or both, within the same session, and the other data elements include: a user account, a digital ID of a mobile device (e.g., a phone number), a SIM card (e.g., eSIM or data of the physical SIM card), and a user (e.g., via biometric authentication of the user or a password known to the user). In some cases, an indication of the user is data bound to these other data elements using a biometric authentication process (or some other process) involving the user at the mobile device. In some cases, by establishing or verifying (or both) these data elements in the same session, which involves datacommunication amongst different devices and / or servers, the system can bind these data elements together. The use of a single session is important to prevent unauthorized access to the multi-layered bindings and potentially introduce data which is not associated with the user. For example, a later update outside of the session could introduce a new phone number that does not belong to the user. This multi-layered authentication and binding improve the security and authentication of a user and their related data elements, which is useful and applicable, for example, when accessing a protected online resource, or when executing a protected online action.

[0038] In some other cases, when the passkey has already been established as part of a previous process for multi-layer binding and authentication, then the user account, the digital ID of a mobile device (e.g., a phone number), the SIM card (e.g., eSIM or data of the physical SIM card), and the user (e.g., via biometric authentication of the user or a password known to the user) are verified and / or authenticated, in a same session. By conducting this process in the same session, this helps to verify and / or authenticate each data component, as well as confirm that these data components are bound to each other.

[0039] In some cases, an existing app (e.g., a utility app, a banking app, a government app, or some other organization’s app) is adapted to include authentication features to authenticate a user’s access to a third-party client server. In some other cases, a dedicated authentication app is used to authenticate a user’s access to a third-party client server.

[0040] In some cases, the passkey refers to a passkey pair that includes a private key and a corresponding public key, also called a private passkey and a public passkey. In some cases, the private passkey is stored in a mobile device’s hardware-backed security device. Example embodiments of a mobile device’s hardware-backed security device include a hardware security module (HSM) (e.g., used in some cases for Android® phones) and a secure enclave (e.g., used in some cases in Apple® phones). In some cases, the private passkey stored on the mobile device’s hardware-backed security device is accessible after using a biometric scan to authenticate a user. In some cases, the private passkey and the public passkey are a FIDO2 key pair of a FIDO2 private key and a FIDO2 public key, where FIDO stands for Fast Identity Online and includes securityspecifications provided by the FIDO Alliance. In some cases, these passkeys may be backed up by the OEM (Original Equipment Manufacturer) that manufactures the hardware.

[0041] The named inventors of this application have recognized that the passkey is, in many cases, disconnected from the identity of the user. Possession of a key in many cases provides access, but it does not mean the identity of the user has been recognized and authenticated.

[0042] In some cases of the system and method provided herein, the identity is verified based on the mobile phone number and a passkey, to confirm that the user can be allowed to specify whether the passkey should be stored on a device of their choosing.

[0043] In some cases, the system uses an existing database that stores a preferred authentication factor in association with a known user identifier (e.g., a phone number, a username, an email, or some other identifier). In some cases, the known user identifier is stored in association with a phone number. In some other cases, the known user identifier is the phone number. In some other cases, the known user identifier is used as part of an Open ID Connect (OIDC) protocol to initiate the authentication process.

[0044] In some cases, a mobile phone number factor authentication does not require user intervention. This is also referred to as a “silent network authentication” using SIM factor authentication with a mobile network operator. In some cases, Silent Network Authentication (SNA) is used to authenticate and bind a digital ID of the mobile device (e.g., a phone number) and SIM card of the mobile device.

[0045] In some cases, a method is provided that includes verifying the mobile phone number of a user’s mobile device that is in an active data session, by using the SIM card as a strong authentication method, which can be independently verified, over APIs, with the mobile network operator. In some cases, an initial mobile identity registration requires the user to enter their mobile number for verification and prove its possession to then be bound to an identity as it may exist on an Identity Provider (IdP) or Identity Access Management (IAM) gateway. In some cases, the verification and possession of the mobile number is computed through the SNA. In some cases, the identity verification for logging in requires a user to enter their mobile phone number for verification, and if a userexists with that number, a verification is initiated. Alternatively, in some other cases, identity verification for logging in requires a user to provide another type of identifier, and the mobile phone number is retrieved (e.g., from a stored profile or some other input process) and used for SNA. Upon verification, the result and the user object are returned to the IdP or 1AM gateway.

[0046] In some cases, the system and method described herein are advantageous over “device fingerprinting” as SIM-based authentication is independent of the mobile handset, of the device operating system and of all applications. This may also make it immune to malware on the device — malicious programs that try to intercept sensitive information or assume elevated privileges from the user.

[0047] In some cases, the system and method described herein are advantageous over SMS One-Time-Passcodes as it is more secure and easier for the user. The system and method described, for example, helps to prevent phishing and man-in-the-middle attacks and reduces the risk of social engineering and Account Take Over attacks. In some cases, the system and method also improve the deliverability of the SMS Protocol, whereby the SMS Protocol is considered to lack deliverability guarantees.

[0048] In some cases, the system and method verify the user’s mobile phone number and SIM card by interacting with APIs provided by mobile network operators. SIM cards securely store keys that authenticate it to a mobile network and enable it to identify the International Mobile Subscriber Identity (I MSI) associated with the SIM. This can uniquely identify subscribers on mobile telephony devices (such as mobile phones and laptops — anything with a SIM card). If a third-party server (e.g., associated with a business) has a phone number associated with a digital identity, verifying the SIM card in a device associated with the same number can be used to authenticate the digital identity.

[0049] In some cases, mobile phone numbers are a digital identity, which can be identified and matched to a real-world persona through simple means such as calling a person. Proof of the presence of this digital identity can be obtained during a mobile digital session. After this proof has been obtained, a set of public / private keypairs (e.g., using the specification X.509) for the identity can be generated and bound to the mobile device that the user is using. This chain of being able to place trust on a phone number, verifyits possession, and then authorize a physical device can form a basis of trust. In some cases, this can be used to establish a hardware possession factor and user identity associated with the SIM and MNO.

[0050] In some cases, the physical SIM card is known as a Universal Integrated Circuit Card (UICC). An embedded SIM (eSIM) includes software installed onto an embedded UICC (eUlCC) chip permanently attached to or part of a device. After an eSIM carrier profile has been installed on an eUlCC, it operates the same as a physical SIM card, complete with a unique Integrated Circuit Card Identification number (ICCID) and network authentication key generated by the carrier. This process therefore works identically on physical as well as eSIMs. The cryptography baked into SIMs is tamper-proof to a whole suite of attacks, which prevent any unauthorized access even including physical tampering. In other words, the processes and system described herein may be adapted to mobile devices with a physical SIM card or an eSIM. An eSIM is sometimes also referred to as a virtual SIM or a digital SIM.

[0051] In some cases, man-in-the-middle attacks are prevented by the design of mobile data connectivity, which requires the device to directly connect to the mobile network operator. In some cases, if there is an indirection through non-mobile data connectivity , the Mobile Network Operator simply cannot identify the user and the verification fails.

[0052] Referring to FIG. 1 , a system 100 shows a mobile device 120, a mobile network operator (MNO) server 140, an authentication server 180, and a client server 160. The mobile device 120, the authentication server 180, the client server 160, and the MNO server 140 are configured to communicate with each other over a data network 130, such as the Internet.

[0053] The MNO server 140 and the mobile device 120 are also configured to communicate with each other over a mobile network 150 that includes cell towers and / or satellites. In some cases, the mobile network 150 is also called a cellular network.

[0054] The mobile device 120, for example, is a cell phone that includes a SIM card (e.g., a physical SIM card or an eSIM). The MNO server 140 is able to connect mobile phone calls and communicate with mobile devices using an IMSI that is unique to each SIM card. The Mobile Station International Subscriber Directory Number (MSISDN) is the mobilephone number which is commonly exchanged between users. The MSISDN includes a country code where the SIM is registered, a network code which identifies the network operator, and a subscriber number. The subscriber number is unique to each SIM and identifies an individual subscriber. In some other cases, other types of mobile devices that use a SIM card are used in the system described herein. Some other examples of mobile devices may include a tablet, a phablet, a laptop, a communication device embedded in a car or vehicle, a headset (e.g., for augmented reality).

[0055] The mobile device 120 also includes thereon an app 124 (also herein interchangeably called a client app) that the user uses to access the client server 160. In some cases, a browser 126 is stored on the mobile device 120, which is used to facilitate communication with the MNO server 140 over the mobile network 150. It will be appreciated that the browser 126 is a web browser or Internet browser.

[0056] In some cases, the user 122 is attempting to log in on the app 124 and undergoes authentication using the browser 126. In some other cases, the app 124 is used to establish multi-layer binding and authentication, and the browser 126 is not used in the process. In some other cases, the browser 126 is used to establish multi-layer binding and authentication, in place of the app 124, and the app 124 is not used in the process. In other words, the browser interacts with the client server; the browser interacts with the OIDC module; and the browser interacts with the mobile device’s hardware-backed security device to establish a FIDO passkey.

[0057] In some cases, the authentication server 180 also includes an authentication module 184, which can communicate with other systems using its own API.

[0058] In some cases, the client server 160 includes a user account database 164 that stores there on identifiers and information for user accounts and available types of authentication. For example, the client server 160 stores thereon, a user account identifier and a digital identifier of the mobile device (e.g., a phone number of the mobile device), and the phone number of the mobile device has been verified and bound to the SIM of the mobile device. In some cases, the user account identifier is “Bob@emailexample.com” that is associated with a mobile phone number (e.g., 886337944) and is further associated with a SIM factor authentication. In an alternativeexample, a user has a user account identifier that is the phone number of the mobile device (e.g., 886337944) itself. Other types of user account identifiers can be used.

[0059] In some cases, the authentication module 184, or more generally the authentication server 180, stores a mapping or association between the phone number of the mobile device, information about a passkey (e.g., a public key of the passkey) that is associated with the phone number of the mobile device, and data indicating a user’s actual presence that is associated with the passkey. In some cases, the user’s actual presence is verifiable via biometric scanning of the user and is also associated with authenticating the passkey (e.g., using FIDO2 authentication).

[0060] The client server 160 includes a client back end 162 that is configured to communicate with the client app 124. In other words, in some cases, when the user 122 interfaces with the client app 124 on their mobile device 120, the user 122 is interacting indirectly with the client server.

[0061] A user 122 uses the app 124 to engage with the client server 160. In some cases, a user wishes to access protected data on the client server 160, which requires user authentication. In some other cases, a user wishes to execute an action via the client server 160, which requires user authentication. The app 124 engages the authentication server 180 to initiate authentication. In some cases, the app 124 engages the authentication module 184 of the authentication server 180. In some cases, the app 124 engages the authentication module 184 in response to the client server 160 triggering a redirect of the app 124 to the authentication module 184. An authentication process is completed. After completing the authentication, the app 124 is able to access the restricted data or execute the action via the client server 160.

[0062] In some cases, many different clients (e.g., different client servers) can use the authentication process provided by the authentication server 180. In other words, using the process provided herein, the user 122 can access many different client services provided by different client servers by using the same known user identifier (e.g., a phone number, a username, an email, or some other identifier). This is part of the open ID connect protocol that allows for single sign-on capabilities.

[0063] Referring now to FIG. 2, there is illustrated a simplified block diagram of a computer in accordance with at least some embodiments. Computer 200 is an example implementation of a computer such as MNO server 140, client server 160, and authentication server 180. Computer 200 has at least one processor 210 operatively coupled to at least one memory 220, at least one communications interface 230 (also herein called a network interface), and at least one input / output device 240.

[0064] At least one memory 220 includes a volatile memory that stores instructions executed or executable by processor 210, and input and output data used or generated during execution of the instructions. Memory 220 may also include non-volatile memory used to store input and / or output data - e.g., within a database - along with program code containing executable instructions.

[0065] Processor 210 may transmit or receive data via communications interface 230 and may also transmit or receive data via any additional input / output device 240 as appropriate.

[0066] Referring to FIG. 3, there is illustrated a simplified block diagram of a mobile device 120 in accordance with at least some embodiments. The mobile device 120 includes a display 305, an input / output module 310 (e.g., a touch display screen, audio system, and / or physical buttons), one or more processors 315, one or more communication interfaces 320 (e.g., including different types of wireless communication modules or radios for interacting with the cell network, WiFi, BlueTooth, etc.), one or more cameras 325, one or more biometric scanners 330 (which in some cases includes the camera), a battery 335, a SIM card or eSIM module 340, a hardware-backed secure storage device 345 (e.g., hardware-backed security device, HSM, secure enclave, etc.), a memory system 350, and a data bus 370 for data-connecting the different components. The memory stores data about the mobile device 355. The memory also stores an operating system (OS) 360 and one or more applications that operate on the OS. The one or more applications include the browser or client app 124 (hereon called the app 124) that can data communicate with the client server 160. A browser 126 is also considered an application on the mobile device 120. Another application includes a camera app 362 that is used, in some cases, to scan a quick response (QR) code.

[0067] In some cases, the cell network radio 321 is used for all data communications between the mobile device 120 and the MNO server 140 over the mobile network 150, while the other data communications in the processes described herein may use the WIFI radio 322.

[0068] In some other cases, the cell network radio 321 is used for all data communications between the mobile device 120 and the MNO server 140, while the other data communications in the processes described herein may use one of, or a combination of, the WIFI radio 322 and the cell network radio 321.

[0069] An example of a biometric scanner 330 includes a facial scanner. This can include a camera or a Light Detection and Ranging (LIDAR) sensor, or both. Another example of a biometric scanner 330 includes a thumbprint scanner or reader. Another example of a biometric scanner 330 includes an eye scanner, which may include a camera. It will be appreciated that different currently known and future known biometric scanners could be used with the authentication processes described herein.

[0070] In some cases, the block diagram shown in FIG. 3 also applies to the secondary user device 121.

[0071] Referring now to FIG. 4A, an example compute and communication process 400 is shown between the system devices shown in FIGs. 1A and 1 B.

[0072] A session 401 is initiated by the app 124 on the mobile device 120. In some cases, the session 401 is identified by a session ID. In some cases, the session ID is created by the app 124.

[0073] In some cases, a session is established at a certain point in time, and then “tom down”, or brought to an end, at some later point. An established session may involve multiple data messages being transmitted in different directions between certain devices and / or servers, as discussed below. In some cases, a session is stateful, meaning that at least one of the communicating devices and / or servers holds current state information and saves information about the session history to be able to communicate. For example, stateful communication is opposed to stateless communication, where thecommunication consists of independent requests and responses, which must be correlated using unique identifiers in the communication.

[0074] In some cases, each session will have a unique session ID, so as to delineate data from amongst different sessions. In some cases, the session ID is stored by the devices and / or servers in association with some or all of the data, and / or with some or all of the actions, that are used during the session 401.

[0075] In some cases, if any of the steps fail (e.g,, verification fails, an expected message is not received, authentication fails, etc.) during the session 401 , then the session stops.

[0076] In FIG. 4A, at block 402, the app 124 sends a request to the mobile device 120 (e.g., via the OS 360) to attempt to use a passkey. At block 404, the mobile device 120 provides a response regarding the passkey. The app 124 determines, from the response, if a passkey exists (block 405). In some cases, the response indicates that the passkey does not exist, which may be indicated by failure to use the passkey. In some other cases, the response indicates that the passkey does exist and the authentication begins.

[0077] In some cases, the passkey includes a private key and a corresponding public key that are associated with the app 124 (or a user account identifier applicable to the app 124), the mobile device 120, and the user 122 (via biometric authentication). In some cases, the passkey private key is stored on the hardware-backed secure storage device 345 (e.g., the secure enclave or the hardware security module) and the passkey public key is returned to the app 124. In some cases, the public key is passed on to the client server 160 and the authentication module 184.

[0078] In cases in which the response indicates that the passkey does not exist, the session 401 continues to a process 410, shown in FIG. 4B, which includes establishing a passkey.

[0079] In cases in which the response indicates that the passkey does exist, the session 401 continues to a process 450, shown in FIG. 4C, which includes utilizing the existing passkey for multi-layer binding and authentication.

[0080] Referring now to FIG. 4B, the process 410 is shown, which is part of the same session 401. In some cases, the process 410 includes the app 124 and the client server160 creating a user account (block 412). For example, this includes the app 124 sending the phone number of the mobile device 120 to the client server 160. After the client server 160 obtains the phone number of the mobile device 120 and information about the user account (e.g., a user account ID, user account profile information, etc.), then the client server 160 links the user account and the phone number of mobile device (block 414).

[0081] A sub-session 416, which is part of the session 401 , is initiated for verifying the phone number of the mobile device and the user account. The sub-session 416 may be herein referred to as a SIM verification session, or SIM verification sub-session. In some cases, the sub-session 416 has its own sub-session ID (e.g., a first sub-session ID) that is linked to the session ID of session 401 .

[0082] As part of the sub-session 416, at block 418, the app 124 initiates an action redirect with the client server 160, which leads to the app 124 communicating with the authentication module 184. At block 420, the app 124 sends the phone number of the mobile device 120 to the client server 160. This initiates a silent network authentication (block 422), in which the SIM card or eSIM and the phone number are both verified to be associated with the mobile device 120 by the MNO server 140.

[0083] If the silent network authentication is successful, the authentication module 184 sends a message to the client server 160 indicating that the SIM card or eSIM and the phone number are verified (block 424). After receiving the message from block 424, the client server 160 then sends a message to the app 124 that the user account is verified (block 426). The sub-session 416 ends.

[0084] Another sub-session 428, which is part of the session 401 , is initiated for generating a passkey. The sub-session 428 may be herein referred to as a passkey session. In some cases, the sub-session 428 has its own sub-session ID (e.g., a second sub-session ID) that is linked to the session ID of session 401 .

[0085] In the sub-session 428, the app 124 initiates the mobile device 120 (e.g., via the OS 360) to generate a passkey that includes a public key and a private key pair (block 430). At block 432, the mobile device 120 links the passkey, the app 124 (or user account ID for the app), the mobile device 120 itself and the user 122 together using biometric authentication. For example, the biometric scanner 330 or a camera 325 (or both) on themobile device 120 is used to scan one or more biometric features of the user 122, and, if the user’s biometric features are authenticated by the user device, then the mobile device 120 saves the passkey in association with the app 124 (or user account ID associated with the app). In some cases, the passkey private key is saved in the hardware-backed secure storage device 345. By establishing and saving the passkey private key on the device in the process described, the mobile device inherently links the passkey, the app 124 (or user account ID associated with the app), the mobile device 120 itself and the user 122.

[0086] After the passkey is saved in the mobile device, the public key of the passkey is sent from the OS 360 of the mobile device to the app 124. The app 124 then sends the public key to the authentication module 184 for storage (block 434). The sub-session 428 ends.

[0087] At block 436, the authentication module 184 links the public key of the passkey and the phone number of the mobile device. At block 438, the authentication module 184 sends an update to the client server 160 indicating that the authentication and verification are complete. At block 440, the authentication module 184 sends an update to the app 124 indicating that the authentication and verification are complete. The session 401 ends.

[0088] In this way, the passkey is established, and the passkey, the user account (or the user account identifier), the phone number of the mobile device, the SIM card or eSIM of the mobile device, and the user are bound together and authenticated.

[0089] The app 124 then sends a message to the client server 160 to initiate the action (block 442), subsequent to the multi-layer binding and authentication.

[0090] Referring now to FIG. 4C, the process 450 is shown, which is part of the same session 401. This occurs, for example, if the passkey already exists.

[0091] In some cases, a sub-session 451 , which is part of the session 401 , is initiated for verifying the data components that have undergone the multi-layered binding and authentication. The sub-session 451 , for example, has its own sub-session ID (e.g., a third sub-session ID) that is linked to the session ID for the session 401 .

[0092] A sub-session 455, which is a subset of the sub-session 451 , is initiated. The subsession 455, in some cases, has its own sub-session ID (e.g., a fourth sub-session ID) that is linked to the sub-session ID of the sub-session 451 , and which is linked to the session ID of the session 401. The sub-session 455, for example, is for passkey verification.

[0093] It is noted that in FIG. 4A, the authentication of the passkey was already successfully begun in session 401 . In sub-session 455, at block 458, the app 124 initiates the mobile device 120 to perform a passkey verification. This includes, for example, the mobile device 120 (in some cases via the OS 360) scanning the user 122 for their biometric authentication (e.g., using the biometric scanner 330). In some cases, after completing the biometric authentication, the mobile device is able to access the private key of the passkey and provide a result for verification by the authentication module 184.

[0094] In some cases, the authentication module 184 sends, in the message from block 456, a challenge. This challenge is sent to the mobile device. The mobile device accesses the private key of the passkey that is stored in the hardware-backed secure storage device 345, subsequent to or as part of the biometric authentication. The mobile device then uses the private key of the passkey to digitally sign the challenge, generating a signed challenge. The signed challenge is then sent back to the authentication module for verification. In particular, the authentication module has the public key of the same passkey, and uses the public key to verify the signed challenge. It will be appreciated that currently known and future known approaches for verifying digital signatures for public key cryptography can be applied to the process described herein. In some cases, FIDO2 authentication is herein used.

[0095] At block 462, the mobile device OS returns the result of the passkey authentication (e.g., a signed challenge) to the app 124. At block 464, the app 124 sends the result to the authentication module 184 for verification. As noted above, the authentication module, for example, uses the stored public key of the passkey to verify the signed challenge. The sub-session 455 ends.

[0096] The authentication module, after verifying the signed challenge, stores an indicator or a state that the passkey and the user are authenticated (block 466). In other words,the authentication module 184 has confirmed that the passkey is authenticated and the user 122 (via biometrics) is present and authenticated.

[0097] At block 467, the sub-session 451 includes the app 124 sending the phone number of the mobile device to the authentication module 184

[0098] At block 468, the silent network authentication is executed. If successful, the authentication module 184 confirms that the SIM card or eSIM and the phone number are both associated with the same mobile device 120 and are verified (block 470). In some cases, this is stored in the authentication module 184.

[0099] After blocks 466 and 470, the authentication module 184 sends a result to the app 124 indicating that the verification of the multi-layer binding and authentication is complete (block 472). In other words, the result from block 472 indicates to the app 124 that the user account (indicative of the session ID of the app), the SIM card or eSIM of the mobile device, the phone number of the mobile device, the passkey, and the user are bound together and are authenticated.

[0100] The sub-session 451 ends. After, the session 401 ends.

[0101] The app 124 then sends a message to the client server 160 to initiate the action (block 442), subsequent to the multi-layer binding and authentication. As noted above, the action in some cases is to access data. In some other cases, the action is to execute a computation action.

[0102] In some cases, the session 401 is a subset or part of another session related to the action to be conducted by the app 124 or the client server 160, or both.

[0103] In some cases, the operations of block 470 (e.g., inclusive of blocks 468 and 470) and the operations of block 480 (e.g., inclusive of blocks 458, 460, 462, 464, and 466) occur in parallel. In some cases, operations of block 470 and the operations of block 480 occur in a differing order than what is shown in FIG. 4C. For example, the operations of block 480 are executed before the operations of block 470.

[0104] In some other cases, an example implementation of a silent network authentication, which is used in block 422, is shown in FIGs. 5A and 5B.

[0105] Referring to FIG. 5A, in some cases, the client server 160 initiates the silent network authentication.

[0106] Block 500: In some cases, the browser 126 at the mobile device 120 displays a message indicating that the phone checking process will be happening and requests the user to consent to proceed. In some cases, the message is displayed along with a control button that, when selected by user 122, is recorded as consent provided by the user 122 to proceed. In some cases, the record of user consent is stored in the client server 160 initially, and then such record is used as a signal to not require new user consent on subsequent authentication attempts.

[0107] Block 502: The client server 160 creates a silent network initialization request to the authentication module 184 for the phone number.

[0108] Block 504: The authentication module 184 creates a check uniform resource locator (URL) for the phone number. In some cases, the check URL also includes a unique identifier that is unique to the verification session 501 . The check URL, when opened or accessed by a browser, directs the browser to the MN O server 140 for checking the specific phone number (and in some cases the specific verification session).

[0109] Block 506: The authentication module 184 returns the check URL to the client server 160.

[0110] Block 508: The client server 160 sends the check URL to the mobile device 120, which is accessed via the browser 126.

[0111] Block 510: The mobile device opens a check URL on a browser 126 on the mobile device 120, and the browser 126 connects to the authentication module 184 for checking the phone number of the mobile device. This verification session 501 is done over mobile data, for example, using the cell network radio 321 that connects to the mobile network 150. The browser 126 on the mobile device 120 opens any provided redirect URL via the mobile network 150 (e.g., using mobile data), and, after following any additional provided redirects, connects to the MNO server 140.

[0112] In some cases, if the mobile device 120 has its WIFI radio turned on, the authentication module 184 can inform the mobile device to display a message to turn offthe WIFI radio, so that communication occurs using the mobile data over the mobile network 150. In some cases, networking libraries can be used to instruct the OEM OS on the mobile device to send this communication over mobile data.

[0113] Block 512: The MNO server 140 checks the IP address (internet protocol address) associated with the browser 126 and searches its MNO system (or MNO database) to determine the phone number of the mobile device assigned to the IP address. This is also called the assigned mobile phone number.

[0114] Block 514: The MNO server 140 then determines if the assigned mobile phone number matches the phone number it received as part of the redirects (at block 510).

[0115] If the MNO server 140 confirms that there is either a match or mismatch between the assigned mobile phone number and the mobile phone number from the redirects, then a verification code is transmitted by the MNO server. The verification code, for example, is unique to the session 501. Otherwise, if an error arises, then the MNO server returns an error message.

[0116] Block 516: The MNO server 140 sends the verification code via the mobile network 150 to the browser 126.

[0117] Block 518: The MNO server 140 sends the verification code to the authentication module 184.

[0118] The process continues in FIG. 5B.

[0119] Block 522: The browser 126 sends the verification code to the client server 160.

[0120] Block 524: The client server 160 issues a PATCH flow with the verification code to the authentication module 184. The PATCH operation is used to indicate how to modify the information in the authentication module 184 by adding the verification code received from client server 160 to the record for this specific silent number verification request.

[0121] Block 526: The authentication module 184 then compares the verification codes it has received (e.g., one verification received from the MNO server and oneverification code received from the client server 160) match each other, and looks up the match result. If the result is available, the process proceeds to block 528. In some cases, there may be other implementations of this code exchange. In some cases, the verification code should only be known by the mobile device and sent to the client server upon implicit or explicit user confirmation. This verification code can then be exchanged by the server for the result of the response. In some cases, making it mandatory for the mobile device to speak with the client server prevents phishing attempts.

[0122] Block 528: The authentication module 184 then issues a callback message to the client server 160, which includes a match result. The match result, for example, is an indication that the phone number was checked and verified. This is the SIM factor authentication that does not require user intervention. In some cases, this is herein called a silent network authentication as it does not require user intervention.

[0123] Block 530: The client server 160 communicates the results of the verification to the browser 126.

[0124] State 536: At this state, the phone verification is complete. This indicates that the SIM card or eSIM of the mobile device 120 and the phone number of the same mobile device are verified.

[0125] The implementation in FIGs. 5A and 5B is an example. In some other cases, other types of implementations of silent network authentication that involve the MNO 140 are applied to block 422. In some other cases, the silent network authentication may be possible without the mobile device 120 being on the mobile data network, depending on MNO implementation.

[0126] Referring to FIG. 6, the multi-layer binding of data components is shown.

[0127] The user account 602 that is associated with the app 124 is bound to the phone number 604 of the mobile device 120. In some cases, this binding is due to the session ID 650 of the session (e.g., session 401).

[0128] The phone number 604 of the mobile device 120 is bound to the SIM card or eSIM 340 of the mobile device 120. In some cases, this binding is verified using silent network authentication (such as at block 422).

[0129] The phone number 604 of the mobile device 120 is bound to the passkey 608, of which the passkey private key is stored in the hardware-backed security storage device 345 of the mobile device 120 (“device-bound passkey”). In some cases, the phone number is bound to the passkey, in which the passkey private key is stored in the user secured cloud storage, and is synchronized between the users’ devices (“synched passkey”). In some cases, this binding is verified using a public key 652 that is stored in association with the phone number 604 on the authentication module 184 (which in some cases resides on the authentication server 180).

[0130] The passkey 608 is bound to the user 122. In some cases, this binding is verified using biometric authentication 654, executed by the mobile device 120 in response to a passkey challenge from the authentication module 184.

[0131] In some cases, the bindings or mappings of the user account to the phone number, and the phone number to the SIM card or eSIM are stored on the client server 160 or authenticated by the client server 160.

[0132] In some cases, the bindings or mappings of the phone number to the passkey, and the passkey to the user are stored on the authentication module 184 or authenticated by the authentication module 184.

[0133] In some cases, the binding between the user account the phone number using the session ID occurs first; the binding between the phone number and the SIM card or eSIM using the silent network authentication occurs second; the binding between the passkey and the user using biometric authentication occurs third; and the binding between the passkey and the phone number using the public key of the passkey occurs fourth.

[0134] Other orders of operation may be used.

[0135] FIGs. 7A to 7F show a sequence of graphical user interfaces (GUIs) for an app 124 on a mobile device 120, to perform a user registration. The client app resides on the mobile device 120, so the session remains on the mobile device.

[0136] In FIG. 7A, the GUI shows a login screen with the option to register with a phone number and the option to sign in. A selection to register with a number is received.

[0137] In FIG. 7B, the GUI shows a user ID form. In this example, the user inputs the mobile phone number of the mobile device. The user then selects the control button to verify the mobile phone number.

[0138] In FIG. 7C, the GUI shows a message to ensure that the mobile data is turned on (e.g., the cell network radio is turned on), and shows the mobile phone number to be verified. It also includes, in some cases, a control button is shown, and is selected by the user, to continue with the process. In some cases, the app is able to switch automatically to mobile data without this message. In some cases, a progress indicator may be displayed on this screen such as a spinning wheel. In some cases, mobile phone number verification can be done without switching to mobile data, so this screen may be omitted.

[0139] In FIG. 7D, the GUI shows that the verification has been completed. It also optionally prompts the user to save a passkey and, in some cases, includes a control button to initiate the saving of a passkey. In this example, the control button is selected.

[0140] In FIG. 7E, the GUI shows a biometric scanning indicator. For example, a thumbprint or facial scan or eye scan is conducted.

[0141] In FIG. 7F, the GUI shows that the user is verified and that the client app can be used. In this example scenario, the passkey private key is stored on the mobile device.

[0142] Turning to FIGs. 8A to 8C, after the registration process shown in FIGS. 7A to 7F, a subsequent registration process is shown from the perspective of GUIs of the client app.

[0143] In FIG. 8A, the GUI shows a sign in button, which is selected by the user.

[0144] In FIG. 8B, the GUI shows a biometric scanning indicator. The mobile device conducts a biometric scan of the user.

[0145] In FIG. 8C, the GUI shows that the user is verified and enables the user to use the client app as desired.

[0146] Various systems or processes have been described to provide examples of embodiments of the claimed subject matter. No such example embodiment describedlimits any claim and any claim may cover processes or systems that differ from those described. The claims are not limited to systems or processes having all the features of any one system or process described above or to features common to multiple or all the systems or processes described above. It is possible that a system or process described above is not an embodiment of any exclusive right granted by issuance of this patent application. Any subject matter described above and for which an exclusive right is not granted by issuance of this patent application may be the subject matter of another protective instrument, for example, a continuing patent application, and the applicants, inventors or owners do not intend to abandon, disclaim or dedicate to the public any such subject matter by its disclosure in this document.

[0147] For simplicity and clarity of illustration, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, numerous specific details are set forth to provide a thorough understanding of the subject matter described herein. However, it will be understood by those of ordinary skill in the art that the subject matter described herein may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the subject matter described herein.

[0148] The terms “coupled” or “coupling” as used herein can have several different meanings depending in the context in which these terms are used. For example, the terms coupled or coupling can have a mechanical, electrical or communicative connotation. For example, as used herein, the terms coupled or coupling can indicate that two elements or devices are directly connected to one another or connected to one another through one or more intermediate elements or devices via an electrical element, electrical signal, or a mechanical element depending on the particular context. Furthermore, the term “operatively coupled” may be used to indicate that an element or device can electrically, optically, or wirelessly send data to another element or device as well as receive data from another element or device.

[0149] As used herein, the wording “and / or” is intended to represent an inclusive- or. That is, “X and / or Y” is intended to mean X or Y or both, for example. As a further example, “X, Y, and / or Z” is intended to mean X or Y or Z or any combination thereof.

[0150] Terms of degree such as "substantially", "about", and "approximately" as used herein mean a reasonable amount of deviation of the modified term such that the result is not significantly changed. These terms of degree may also be construed as including a deviation of the modified term if this deviation would not negate the meaning of the term it modifies.

[0151] Any recitation of numerical ranges by endpoints herein includes all numbers and fractions subsumed within that range (e.g., 1 to 5 includes 1 , 1.5, 2, 2.75, 3, 3.90, 4, and 5). It is also to be understood that all numbers and fractions thereof are presumed to be modified by the term "about" which means a variation of up to a certain amount of the number to which reference is being made if the result is not significantly changed.

[0152] Some elements herein may be identified by a part number, which is composed of a base number followed by an alphabetical or subscript-numerical suffix (e.g. 112a, or 112b). All elements with a common base number may be referred to collectively or generically using the base number without a suffix (e.g., 112).

[0153] The systems and methods described herein may be implemented as a combination of hardware or software. In some cases, the systems and methods described herein may be implemented, at least in part, by using one or more computer programs, executing on one or more programmable devices including at least one processing element, and a data storage element (including volatile and non-volatile memory and / or storage elements). These systems may also have at least one input device (e.g. a pushbutton keyboard, mouse, a touchscreen, and the like), and at least one output device (e.g. a display screen, a printer, a wireless radio, and the like) depending on the nature of the device. Further, in some examples, one or more of the systems and methods described herein may be implemented in or as part of a distributed or cloud-based computing system having multiple computing components distributed across a computing network. For example, the distributed or cloud-based computing system may correspond to a private distributed or cloud-based computing cluster that is associated with an organization. Additionally, or alternatively, the distributed or cloud-based computing system be a publicly accessible, distributed or cloud-based computing cluster, such as a computing cluster maintained by Microsoft Azure™ , Amazon Web Services™ , GoogleCloud™, or another third-party provider. In some instances, the distributed computing components of the distributed or cloud-based computing system may be configured to implement one or more parallelized, fault-tolerant distributed computing and analytical processes, such as processes provisioned by an Apache Spark™ distributed, clustercomputing framework or a Databricks™ analytical platform. Further, and in addition to the CPUs described herein, the distributed computing components may also include one or more graphics processing units (GPUs) capable of processing thousands of operations (e.g., vector operations) in a single clock cycle, and additionally, or alternatively, one or more tensor processing units (TPUs) capable of processing hundreds of thousands of operations (e.g., matrix operations) in a single clock cycle.

[0154] Some elements that are used to implement at least part of the systems, methods, and devices described herein may be implemented via software that is written in a high-level procedural language such as object-oriented programming language. Accordingly, the program code may be written in any suitable programming language such as Python or Java, for example. Alternatively, or in addition thereto, some of these elements implemented via software may be written in assembly language, machine language or firmware as needed. In either case, the language may be a compiled or interpreted language.

[0155] At least some of these software programs may be stored on a storage media (e.g., a computer readable medium such as, but not limited to, read-only memory, magnetic disk, optical disc) or a device that is readable by a general or special purpose programmable device. The software program code, when read by the programmable device, configures the programmable device to operate in a new, specific, and predefined manner to perform at least one of the methods described herein.

[0156] Furthermore, at least some of the programs associated with the systems and methods described herein may be capable of being distributed in a computer program product including a computer readable medium that bears computer usable instructions for one or more processors. The medium may be provided in various forms, including non-transitory forms such as, but not limited to, one or more diskettes, compact disks, tapes, chips, and magnetic and electronic storage. Alternatively, the medium may betransitory in nature such as, but not limited to, wire-line transmissions, satellite transmissions, internet transmissions (e.g., downloads), media, digital and analog signals, and the like. The computer usable instructions may also be in various formats, including compiled and non-compiled code.

[0157] While the above description provides examples of one or more processes or systems, it will be appreciated that other processes or systems may be within the scope of the accompanying claims.

[0158] To the extent any amendments, characterizations, or other assertions previously made (in this or in any related patent applications or patents, including any parent, sibling, or child) with respect to any art, prior or otherwise, could be construed as a disclaimer of any subject matter supported by the present disclosure of this application, Applicant hereby rescinds and retracts such disclaimer. Applicant also respectfully submits that any prior art previously considered in any related patent applications or patents, including any parent, sibling, or child, may need to be revisited.

Claims

What is claimed is:1 . A mobile device for multi-layer binding and authentication, the mobile device comprising: a memory storing an application and instructions; a communication interface; and one or more processors coupled to the memory and the communication interface, the one or more processors being configured to execute the instructions to: initiate a session using the application, the session identified by a session ID; and, during the session: send, using the application, a phone number of the mobile device, which is receivable by a client server; send, using the application, the phone number, which is receivable by the client server; execute a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; receive, using the application, a message that a user account is verified, the user account associated with the application and the phone number, and the message transmittable by the client server; create, using the application, a passkey and store the passkey on the mobile device; and send, using the application, a public key of the passkey for storage, the public key receivable by an authentication server.

2. The mobile device of claim 1 , wherein, during the session, the user account, the phone number, the passkey, the SIM, and a user of the mobile device are data bound together and are authenticated.

3. The mobile device of claim 2, wherein the user account is data bound to the phone number using the session ID; the phone number is data bound to the SIM using the silent network authentication; the passkey is data bound to the user using a biometric authentication executed by the mobile device; and the passkey is data bound to the phone number by associating the public key with the phone number in the session.

4. The mobile device of claim 2, wherein the user account, the phone number, the passkey, the SIM, and the user of the mobile device are used in a subsequent authentication process in a new session.

5. The mobile device of claim 4, wherein the subsequent authentication process is computed before accessing a protected online resource, or wherein the subsequent authentication process is computed before executing a protected online action.

6. The mobile device of claim 1 , wherein the one or more processors are further configured to: receive an update message, using the application, indicating the passkey is verified, the update message transmittable by the authentication server; and end the session using the application.

7. The mobile device of claim 1 , wherein, during the session, and before initiating a SIM verification session, the application initiates creating the user account and linking the user account to the phone number.

8. The mobile device of claim 1 , wherein the communication interface comprises a cell network radio and a WIFI radio, and during at least a portion of the silent network authentication, the mobile device communicates with the MNO and the authentication server using only the cell network radio.

9. The mobile device of claim 8, wherein the WIFI radio is deactivated prior executing the at least the portion of the silent network authentication.

10. The mobile device of claim 1 , wherein the silent network authentication with the MNO occurs without using a cell network radio.11 . The mobile device of claim 1 , wherein the user account is associated with at least a second mobile device; both the mobile device and the second mobile device are configured to communicate with a cloud-based passkey database; and mobile device sends a private key of the passkey to the cloud-based passkey database for storage and synchronization with the second mobile device.

12. The mobile device of claim 1 , wherein, during the session, the one or more processors are further configured to: initiate, using the application, a subscriber identity module (SIM) verification subsession, and, during the SIM verification sub-session: send the phone number, execute the silent network authentication with the MNO; receive the message that the user account is verified; and initiate, using the application, a passkey verification sub-session, and, during the passkey verification sub-session: create the passkey and store the passkey on the mobile device, and send the public key of the passkey for storage.

13. A method for multi-layer binding and authentication, executable by a mobile device, the method comprising initiating a session using an application on the mobile device, the session identified by a session ID; and, during the session: sending, using the application, a phone number of the mobile device, which is receivable by a client server; sending, using the application, the phone number, which is receivable by the client server;executing a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; receiving, using the application, a message that a user account is verified, the user account associated with the application and the phone number, and the message transmittable by the client server; creating, using the application, a passkey and store the passkey on the mobile device; and sending, using the application, a public key of the passkey for storage, the public key receivable by an authentication server.

14. A server system for multi-layered binding and authentication in a data network, the server system comprising one or more servers configured to communicate with a mobile device, and the one or more servers configured to at least: engage in a session with an application of the mobile device, the session identified by a session ID; and, during the session: obtain a phone number of the mobile device; execute a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; verify a user account, which is associated with the phone number and the application; store a public key of a passkey, the passkey generated by the mobile device; and data bound together in a data store of the one or more servers, the user account, the phone number, the public key of the passkey, the SIM, and an indication of a user of the mobile device.

15. The server system of claim 14, wherein the user account, the phone number, the passkey, the SIM, and the indication of the user of the mobile device are used in a subsequent authentication process in a new session.

16. The server system of claim 15, wherein the subsequent authentication process is computed before accessing a protected online resource, or wherein the subsequent authentication process is computed before executing a protected online action.

17. The server system of claim 14, wherein the user account is data bound to the phone number using the session ID; the phone number is data bound to the SIM using the silent network authentication; the passkey is data bound to the indication of the user using a biometric authentication executed by the mobile device; and the passkey is data bound to the phone number by associating the public key with the phone number in the session.

18. The server system of claim 14, wherein during at least a portion of the silent network authentication, the one or more servers or the MNO, or both, communicate with the mobile device using a cellular network, which is accessible by a cell network radio of the mobile device.

19. The server system of claim 18, wherein a portion of the session is performed over a WiFi data network between the one or more servers and the mobile device, and the mobile device initiates switching from the WiFi data network to the cellular network during the session.

20. The server system of claim 14, wherein the silent network authentication with the MNO occurs without using a cell network radio of the mobile device.21 . The server system of claim 14, wherein the user account is associated with at least a second mobile device; the one or more servers comprises a cloud-based passkey database; and, when the cloud-based passkey database receives and stores a private key of the passkey from the mobile device, the one or more servers synchronizes the passkey with the second mobile device.

22. A method for multi-layered binding and authentication in a data network, the method executable by a server system, the method comprising: engage in a session with an application of a mobile device, which is in communication with the server system, the session identified by a session ID; and, during the session: obtain a phone number of the mobile device; execute a silent network authentication with a mobile network operator (MNO) associated with the mobile device to confirm that a Subscriber Identity Module (SIM) of the mobile device and the phone number are verified; verify a user account, which is associated with the phone number and the application; store a public key of a passkey, the passkey generated by the mobile device; and data bound together in a data store of the one or more servers, the user account, the phone number, the public key of the passkey, the SIM, and an indication of a user of the mobile device.

Images