Patent Publication Number: US-9854046-B2

Title: Method for registering at least one public address in an IMS network, and corresponding application

Description:
The field of the invention is that of telecommunications in data transmission networks. More specifically, the present invention relates to the registering of at least one public address in an IMS (IP Multimedia Subsystem) network. 
     An IMS network is an IP network connected to an access network. The IMS network provides a dynamic combination of voice, video, messages, data, etc. transmission during the same session. The IMS uses the SIP (Session Initiation Protocol) protocol to establish and control communications or sessions between user terminals (called terminal points) or between terminal points and application servers. The SIP protocol enables a caller to establish a session by packet switching with a person called (using SIP User Agents, UAS, installed in the terminal points), even though the caller does not know the caller&#39;s current IP address before making the call. 
     The current 3GPP IMS specifications require the use of a procedure of user authentication to the IMS network. This procedure is described in 3GPP TS 24.229 and 33.203. Using this approach, the identity of the private user (IMPI) and one or more public identity(ties) of the users (IMPU) are allocated to the user by the operator. To participate in multimedia sessions, the user must register at least one IMPU in the network. The identities are then used by the network to identify the user when registering and the authentication procedure (the IMPI is used to locate the subscribers&#39; information, such as the user authentication data, whereas the allocation model mentions the user identity that the user wants to interact with and which specific services must be linked with). The IMPI and the IMPUs are stored in an application called IMS Subscriber Identity Module (ISIM) conventionally stored in an integrated circuit card (UICC), in the user&#39;s terminal. 
     Each IMPU is associated with a so-called service profile. The service profile is a set of services and related data, which includes, among others, initial filtering criteria which provide a service logic easily accessible to the user (for example, it defines a set of IMS services that the public identity IMPU will be allowed to use). 
     The network giving access to the IMS network is, for instance an UMTS, LTE, WLAN and/or Internet network. 
       FIG. 1  shows such an IMS network connected to various access networks. 
     An IMS network  10 , as defined by 3GPP TS 23.228, is connected to application servers  11 ,  12  by SIP  13 , connections. The servers  11  and  12  host IMS applications representing services such as instant messaging, presence management (user present, absent, in a meeting, . . . ), call screening and real-time sessions, such as Voice over IP (VoIP), video conferencing, video on demand, video sharing, network games or television via IP. 
     Users of the terminal points  15  to  20  access these services of the IMS network via access networks, such as a UMTS network  21 , a LTE (Long Term Evolution)  22 , a 3GPP2 network  23 , a WLAN network  24  or an Internet network  25 . The terminal  17  communicates via a wireless connection  26  with the LTE network  22  and an EV-DO link  27  with the 3GPP2 network  23 . 
     The IMS network  28  includes a proxy connected by SIP links  29  to  31  to interconnection gateways, such as a GGSN (Gateway GPRS Support Node) gateway  32  more particularly in charge of providing an IP address to the terminal point  15  including a GPRS terminal throughout its connection to the IMS network, with a PDN GW gateway (Packet Data Network Gateway)  33  providing the same service for the LTE terminals  16  and  17 , and a PDSN (Packet Data Serving Node) gateway  34  providing a connection via the 3GPP2 network  23  of the terminal  18  of the CDMA 2000 type. 
     The access to the services of the IMS network  10  by the users of the terminal points  15  to  20  is obtained when such users are connected to their access networks and have requested an IP connection to the IMS network  10 . The terminal points can also communicate with each other via the IMS network, such as VoIP. 
     The authentication of the terminal points by the IMS network  10  is achieved through their private identities IMPIs, generally contained in a USIM or an ISIM application embedded in each one of the terminal points  15  to  20 . Each terminal point therefore has its own private identity IMPI. During the request for access to the IMS network  10 , a terminal point submits its IMPI to the network  10  and, if authenticated (in a registration server called HSS—Home Subscriber Subsystem), access rights are granted thereto according to its profile and its subscription. The IMS network shall in particular charge the user and control the session. 
     Each terminal point  15  to  20  also contains at least one public (i.e. not secret) address IMPU which enables the user to request and receive communications with other users or to access a service. The IMPUs are thus in the form of a SIP URI (Unified Resource 
     Identifier) as defined in the IETF RFC 3261 and IETF RFC recommendations 2396. For example, an IMPU address could be in the following form: 
     sip: jean-yves@gemalto.com 
     or else as a phone number: 
     sip: 0123456789@gemalto.ims.com. 
     On the contrary, the format of an IMPI private address is of the following type: 
     &lt;xyz&gt;@gemalto.com 
     with &lt;xyz&gt; being a string of any characters, the format of an IMPI being called a Network Access 
     Identifier as described in the IETF RFC 2486 recommendation. 
     The IMPUs and the IMPI are conventionally stored in the ISIM application of a terminal point. The terminal point may contain software that can save IMPUs or the right to register the IMPUs, i.e. to select the active IMPU at any given moment is left to the user. The user can for example decide that his/her professional IMPU must remain active during his/her working hours and that his/her private IMPU must be active outside these hours. 
     If the terminal point does not include any ISIM or USIM application, the IMPUs and the IMPI are stored in a memory of the terminal point. In a typical embodiment, the ISIM is stored in a secure element, for example in a UICC smart card which can be removed from the terminal point. A UICC card may include one or more ISIM or USIM application(s). The secure element may also be an integral part of the terminal point. 
     After or during the authentication of a terminal point by recognition of its IMPI and checking the secrets it contains, the terminal point submits one of its IMPU addresses to the HSS of the IMS network  10  in order to register therein and be able to use an IMS service. 
     The problem to be solved by the present invention is as follows: when customizing a UICC or a terminal, the end user is not known. Therefore there is no IMPU in the UICC or in the terminal sold to the end user. At best, any (not customized) IMPU is stored in the UICC (e.g. martin1234@gemalto.com). The user of a terminal then usually registers the IMPUs at the point of sale of the terminal in one of the operator&#39;s commercial branches. One of the operator&#39;s commercial agent with whom the user takes a subscription registers one or more IMPU(s) selected by the end user via an operator terminal. This/these IMPU(s) is/are loaded by an appropriate connection into the UICC or in the terminal (wired connection, OTA, . . . ) and the operator&#39;s HSS is informed thereof in parallel. 
     In practice and as an example, the operator&#39;s agent enters an administrative code ADM using the “Verify Pin” command and updates the EF_IMPU file of the UICC using an “Update” command, with the UICC being inserted into a card reader. 
     The disadvantage of this solution is that the end user needs to go to one of the operator&#39;s branches to customize his/her terminal/UICC to register therein one or more IMPU(s) he/she has selected. This also applies if the user wishes to add, delete or modify any of his/her IMPUs when using the terminal. 
     In addition, the 3GPP TS31.103 standard does not enable a user to update the ISIM in his/her terminal: access to the EF_IMPU file requires a command of the administrative type (“ADM command”) that only the operator knows. The end user therefore cannot modify or update himself/herself the contents of the file containing one or more IMPU(s). Reference will advantageously be made to version  10  of the standard published in April 2011, where paragraph 4.2.4 entitled EF_IMPU (IMS public user identity) shows that the “Update”, “Deactivate” and “Activate” commands of IMPUs are protected by administrative codes. 
     The present invention is especially aimed at overcoming this drawback. 
     More specifically, one object of the invention is to provide a method and an application enabling the user of a terminal including a security element to personally create, edit, activate or deactivate a public address IMPU from his/her terminal without having to go to one of his/her telephone operator&#39;s commercial branches. 
     This objective, as well as others which will become apparent hereinafter, is achieved using a method for registering at least one public address in an IMS network including a terminal that interacts with a security element, with the security element including an application that invites the user of the terminal, upon the occurrence of an event, to enter a public address, selected by the user, via the man-machine interface of the terminal, with the application transmitting the public address accompanied by at least one identifier of the security element to a remote network via the terminal, so that the remote network associates the public address with the identifier. 
     Preferably, the remote network includes an OTA platform used as an entry point to a HSS of an IMS network. 
     Advantageously, the method according to the invention consists in transmitting from the remote network to the security element an association acknowledgment message once the public address is associated with the identifier. 
     In an advantageous embodiment, the invention consists in updating the terminal with the public address after the receiving of said association acknowledgment message by said security element. 
     Preferably, the identifier of the security element includes at least one of the following identifiers:
         the IMSI;   the ICCID;   the IMPI.       

     The event is for example the first powering on of the terminal. 
     The invention also relates to an application for registering at least one public address in an IMS network including a terminal that interacts with a security element, with said security element including said application, characterized in that said application prompts the user of said terminal, upon the occurrence of an event, to enter a public address, selected by the user, via the man-machine interface of said terminal, with said application transmitting said public address, accompanied by at least one identifier of said security element, to a remote network via said terminal such that said remote network associates the public address with the identifier. 
    
    
     
       Other features and advantages of the invention will become apparent upon reading the following description of a preferred embodiment, given in an illustrative and not restrictive example and the appended figures wherein: 
         FIG. 1  shows an IMS network connected to various access networks; 
         FIG. 2  shows an exemplary implementation of the method according to the invention. 
     
    
    
       FIG. 1  has been described with reference to the prior art. 
       FIG. 2  shows an exemplary implementation of the method according to the invention. 
     The invention proposes to operate an application (applet) installed in an ISIM within a UICC  100 . The UICC  100  is included in a terminal  101 , shown here as a mobile phone. The application can also be installed in a chip (eUICC) integral with the terminal  101 , with the UICC  100  then not being removable from the terminal  101  as a SIM card can be. 
     The UICC  100  or eUICC can also communicate by radio (for example Bluetooth or WiFi) with the terminal  101 , i.e. it needs not be included in the terminal  101 . It may for example be installed in a remote element such as a watch, with the main point being that it communicates with the terminal  101 . 
     The terminal  101  is capable of communicating with a remote network here including an OTA platform  101  and an HSS element  103  of an operator&#39;s network. The terminal  101  can communicate with the HSS  103  through the OTA platform  102 . 
     The HSS  103  is particularly used to store, for each network user, information relative to his/her UICC  100 . As such, to each UICC is associated an IMSI/ICCID an IMPI, one or more IMPU(s), its IMS domain (the IMS domain enables subscribers to communicate with each other via the IMS services or to access IMS services hosted on service platforms) and a service profile. Prior to the execution of the application according to the invention, the HSS  103  knows the user  104  by his/her IMSI, its ICCID and/or its IMPI, the domain which it belongs to and its service profile. It also knows that no IMPU is associated with these identifiers (IMPU NOK). Similarly, the UICC  100  contains the EF_IMPI, EF_Domain and EF_PCSCF files (the IP address of the proxy giving access to the operator). The UICC  100  also contains the EF_IMPU (EF_IMPU NOK) empty file. 
     On the occurrence of an event, for example on the first powering on of the terminal  101 , upon the powering on of the terminal  101  after downloading the application according to the invention, or upon activation of a function in a menu, or more generally upon request, a greeting message  105  prompts the user  104  of the terminal  101  to enter one or more IMS profile(s), with an IMS profile corresponding to an IMPU address. 
     The user  104  then enters one or more IMPU(s) of selected by him/her via the man-machine interface of the terminal  101 , such as a keyboard. In the example shown, he/she selects the following addresses during a step  106 : 
     Sip: James.bond@mno.com 
     Sip: Bob.thebest@mno.com 
     Sip: little.Louise@mno.com 
     The application submits these public addresses to the ISIM during a step  107  using a STK command. The ISIM temporarily stores these IMPUs in an appropriate directory. 
     During a step  108 , the application submits the IMPUs selected by the user  104  to the OTA platform  102 , together with at least one identifier of the UICC. In the given example, three identifiers of the UICC are transmitted with the IMPUs to the OTA platform  102 : the 
     IMSI, the ICCID and the IMPI. The OTA platform forwards such identifiers (IMSI/ICCID/IMPI/IMPUs) to the HSS during a step  109 . The HSS  103  then checks the IMPUs selected by the user  104 . This checking more particularly consists in verifying that the received IMPUs have not already been assigned to another user, having subscribed to the same operator&#39;s network or another operator&#39;s network. The HSS  103  also associates the IMPUs received with the identifier of the UICC. 
     If the HSS  103  finds that the received IMPUs are available, it shall inform the UICC thereof by an association acknowledgment message ACK (step  110 ) once the public address(es) has/have been associated with the identifier or identifiers received. This message is forwarded from the OTA platform  102  to the UICC  100 . 
     The ISIM then updates its EF_IMPU 6F04 file including the user&#39;s  104  IMPUs. This update consists in registering therein the IMPUs previously stored temporarily in the aforementioned appropriate directory. 
     If one of the IMPUs is not available, it also informs the UICC thereof so that it does not take into account the not available IMPU. A message is then displayed to the user to inform him/her of the non-availability of this IMPU, together with an invitation to select another one, if need be. 
     The application then submits a “Refresh ISIM” command to the terminal  101  (step  111 ), so that the latter can take the new IMPUs into account. The terminal then acknowledges receipt of these IMPUs during step  112 . The registering of the IMPUs can then be validated (executed after step  110 ). 
     Optionally, the user  104  may then be invited to subscribe to services (step  113 ) since he/she now has at least one IMPU address. If the user agrees thereto, a list of services can be proposed to him/her (step  114 ). Here, four services are offered to the user:
         Video on demand   Messaging   Online Games   Music downloading       

     If the user selects e.g. “Online Games”, the HSS  103  receives an order for online games service (step  115 ), together with at least one identifier of the UICC (here, the IMSI, the ICCID and the IMPI) through the OTA platform  102 . The HSS  103  can then contact the UICC  100  using one of the IMPUs associated with the received identifier, using the received identifier. 
     The invention described above is provided within the scope of the creation of IMPUs, but it may also be applied to the modification of existing IMPUs, as well as to the activation or deactivation of IMPUs, or to the deleting of IMPUs. 
     The application of the ISIM making it possible to implement the present invention can be saved in the ISIM under the operator&#39;s control, for example via the OTA platform  102 . The installation thereof in the ISIM is performed under the operator&#39;s control and the application includes the PIN and administrative (ADM) rights. The operator has the rights to install the application in the ISIM of the user&#39;s UICC (eUICC). The application thus knows the administrative code (ADM) giving access to the HSS and to save one or more IMPU(s) therein. 
     The invention is therefore based on a trusted application which is an applet installed in a UICC. This applet initiates the dialogue between the OTA platform  102  and the HSS  103  to send the IMPUs selected by the user  104 . Further to the agreement from the HSS  103 , this applet writes the selected IMPUs into the EF_IMPU file (via an internal interface of the OS and because it was installed with the administrative right ADM). 
     The invention thus enables a user to create, modify, activate or deactivate one or more IMPU(s) in an IMS network. 
     The OTA platform  102  which acts in the previous description, as the entry point to a HSS in an IMS network may be substituted with an application server connected to the operator&#39;s HSS. 
     The communications shown in  FIG. 2  are preferably of the http type (full IP network such as 
     LTE), but communications of the SMS or SIP types may also be used between the terminal  101  and the OTA platform  102 , and even between the platform  102  and the HSS  103 . These communications are encrypted by well known means to prevent fraud and guarantee the user&#39;s  104  and the network operator&#39;s security. 
     The invention makes it possible to find a way parallel to the existing standard, by enabling the user of a terminal to define IMPUs addresses he/she has selected, without having to go to one of his/her operator&#39;s branches. 
     The invention also relates to an application for registering at least one public address in an IMS network including a terminal that interacts with a security element, with the security element containing this application prompting the user of the terminal, upon the occurrence of an event, to enter a public address, selected by the user, via the man-machine interface of the terminal, with the application transmitting the public address together with at least one identifier of the security element to a remote network via the terminal, so that the remote network associates the public address with the received identifier. 
     The invention makes it possible for a user of a terminal to avoid having to go to one of his/her telephone operator&#39;s branch offices or to connect to an internet service after purchasing the terminal with his/her UICC (eUICC), in order to configure it with his/her IMPU (s). 
     The operator&#39;s HSS is dynamically updated by the end user and the invention meets the standards of the IMS, 3GPP in the ISIM and OTA exchanges (“OTA messaging”) and of the supplying of the operator&#39;s HSS.