Patent Description:
Presently, mobile communication devices utilize a variety of technologies and formats, which may include, for example, GSM (Global System for Mobile Communication), CDMA (Code Division Multiple Access), and/or UMTS (Universal Mobile Telecommunications System) technologies depending on the service provider of choice. In order to store the necessary provisioning data that allows the mobile device to communicate with a wireless communications network, GSM and UMTS mobile devices utilize a Subscriber Identity Module ("SIM"), commonly known as a SIM Card.

By utilizing SIM Cards, a user may select a service provider to use based upon which service provider will provide the optimal service for the user's specific need. Then the user may simply replace the current SIM Card with the SIM Card of the desired service provider on a per-usage basis. By carrying multiple SIM Cards, each containing the provisioning information of a different service provider, a user may switch service providers simply by physically switching SIM Cards.

<CIT> describes a method of providing connectivity to a vehicle and authentication of a device on a vehicle using a virtual SIM. <CIT> describes a method and apparatus to provide access to communication services using dynamically assigned user credentials.

With the virtual SIM technology described herein in connection with the present disclosure, users will be able to use the best service available from different service providers without purchasing and switching physical SIM Cards.

The described aspects apply to mobile and wireless communication devices, including cellular telephones, smart-phones, tablets, mobile hotspots, laptop computers, palmtop computers, Ultra-Mobile Personal Computers (UMPC), PDA, dual-mode (tele- and data-communications) phones, and other devices capable of voice and/or data communications like text messaging, Internet browsing, etc, such as a Blackberry® handheld device or portable computer. Embodiments of the present disclosure makes wireless communication clients more convenient and less expensive to operate in a multitude of geographic locations, such as in different countries, different regions within a large country, or where different communications technologies are required, such as CDMA and GSM.

In one aspect, a system according claim <NUM> is defined.

Further advantageous systems are defined by dependent claims <NUM> to <NUM>.

In another aspect, a method is defined according to claim <NUM>.

Further advantageous methods are defined by dependent claims <NUM> to <NUM>.

In another aspect, a wireless communications device is defined according to claim <NUM>.

The features of the various aspects are set forth with particularity in the appended claims. The various aspects, both as to organization and methods of operation, together with advantages thereof, may, however best be understood by reference to the following description, taken in conjunction with the accompanying drawings as follows:.

Other examples, features, aspects, aspects, and advantages of the technology will become apparent to those skilled in the art from the following description, which is, by way of illustration, one of the best modes contemplated for carrying out the technology.

<FIG> shows a communications system <NUM> that includes a wireless communication network <NUM> coupled to a voice network <NUM>, such as a public switched telephone network (PSTN), and a data network <NUM>. The communications system <NUM> also includes an administration system <NUM> coupled to the voice network <NUM> and data network <NUM>. The wireless communications network <NUM> may be used to communicate voice and/or data and includes cellular telephone, WIFI, or WIMAX networks. In the case of a cellular telephone network, the network <NUM> includes a number of cellular sites or base stations <NUM>, which typically consist of an antenna tower, transceiver radios (i.e., base transceiver station), and radio controllers (i.e., base station controller). In the case of data networks, such as WIFI or WIMAX, the network <NUM> includes a number of base stations <NUM>, which typically include access points, wireless routers, or the like. Base stations <NUM> include a transceiver, or a transmitter and receiver, through which radio links are established between the network <NUM> and a number of wireless communication clients, including the wireless communication client <NUM>. The wireless communication client <NUM> may be any telephone or computing device capable of communicating wirelessly, such as a cellular telephone handset, personal digital assistant (PDA), computer, VOIP gateway, SIP phone, or the like. In some embodiments, the wireless communication client <NUM> must be capable of accessing and communicating data.

Also shown in <FIG> is an optional wireless communication extension unit <NUM>. In these embodiments, the extension unit <NUM> is capable of communicating with both the wireless communication client <NUM> and the wireless communication network <NUM>, including base station <NUM>. Also, as used herein the combination of the wireless communication client <NUM> and/or the extension unit <NUM> is referred to as the wireless communication system <NUM>.

The provider <NUM> of the wireless network <NUM> is coupled to the one or more base stations <NUM>. This service provider <NUM> is also coupled to the voice network <NUM> and the data network <NUM>.

For convenience, the remainder of the description of <FIG> will refer to the embodiment where the wireless network <NUM> is a cellular telephone network, such as a GSM, GPRS (General Packet Radio Service), CDMA (Code Division Multiple Access), EDGE Enhanced Data for GSM Evolution, 3GSM, DECT, IS-<NUM>, and iDEN, analog, and any combination of these, and the like. However, it should be appreciated that the same system can be used for providing any other type of wireless voice or data service, such as WIMAX, WiFI, VOIP, etc..

The service provider <NUM> may include a number of mobile telephone switching centers ("MSC"), located at one or more mobile telephone switching offices ("MTSO") which route the transmissions. Additionally, the service provider <NUM> may include one or more base cellular centers ("BSC"), not shown, coupled between base stations <NUM> and the MSCs <NUM>, for example, to handle call hand off.

The service provider <NUM> constantly monitors the signal strength of both the caller and receiver, locating the next cell site when signal strength fades, and automatically rerouting the communications to maintain the communications link. For example, when the wireless communication client <NUM> moves from one cell to another cell, the service provider <NUM> monitors the movement, and transfers or hands-off the telephone call from a first base station to a new base station at the appropriate time. The transfer may include switching the radio frequency of the communication, and is transparent to the user. Thus, the service provider <NUM> acts like a standard PSTN or ISDN switching node, and additionally provides mobile subscriber related functions such as registration, authentication, location updating, handovers and call routing to roaming subscribers.

The service provider <NUM> typically employs one or more databases (e.g., Home Location Register "HLR" and a Visitor Location Register "VLR") for tracking subscribers, routing calls and roaming. The service provider <NUM> also typically employs a database (e.g., Authentication Center "AuC") for authenticating subscribers, and a separate database (e.g., Equipment Identity Register "EIR") for verifying the equipment. The service provider <NUM> allocates a routing number to each of the calls that the service provider <NUM> is switching. While the routing number is different than the unique subscriber identifier (e.g., IMSI) and the unique equipment identifier (e.g., International Mobile Equipment Identity "IMEI"), the MTSO may define a relationship between the routing number and the subscriber and/or equipment identifiers associated with each wireless communication client <NUM>. These identifiers allow the service provider <NUM> to track and coordinate all wireless communication clients <NUM> in its service area, and also allow the service provider <NUM> to determine the validity of the call and caller.

As is well understood and documented in the art, the service provider <NUM> routes voice communications to other callers on its network, through its network of base stations <NUM>, or to the PSTN network <NUM>. Data communications are routed to the data network <NUM>, which is typically the Internet.

The data network <NUM> is coupled to the administration system <NUM>. The administration system <NUM> provisions the foreign wireless communication client <NUM> to operate in a local wireless communication network <NUM> as if it were a local wireless communication client. By "foreign" it is meant that the wireless communication client <NUM> (or its SIM card) is not subscribed to the wireless communications network <NUM>. For example, a cellular telephone associated with a wireless contract with AT&T® in San Francisco (the foreign wireless communication client) is not subscribed to the VODAPHONE® cellular telephone network in London (the local wireless communication network). Here, the administration system <NUM> enables the AT&T® cellular telephone to operate in London as if it were a cellular telephone associated with a contract with VODAPHONE® in London.

The administration system <NUM> includes at least one authentication server <NUM> coupled to a subscriber database <NUM> and an authentication bank <NUM>, as well as at least one optional communications server <NUM> coupled to a routing database <NUM>. The authentication server <NUM> primarily authenticates incoming requests for authentication and maintains subscriber accounts. The communications server <NUM> facilitates the rerouting of non-local calls to further provide reduced cost routing. The administration system <NUM> includes at least one provisioning server <NUM>, which provides requesting subscribers with remote authentication software. The provisioning server <NUM> and/or authentication server <NUM> and/or communications server <NUM> may be implemented as one or more components local to regional networks, at a central location, at enterprise computing/communications centers, or in consumer products.

The one or more authentication banks <NUM> and/or the one or more subscriber databases <NUM> may be commonly housed or housed separately from the one or more associated authentication servers <NUM>, communication servers <NUM>, and routing databases <NUM>. Some embodiments of the administration system <NUM> may include additional components for redundancy and faster access time.

<FIG> is a diagram <NUM> illustrating a system implementing virtual SIM technology according to one aspect of the present disclosure. A Virtual SIM Terminal <NUM> is in communication with a Virtual SIM Server <NUM> over the Internet <NUM>, for example. For convenience, the term Virtual SIM Terminal <NUM> may be used to mean a mobile device capable of cellular communication without physical SIM Cards. The terms VirtualSIM or VSIM may be used to mean software that runs in internal memory on a mobile device, which implements the logics and functions of the software running on a physical SIM Card except for the authentication (e.g., Ki authentication) logics. The term SoftSIM may be used to mean software that runs in internal memory on a mobile device, which implements the logics and functions of the software running on a physical SIM Card including the authentication (e.g., Ki authentication) logics. The term simulated SIM may be used to mean either VirtualSIM or SoftSIM, or a combination thereof. The term or acronym HWSIM may be used to mean physical SIM Card. Finally, the term Virtual SIM Server <NUM> may be used to mean a server that provides SIM profiles and authentication functions for the VirtualSIM. The Virtual SIM Terminal <NUM> may be, for example, the wireless communication client <NUM> or the extension unit <NUM> described with reference to <FIG>, or a combination thereof. The Virtual SIM Server <NUM>, for example, may be one or more of the authentication server <NUM>, the provisioning server <NUM>, and the communications server <NUM> described with reference to <FIG>. The Virtual SIM Server <NUM> may provide SIM profiles at least in part by accessing the subscriber database <NUM> described with reference to <FIG>, and may provide authentication functions at least in part by accessing the authentication bank <NUM> described with reference to <FIG>.

In a Virtual SIM Terminal <NUM> configuration, the mobile device may communicate with VirtualSIM and SoftSIM modules without accessing a physical SIM Card. VirtualSIM and SoftSIM may process the requests and send responses back to the mobile device. In other words, VirtualSIM and SoftSIM may perform the functions of a physical SIM Card.

Before a user turns on the Virtual SIM Terminal <NUM>, the SoftSIM profile may be provisioned on the mobile device. At the time of bootstrapping, SoftSIM may establish a data connection between the Virtual SIM Terminal <NUM> and the Virtual SIM Server <NUM> (sometimes referred to as the back-end server, or the remote server) via the Internet, and download the basic VirtualSIM profile data excluding authentication information (e.g., Ki authentication information). The VirtualSIM profile may be selected based on quality and cost of services among carriers.

The Virtual SIM Terminal <NUM> may use the VirtualSIM profile to provide the service to end-users after it is provisioned. When the network challenges the terminal for authentication (e.g., Ki authentication), the VirtualSIM may send the authentication request to the Virtual SIM Server through the data connection previous established by the SoftSIM. The Virtual SIM Server may route the request to the physical cards connected to it and send the authentication response back to the Virtual SIM Terminal <NUM>.

In some embodiments, the SoftSIM profile may be associated with a foreign SIM profile which is subject to roaming charges, and the VirtualSIM profile may be associated with a local SIM profile which is not subject to roaming charges. By using the SoftSIM mainly for authentication purposes and using the VirtualSIM for other communications, service charges may be reduced.

<FIG> is a diagram <NUM> illustrating a configuration without VirtualSIM/SoftSIM and <FIG> is a diagram <NUM> illustrating a configuration with VirtualSIM/SoftSIM, according to one aspect of the present disclosure. In the configuration without VirtualSIM/SoftSIM as shown in diagram <NUM> of <FIG>, the software on the mobile device or Mobile Equipment <NUM> ("ME") accesses a physical SIM card or USIM card <NUM> via an ISO7816 hardware interface <NUM>. In the configuration with VirtualSIM/SoftSIM as shown in diagram <NUM> of <FIG>, the architecture supports both the physical SIM/USIM Card <NUM> and VirtualSIM/SoftSIM <NUM>. In normal mode, the VirtualSIM/SoftSIM module <NUM> is transparent and all commands between the software and the ISO7816 hardware interface <NUM> will pass through. When the VirtualSIM/SoftSIM <NUM> logic is activated, it may intercept the control data and act as a physical SIM/USIM Card <NUM>.

<FIG> is a diagram illustrating a VirtualSIM module <NUM> according to one aspect of the present disclosure. The VirtualSIM module <NUM> may comprise two components <NUM>, <NUM>, which may be denoted by GMATEs <NUM> and GMATEm <NUM>, respectively. The GMATEs <NUM> and the GMATEm <NUM> components may be processes running on a mobile device, for example. In one embodiment, the GMATEs <NUM> may be implemented on an application processor ("AP"), and the GMATEm <NUM> may be implemented on a MODEM. The GMATEs <NUM> and the GMATEm <NUM> may communicate via a Remote Procedure Call ("RPC") communication channel <NUM>. Once the GMATEm <NUM> starts, the MODEM treats the GMATEm <NUM> as a SIM Card. If there are multiple MODEMs, there may be one GMATEm <NUM> for each MODEM, and each GMATEm <NUM> may connect to the GMATEs <NUM> via RPC.

The VirtualSIM module <NUM> may further comprise an application ("APP") <NUM> for controlling the functionality of the SIM simulator <NUM> and a man-machine interface ("MMI") <NUM> for receiving user input. User interaction is implemented on the APP <NUM> or the MMI <NUM>. In Android systems, MMI <NUM> is implemented in APP <NUM>. Other systems might implement the MMI <NUM> on the interface layer. Since it is more convenient to modify and update the functionality of the VirtualSIM module <NUM> on APP <NUM> or MMI <NUM>, most of the functions of the VirtualSIM module <NUM> may be implemented in the GMATEs <NUM>.

<FIG> is a diagram illustrating a GMATEm component <NUM> according to one aspect of the present disclosure. As discussed above, the GMATEm <NUM> may be a process running on a MODEM. The GMATEm <NUM> may comprise an RPC communication module <NUM>, a VirtualSIM driver <NUM>, and a SIM switching controller <NUM>. The RPC communication module <NUM> may be in communication with GMATEs <NUM> via RPC, and may be in communication with the SIM switching controller <NUM> and the VirtualSIM driver <NUM>.

Traditionally, a SIM application module <NUM> communicates with a physical SIM card <NUM> through a SIM card driver <NUM>. The physical SIM card driver <NUM> receives commands from the SIM application <NUM> and communicates with the physical SIM Card <NUM> through an ISO7816 interface. The MODEM reads and writes on the physical SIM card <NUM> through the SIM application <NUM> and the SIM card driver <NUM>.

As shown in <FIG>, the SIM switching controller <NUM> may intercept the communication between the SIM application module <NUM> and the SIM card driver <NUM>. The RPC communication module <NUM> may send a SIM switching command to the SIM switching controller <NUM>. In response to the command, the SIM switching controller <NUM> may selectively couple the SIM application <NUM> to the VirtualSIM driver <NUM> or the physical SIM card driver <NUM>. Therefore, the SIM switching controller <NUM> may route data from the SIM application <NUM> to either the VirtualSIM driver <NUM> or the physical SIM card driver <NUM>.

The VirtualSIM driver <NUM> may run on the MODEM. The VirtualSIM driver <NUM> may be an adapter that implements the same interface as the physical SIM card driver <NUM> when it communicates with the SIM card application <NUM>. The VirtualSIM driver <NUM> may send RESET, PPS (Protocol and Parameter Selection), APDU (Application Protocol Data Unit), and other control data received from the SIM application module <NUM> to the RPC communication module <NUM>, which may relay the control data to GMATEs <NUM>. The VirtualSIM driver <NUM> may also notify the SIM application <NUM> that the SIM card has been changed and request the SIM application <NUM> to reset and read the new SIM card information.

<FIG> is a diagram illustrating a GMATEs component <NUM> according to one aspect of the present disclosure. As discussed above, the GMATEs <NUM> may be a process running on an AP. The GMATEs <NUM> may need to have root access to connect to the MODEM via RPC. The GMATEs <NUM> may comprise a GMATEs application module <NUM>, a SIM simulator <NUM>, and a RPC communication module <NUM>.

The RPC communication module <NUM> may send/receive control data to/from the GMATEm <NUM> implemented on the MODEM. The RPC communication module <NUM> may need to send or receive at least <NUM> bytes of data, respond with a confirmation, and wait until it receives the responses from the MODEM.

The SIM card simulator <NUM> may be in communication with the GMATEm <NUM> via the RPC communication module <NUM>. The SIM card simulator <NUM> may function as a SIM card operating system. The SIM card simulator <NUM> may control the selective coupling of the SIM switch controller <NUM>, and may receive requests from the SIM card application module <NUM> on the MODEM and respond with SIM card profile information such as ICCID (integrated Circuit Card ID), IMSI (International Mobile Subscriber Identity) received from a back-end server <NUM>. A default SIM profile may be used if the SIM card simulator <NUM> does not receive a new profile from the back-end server <NUM>.

The GMATEs application module <NUM> may receive SIM profiles from the back-end server <NUM> and send it to the SIM card simulator <NUM>. It may also monitor the GMATEs process. If there is an error, the GMATEs application module <NUM> may request the GMATEm <NUM> to reset the SIM card. When the network challenges the device for VirtualSIM authentication, the GMATEs application module <NUM> may relay a SIM authentication request and a SIM authentication response between the MODEM and the back-end server <NUM>.

<FIG> is a flow diagram <NUM> illustrating a workflow according to one aspect of the present disclosure. In the example illustrated in <FIG>, two MODEMs may be implemented, one being used with the SoftSIM and the other being used with the VirtualSIM. Similar to the VirtualSIM, the SoftSIM may comprise a GMATEs and a GMATEm. In some embodiments, the SoftSIM may share a common GMATEs with the VirtualSIM, but comprise a separate GMATEm. In order to allow VirtualSIM to communicate to the back-end server, the SoftSIM process may start and establish a data connection to the back-end server ahead of time.

Initially, profile information for the SoftSIM is loaded <NUM>. The SoftSIM profile including Ki and OP (Operator) may be pre-downloaded or burned onto the device. Thereafter the SoftSIM process may be started in a way substantially similar to the VirtualSIM start process <NUM>-<NUM> described below.

With reference now to <FIG>, a SoftSIM authentication request is received <NUM>. For example, a service provider may challenge the device with an authentication request (e.g., Ki authentication request) before wireless communication service can be provided to the SoftSIM. The authentication request may be part of an APDU request. Since the SIM simulator <NUM> can resolve the SoftSIM authentication request on the device, it does not need to relay the authentication request to the back-end server <NUM>. Therefore, the SoftSIM authentication request is responded <NUM> to by locally resolving the request. A data communication link is established <NUM> via the SoftSIM.

With reference now to <FIG>, the profile information for VirtualSIM is loaded <NUM>. For example, the GMATEs <NUM> may request a VirtualSIM profile from the back-end server <NUM>. The VirtualSIM profile may comprise ICCID, IMSI, PLMN (Public Land Mobile Network), and other parameters, but not Ki. The VirtualSIM profile is stored on device. The GMATEs application module <NUM> sends the VirtualSIM profile to the SIM simulator <NUM> and starts the SIM card simulator <NUM>. With reference now to <FIG>, thereafter the VirtualSIM process may be started as follows:.

Thereafter, a VirtualSIM authentication request is received <NUM>. For example, a service provider may challenge the device with an authentication request (e.g., Ki authentication request) before wireless communication service can be provided to the VirtualSIM. The authentication request may be part of an APDU request. The SIM simulator <NUM> may resolve and respond to the APDU request on the device except for authentication request.

The VirtualSIM authentication request is relayed <NUM> to a remote server, e.g., the back-end server <NUM>, via the data communication link established by the SoftSIM. For example, when the SIM simulator <NUM> receives the VirtualSIM authentication request, it requests the VirtualSIM driver <NUM> to hold the command execution and wait for the authentication response. At the same time, the SIM simulator <NUM> sends the authentication request to the back-end server <NUM>, which resolves the authentication request.

A VirtualSIM authentication response is received <NUM> from the remote server via the data communication link. The VirtualSIM authentication request is responded <NUM> to with the authentication response received from the remote server. For example, once the SIM simulator <NUM> receives the authentication response from the back-end server <NUM>, it sends the response to the SIM card application <NUM> on the MODEM. Therefore, wireless communication service is provided to the VirtualSIM. If the SIM simulator <NUM> receives the next authentication request, the process <NUM>-<NUM> will be repeated.

If the GMATEs application <NUM> does not receive <NUM> the authentication response from the back-end server <NUM> for a period of time, e.g., <NUM>, the GMATEs application <NUM> will inform the SIM simulator <NUM> that the authentication has failed, e.g., by sending a time-out indication. The SIM simulator <NUM> will then inform the VirtualSIM driver <NUM> that the authentication has failed. The VirtualSIM will be reset again, and the process <NUM>-<NUM> will be repeated.

With reference now to <FIG>, embodiments of the present disclosure implementing a Dual-SIM-Dual-Standby (DSDS) configuration are described below. A typical DSDS device implements two SIM cards on a single MODEM. Therefore, such a DSDS device may not be able to have both SIM cards connected to the network at the same time. In other words, when one SIM card is working, the other is in standby mode. For example, a DSDS device may comprise another physical SIM driver, another SIM switching controller, and a SoftSIM driver similar to the physical SIM driver <NUM>, the SIM switching controller <NUM> and the VirtualSIM driver <NUM> in <FIG>.

<FIG> and <FIG> are diagrams <NUM>, <NUM> illustrating workflows when a DSDS configuration is implemented, according to various aspects of the present disclosure. In <FIG>, arrows represent communications among the application <NUM>, the SoftSIM/VirtualSIM module <NUM>, and the MODEM <NUM>. The application <NUM> may be an operation system level application on a mobile device. The SoftSIM/Virtual SIM module <NUM> may represent the GMATEs <NUM> described with reference to <FIG>, and the MODEM <NUM> may represent the GMATEm <NUM> described with reference to <FIG>. In <FIG>, each dashed line represents one or more communications between the components, which may be in either direction.

According to embodiments of the present disclosure, the SoftSIM module may connect to the Internet and simulate the first physical SIM on the DSDS device. The SoftSIM module may connect to the Virtual SIM Server to load a VirtualSIM profile. Once the SoftSIM module receives the VirtualSIM profile from the Virtual SIM Server, the SoftSIM may be set as the default SIM to open a data session.

When the VirtualSIM receives an authentication challenge from the network, the MODEM may send the authentication request to the VirtualSIM Module. It is then determined if the SoftSIM is ready to transmit data. If the SoftSIM has data session opened and is ready to transmit data, the authentication request may be relayed to the Virtual SIM Server. Otherwise the SoftSIM module may start the SoftSIM and open the data session again as described above. Once an authentication response is received from the Virtual SIM Server, the response may be relayed to the network through the MODEM. Now the VirtualSIM is ready to use. Optionally, the SoftSIM module may terminate the SoftSIM and switch back to the first physical SIM for standby mode. Therefore, the first physical SIM may still be used to receive phone calls, SMS, etc..

Specifically, at <NUM>, the application <NUM> sends a request to start the SoftSIM to the SoftSIM/VirtualSIM module <NUM>. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a request to switch the first physical SIM to the SoftSIM to the MODEM <NUM>. At <NUM>, the SoftSIM profile is loaded. At <NUM>, the application <NUM> sends a request to set the SoftSIM as the default SIM to the MODEM <NUM>. At <NUM>, the SoftSIM authentication is completed. At <NUM>, the MODEM <NUM> sends a response to the application <NUM> indicating that the SoftSIM has been set as the default SIM. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a response to the application <NUM> indicating the SoftSIM has started. At <NUM>, the application <NUM> sends a request to download and start the VirtualSIM to the SoftSIM/VirtualSIM module <NUM>. At <NUM>, the VirtualSIM profile is downloaded by the SoftSIM/VirtualSIM module <NUM>. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a request to switch the second physical SIM to the VirtualSIM to the MODEM <NUM>. At <NUM>, the VirtualSIM profile is loaded. At <NUM>, the application <NUM> sends a request to set the VirtualSIM as the default SIM and in standby mode to the MODEM <NUM>. At <NUM>, the application <NUM> sends a request to establish the SoftSIM data session to the MODEM <NUM>. Note that prior to <NUM>, any data session established by SoftSIM may have been time out. At <NUM>, the SoftSIM authentication is completed. At <NUM>, the MODEM <NUM> sends a response to the application <NUM> indicating that the SoftSIM data session has been established.

At <NUM>, the MODEM <NUM> sends a VirtualSIM authentication request to the SoftSIM/VirtualSIM module <NUM>. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a request to check if the SoftSIM data session is ready to the application <NUM>. If the SoftSIM data session is ready, at <NUM>, the application <NUM> sends a response to the SoftSIM/VirtualSIM module <NUM> indicating that the SoftSIM data session is ready. At <NUM>, the SoftSIM/VirtualSIM module <NUM> relays the VirtualSIM authentication request to the Virtual SIM Server using the SoftSIM data session, and receives an authentication response from the Virtual SIM Server using the SoftSIM data session. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends the VirtualSIM authentication response to the MODEM <NUM>. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a response to the application <NUM> indicating the VirtualSIM is ready to use. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a notification to switch the SoftSIM back to the physical SIM to the application <NUM>. At <NUM>, the application <NUM> sends a request to the SoftSIM/VirtualSIM module <NUM> to stop the SoftSIM. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a request to detach the SoftSIM and switch back to the first physical SIM to the MODEM <NUM>. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a response to the application <NUM> indicating the SoftSIM has been stopped.

<FIG> is a diagram <NUM> illustrating a workflow for re-authentication when a DSDS configuration is implemented, according to one aspect of the present disclosure. Once in a while, certain conditions may trigger the network to send authentication requests to the MODEM <NUM> to challenge the VirtualSIM again. Once the SoftSIM/Virtual SIM module <NUM> receives the network challenge, the SoftSIM/Virtual SIM module <NUM> may check if the SoftSIM data session is still available. If the SoftSIM data session is still available, the SoftSIM/Virtual SIM module <NUM> may relay the authentication request back to the VirtualSIM Server. To maintain the VirtualSIM session, the SoftSIM/Virtual SIM module <NUM> sends an authentication response received from the VirtualSIM Sever to the network through the MODEM <NUM> in time. If the SoftSIM data session is not available, the SoftSIM/Virtual SIM module <NUM> may start the data session similar to the process described in <FIG>. After the SoftSIM/Virtual SIM module <NUM> responds to the network authentication challenge, the SoftSIM/Virtual SIM module <NUM> will keep the VirtualSIM session for normal usage. The optional last step is to terminate the SoftSIM connection and switch it back to the first physical SIM to keep the first physical SIM available for receiving phone calls, SMS, etc..

Specifically, at <NUM>, the MODEM <NUM> sends a VirtualSIM authentication request to the SoftSIM/Virtual SIM module <NUM>. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a request to the application <NUM> to check if the SoftSIM data session is ready. If the SoftSIM data session is not ready, at <NUM>, the application <NUM> sends a response to the SoftSIM/VirtualSIM module <NUM> indicating the SoftSIM data session is not ready, and requests to restart the SoftSIM. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a request to the MODEM <NUM> to switch the first physical SIM to SoftSIM. At <NUM>, the SoftSIM profile is loaded. At <NUM>, the application <NUM> sends a request to the MODEM <NUM> to establish the SoftSIM data session. At <NUM>, the SoftSIM authentication is completed. At <NUM>, the MODEM <NUM> sends a response to the application <NUM> indicating the SoftSIM data session had been established. At <NUM>, the SoftSIM/VirtualSIM module <NUM> sends a VirtualSIM authentication time-out indication to the MODEM <NUM>. Note that at this time the VirtualSIM authentication may not be actually time-out, but a time-out indication may be needed to restart the authentication process. At <NUM>, the MODEM <NUM> sends a VirtualSIM authentication request to the SoftSIM/VirtualSIM module <NUM> again. Because the SoftSIM data session should be available by now, the remaining sequence <NUM>-<NUM> will be substantially the same as <NUM>-<NUM> shown in <FIG>. Therefore, the VirtualSIM may be re-authenticated and SoftSIM may be terminated thereafter.

In summary, numerous benefits have been described that result from employing the concepts described herein. The foregoing description of the one or more aspects has been presented for purposes of illustration and description. It is not intended to be exhaustive or limiting to the precise form disclosed. Modifications or variations are possible in light of the above teachings. The one or more aspects were chosen and described in order to illustrate principles and practical application to thereby enable one of ordinary skill in the art to utilize the various aspects and with various modifications as are suited to the particular use contemplated.

The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings within the scope of the invention that is defined by the appended claims. For example, the described embodiments can utilize different registration, power-up, call-out or call-in procedures than those described here. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated.

Claim 1:
A system, comprising:
a subscriber identity module 'SIM' application (<NUM>);
a physical SIM driver (<NUM>) configured to be coupled to a physical SIM card;
a first simulated SIM driver (<NUM>);
a second simulated SIM driver (<NUM>);
a control switch (<NUM>) that selectively couples the SIM application (<NUM>) to the physical SIM driver (<NUM>) or the first simulated SIM driver (<NUM>), wherein the SIM application (<NUM>), when coupled to the physical SIM driver (<NUM>), is configured to read and write on the physical SIM card (<NUM>); and
a SIM simulator (<NUM>) in communication with the control switch (<NUM>) and the first simulated SIM driver (<NUM>), wherein the SIM simulator (<NUM>) is configured to control the selective coupling of the control switch (<NUM>), and to receive (<NUM>) at least one request comprising an authentication request from the first simulated SIM driver (<NUM>) and transmit (<NUM>) at least one response comprising an authentication response to the first simulated SIM driver (<NUM>), wherein the authentication request is received by the first simulated SIM driver (<NUM>) from a communication network, and the SIM simulator (<NUM>) is configured to:
relay (<NUM>) the authentication request received from the first simulated SIM driver (<NUM>) to a remote server (<NUM>) via a data communication link established by the second simulated SIM driver (<NUM>),
receive (<NUM>) the authentication response transmitted to the first simulated SIM driver (<NUM>) from the remote server (<NUM>) via the data communication link established by the second simulated SIM driver (<NUM>), and
if no authentication response is received from the remote server (<NUM>) within a predetermined period of time after relaying the authentication request, send a time-out indication to the first simulated SIM driver (<NUM>).