Authorizing use of third party specific user identification in internet protocol multimedia subsystem

Abstract

The invention relates to authorizing the use of third party specific user identification in an Internet Protocol Multimedia Subsystem. A method for authorizing use of a third-party specific user identification may include sending a request to a signature server to sign an identifier associated with third-party user data, the identifier having been determined to be a uniform resource identifier. The method may also include receiving a reply including a signature token associated with the uniform resource identifier; and modifying the session initiation protocol invitation request by inserting the uniform resource identifier and the signature token into one or more headers of the session initiation protocol invitation request. The method may also include providing the modified session initiation protocol invitation request to the destination network for initiating communication between the at least two user devices.

Description

Technical Field

[0001] Some example embodiments generally relate to mobile or wireless telecommunication systems, such as Long Term Evolution (LTE) or fifth generation (5G) New Radio (NR) access technologies, or above 5G, or other communication systems. For example, certain example embodiments may relate to authorizing the use of a third party specific user identity in an Internet Protocol (IP) Multimedia Subsystem (IMS). Background Art

[0002] Examples of mobile or wireless telecommunication systems may include Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), MulteFire, LTE-A Pro and / or fifth generation (5G) radio access technology or new radio (NR) access technology. Fifth generation (5G) wireless systems refer to next generation (NG) radio systems and network architectures. 5G network technology is primarily based on new radio (NR) technology, but 5G (or NG) networks may also be built on E-UTRAN radios. It is estimated that NR can provide bit rates of approximately 10-20 Gbit / s or higher and can support at least enhanced mobile broadband (eMBB) and ultra-reliable low latency communications (URLLC) and massive machine type communications (mMTC). NR is expected to provide ultra-wideband and ultra-robust, low latency connectivity and massive networking to support the Internet of Things (IoT). Summary of the invention

[0003] Various example embodiments may provide an apparatus comprising: means for sending a request to a signing server to sign an identifier associated with third-party user data, the identifier having been determined to be a uniform resource identifier. The apparatus may also include: means for receiving a reply including a signature token associated with the uniform resource identifier; and means for modifying a session initiation protocol invite request by inserting the uniform resource identifier and the signature token into one or more headers of the session initiation protocol invite request. The apparatus may also include: means for providing the modified session initiation protocol invite request to a destination network for initiating communication between at least two user devices.

[0004] Certain example embodiments may provide an apparatus comprising: means for receiving a session initiation protocol invite request from a network, the session initiation protocol invite request including a uniform resource identifier and a signature token in one or more headers of the session initiation protocol invite request. The apparatus may also include: means for verifying the uniform resource identifier using the signature token using a verification server. The apparatus may also include: means for relaying the session initiation protocol invite request including the uniform resource identifier to a destination user device for configuring communications with at least one other user device when the uniform resource identifier is verified. The at least one other user device may retrieve third-party user data associated with the identifier from a third-party network.

[0005] Some example embodiments may provide a method comprising: sending a request to a signing server to sign an identifier associated with third-party user data, the identifier having been determined to be a uniform resource identifier. The method may also include: receiving a reply including a signature token associated with the uniform resource identifier; and modifying a session initiation protocol invite request by inserting the uniform resource identifier and the signature token into one or more headers of a session initiation protocol invite request. The method may also include: providing the modified session initiation protocol invite request to a destination network for initiating communication between at least two user devices.

[0006] Various example embodiments may provide a method comprising: receiving a session initiation protocol invite request from a network, the session initiation protocol invite request comprising a uniform resource identifier and a signature token in one or more headers of the session initiation protocol invite request. The method may also include: using a verification server to verify the uniform resource identifier using the signature token. The method may also include: when the uniform resource identifier is verified, relaying the session initiation protocol invite request including the uniform resource identifier to a destination user device for configuring communications with at least one other user device. The at least one other user device may retrieve third-party user data associated with the identifier from a third-party network. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to properly understand the example embodiments, reference should be made to the accompanying drawings, as follows:

[0008] Figure 1 An example of a signal diagram illustrating one or more processes according to certain example embodiments;

[0009] Figure 2 An example of a flow chart illustrating a method according to various example embodiments;

[0010] Figure 3an example of a flowchart illustrating another method according to some example embodiments; and

[0011] Figure 4 A set of devices according to various example embodiments is shown. DETAILED DESCRIPTION

[0012] It should be readily understood that the components of the specific example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a variety of different configurations. The following is a detailed description of some example embodiments of systems, methods, apparatuses, and non-transitory computer program products for authorizing the use of third-party specific user identities in an Internet Protocol (IP) Multimedia Subsystem (IMS). Although the devices discussed below and shown in the figures refer to 5G or next-generation NodeB (gNB) devices and user equipment devices, the present disclosure is not limited to the network nodes, gNBs, and UEs discussed herein.

[0013] It can be easily understood that, as generally described and shown in the drawings herein, the components of a particular example embodiment can be arranged and designed in a variety of different configurations. In the description, different reference numerals in multiple figures may be used out of order to refer to the same element to illustrate their features or functions. If necessary, the different functions or processes discussed herein may be performed in different orders and / or simultaneously with each other. In addition, if necessary, one or more of the described functions or processes may be optional or may be combined. Therefore, the following description should be regarded as an explanation of the principles and teachings of a particular example embodiment, rather than a limitation thereof.

[0014] In 5G / NR technology, the next generation real-time communication (NG_RTC) may implement IMS as a network architecture that integrates with 4G LTE and 5G networks to allow IP-based real-time services. The network may use IMS to transmit, for example, voice calls, video calls / streaming, text messages, multimedia messages, and / or other real-time services. The Third Generation Partnership Project (3GPP) may have specific protocols established for implementing IMS networks. However, access to the IMS network by a third party (e.g., an enterprise user) may not be authorized. Traditional IMS networks do not have such a mechanism: where the serving IMS network can authorize a third-party user, and whether the authorized third-party user is allowed to communicate with the IMS network using a third-party specific user identity, for example, to initiate a phone call via IMS, and to provide other user-related data in addition to the phone number, such as a position or department name.

[0015] The third party may have a specific user ID, which may be, for example, a company name and logo, a department name, a location, a picture, a position, etc. The third party ID may conform to the Internet Engineering Task Force (IETF) draft-ietf-sipcore-callinfo-rcd or any similar document agreed by the IETF, which defines rich call data (RCD) as a jCard, which may take the form of a JavaScript Object Notation (JSON) object. The third party ID may be stored at a server and may be retrieved via a uniform resource indicator (URI) pointing to a corresponding resource on the server. The server may be, for example, a web server. The URI may be transmitted from side A to side B as part of the Call-Info header field in a Session Initiation Protocol (SIP) request. The jCard may also be carried in the body of the SIP request. In order to prevent scammers or spammers from providing illegal or false information, the provided data (such as the URI in the Call-Info header) may be signed by the initiating network by calling a signature server based on IETF draft-ietf-stir-passport-rcdor or a similar document agreed by the IETF. The terminating network side can verify the provided data by calling the verification server.

[0016] A technique for authorizing third-party (e.g., enterprise) user data (such as a URI in a Call-Info header) may be to sign the third-party user data by a signing server. The third-party user data may be provided by a third-party user or by an IP Private Branch Exchange (IP PBX). The IMS may trust the provided data based on a service level agreement (SLA) and may sign the provided data using, for example, IETF draft-ietf-stir-passport-rcd. This technique may have less impact on the IMS and does not require the IMS to retrieve or store enterprise-specific data. However, the technique may not allow the IMS to check whether the third-party (e.g., enterprise) user is authorized to use the provided data (which may include a position), even in the case where the third-party subscription data may be stored in the Home Subscriber Server (HSS) of the IMS.

[0017] Another technique may be to use IMS to retrieve third-party specific user data from a third-party network during IMS call setup. For example, the Serving Call Session Control Function (S-CSCF) and / or Telephony Application Server (TAS) of the IMS may be used. This may be done via a Network Exposure Function (NEF) or directly via a third-party Application Function (AF) such as an enterprise AF. This technique may require the IMS to query the third-party (e.g., enterprise) network during call setup in the case where the call ID is a specific IMS Public User Identity (IMPU) and allow authorization to use the third-party user data while avoiding storing the data in the HSS. In the case of an IP PBX, individual subscription data may not exist in the HSS and the IMS may need to trust the data provided by the IP PBX.

[0018] Another technique may be to use only group data (such as company name and logo) which may be stored in the HSS without individual data (including third party individual data). This technique may not require the IMS to interact with third party networks, but may require data to be stored in the HSS which may vary for various third party networks. This technique may not allow storage of individual third party specific user data in the HSS.

[0019] Various example embodiments can advantageously improve the deficiencies of the above-described techniques. Certain example embodiments can allow the IMS to authorize a third-party (e.g., enterprise) user to use a third-party specific user identity without storing individual user identity information in the IMS / HSS. If the data is stored in the HSS, it may be disadvantageous because different third parties may use different data sets, and the data may change frequently, such as when an employee changes from one job to another or is relocated within a company. Various example embodiments can specify that the data is stored in a third-party (e.g., enterprise) network or another storage device. draft-ietf-stir-passport-rcd can be used to define the data. Third-party specific user data can be accessed via an individual and unique ID, which can be, for example, a URI described in draft-ietf-stir-passport-rcd.

[0020] Some example embodiments may provide that the IMS stores individual subscription data of third-party (e.g., enterprise) users. The HSS may store subscription data of third-party (e.g., enterprise) users. A unique ID (e.g., a static URI) associated with third-party user data stored on a server (e.g., a web server) in a third-party network may be stored in the service profile of the third-party user as a new parameter together with the IMPU. The service profile may, for example, include information about activated call forwarding or other multimedia telephony service information. Different identifiers (IDs) may be stored per service profile. The TAS or S-CSCF may obtain the ID and the service profile from the HSS, for example, by downloading.

[0021] If the unique ID is a URI, the unique ID can be directly inserted into the Call-Info header according to draft-ietf-stir-passport-rcd and can be signed by the signature server triggered by the IMS. If the unique ID is not a URI, the TAS, S-CSCF, or another entity of the network can convert the ID into a URI before inserting the URI into the Call-Info header. By using the unique ID as the URI, there is no need to retrieve third-party user data from a third-party (e.g., enterprise) network during call establishment, and there is no need to store individual third-party user data in the HSS. Although the third-party user data may change in the third-party (e.g., enterprise) network, the unique ID or URI will not change, or will rarely change. The third-party (e.g., enterprise) server can redirect the HTTP request to the new URI and can provide the new URI to the IMS. The unique ID / URI can be provided by the third-party (e.g., enterprise) network together with the IMPU and other service-related data, and thus be considered trustworthy. Therefore, various example embodiments may provide that when the UE provides untrusted data in the SIP INVITE, the IMS is not required to accept the untrusted data.

[0022] According to some example embodiments, the IMS may retrieve third-party data directly from a server storing the third-party data using a unique ID / URI via the TAS, HSS and / or S-CSCF. This may be achieved via an HTTP GET request containing the unique ID / URI as the RequestURI. The HTTP GET request may be provided during or after the data is stored in the HSS or during call establishment. The HTTP GET request may be repeated at regular or preset time intervals. The unique ID / URI may be provided to the HSS via Operation, Administration and Maintenance (OAM), or provided to the HSS by a third-party network via the NEF API together with other IMPU-specific service data, or provided to the HSS by any other means.

[0023] Certain example embodiments may involve an IP PBX where the IMS is only aware of the PBX bootstrap directory number (DN) used. However, the IMS is not aware of whether individual DNs outside the range of the bootstrap DN are valid, meaning that the IMS is unclear whether an individual DN is assigned to a particular user of the IP PBX. The HSS does not store subscription data for individual third-party (e.g., enterprise) users. The IMS may treat third-party user data or URIs provided by the IP PBX as trusted in a manner similar to how the IMS trusts the calling number identity provided by the IP PBX. Some example embodiments may provide that the IMS may be configured with information or instructions per bootstrap DN that are configured to define the manner in which a unique ID / URI is created based on the IMPU used as the calling number. Configuration per bootstrap DN may be done in the TAS or CSCF. Information or instructions for configuring the IMS per bootstrap DN may be stored in the HSS and provided via OAM, or provided by a third-party network via the NEF API.

[0024] Figure 1 An example of a signal diagram of one or more processes for storing a URI pointing to third-party user data in an HSS per user's IMPU according to a specific example embodiment is shown. The one or more processes may be performed, for example, using a third-party network, an initiating IMS network, and a terminating IMS network. At 110, a third-party user equipment (UEA) 10 in the third-party network may send a SIP INVITE message with the IMPU as a call ID to the CSCF 12 of the initiating IMS network. A service profile including the IMPU and the URI pointing to user data stored on the third-party network may be stored in the HSS 14. The service profile may be stored in the HSS via OAM or via the NEF through the third-party network.

[0025] At 120, CSCF 12 can forward the SIP INVITE received from UE A 10 to TAS 15 to perform the specified service. At 130, TAS 15 can query HSS 14 to obtain a service profile. The service profile may include a URI pointing to user data stored in a third-party network specific to the IMPU. At 140, TAS 15 or alternatively, for example, a CSCF or SBC 16 on an initiating IMS network can request the signature server 13 to sign the URI through, for example, draft-ietf-sipcore-callinfo-rcd, draft-ietf-stir-passport-rcd, and ATIS-1000094. Data can be retrieved via the URI using the format defined in draft-ietf-sipcore-callinfo-rcd. Then, the data can be signed as defined in draft-ietf-stir-passport-rcd and ATIS-1000094. The output of the signature process is a token placed in the SIP INVITE. Since the URI is stored in the HSS 14, the use of the URI may be implicitly authorized. The signing server 13 may respond with a signed token according to draft-ietf-stir-passport-rcd. The signed token may be used as a signature for the rich call data of the user of UE A 10 in addition to the existing token that is a signature for the user's calling line ID. The signed token and the existing token may be transmitted in an additional identity header. The signed token may be an output of a process in which the rich call data (RCD) is signed and the existing token may be an output of signing the calling line ID.

[0026] At 150, TAS 15 may add or insert a URI in the Call-Info header according to draft-ietf-sipcore-callinfo-rcd. The signature token may be transmitted in the SIP INVITE to the terminating IMS network via SBC 16. At 160, the SBC 16 on the originating IMS network may forward the SIP INVITE to the terminating IMS network. At 170, the SBC, CSCF, or TAS 17 on the terminating IMS network may verify the signature token via the verification server 18, for example, using draft-ietf-sipcore-callinfo-rcd, draft-ietf-stir-passport-rcd, and ATIS-1000094.

[0027] At 180, the SIP INVITE may be forwarded to UE B 19. At 190, UE B 19 may send an HTTP request using the URI provided in the SIP INVITE to retrieve and display the specific third-party user data of UE A 10 at UE B 19.

[0028] Various example embodiments can provide technical advantages that enable the IMS to make an informed decision about whether to trust third-party user data. The IMS may not need to accept such data when it is provided by the UE in a SIP INVITE. Certain example embodiments allow for authorized third parties to access an IMS network and define a process for an authorized third party to verify whether a third-party user is allowed to initiate a phone call using a third-party specific identity.

[0029] Figure 2 An example flow chart of a method according to a specific example embodiment is shown. In an example embodiment, Figure 2 The method may be performed by a network unit or a group of multiple network units in a 3GPP system (such as LTE or 5G-NR). For example, in an example embodiment, Figure 2 The method may also be performed by a network element (such as TAS) on the initiating IMS network, which network element is similar to Figure 4 Device 410 is shown.

[0030] According to various example embodiments, Figure 2 The method may include sending a request to a signing server to sign an identifier associated with third-party user data, the identifier having been determined to be a URI, at 210. The method may also include receiving a reply including a signature token associated with a uniform resource identifier, at 220, and modifying the SIP INVITE request by inserting the URI and the signature token into one or more headers of the SIP INVITE request, at 230. At 240, the method may include providing the modified SIP INVITE request to a destination network to initiate communication between at least two UEs.

[0031] Certain example embodiments may provide that the method further comprises obtaining an identifier associated with the third-party user data from a storage device, and / or determining whether the identifier obtained from the storage device is a URI. The method may also comprise converting the identifier obtained from the storage device into a URI when it is determined that the identifier is not a URI. Alternatively or additionally, the method may comprise obtaining a service profile including the identifier from the storage device. The third-party user data associated with the identifier may comprise user data of a user in a third-party network. Some example embodiments may provide that the method comprises obtaining the identifier from the third-party network via an application programming interface, or providing the identifier via an operation and management interface.

[0032] Various example embodiments may provide that the method includes obtaining third-party user data associated with an identifier from a third-party network, and sending a request to a signing server to sign the third-party user data obtained from the third-party network. The method may also include receiving a reply including a signature token associated with the third-party user data, and modifying the SIP INVITE request by inserting the third-party user data and the signature token into one or more headers of the SIP INVITE request. The modified SIP INVITE request may be provided to a destination network for initiating communication between at least two UEs. The identifier may be provided by an IP PBX.

[0033] Figure 3 An example flow chart of a method according to a specific example embodiment is shown. In one example embodiment, Figure 3 The method may be performed by a network unit or a group of multiple network units in a 3GPP system (such as LTE or 5G-NR). For example, in an example embodiment, Figure 3 The method may be performed by a network element (such as SBC, CSCF or TAS) terminating the IMS network, which is similar to Figure 4 Device 420 is shown.

[0034] According to various example embodiments, Figure 3 The method may include receiving a SIP INVITE request from a network at 310, the SIP INVITE request including a URI and a signature token in one or more headers of the SIP INVITE request. At 320, the method may include using a verification server to verify the URI using the signature token, and at 330, the method may include, when the URI is verified, relaying the SIP INVITE request including the URI to a destination UE for configuring communications with at least one other UE. The at least one other user device may obtain third-party user data associated with the identifier from a third-party network.

[0035] Certain example embodiments may provide for validating a URI by: (i) sending a validation request including the URI and a signature token to a validation server, and (ii) receiving a reply including an indication of whether the URI is validated. A storage device may be caused to create an identifier based on a PBX DN and a calling number provided in a SIP INVITE request using the supplied instructions, or to retrieve the instructions from the storage device. The method may also include retrieving the supplied instructions from a third party network via an API, or providing the supplied instructions via an OAM interface. The method may also include retrieving third party user data associated with the identifier from the third party network, and relaying a session initiation protocol invite request including the third party user data to a destination user device for configuring communications with at least one other user device.

[0036] Figure 4 A set of apparatuses 410 and 420 are shown according to various example embodiments. In various example embodiments, apparatus 410 may be a network, a network entity or a unit located in a communication network or associated with such a network, such as a network unit in an originating IMS network. For example, TAS 15 may be an example of apparatus 410. It should be noted that a person skilled in the art will understand that apparatus 410 may include Figure 4 Components or features not shown in the diagram. In addition, the device 420 may be a network, a network entity, or a unit located in a communication network or associated with such a network (such as a terminating IMS network). For example, an SBC, a CSCF, or a TAS may be examples of the device 420. It should be noted that a person of ordinary skill in the art will understand that the device 420 may include Figure 4 Components or features not shown.

[0037] According to various example embodiments, the apparatus 410 may include at least one processor 412 and at least one memory 414, such as Figure 4 As shown. The memory 414 may store instructions that, when executed by the processor 412, may cause the device 410 to send a request to a signature server to sign an identifier associated with the third-party user data, the identifier having been determined to be a uniform resource identifier. The device 410 may also receive a reply including a signature token associated with the uniform resource identifier, and modify the session initiation protocol invitation request by inserting the uniform resource identifier and the signature token into one or more headers of the session initiation protocol invitation request. The device 410 may also provide the modified session initiation protocol invitation request to the destination network for initiating communication between at least two user devices.

[0038] According to various example embodiments, the apparatus 420 may include at least one processor 422 and at least one memory 424, such as Figure 4As shown. The memory 424 may store instructions that, when executed by the processor 422, may cause the device 420 to receive a session initiation protocol invitation request from a network, the session initiation protocol invitation request including a uniform resource identifier and a signature token in one or more headers of the session initiation protocol invitation request. The device 420 may also be caused to use a verification server to verify the uniform resource identifier using the signature token. The device may also be caused to relay the session initiation protocol invitation request including the uniform resource identifier to a destination user device for configuring communications with at least one other user device when the uniform resource identifier is verified. The at least one other user device may obtain third-party user data associated with the identifier from a third-party network.

[0039] In some example embodiments, apparatus 410 and / or 420 may include one or more processors, one or more computer-readable storage media (e.g., memory, storage device, etc.), one or more radio access components (e.g., modem, transceiver, etc.), and / or a user interface. In some example embodiments, apparatus 410 and / or 420 may be configured to operate using one or more radio access technologies, such as GSM, LTE, LTE-A, NR, 5G, WLAN, WiFi, NB-IoT, Bluetooth, NFC, MulteFire, and / or any other radio access technology.

[0040] like Figure 4 As shown in the example, devices 410 and / or 420 may include or be coupled to processors 412 and 422, respectively, for processing information and executing instructions or operations. Processors 412 and 422 may be any type of general-purpose or special-purpose processors. In practice, processors 412 and 422 may include, as examples, one or more of a general-purpose computer, a special-purpose computer, a microprocessor, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and a processor based on a multi-core processor architecture. Although Figure 4 A single processor 412 (and 422) is shown for each of the devices 410 and / or 420, but according to other example embodiments, multiple processors may be used. For example, it should be understood that in certain example embodiments, the devices 410 and / or 420 may include two or more processors that may form a multiprocessor system that may support multiprocessing (e.g., in this case, processors 412 and 422 may represent multiple processors). According to certain example embodiments, the multiprocessor system may be tightly coupled or loosely coupled to form, for example, a computer cluster.

[0041] Processors 412 and 422 may perform functions associated with the operation of devices 410 and / or 420, respectively, including, as some examples, precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming communication messages, formatting of information, and overall control of devices 410 and / or 420, including Figure 1-3 The process shown.

[0042] Devices 410 and / or 420 may also include or be coupled to memory 414 and / or 424 (internal or external memory), respectively, which may be coupled to processors 412 and 422, respectively, for storing information and instructions that may be executed by processors 412 and 424. Memory 414 (and memory 424) may be one or more memories of any type suitable for the local application environment and may be implemented using any suitable volatile or non-volatile data storage technology, such as semiconductor-based storage devices, magnetic storage devices and systems, optical storage devices and systems, fixed memory, and / or removable memory. For example, memory 414 (and memory 424) may include any combination of random access memory (RAM), read-only memory (ROM), static memory (such as a magnetic disk or optical disk), hard disk drive (HDD), or any other type of non-transitory machine or computer readable medium. The instructions stored in memory 414 and memory 424 may include program instructions or computer program codes that, when executed by processors 412 and 422 , cause apparatus 410 and / or 420 to perform tasks described herein.

[0043] In certain example embodiments, the devices 410 and / or 420 may also include or be coupled to a (internal or external) drive or port configured to accept and read an external computer-readable storage medium, such as an optical disk, a USB drive, a flash drive, or any other storage medium. For example, the external computer-readable storage medium may store computer programs or software that are executed by the processors 412 and 422 and / or the devices 410 and / or 420 to implement the Figure 1-3 Any method shown.

[0044] In some example embodiments, the apparatus 410 may also include or be coupled to one or more antennas 415 for receiving downlink signals and transmitting signals from the apparatus 410 via an uplink. The apparatuses 410 and / or 420 may also include transceivers 416 and 426, respectively, configured to transmit and receive information. The transceivers 416 and 426 may also include a radio interface, which may correspond to a variety of radio access technologies, including one or more of GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, Bluetooth, BT-LE, NFC, RFID, UWB, etc. The radio interface may include other components, such as filters, converters (e.g., digital-to-analog converters, etc.), symbol demappers, signal shaping components, inverse fast Fourier transform (IFFT) modules, etc., to process symbols carried by the downlink or uplink, such as OFDMA symbols.

[0045] For example, transceivers 416 and 426 may be configured to modulate information onto a carrier waveform for transmission, and demodulate received information for further processing by other units of apparatus 410 and / or 420, respectively. In other example embodiments, transceivers 416 and 426 may be capable of directly transmitting and receiving signals or data. Additionally or alternatively, in some example embodiments, apparatus 410 and / or 420 may include input and / or output devices (I / O devices). In certain example embodiments, apparatus 410 and / or 420 may also include a user interface, such as a graphical user interface or a touch screen.

[0046] In certain example embodiments, memory 414 and memory 424 store software modules that provide functionality when executed by processors 412 and 422, respectively. These modules may include, for example, an operating system that provides operating system functionality for device 410 and / or 420. The memory may also store one or more functional modules, such as applications or programs, to provide additional functionality for device 410 and / or 420. The components of device 410 and / or 420 may be implemented in hardware, or as any suitable combination of hardware and software. According to certain example embodiments, device 410 may be selectively configured to communicate with device 420 via a wireless or wired communication link 430 according to any radio access technology (such as NR).

[0047] In some exemplary embodiments, an apparatus (e.g., apparatus 410 and / or apparatus 420) may include components for performing a method, process, or any variant discussed herein. Examples of components may include one or more processors, memories, controllers, transmitters, receivers, and / or computer program codes for causing operations to be performed.

[0048] Certain example embodiments may be directed to an apparatus including means for sending a request to a signing server to sign an identifier associated with third-party user data, the identifier having been determined to be a uniform resource identifier. The apparatus may also include means for receiving a reply including a signature token associated with the uniform resource identifier, and means for modifying a session initiation protocol invite request by inserting the uniform resource identifier and the signature token into one or more headers of the session initiation protocol invite request. The apparatus may also include means for providing the modified session initiation protocol invite request to a destination network for initiating communication between at least two user devices.

[0049] Various example embodiments may be directed to an apparatus comprising means for receiving a session initiation protocol invite request from a network, the session initiation protocol invite request including a uniform resource identifier and a signature token in one or more headers of the session initiation protocol invite request. The apparatus may also include means for verifying the uniform resource identifier using the signature token using a verification server. The apparatus may also include means for relaying the session initiation protocol invite request including the uniform resource identifier to a destination user device for configuring communications with at least one other user device when the uniform resource identifier is verified. The at least one other user device may retrieve third-party user data associated with the identifier from a third-party network.

[0050] According to certain example embodiments, processors 412 and 422 and memories 414 and 424 may be included in a processing circuit or a control circuit, or may form a part of a processing circuit or a control circuit. In addition, in some example embodiments, transceivers 416 and 426 may be included in a transceiver circuit, or may form a part of a transceiver circuit.

[0051] As used herein, the term "circuit" may refer to a pure hardware circuit implementation (e.g., analog and / or digital circuits), a combination of hardware circuits and software, a combination of analog and / or digital hardware circuits and software / firmware, any portion of a hardware processor with software (including a digital signal processor) that works in conjunction to enable a device (e.g., device 410 and / or 420) to perform various functions, and / or a hardware circuit and / or processor or a portion thereof that uses software to operate, but the software may not be present when the software is not required to perform the operation. As another example, as used herein, the term "circuit" may also cover an implementation of a pure hardware circuit or processor or multiple processors, or a portion of a hardware circuit or processor and accompanying software and / or firmware. The term "circuit" may also cover, for example, a baseband integrated circuit in a server, cellular network node or device, or other computing or network device.

[0052] The computer program product may include one or more computer executable components that are configured to perform some example embodiments when the program is run. The one or more computer executable components may be at least one software code or a portion thereof. Modifications and configurations required to implement the functionality of a particular example embodiment may be performed as routines that may be implemented as added or updated software routines. The software routines may be downloaded to a device.

[0053] For example, software or computer program code or a portion thereof may take source code form, object code form, or some intermediate form, and may be stored in some carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. For example, such carriers may include recording media, computer memory, read-only memory, optoelectronic and / or electrical carrier signals, telecommunication signals, and software distribution packages. Depending on the processing power required, the computer program may be executed in a single electronic digital computer or distributed among multiple computers. A computer readable medium or computer readable storage medium may be a non-temporary medium. As used herein, the term "non-temporary" is a limitation on the medium itself (e.g., a tangible medium, not a signal), rather than a limitation on the persistence of data storage (e.g., RAM vs. ROM).

[0054] In other example embodiments, the functionality may be performed by hardware or circuitry included in a device (e.g., device 410 and / or 420), such as by using an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another example embodiment, the functionality may be implemented as a signal, a non-tangible means that may be carried by an electromagnetic signal downloaded from the Internet or other network.

[0055] According to certain example embodiments, an apparatus such as a node, a device or a corresponding component may be configured as a circuit, a computer or a microprocessor, such as a single-chip computer element, or as a chipset, which includes at least a memory providing storage capacity for arithmetic operations and an operation processor for performing arithmetic operations.

[0056] The features, structures, or characteristics of the example embodiments described throughout this specification may be combined in any suitable manner in one or more example embodiments. For example, the use of the phrases "a particular embodiment," "an example embodiment," or "some embodiments," or other similar language throughout this specification refers to the fact that a particular feature, structure, or characteristic described in conjunction with an embodiment may be included in at least one embodiment. Therefore, the appearance of the phrases "in a particular embodiment," "an example embodiment," "in some embodiments," "in other embodiments," or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more example embodiments. In addition, the terms "cell," "node," "gNB," or other similar language may be used interchangeably throughout this specification.

[0057] As used herein, “at least one of: ” and “at least one of ” and similar expressions (wherein a list of two or more elements is connected by “and” or “or”) mean at least any one of the elements, or at least any two or more of the elements, or at least all of the elements.

[0058] Those of ordinary skill in the art will readily appreciate that the above disclosure may be practiced with processes in a different order and / or with hardware units that are different from the disclosed configurations. Therefore, although the present disclosure has been described based on these example embodiments, those skilled in the art will appreciate that certain modifications, variations, and alternative constructions will be apparent while remaining within the spirit and scope of the example embodiments. Although the above embodiments relate to 5G NR and LTE technologies, the above embodiments may also be applied to any other current or future 3GPP technologies, such as LTE-advanced, fourth generation (4G) technologies, and / or sixth generation (6G) technologies.

[0059] Partial Glossary :

[0060] 3GPP Third Generation Partnership Project

[0061] 5G Fifth Generation

[0062] AF Application Function

[0063] API Application Programming Interface

[0064] AS Application Server

[0065] ATIS Alliance for Telecommunications Industry Solutions

[0066] CSCF Call Session Control Function

[0067] DL Downlink

[0068] DN Directory Number

[0069] EMBB Enhanced Mobile Broadband

[0070] gNB 5G or Next Generation NodeB

[0071] HSS Home Subscriber Server

[0072] ID Identifier

[0073] IETF Internet Engineering Task Force

[0074] IMS IP Multimedia Subsystem

[0075] IMPU IMS Public User Identity

[0076] IP Internet Protocol

[0077] IP PBX IP Private Branch Exchange

[0078] Jcard JSON card

[0079] JSON JavaScript Object Notation

[0080] LTE Long Term Evolution

[0081] MNO Mobile Network Operator

[0082] NEF Network Exposure Function

[0083] NR New Radio

[0084] OAM Operations, Administration and Maintenance

[0085] RCD Rich Call Data

[0086] RTC Real-time Communication

[0087] S-CSCF Serving CSCF

[0088] SBC Session Border Controller

[0089] SIP Session Initiation Protocol

[0090] STIR Secure Telephone Identity Re-examination

[0091] TAS Telephone Application Server

[0092] UE User Equipment

[0093] UL Uplink

[0094] URI Uniform Resource Identifier

[0095] URL Uniform Resource Locator

Claims

1. A device comprising: means for sending a request to a signing server to sign an identifier associated with third-party user data, the identifier having been determined to be a uniform resource identifier; means for receiving a reply including a signed token associated with the uniform resource identifier; means for modifying the session initiation protocol invite request by inserting the uniform resource identifier and the signature token into one or more headers of the session initiation protocol invite request; as well as Means for providing a modified session initiation protocol invite request to a destination network for initiating communications between at least two user equipments.

2. The apparatus according to claim 1, further comprising: Means for retrieving from a storage device an identifier associated with the third-party user data.

3. The apparatus according to claim 2, further comprising: Means for determining whether the identifier retrieved from the storage device is a uniform resource identifier.

4. The device according to any one of claims 1 to 3, further comprising: means for obtaining said third-party user data associated with said identifier from a third-party network; A component for sending a request to a signature server to sign the third-party user data obtained from the third-party network; means for receiving a reply including said signed token associated with said third party user data; means for modifying the session initiation protocol invite request by inserting the third party user data and the signature token into one or more headers of the session initiation protocol invite request; as well as Means for providing a modified session initiation protocol invite request to a destination network for initiating communications between at least two user equipments.

5. A device comprising: means for receiving a session initiation protocol invite request from a network, the session initiation protocol invite request including a uniform resource identifier and a signature token in one or more headers of the session initiation protocol invite request; means for verifying, using a verification server, the uniform resource identifier using the signature token; as well as Means for relaying the session initiation protocol invite request including the uniform resource identifier to a destination user equipment for configuring communications with at least one other user equipment when the uniform resource identifier is verified, wherein the at least one other user equipment retrieves third party user data associated with the identifier from a third party network.

6. A method comprising: sending a request to a signing server to sign an identifier associated with the third-party user data, the identifier having been determined to be a uniform resource identifier; receiving a reply including a signed token associated with the uniform resource identifier; modifying the session initiation protocol invite request by inserting the uniform resource identifier and the signature token into one or more headers of the session initiation protocol invite request; as well as A modified session initiation protocol invite request is provided to a destination network for initiating communications between at least two user equipments.

7. The method according to claim 6, further comprising: An identifier associated with the third-party user data is retrieved from a storage device.

8. The method according to claim 7, further comprising: It is determined whether the identifier obtained from the storage device is a uniform resource identifier.

9. The method according to any one of claims 6 to 8, further comprising: obtaining the third-party user data associated with the identifier from a third-party network; Sending a request to a signature server for signing the third-party user data obtained from the third-party network; receiving a reply including the signed token associated with the third-party user data; modifying the session initiation protocol invite request by inserting the third-party user data and the signature token into one or more headers of the session initiation protocol invite request; as well as A modified session initiation protocol invite request is provided to a destination network for initiating communications between at least two user equipments.

10. A method comprising: receiving a session initiation protocol invite request from a network, the session initiation protocol invite request including a uniform resource identifier and a signature token in one or more headers of the session initiation protocol invite request; using a verification server to verify the uniform resource identifier using the signed token; as well as When the uniform resource identifier is verified, the session initiation protocol invite request including the uniform resource identifier is relayed to a destination user equipment for configuring communications with at least one other user equipment, wherein the at least one other user equipment retrieves third party user data associated with the identifier from a third party network.

Images