Patent Description:
Today, user equipment (UE) (e.g., smartphones, tablets, etc.) can use either a physical subscriber identity module (SIM) card or a virtual SIM, which can help a service provider identify the UE, store various data (e.g., contacts and/or photos), and allow the service provider to provide one or more services (e.g., text, talk, data, internet of things (IoT), etc.) to the UE. Presently, sharing a service between UEs requires a user to remove a physical SIM card from one UE and insert it in another UE. Once this is done, the user can receive the service on the other device. Unfortunately, sharing a physical SIM between multiple UEs requires the UEs to be in physical proximity of one another. Furthermore, with physical SIM cards, sharing a service can be limited to device types. Physical SIM cards can be incompatible between UEs, for example, and/or different device types (e.g., a vehicle vs. a UE) may not use the same type of physical SIM card.

These and other drawbacks exist. Accordingly, there is a need for a method of sharing a virtual SIM between multiple devices. More specifically, a need exists for dynamically provisioning the virtual SIM of multiple devices to enable sharing of a service. <CIT> relates to a method for using virtual subscriber identity modules (vSIMs) for client devices. A network device creates, in a memory, a user account for storing one or more vSIMs. The network device receives, from a user of the user account, a selection of network services to be associated with a vSIM. The network device initiates creation of a blockchain including a vSIM certificate for the network services, wherein the vSIM certificate includes an International Mobile Subscriber Identity (IMSI). The network device associates the vSIM certificate with the user account. The vSIM can be retrieved and used by any one of different devices associated with the user account or loaned to other users. <CIT> relates to a method for downloading a profile on an embedded universal integrated circuit card (eUICC) of a terminal. The method includes transmitting a profile request containing eUICC authentication information to a profile providing server through a security channel, upon receiving, from the profile providing server, profile-related information generated in response to the profile request, displaying non-encrypted profile information contained in the profile-related information on a screen, identifying whether a user input indicating whether to proceed to download the profile is detected, and downloading the profile, corresponding to the identified user input.

Examples of the present disclosure relate generally to methods for sharing a virtual subscriber identity module (SIM) card. The method can include a plurality of user equipment (UEs), one or more other internet connected devices, and one or more service providers in communication. A user may wish to use different UEs for different services, for example, or to receive a service (e.g., voice calls) on different UEs at different times. The user may desire for a first UE to receive calls most of the time, for example, but for a second UE to receive calls between 8PM and midnight. To accomplish this, the first UE can send a request to the service provider to allow sharing of the service with the second UE. The request can include service details, first device information for the first UE, second device information for the second UE, and the customer's information.

The service provider can then verify the request (e.g., customer information, first device information, and/or second device information) and then generate a first SIM over-the-air message (OTA). The first SIM-OTA can be sent to the first UE, which causes the first UE to generate a virtual SIM that can be used to receive the service (e.g., voice calls). Similarly, the service provider can generate a second SIM-OTA message and send it to the second UE, which causes the second UE to generate a virtual SIM that can also receive the service. As a result, the second UE can receive calls between 8PM and midnight, while the first UE can receive calls between <NUM>:01AM and <NUM>:59PM.

Reference will now be made in detail to examples of the disclosed technology, examples of which are illustrated in the accompanying drawings and disclosed herein. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

As shown in <FIG>, an example of the present disclosure can comprise a system <NUM> for virtual SIM card sharing. The components and arrangements shown in <FIG> are not intended to limit the disclosed embodiments, as these components and features can vary. As shown in <FIG>, in some implementations, the system <NUM> can include one or more UEs <NUM> (e.g., first UE 110A and second UE 110B). As non-limiting examples, the UEs <NUM> can be cell phones, smartphones, laptop computers, tablets, or other personal computing devices that include the ability to communicate on one more different types of networks. The system <NUM> can also be in communication with one or more cars <NUM>, or other vehicles, equipped with the capabilities to receive data via the Internet and/or a cellular network. It should be noted that, while depicted as a vehicle in this example, the car <NUM> can be any of various devices configured to receive data over the Internet and/or a cellular network such as, for example, a refrigerator, smart television, smart watch, smart home hub (e.g., Amazon® Echo, Amazon Alexa®), or other device.

The system <NUM> can also include a service provider <NUM> for providing various communications services (e.g., talk, text, data, internet of things (IoT)). The service provider <NUM> can include one or more physical or logical devices (e.g., servers, cloud servers, etc.) or drives. Example computer architectures that can be used to implement the UEs <NUM>, the car <NUM>, and the service provider <NUM> are described below with reference to <FIG>, <FIG>, and <FIG>, respectively.

According to some examples, the UE <NUM> (e.g., first UE 110A) can communicate with another UE (e.g., second UE <NUM>10B), the car <NUM>, and the service provider <NUM>. For ease of explanation, as used herein, the first UE 110A can refer to the first device, or the device that is initiating the sharing of a virtual SIM, and the second UE 110B or the car <NUM> can refer to the second device, or the device receiving the requested service.

In some examples, to initiate service (e.g., text service) with a service provider, the first UE 110A can send a request to the service provider <NUM>. The request can include first device information for the first UE 110A, second device information for a second device that will share the service (e.g., second UE 110B or car <NUM>), one or more requested services (e.g., text, voice, and/or data service), service details, customer information, master device information, and/or the like. The service details can include, for example, a schedule of when a service should be shared, which devices to share the service, service limits (e.g., usage caps), etc. As the name implies, the master device information indicates which device operates as the master device, i.e., the device capable of changing the service details. In some examples, the device sending the request to share the service can be the master device by default, however, the master device information can specify for another device to be changed to the master device. The customer information can include the user's social security number, first and last name, address, permission to perform a credit check, payment information, account information, and other information typically used to establish or maintain an account with a service provider. Further, device information (e.g., first device information and/or second device information) can include an International Mobile Equipment Identity (IMEI), SIM identification (SIM ID), Universal Integrated Circuit Card (UICC) number, international mobile subscriber identity (IMSI), integrated circuit card identifier (ICCID), mobile subscription identification number (MSIN), etc. to enable the service provider <NUM> to identify the user and/or the device and to provision the device.

According to some examples, the service provider <NUM> can transmit the customer information to a credit bureau (e.g., Experian®, Transunion®, Equifax®). In response, the service provider <NUM> can receive the user's credit score from the credit bureau. In some examples, based at least in part on the user's credit score, the service provider <NUM> can determine whether the user is eligible for a service, to share services, or set limits on the user's account, among other things.

In some examples, the UEs <NUM> (e.g., first UE 110A and second UE 110B) and the car <NUM> can include sharing applications (apps) <NUM>, <NUM>, as discussed below with reference to <FIG> and <FIG>. The sharing apps <NUM>, <NUM> can enable the devices to share information, for example, when the sharing app <NUM> is enabled on two devices (e.g., first UE 110A and second UE 110B). Thus, the first UE 110A can receive the second device information from the second UE 110B and can send first device information to the second UE 110B. This can be accomplished through near-field communication (NFC), Bluetooth® communication, Wi-Fi, cellular communication, or by other means known in the art.

After verifying the user and/or the first UE 110A, the service provider <NUM> can generate a first and second SIM OTA message based on the first and second device information, customer information, and/or the service details. The service provider <NUM> can then send the first SIM-OTA message to the first UE 110A and the second SIM-OTA message to the second device (e.g., second UE 110B or car <NUM>) using the second device information. Further, the Mobile Country Code (MCC), Mobile Network Code (MNC), and Group ID (GID), and other information for the service provider <NUM> can be sent (either as part of the first and second SIM-OTA message or separately). The MCC, MNC, and GID can be required to provision a virtual SIM on the devices (e.g., first UE 110A, second UE 110B, and/or car <NUM>). Indeed, the first SIM-OTA message can be used to configure the virtual SIM on the first UE 110A, such that the first UE 110A can receive the requested service(s) from the service provider <NUM>. Of course, the second SIM-OTA message can be used to configure the virtual SIM on the second UE 110B or the car <NUM>, such that the second UE 110B or the car <NUM> can receive the requested service from the service provider <NUM>.

In some examples, the service provider <NUM> can use dual authentication to provision the second device (e.g., second UE 110B). In these examples, the service provider <NUM> can also generate a unique identifier, which can be transmitted to the first UE 110A. The unique identifier can be a string of unique characters, public/private key pairs, etc. The UEs <NUM> can include a provider app <NUM>. Similarly, the car <NUM> can include a provider app <NUM>. The provider app <NUM> and/or the provider app <NUM> can receive the unique identifier from the service provider <NUM>, which can use provision app <NUM> to generate and transmit the unique identifier.

The service provider <NUM> can require a matching unique identifier from the second UE 110B before generating the second SIM-OTA. Therefore, a user of the first UE 110A can provide the unique identifier to the second UE 110B to facilitate sharing of the service. The second UE 110B can then send a copy of the unique identifier to the service provider <NUM> for verification (e.g., to verify that the copy of the unique identifier from the second UE 110B matches the unique identifier for the first UE 110A). After the service provider <NUM> determines a match, it can generate a second SIM-OTA based on the second device information, customer information, and/or the service details that can be transmitted to the second UE 110B. The second UE 110B can then use the second SIM-OTA to dynamically provision a virtual SIM to receive the service according to the service details.

The following describes how a device (e.g., first UE 110A, second UE 110B, and/or car <NUM>) can be provisioned. In this example, the first UE 110A is used to describe how provisioning can occur, however, provisioning can occur the same, or similarly, on the second UE 110B and/or the car <NUM>. Provisioning the first UE 110A can include the first UE 110A determining whether the first UE 110A already has the requested service (e.g., text messaging or a data package). When the first UE 110A has the service (i.e., there is an existing subscription for the same service), the first UE 110A can determine that a first virtual SIM is associated with the existing service, remove the existing service from the first virtual SIM, generate a second virtual SIM using the data in the SIM-OTA message, and assign the requested service to the second virtual SIM. Alternately, when the first UE 110A lacks the requested service, the first UE 110A can generate a first virtual SIM and based on the SIM-OTA message, and associate the requested service with the first virtual SIM.

According to some examples, a user (e.g., user of first UE 110A) can already have a particular service with the service provider <NUM>, but wishes to share the service with another device (e.g., second UE 110B). To share the service with the second UE 110B, the first UE 110A can receive second device information from the second UE 110B and then transmit a request to share the service to the service provider <NUM>. The request can include, for example, first device information, second device information, customer information, the service (including service details), master device information, etc. In response, the service provider can verify the request and then generate a first and second SIM-OTA message based at least in part on the first device and the second device information, respectively.

The service provider <NUM> can then transmit the first SIM-OTA message to the first UE 110A and the second SIM-OTA message to the second UE 110B. In this example, the first SIM-OTA can include instructions to update the existing service according to the service details. As a result, it may not be necessary to provision a virtual SIM or re-provision a virtual SIM on the first UE 110A-i.e., the first UE 110A can already have the service, so no modification is required. The second SIM-OTA message can cause the second UE 110B to dynamically provision a virtual SIM, such that the service can be received by the second UE 110B according to the service details.

<FIG> illustrates a flowchart for an example of a method for sharing a virtual SIM, where the method uses dual authentication. The flowchart is written from the perspective of the service provider <NUM> in communication with the first UE 110A and the car <NUM>. Here, dual authentication can require receipt of the second device information, and receipt of the unique identifier from the second device (e.g., car <NUM>).

At <NUM>, the service provider <NUM> can receive a request for dynamic provisioning from the first UE <NUM>10A. The user of the first UE 110A can send the request to establish service (e.g., voice) through the service provider <NUM>. Further, the user can seek to share the service with another device (e.g., car <NUM>). The request can include service details that indicate times and/or days when each device should receive the service. The user can drive to work Monday-Friday between <NUM>:30AM and <NUM>:00AM, for example; and thus, would prefer calls to be routed to the car <NUM>, rather than the first UE 110A, during these times. In some examples the service details can also indicate which device can operate as the master device, i.e., the device capable of changing the service details. The master device can send a request to the service provider <NUM> that overrides the service details. For example, the service details can cause the first UE 110A to receive calls in the morning, however, in a scenario where the second UE 110B is the master device, the second UE 110B can transmit a request to receive calls one morning, which overrides the service details. The request can be sent through the provider app <NUM>, for example, or as an email, text message, or even as a voice call to a call center of the service provider <NUM>. The request can also include first device information for the first UE 110A, second device information for the car <NUM>, and/or customer information for the user.

At <NUM>, the service provider <NUM> can verify the request, which can involve communicating with a credit bureau to perform a background check, communicating with the user's financial institution to verify the user's payment information, verifying the first device information, etc. In examples where the user already has existing service with the service provider <NUM>, the service provider <NUM> can verify the request by comparing the customer information to stored customer information, comparing the first device information to stored first device information, and/or verifying the services authorized for use by the first device.

At <NUM>, The service provider <NUM> can generate a first SIM-OTA message based on the first device information, the customer information, and other relevant information. In some examples, the service provider <NUM> can also generate a unique identifier at <NUM>. At <NUM>, the service provider <NUM> can transmit the first SIM-OTA message and the unique identifier to the first UE 110A. As described below in reference to <FIG>, the first SIM-OTA message can cause the first UE 110A to dynamically provision a virtual SIM that can be used to receive the service.

At <NUM>, the service provider <NUM> can receive a confirmation of the dynamic provisioning from the first UE 110A. Similar to the request mentioned above, the confirmation can be transmitted via the provider app <NUM> or as an email, text message, or even as a voice call to a call center of the service provider <NUM>. In response to receiving confirmation, at <NUM>, the service provider <NUM> can provide the service to the first UE 110A according to the service details. At <NUM>, the service provider <NUM> can receive the unique identifier from the car <NUM>. The first UE 110A can transmit the unique identifier to the car <NUM> via the sharing app <NUM>, or via email, text, etc. Furthermore, the user of the first UE 110A can communicate (e.g., verbally) the unique identifier to the user of the car <NUM>, such that the user of the car <NUM> sends the unique identifier, for example, as an input in the provider app <NUM>.

In some examples, the first UE 110A can only send first device information to the service provider <NUM>. Therefore, in those examples, the car <NUM> can need to send the unique identifier and the second device information to the service provider <NUM> to receive the service according to the service details.

At <NUM>, the service provider <NUM> can determine whether the unique identifier received from the car <NUM> matches the stored unique identifier. If the service provider <NUM> determines no match exists, then the method <NUM> can end. In some examples, the service provider <NUM> can send a message to the car <NUM> indicating the unique identifier does not match, and can provide the car <NUM> another opportunity to enter the unique identifier. If the service provider <NUM> determines a match exists, then at <NUM>, the service provider <NUM> can generate a second SIM-OTA based on the second device information and/or the customer information.

At <NUM>, the service provider <NUM> can transmit the second SIM-OTA message to the car <NUM>. The service provider <NUM> can use second device information to determine an address to send the second SIM-OTA. With respect to the first SIM-OTA message mentioned above, the service provider <NUM> can similarly use the first device information to determine an address to send the first SIM-OTA. Similar to the first SIM-OTA message, the second SIM-OTA message can cause the car <NUM> to generate a virtual SIM that can receive the service according to the service details. At <NUM>, the service provider <NUM> can receive confirmation that the virtual SIM has been successfully provisioned from the car <NUM>. Of course, the confirmation can be transmitted via the provider app <NUM> or as an email, text message, or even as a voice call. At <NUM>, the service provider <NUM> provides the service to the car <NUM> according to the service details.

<FIG> illustrates a flowchart for an example of a method for sharing a virtual SIM requiring single authentication. Similar to <FIG>, the method <NUM> is written from the perspective of the service provider <NUM>. The method <NUM> differs, however, from the method <NUM> in that only second device information is necessary to provide service to the second device (e.g., second UE 110B) according to the service details.

At <NUM>, the service provider <NUM> can receive a request for dynamic provisioning from the first UE 110A. As mentioned above, the request can include service details, first device information, second device information, master device information (i.e., which, if any, device can change the service details), and/or customer information. Indeed, the request can be sent through the provider app <NUM>, or in some examples, the first UE 110A can send the request as an email, text message, and/or as a voice call. Steps <NUM>-<NUM> can be substantially similar to steps <NUM>-<NUM> in <FIG>, however, no unique identifier is involved in the method <NUM>. Therefore, the method <NUM> can include the service provider <NUM> performing the following: verifying the request at <NUM>; generating a first SIM-OTA message based on the first device information at <NUM>; transmitting the first SIM-OTA message to the first UE 110A at <NUM>; receiving confirmation of dynamic provisioning from the first UE 110A at <NUM>; and providing the service to the first UE 110A at <NUM>. Additionally, steps <NUM>-<NUM> can be substantially similar to steps <NUM>-<NUM> in <FIG>. These steps can further include the following: generating a second SIM-OTA message based on the second device information at <NUM>; transmitting the second SIM-OTA message to the second UE 110B at <NUM>; receiving confirmation of dynamic provisioning from the second UE 110B at <NUM>; and providing the service to the second UE 110B at <NUM>.

<FIG> illustrates a flowchart depicting an example of a method for sharing a virtual SIM from the perspective of the UE <NUM>. In the method <NUM>, the user of the first UE 110A can wish to establish a service (e.g., texting) through the service provider <NUM>. Furthermore, the user of the first UE 110A can desire to share the service with at least one other device (e.g., second UE 110B). Similar to method <NUM> shown in <FIG>, the method <NUM> can use dual authentication to share the service with the second device (e.g., second UE 110B). Of course, single authentication, or other types of authentication could be used and are contemplated herein.

At <NUM>, the first UE 110A can send a request for dynamic provisioning to the service provider <NUM> using, for example, the provider app <NUM> to transmit the request. Similar to methods <NUM> and <NUM>, the request can include first device information, second device information, customer information, service details, and other relevant information. The first UE 110A can obtain second device information from the second UE 110B via a text message, internet connection, or other suitable means. The first UE 110A can obtain second device information from the second UE 110B when, for example, both devices are (<NUM>) using the sharing app <NUM>, (<NUM>) brought within range of each other for NFC, and (<NUM>) a "sharing feature" is enabled on the sharing app <NUM> of one, or both, UE <NUM>. The first UE 110A can also receive the second device information through Bluetooth®, WIFI, or any other means known in the art.

At <NUM>, the first UE 110A can receive a SIM-OTA message and a unique identifier from the service provider <NUM>. At <NUM>, the first UE 110A can determine whether the first UE 110A has an existing service that is the same type as the requested service. If the first UE 110A determines the requested service does not exist on the first UE 110A, then at <NUM>, the first UE 110A (e.g., a processor on the first UE 110A) can generate a new virtual SIM using the data from the SIM-OTA message. When received by the first UE 110A, the SIM-OTA message can cause the first UE 110A to create the virtual SIM (e.g., a trustlet or a small agent) within a secure element of the first UE 110A, such as the trusted execution environment (TEE). In examples where the new SIM credentials (e.g., MNC, MCC, and GID) are received separately from the SIM-OTA message, the secure element can store the new SIM credentials for later use to generate the virtual SIM. This process can be performed, for example, by an embedded SIM (e-SIM)-e.g., e-SIM <NUM>, discussed below with reference to <FIG>. The e-SIM can be located within the secure element or located within the normal operating system (OS) and communicate to the SIM-OTA platform via a secure channel. Further, the e-SIM can send a secure message to a processor of the first UE 110A to generate the virtual SIM and to associate the values of MNC, MCC, and GID. The e-SIM can also be responsible for switching between various virtual SIMs (e.g., virtual SIMs 632A-632n) to change services, communications channels, and/or antennas for the first UE 110A.

At <NUM>, the first UE 110A can associate the service with the new virtual SIM. In some examples, the first UE 110A can include one antenna (e.g., antenna <NUM>). In those examples, the e-SIM can communicate with the service provider <NUM> and determine the frequencies of communication (generally a frequency pair - one for uplink and one for downlink). The frequencies can vary by provider and/or by the type of service being used (e.g., talk, text, data, IoT) with each provider and/or service generally allocated a particular frequency spectrum. In this configuration, the eSIM, transceiver, or OS (via the processor), for example, can provide a multiplexing function to enable each virtual SIM to use the antenna (e.g., to send and receive data packets) at the appropriate frequency and at the appropriate time. In other words, each virtual SIM or each frequency can use the single antenna with "traffic control" provided by one or more components of the first UE 110A.

In some examples, the traffic control can be provided on a time divided basis. The time divided basis can use a first-in-first-out (FIFO) basis, for example, a time to transmit basis (i.e., smaller packets go before larger packets, or vice-versa), a latency basis (i.e., packets for networks with higher or lower latency go first), or any other suitable time-based scheme. In other examples, the traffic control can be provided on a priority basis. In other words, packets associated with services that require low latency (e.g., voice calls or streaming) can be sent and received before, for example, packets associated with services that can tolerate higher latency (e.g., text messaging or e-mail).

In other examples, each virtual SIM can be associated with a separate antenna; for example, virtual SIM A (e.g., virtual SIM 632A) can be associated with antenna A (e.g., antenna 534A), and virtual SIM B can be associated with antenna B, etc. In those examples, the SIM-OTA can instruct the processor, for example, to assign each virtual SIM to a particular antenna. The SIM-OTA message can also include the appropriate frequency (or frequency pair), provider information (e.g., the MCC, MNC, GID, etc.), and other data to enable the virtual SIM to communicate on the appropriate frequency and with the appropriate provider.

In those examples, the e-SIM, transceiver, or processor, for example, can determine and route communications to and from the appropriate virtual SIM. The appropriate virtual SIM can be chosen based on the type of service (e.g., <NUM>, <NUM>, <NUM>, or <NUM>), the provider, or the priority. So, for example, autonomous driving functions - which require very low latency - can be assigned to a first virtual SIM on a <NUM> network and the virtual SIM can be given high priority when sending and receiving data. Text messaging, on the other hand, which can tolerate relatively high latency, can be assigned to a second virtual SIM on a <NUM> (legacy) network and be given low priority when sending and receiving data. In some examples, user preferences can determine the appropriate virtual SIM - e.g., the user has exclusively designated a particular service provider for a particular service.

At <NUM>, after successfully provisioning the first virtual SIM, the first UE 110A can send confirmation of the provisioning to service provider <NUM>. Once the first virtual SIM is provisioned, the first UE 110A can receive the service from the service provider <NUM>. At <NUM>, to facilitate sharing of the service with the second UE 110B, the first UE 110A can transmit the unique identifier to the second UE 110B. Once the second UE 110B successfully transmits the unique identifier to the service provider <NUM>, the second UE 110B can receive the second SIM-OTA message from the service provider <NUM>, which can cause the second UE 110B to dynamically provision a virtual SIM.

If, at <NUM>, the first UE 110A determines the service already exists, on the other hand, then at <NUM>, the first UE 110A can generate a second virtual SIM. At <NUM>, the first UE 110A can then remove the service from the first virtual SIM. At <NUM>, the first UE 110A can associate the service with the second virtual SIM. At <NUM>, the first UE 110A can then send a confirmation of the dynamic provisioning to the service provider <NUM>. At <NUM>, for security, the first UE 110A can then transmit the unique identifier to the second UE 110B.

In some examples, rather than deleting an existing virtual SIM, the existing virtual SIM can be re-provisioned. When the virtual SIM is re-provisioned, certain associated data (e.g., provider name, communication frequency, MNC, MCC, and GID) can be removed from the virtual SIM and replaced with new data corresponding to the new provider and/or type of service. So, for example, rather than deleting the first virtual SIM, above, it can be possible to merely change the service details (e.g., to add or remove a service).

<FIG> illustrates a timing diagram depicting an example of a method <NUM> where a service provider dynamically provisions two UEs <NUM> (e.g., first UE 110A and second UE 110B) to share a service. The method <NUM> also uses dual authentication to provide the shared service with the second device (second UE 110B).

At <NUM>, the second UE 110B can send the second device information to the first UE 110A. As mentioned above, in some examples, the second UE 110B can use the sharing app <NUM> to send the second device information to the first UE 110A. At <NUM>, the first UE 110A can send a request for dynamic provisioning to the service provider <NUM>. The request can include a service (e.g., text messaging), first device information for the first UE 110A, second device information for the second UE 110B, service details, master device information, and/or customer information.

At <NUM>, the service provider <NUM> can verify the request, for example, by confirming with a financial institution that the payment information belongs to the customer name listed in the customer information. The service provider <NUM> can further verify the request by determining whether the first device information and/or the second device information has a predetermined number of characters, contains only valid characters, etc..

At <NUM>, the service provider <NUM> can generate a first SIM-OTA based on, for example, the first device information and/or the customer information. The service provider <NUM> can also generate a unique identifier, which can be used to authenticate the request for a shared service. At <NUM>, the service provider <NUM> can transmit the first SIM-OTA message and the unique identifier to the first UE 110A using the first device information (e.g., to determine an address or phone number for the first UE 110A). The first SIM-OTA message can cause the first UE 110A to generate, or provision, a virtual SIM and to associate the service with the virtual SIM. At <NUM>, the first UE 110A can send a confirmation message to the service provider <NUM> indicating the virtual SIM has been successfully provisioned. At <NUM>, the service provider <NUM> can provide the requested service to the first UE 110A according to the service details.

At <NUM>, the first UE 110A can transmit the unique identifier to the second UE 110B. As previously mentioned, the first UE 110A and second UE 110B can communicate via the sharing app <NUM> (e.g., via a WiFi or Bluetooth® connection). At <NUM>, to receive the shared service, the second UE 110B can transmit the unique identifier to the service provider <NUM>. At <NUM>, the service provider <NUM> can compare the unique identifier received from the second UE 110B to a stored unique identifier. At <NUM>, when a match is determined, the service provider <NUM> can generate a second SIM-OTA message based on the second device information and/or the customer information. In some examples, when a match is not found, the service provider <NUM> can send a message to the second UE 110B indicating the unique identifier does not match the stored unique identifier, and can provide the second UE 110B another opportunity to enter a matching unique identifier or can cancel the provisioning for one, or both, UE <NUM>. At <NUM>, the service provider <NUM> can transmit the second SIM-OTA message to the second UE 110B. The second SIM-OTA message can cause the second UE 110B to be dynamically provisioned, i.e., generating a virtual SIM to receive the shared service. At <NUM>, the second UE 110B can transmit a message to the service provider <NUM> indicating the second UE 110B has been successfully provisioned. Finally, at <NUM>, the service provider <NUM> can provide the shared service according to the service details to the second UE 110B.

As shown in <FIG>, some, or all, of the system <NUM> and methods <NUM>, <NUM>, <NUM>, <NUM> can be performed by, and/or in conjunction with, the UE <NUM> (e.g., first UE 110A and/or second UE 110B). For clarity, the UE <NUM> is described herein generally as a cell phone or smart phone. One of skill in the art will recognize, however, that the system <NUM> and methods <NUM>, <NUM>, <NUM>, <NUM> can also be used with a variety of other electronic devices, such as, for example, tablet computers, laptops, desktops, and other network (e.g., cellular or internet protocol (IP) network) connected devices from which a call can be placed, a text can be sent, and/or data can be received. These devices are referred to collectively herein as the UE <NUM>. The UE <NUM> can comprise a number of components to execute the above-mentioned functions and apps. As discussed below, the UE <NUM> can comprise memory <NUM> including many common features such as, for example, contacts <NUM>, a calendar <NUM>, a call log (or, call history) <NUM>, and OS <NUM>. In this case, the memory <NUM> can also store a sharing app <NUM> and a provider app <NUM>.

The UE <NUM> can also comprise one or more processors <NUM>. In some implementations, the processor(s) <NUM> can be a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or any other sort of processing unit. The UE <NUM> can also include one or more of removable storage <NUM>, non-removable storage <NUM>, one or more transceiver(s) <NUM>, output device(s) <NUM>, and input device(s) <NUM>. In some examples, the UE <NUM> can also include a physical SIM <NUM> and/or an e-SIM <NUM> including an International Mobile Subscriber Identity (IMSI) and other relevant information.

In various implementations, the memory <NUM> can be volatile (such as random-access memory (RAM)), non-volatile (such as read only memory (ROM), flash memory, etc.), or some combination of the two. The memory <NUM> can include all, or part, of the functions <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and the OS <NUM> for the UE <NUM>, among other things.

The memory <NUM> can also comprise contacts <NUM>, which can include names, numbers, addresses, and other information about the user's business and personal acquaintances, among other things. In some examples, the memory <NUM> can also include a calendar <NUM>, or other software, to enable the user to track appointments and calls, schedule meetings, and provide similar functions. In some examples, the memory <NUM> can also comprise the call log <NUM> of calls received, missed, and placed from the UE <NUM>. As usual, the call log <NUM> can include timestamps for each call for use by the system <NUM>. Of course, the memory <NUM> can also include other software such as, for example, e-mail, text messaging, social media, and utilities (e.g., calculators, clocks, compasses, etc.).

The memory <NUM> can also include the OS <NUM>. Of course, the OS <NUM> varies depending on the manufacturer of the UE <NUM> and currently comprises, for example, iOS <NUM>. <NUM> for Apple products and Pie for Android products. The OS <NUM> contains the modules and software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals.

As mentioned above, the UE <NUM> can also include the sharing app <NUM>. The sharing app <NUM> can perform some, or all, of the functions discussed above with respect to the methods <NUM>, <NUM>, <NUM>, <NUM> for interactions occurring between the service provider <NUM>, the first UE 110A, the second UE 110B, and/or the car <NUM>. Thus, the sharing app <NUM> can receive the device information and/or the unique identifier, transmit the device information and/or the unique identifier to the service provider <NUM> and/or between the UE <NUM>. The sharing app <NUM> can also receive messages from the service provider <NUM> indicating whether the unique identifier matches the stored copy, among other things.

From a practical standpoint, the user of the first UE 110A can open the sharing app <NUM> by pressing an icon on a touchscreen of the first UE 110A representing the sharing app <NUM>. Once opened, the sharing app <NUM> can display as a graphical user interface (GUI), for example, including several options as buttons, radio boxes, and/or text input boxes. The GUI can enable the user to enter information related to what services and devices to share/receive (e.g., device information, unique identifier, etc.), who to share/receive it with/from (e.g., other devices within a network, a specific device name, phone number, etc.), and/or how to share the data (e.g., Bluetooth®, NFC, Wi-Fi, etc.). Further, the sharing app <NUM> can include notifications alerting the user that another device would like to acquire its device information, and can ask for user permission to share the device information. The user of the second UE 110B can similarly select the sharing app <NUM> on the second UE 110B and select one or more of the aforementioned options. In examples where the data is shared via NFC, the first UE 110A and the second UE 110B can be brought with an NFC range to transmit and receive data.

So, for example, the user of the first UE 110A can open the sharing app <NUM> and select "share. " The GUI can then prompt the user to enter (<NUM>) what services to share (e.g., voice and text) (<NUM>) who to share it with (e.g., phone number <NUM>-<NUM>-<NUM> for the second UE 110B) and how to communicate with the second UE 110B (e.g., NFC). The users can then place the first UE 110A and the second UE 110B within a predetermined distance (e.g., three feet) and select "connect. " The first UE 110A can then receive the information from the second UE 110B (e.g., UCCID, SIM ID, etc.) needed to provision the second UE 110B on the network. The user of the first UE 110A can then select "send" to send the request to the service provider <NUM> including device information for the first UE 110A and second UE 110B, customer information, account information, and other information to enable the service provider <NUM> to provisional virtual SIMS and share the requested services (e.g., voice and text) on the first UE 110A and the second UE 110B.

The UE <NUM> can also include the provider app <NUM>. The provider app <NUM> can work facilitate communication between the UE <NUM> and the service provider <NUM>. The provider app <NUM> can receive, for example, the SIM-OTA message from the service provider <NUM> and can also configure the e-SIM <NUM> using the configurations provided in the SIM-OTA message. The e-SIM <NUM> can use the SIM-OTA message to generate a first virtual SIM 632A and associate the requested service with the first virtual SIM 632A and the service provider <NUM>. In some examples, the requested service can be replacing an existing service, but switching to a new service provider <NUM>, or replacing an existing service with a different package (e.g., the same service provider <NUM> came out with a new deal for the same service(s)). In those examples, if the existing service is associated with the first virtual SIM 632A, the e-SIM <NUM> can remove the existing service from the first virtual SIM 632A and generate a second virtual SIM 632B. Further, the e-SIM <NUM> can associate the requested service with the second virtual SIM 632B.

The provider app <NUM> can also be accessed by the user pressing an icon on the touchscreen of UE <NUM> and/or the car <NUM> that represents the provider app <NUM>. The provider app <NUM> can display various options as a graphic user interface, for example, an option to send a request for sharing a service, which may include fields to input data as part of the request (e.g., customer information, first device information, master device information, etc.). The SIM-OTA message and/or the unique identifier can be received by the provider app <NUM>. Prior to receiving either, the provider app <NUM> can generate an alert seeking user permission to receive the SIM-OTA message or the unique identifier. Of course, the provider app <NUM> can communicate with the processor to determine the result of the provisioning. In some examples, after receiving the SIM-OTA message, the provider app <NUM> can generate and output a message indicating successful or unsuccessful provisioning of the device.

The UE <NUM> can also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. The removable storage <NUM> and non-removable storage <NUM> can store some, or all, of the functions <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and the OS <NUM>.

Non-transitory computer-readable media can include volatile and nonvolatile, removable and non-removable tangible, physical media implemented in technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The memory <NUM>, removable storage <NUM>, and non-removable storage <NUM> are all examples of non-transitory computer-readable media. Non-transitory computer-readable media include, but are not limited to, RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disc ROM (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which can be used to store the desired information and which can be accessed by the UE <NUM>. Any such non-transitory computer-readable media can be part of the UE <NUM> or can be a separate database, databank, remote server, or cloud-based server.

In some implementations, the transceiver(s) <NUM> include any sort of transceivers known in the art. In some examples, the transceiver(s) <NUM> can include wireless modem(s) to facilitate wireless connectivity with the other UEs, the Internet, and/or an intranet via a cellular connection. Further, the transceiver(s) <NUM> can include a radio transceiver that performs the function of transmitting and receiving radio frequency communications via antenna <NUM> (e.g., Wi-Fi or Bluetooth®).

In some examples, the transceiver(s) <NUM> can include a plurality of antennas 634An. Each of the plurality of antennas 634A-n can correspond to a respective virtual SIM <NUM> and a designated communication frequency or frequency pair. This can enable each virtual SIM <NUM> to use a dedicated antenna for communications, obviating the need for traffic controls, multiplexing, etc. The communication frequency can be specific to the service provider <NUM> and/or to the type of service (e.g., talk, text, or IoT) associated with the respective virtual SIM <NUM>, for example, the virtual SIM <NUM> can be programmed by the SIM-OTA message to communicate at a designated frequency for text services. Additionally, the communication frequency can be, at least in part, based on the type of service (e.g., <NUM>, <NUM>, <NUM>, or <NUM>) used by the respective virtual SIM <NUM>. Therefore, the virtual SIM <NUM> can communicate at a variety of frequencies based on the available type of service. In other words, different portions of the communications spectrum are dedicated to <NUM> communication rather than, for example, <NUM> long-term evolution (LTE) communications. Furthermore, the e-SIM <NUM> can determine the type of communication (e.g., text or talk), the available frequencies, the available providers, etc. and route communications to the appropriate virtual SIM <NUM>.

In some examples, UE <NUM> can include only one antenna (e.g., antenna <NUM>) that provides communications for all of the virtual SIMs 632A-n. In those examples, the e-SIM <NUM> can identify the service provider <NUM>, the type of service, and/or the quality service and determine an appropriate communication frequency. Next, the e-SIM <NUM> can communicate the appropriate frequency to the respective virtual SIM <NUM>. The e-SIM <NUM> can determine the appropriate virtual SIM <NUM> based on the service provider <NUM>, type of service, and/or quality of service to the corresponding values assigned to the virtual SIM <NUM>.

In this configuration, the e-SIM <NUM>, transceiver(s) <NUM>, OS <NUM>, or other component of the UE <NUM>, can act as "traffic cop" to prevent interference between the various virtual SIMs <NUM>. In other words, as packets are sent and received for voice and text messages occurring contemporaneously on the UE <NUM> - i.e., the user is texting and talking on the phone at the same time - the transceiver <NUM>, for example, can switch back and forth between the appropriate frequencies on the antenna to effect both types of communications. This can be done on a time basis (e.g., first-in-first-out), a priority basis (e.g., voice takes precedence over text), or any other suitable method. This can enable the UE <NUM> to use multiple virtual SIMs <NUM> on multiple frequencies with multiple providers, for example, at the same time.

In other examples, the transceiver(s) <NUM> can include wired communication components, such as a wired modem or Ethernet port, for communicating with the other UE or the provider's Internet-based network. In this case, the transceiver(s) <NUM> can also enable the UE <NUM> to communicate with the car <NUM> and the service provider <NUM>, as described herein.

In some implementations, the output device(s) <NUM> include any sort of output devices known in the art, such as a display (e.g., a liquid crystal or thin-film transistor (TFT) display), a touchscreen display, speakers, a vibrating mechanism, or a tactile feedback mechanism. In some examples, the output device(s) <NUM> can play various sounds based on, for example, whether the UE <NUM> is connected to a network, the type of call being received (e.g., video calls vs. voice calls), the number of active calls, etc. In some examples, the output device(s) can play a sound when a new service listing is requested, a match is found for a request, a new SIM-OTA message is received, etc. Output device(s) <NUM> can also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display.

In various implementations, input device(s) <NUM> include any sort of input devices known in the art. The input device(s) <NUM> can include, for example, a camera, a microphone, a keyboard/keypad, or a touch-sensitive display. A keyboard/keypad can be a standard push button alphanumeric, multi-key keyboard (such as a conventional QWERTY keyboard), virtual controls on a touchscreen, or one or more other types of keys or buttons, and can also include a joystick, wheel, and/or designated navigation buttons, or the like.

The UE <NUM> can also include a physical SIM <NUM>. The physical SIM <NUM> can comprise a removable card that includes UE data, user data, provider data, etc. In some examples, the physical SIM <NUM> can be linked to the service provider <NUM>, for example, or another service provider from which the UE <NUM> was originally obtained, among other things. The physical SIM <NUM> can be used to establish an initial connection with a network, for example, to enable the UE <NUM> to access the service provider <NUM>.

The e-SIM <NUM> can also include one or more virtual SIMs <NUM> (e.g., virtual SIMs 632A-632n). The virtual SIMs <NUM>, in conjunction with the service provider <NUM> or other service providers, can enable the user to dynamically change the services, service details, service providers, etc. on the UE <NUM>. Indeed, the virtual SIMs <NUM> can also enable the UE <NUM> to access different services using different service providers at the same time. When a service is changed on the UE <NUM>, new virtual SIMs <NUM> can be added and provisioned and/or existing virtual SIMs <NUM> can be re-provisioned or deleted.

As shown in <FIG>, the system <NUM> and methods <NUM>, <NUM>, <NUM>, <NUM> can also be used in conjunction with a car server 700A and a service provider server 700B. The servers <NUM> can comprise, for example, a desktop or laptop computer, a server, bank of servers, or cloud-based server bank. Thus, while the servers <NUM> are depicted as single standalone servers, other configurations or existing components could be used. In some examples, the servers <NUM> can comprise existing network entities such as, for example, a home location register (HLR), home subscriber service (HSS), a third-generation partnership project authentication, authorization and accounting (3GPP AAA) server, or another server or component.

The servers <NUM> can be substantially similar and can perform many of the same functions. The servers <NUM> can comprise a number of components to execute the above-mentioned functions and apps. As discussed below, the servers <NUM> can comprise memory <NUM> including many common features such as, for example, the OS <NUM>.

In various implementations, the memory <NUM> can be volatile (such as random-access memory (RAM)), non-volatile (such as read only memory (ROM), flash memory, etc.), or some combination of the two. The memory <NUM> can include all, or part, of the functions of a provider app <NUM> and a sharing app <NUM> on the car server 700A, among other things. Similarly, on the service provider server 700B, the memory <NUM> can include all, or part, of the functions of the provider app <NUM>, among other things.

The memory <NUM> can also include the OS <NUM>. Of course, the OS <NUM> varies depending on the manufacturer of the server <NUM> and the type of component. Many servers, for example, run Linux or Windows Server. Dedicated cellular routing servers can run specific telecommunications OS <NUM>. The OS <NUM> contains the modules and software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals.

As shown in <FIG>, the car server 700A can incorporate the car <NUM>. The provider app <NUM> can be substantially similar to the provider app <NUM> mentioned above. Therefore, the provider app <NUM> can be accessed via the touchscreen of the car <NUM>, and can include a graphical user interface. To this end, the provider app <NUM> can provide communication between the car server 700A and the service provider <NUM>. Thus, the provider app <NUM> can transmit device information to the service provider <NUM>. Of course, the device information can be its own device information and/or device information of one or more UEs. The provider app <NUM> can also receive the unique identifier from the service provider <NUM>.

The sharing app <NUM> can provide communication between the car <NUM> and the UEs <NUM>. For example, the sharing app <NUM> can request and receive device information from the UE <NUM>. The sharing app <NUM> can also request and receive the unique identifier from the UE <NUM>. Similarly, the sharing app <NUM> can receive a request for device information and/or the unique identifier from the UE <NUM>. In response, the sharing app <NUM> can transmit the device information and/or the unique identifier to the UE <NUM>.

As shown in <FIG>, the service provider <NUM> can have one or more service provider servers 700B for communicating with the UEs <NUM>, and/or the car <NUM>. The service provider server 700B can also include the provision app <NUM>, which can provide communication between the service provider <NUM> and the UEs <NUM> and/or the car <NUM>. The provision app <NUM> can receive the request to share a service from UEs <NUM> or the car <NUM>. Also, the provision app <NUM> can transmit the SIM-OTA messages to the UEs <NUM> or the car <NUM> after the request from one of the UEs <NUM> and/or or the car <NUM> is received. In some examples, the provision app <NUM> can be used to verify the request, for example, the provision app <NUM> can verify the request after determining a match by comparing stored data to data received within the request. Further, the provision app <NUM> can transmit the unique identifier to one of the UEs <NUM> and/or or the car <NUM>.

Both servers <NUM> can also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> and <FIG> by removable storage <NUM> and non-removable storage <NUM>. The removable storage <NUM> and non-removable storage <NUM> can store some, or all, of the OS <NUM> and functions <NUM>, <NUM>.

Non-transitory computer-readable media can include volatile and nonvolatile, removable and non-removable tangible, physical media implemented in technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The memory <NUM>, removable storage <NUM>, and non-removable storage <NUM> are all examples of non-transitory computer-readable media. Non-transitory computer-readable media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVDs or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which can be used to store the desired information, and which can be accessed by the servers <NUM>. Any such non-transitory computer-readable media can be part of the servers <NUM> or can be a separate database, databank, remote server, or cloud-based server.

In some implementations, the transceiver(s) <NUM> include any sort of transceivers known in the art. In some examples, the transceiver(s) <NUM> can include wireless modem(s) to facilitate wireless connectivity with the UEs <NUM>, the Internet, and/or an intranet via a cellular connection. Further, the transceiver(s) <NUM> can include a radio transceiver that performs the function of transmitting and receiving radio frequency communications via an antenna (e.g., Wi-Fi or Bluetooth®). In other examples, the transceiver(s) <NUM> can include wired communication components, such as a wired modem or Ethernet port, for communicating with the other UEs or the provider's Internet-based network. The transceiver(s) <NUM>, for example, on the car server 700A can receive requests for device information and/or the unique identifier, and send the device information and/or the unique identifier to the UEs <NUM> and/or the service provider <NUM>, among other things.

In some implementations, the output device(s) <NUM> include any sort of output devices known in the art, such as a display (e.g., a liquid crystal or thin-film transistor (TFT) display), a touchscreen display, speakers, a vibrating mechanism, or a tactile feedback mechanism. In some examples, the output devices can play various sounds based on, for example, whether the server <NUM> is connected to a network, the type of data being received (e.g., a match vs. a request for service listings), when SIM-OTA messages are being transmitted, etc. Output device(s) <NUM> also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display.

In various implementations, input device(s) <NUM> include any sort of input devices known in the art. For example, the input device(s) <NUM> can include a camera, a microphone, a keyboard/keypad, or a touch-sensitive display. A keyboard/keypad can be a standard push button alphanumeric, multi-key keyboard (such as a conventional QWERTY keyboard), virtual controls on a touchscreen, or one or more other types of keys or buttons, and can also include a joystick, wheel, and/or designated navigation buttons, or the like.

While several possible examples are disclosed above, examples of the present disclosure are not so limited. While the system <NUM> and methods <NUM>, <NUM>, <NUM>, <NUM> above are discussed with reference to use with cellular communications, for instance, the system <NUM> and methods <NUM>, <NUM>, <NUM>, <NUM> can be used to provide dynamic provisioning for other types of wired and wireless communications. In addition, while various functions are discussed as being performed on the UEs <NUM>, by the service provider <NUM>, or by the car <NUM>, other components could perform the same or similar functions without departing from the scope of the invention.

Claim 1:
A method for virtual subscriber identity module, SIM, sharing comprising:
transmitting (<NUM>), with a transceiver (<NUM>) of a first device (<NUM>10A), a first request to a first service provider (<NUM>) to share one or more services with a second device (110B), the first request including the one or more services, first service details, and at least one of first device information or second device information;
receiving (<NUM>), at the transceiver, (i) a SIM over-the-air, SIM-OTA, message from the first service provider (<NUM>) and (ii) a unique identifier from the first service provider (<NUM>);
determining (<NUM>), with a processor (<NUM>) of the first device (<NUM>10A), that a first service of the one or more services is an existing service on a first virtual SIM (632A) with a second service provider;
re-provisioning, with the processor (<NUM>), the first virtual SIM (632A) using the SIM-OTA message to enable the first device (110A) to receive the one or more services from the first service provider (<NUM>) according to the first service details; and
transmitting (<NUM>), with the transceiver (<NUM>), the unique identifier to the second device (110B), wherein the second device (110B) is to transmit the unique identifier to the first service provider (<NUM>) to receive the one or more services from the first service provider (<NUM>).