DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
SYSTEM AND METHOD FOR MANAGING IDENTITY RETRIEVAL OF A DEVICE IN A NETWORK
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3.PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to the field of wireless communication networks, more particularly relates to a method and a system for managing identity retrieval of a device in the networks.
BACKGROUND OF THE INVENTION
[0002] Generally, nowadays, unauthorized usage of devices such as mobile phones have substantially increased. Due to which, there is a security threat in using these devices.
[0003] The mobile phone for example is allocated a unique identity by the manufacturer, known as the International Mobile Equipment Identity (IMEI). Whenever a new consumer registers with a service provider, all the information of the consumer is stored in the service provider network. The information of the consumer may be the one of but not limited to IMEI number of mobile devices, consumer subscription plan, consumers personal details, etc.
[0004] Further, for any third party to authenticate whether the mobile phone of the consumer originally belongs to the consumer in the service provider network, the consumer’s details are checked that may be stored at the network elements of the service provider network. So, direct communication is established between the third-party application and the network elements of the service provider in order to fetch the consumer’s details. Due to this direct communication, there is a substantial increase on the load on the network elements. Due to the increased load on the network elements, the process of fetching the consumer’s details may be time consuming.
[0005] In view of the above, in order to avoid the load on the network elements, there is a dire need for a system and method for managing identity retrieval of a communication device, which ensures that the load on the network elements may be substantially reduced.
SUMMARY OF THE INVENTION
[0006] One or more embodiments of the present disclosure provides a method and a system for managing identity retrieval of a device in a network.
[0007] In one aspect of the present invention, the method for managing identity retrieval of the device in the network is disclosed. The method includes the step of receiving, by one or more processors, a request in response to instructions from a third party to retrieve a device identifier from the network. The method further includes the step of authenticating, the third party at a unified Application Programming Interface (API) gateway. The method further includes the step of extracting, by the one or more processors, the device identifier from a unified data store subsequent to authenticating at least one of, the third party. The method further includes the step of transmitting, by the one or more processors, the extracted device identifier to one of, the third party.
[0008] In another embodiment, the device identifier corresponds to an identity of the device.
[0009] In yet another embodiment, the authentication is performed utilizing one of, tokens, and user identifier passwords.
[0010] In yet another embodiment, the step of, authenticating, by the one or more processors, the third party at the unified API gateway further comprises the step of, determining, by the one or more processors, an access control for the request based on the authentication of the third party. The access control is defined by one of, a consumer or a mobile service provider.
[0011] In yet another embodiment, the method further includes the step of, maintaining, by the one or more processors, a log at a storage unit of the request received. The method further includes the step of enriching, by the one or more processors, the request to add additional information as per requirement to extract the device identifier from the unified data store.
[0012] In yet another embodiment, the third party is at least one of, a third-party application or an application server.
[0013] In another aspect of the present invention, the system for managing identity retrieval of the device in the network is disclosed. The system includes an interface unit configured to receive a request in response to instructions from a third party to retrieve a device identifier from the network. The system includes an authentication unit configured to authenticate the third party at a unified Application Programming Interface (API) gateway. The system further includes an extraction unit configured to extract the device identifier from a unified data store subsequent to authenticating the third party. The system further includes a transmission unit configured to transmit the extracted device identifier to the third party.
[0014] In yet another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by a processor. The processor is configured to receive a request in response to instructions from a third party to retrieve a device identifier from the network. The processor is further configured to authenticate the third party at a unified Application Programming Interface (API) gateway. The processor is further configured to extract the device identifier from a unified data store subsequent to authenticating the third party. The processor is further configured to transmit the extracted device identifier to at least one of, the third party.
[0015] In another aspect of the present invention, a User Equipment (UE) is disclosed. One or more primary processors is communicatively coupled to one or more processors. The one or more primary processors is further coupled with a memory. The memory stores instructions which when executed by the one or more primary processors causes the UE to transmit, a request to the one or more processers in response to instructions from the third party to retrieve a device identifier.
[0016] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0018] FIG. 1 is an exemplary block diagram of an environment for managing identity retrieval of a device in a network, according to one or more embodiments of the present invention;
[0019] FIG. 2 is an exemplary block diagram of a system for managing identity retrieval of the device in the network, according to one or more embodiments of the present invention;
[0020] FIG. 3 is an exemplary architecture of the system of FIG. 2, according to one or more embodiments of the present invention;
[0021] FIG. 4 is an exemplary architecture to for managing identity retrieval of the device in the network, according to one or more embodiments of the present disclosure;
[0022] FIG. 5 is an exemplary signal flow diagram illustrating the flow for managing identity retrieval of the device in the network, according to one or more embodiments of the present disclosure; and
[0023] FIG. 6 is a flow diagram of a method to for managing identity retrieval of the device in the network, according to one or more embodiments of the present invention.
[0024] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0025] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0026] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0027] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0028] Various embodiments of the present invention provide a system and method for managing identity retrieval of a communication device in a network. The disclosed system and method aim at enhancing performance of one or more network elements by reducing the load on the one or more network elements. In other words, the present invention provides a unique approach of providing an information of a consumer to a third party for authorization purpose only after consent or permission from the consumer. The information of the consumer is fetched directly from a unified data store. Therefore, a direct communication between the third party and the one or more network elements is avoided, thereby ensuring that load on the one or more network elements is avoided.
[0029] Referring to FIG. 1, FIG. 1 illustrates an exemplary block diagram of an environment 100 for managing identity retrieval of a device 114 in a network 106, according to one or more embodiments of the present invention. The environment 100 includes a User Equipment (UE) 102, a server 104, the network 106, a system 108, the unified data store 110, one or more network elements 112, and the device 114.
[0030] In one embodiment, the device 114 is related to a consumer registered with a service provider. The service provider is an organization that provides one or more services to the consumers. The service provider is an organization that provides one or more services to the consumers. In one embodiment, the one or more services includes at least one of, but not limited to, a voice related service, a message service. In particular, the device 114 is at least one of, is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as smartphones or mobiles, Virtual Reality (VR) devices, Augmented Reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device.
[0031] In one embodiment, the device 114 such as the mobiles are allocated a unique identity by a manufacturer, known as the International Mobile Equipment Identity, or IMEI. The IMEI number is a unique 15–17-digit serial number which is used by the service providers to uniquely identify the valid consumer. In particular, each mobile is identified using the IMEI number.
[0032] For the purpose of description and explanation, the description will be explained with respect to one or more user equipment’s (UEs) 102 of a third party, or to be more specific will be explained with respect to a first UE 102a, a second UE 102b, and a third UE 102c, and should nowhere be construed as limiting the scope of the present disclosure. Each of the at least one UE 102 namely the first UE 102a, the second UE 102b, and the third UE 102c is configured to connect to the server 104 via the network 106.
[0033] In an embodiment, the third party is the one who requests for the identity of the device 114 related to the consumer registered with the service provider. The third party includes at least one of, but not limited to, a third-party application or an application server, a developer, and an enterprise.
[0034] In an embodiment, each of the first UE 102a, the second UE 102b, and the third UE 102c is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as smartphones, Virtual Reality (VR) devices, Augmented Reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device.
[0035] The network 106 includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The network 106 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0036] The network 106 may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth.
[0037] The environment 100 includes the server 104 accessible via the network 106. The server 104 may include by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, a processor executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise side, a defense facility side, or any other facility that provides service.
[0038] The environment 100 includes the unified data store 110 configured to stores details of the consumer registered with the service provider. The unified data store 110 is a concept in data management and IT architecture that refers to a centralized repository where different types of data from various sources are aggregated, stored, and managed. The goal of the unified data store 110 is to provide a single, coherent view of data, to aid in accessing, analyzing, and managing information across an organization. For example, the unified data store 110 is used across industries to centralize data from multiple sources into a single repository for improved access, analysis, and management.
[0039] In particular, the unified data store 110 stores at least one of, but not limited to, the identities of the device 114 for each consumer within the network 106. The unified data store 110 is one of, but not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of unified data store 110 types are non-limiting and may not be mutually exclusive e.g., the database can be both commercial and cloud-based, or both relational and open-source, etc.
[0040] The environment 100 includes the one or more network elements 112 which is communicably coupled to the server 104 via the network 106. In one embodiment, the one or more network elements 112 includes at least one of, but not limited to a Unified Data Management (UDM), a Policy Control Function (PCF), an Equipment Identity Register (EIR), a Unified Data Repository (UDR), an Access and Mobility Management Function (AMF), a Session Management Function (SMF) and a Home Subscriber Server (HSS). In particular, the UDM, the PCF, the EIR, the UDR, the AMF, the SMF and the HSS are the core network elements present in the network 106 of the service provider.
[0041] In one embodiment, the UDM is a centralized element which manages the consumers data. The UDM manages the consumers data for at least one of, but not limited to, an access authorization, and the consumers registration. The PCF is a key component that enables efficient policy control and management, facilitating network behavior control, UE 102 activities, and communication with other one or more network elements 112. The HSS is the main database of the current generation's cellular communications systems. The HSS contains the consumers subscription related information, such as the authentication information and a list of one or more services to which each consumer subscribes.
[0042] The UDR is a centralized database that stores 5G subscription information, which is used by other one or more network elements 112. The EIR is a network entity used in Global System for Mobile communication (GSM) networks that stores lists of device identifiers such as the IMEI numbers, which correspond to the device 114. The SMF is one of the key network elements 112 in the 5G Core Network (5GC), responsible for session management and a policy control. The AMF is one of the control plane network function of the network 106. The AMF handles critical control plane functions like a registration management, a connection management, a reachability management, a mobility management and an access authentication.
[0043] The environment 100 further includes the system 108 communicably coupled to the server 104, the UE 102, the unified data store 110, and the one or more network elements 112 via the network 106. The system 108 is adapted to be embedded within the server 104 or is embedded as the individual entity.
[0044] Operational and construction features of the system 108 will be explained in detail with respect to the following figures.
[0045] FIG. 2 is an exemplary block diagram of the system 108 for managing identity retrieval of the device 114 in the network 106, according to one or more embodiments of the present invention.
[0046] As per the illustrated and preferred embodiment, the system 108 for managing the identity retrieval of the device 114 in the network 106, includes one or more processors 202, a memory 204 and a storage unit 206. The one or more processors 202, hereinafter referred to as the processor 202, may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions. However, it is to be noted that the system 108 may include multiple processors as per the requirement and without deviating from the scope of the present disclosure. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204.
[0047] As per the illustrated embodiment, the processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204 as the memory 204 is communicably connected to the processor 202. The memory 204 is configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed for managing identity retrieval of the device 114 in the network 106. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0048] As per the illustrated embodiment, the storage unit 206 is configured to store details pertaining to at least one of, but not limited to, logs, a subscription plan, an access control policy and keys. The storage unit 206 is one of, but not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of storage unit 206 types are non-limiting and may not be mutually exclusive e.g., the database can be both commercial and cloud-based, or both relational and open-source, etc.
[0049] As per the illustrated embodiment, the system 108 includes the processor 202 for managing identity retrieval of the device 114 in the network 106. The processor 202 includes an interface unit 208, an authentication unit 210, an extraction unit 212, a transmission unit 214, a logging unit 216, an enrichment unit 218 and a notification unit 220. The processor 202 is communicably coupled to the one or more components of the system 108 such as the memory 204 and the storage unit 206. In an embodiment, operations and functionalities of the interface 208, the authentication unit 210, the extraction unit 212, the transmission unit 214, the logging unit 216, the enrichment unit 218, the notification unit 220 and the one or more components of the system 108 can be used in combination or interchangeably.
[0050] Initially, the UE 102 of the third party transmits a request to the system 108 to retrieve a device identifier from the network 106. In particular, the third party pertains to, at least one of, but not limited to, a third-party application or an application server. Hereinafter, the third-party application or the application server is referred as the third party without limiting the scope of the invention. In particular, based on the instructions from at least one of, but not limited to, the third party, the UE 102 of the third party transmits the request to the system 108.
[0051] Further, the interface unit 208 of the processor 202 is configured to receive the request from the UE 102 in order to retrieve the device identifier from the network 106. Herein, the device 114 is related to the consumer registered with the service provider. In particular, the device identifier corresponds to an identity of the device 114 such as at least one of, but not limited to, an International Mobile Equipment Identity (IMEI) of the device 114. In an alternate embodiment, the device identifier includes, at least one of, but not limited to, a consumer subscription plan, and a consumer’s personal details.
[0052] In one embodiment, a current Software Version (SV) of the device 114 is appended to the device identifier, so the device identifier is known as the IMEI SV. The IMEI SV identity is signaled to the network 106 when the device 114 connects in the network 106. The IMEI is a 15-digit integer, and the IMEI SV is a 16-digit integer. The first 8 digits are known as the Type Allocation Code (TAC) which facilitates identifying the manufacturer and model of the device 114. The following 6 digits are the serial number of the device 114 for that TAC. For IMEI, the remaining digit is a check digit. For IMEI SV, the remaining two digits are the software version.
[0053] In one embodiment, the request received from the UE 102 of the third party is at least one of, but not limited to, an Application Programming Interface (API) call. The API calls are the medium by which the user interacts within the network 106. In particular, the API call is a message sent to at least one of, the system 108 to retrieve the device identifier. The API call includes at least one of, but not limited to, a Representational State Transfer (REST) based API with a real time calling feature which allows the third party to connect with the system 108 in real time. The Representational State Transfer (REST) is a software architecture that imposes conditions on how an API should work. The REST was initially created as a guideline to manage communication on a complex network like the internet.
[0054] Upon receiving the request, the authentication unit 210 of the processor 202 is configured to authenticate at least one of, the third party at a unified Application Programming Interface (API) gateway. The unified API gateway is a network node used in telecommunications that connects two networks with different communication protocols together. For example, the unified API gateway is an API gateway which acts as a mediator between UE 102 and the system 108. The API gateway is a software layer that functions as a single endpoint for various APIs performing tasks such as request composition, routing, and protocol translations.
[0055] In one embodiment, the authentication is performed utilizing at least one of, but not limited to, a token, and a user identifier password. In alternate embodiment, the authentication unit 210 authenticates at least one of, the third party at the unified API gateway by utilizing an Authentication key (AUTH key), also known as an Application Programming Interface (API) key access token. The token is a unique identifier used to authenticate the third party to access an API. In one embodiment, the token is created by the service provider and is included in every API call/request to retrieve the device identifier to authorize access to protected resources.
[0056] In one embodiment, the authentication unit 210 determines whether the token included in the API call/request to retrieve the device identifier is valid or invalid. In particular, the authentication unit 210 validates the token included in the API call/request by at least one of, but not limited to, parsing the token, and verifying a token signature. Further, the authentication unit 210 extracts an API key from the validated token and validates the API key. The API key is a unique identifier that is used to authenticate and authorize the third-party application or the application server. The API key is validated by at least one of, but not limited to, checking for a match between the API key extracted from validated token with a similar API key which is prestored in the storage unit 206. In particular, the authentication unit 210 validates the token and the API key in order to authenticate the third party who had requested for the device identifier.
[0057] For example, the token is included within the API call or the request. The third party sends the request to the system 108 with the token included in the request, often in the Authorization header. In order to validate the token, the system 108 extracts the token from the API call or the request. Subsequent to extracting the token, the system 108 verifies the token's signature using the appropriate secret key or public key to ensure that the token has not been tampered. Thereafter, the system 108 decodes the token to extract claims or information about the third party. The claims include user identity, roles, permissions, and other relevant data.
[0058] In one embodiment, the claims validation is a crucial step in the token validation that involves verifying various pieces of information encoded within the token to ensure it is legitimate and authorized for use. While validating claims, the system 108 checks registered claims such as, but not limited to, issuer, subject, audience, expiration, and other claims specific to the third party. After properly validating these claims, the system 108 infers that the token is accepted, therefore the.third party is authenticated.
[0059] In one embodiment, if the verification of the token's signature is failed, then the token inferred as invalid, and the authentication is failed. In another embodiment, if the timestamp of the tokens is expired, then the token is inferred as invalid, and the authentication fails. In both the cases, the system 108 transmits an appropriate error response to the third party. For example, the error response indicates that the request has not been served because the request lacks valid authentication credentials.
[0060] In one embodiment, the authentication using the user identifier passwords involves verifying the credentials provided by the user against stored records in the storage unit 206 to ensure that they are legitimate and match the expected credentials. The process of the user identifier passwords is commonly used in web applications, APIs, and other systems requiring secure access.
[0061] In an alternate embodiment, in response to checking, if the authentication unit 210 determines that the API key extracted from the validated token is not matching with the similar API key which is prestored in the storage unit 206, then the notification unit 220 of the processor 202 is configured to notify the third party regarding the invalidity of the at least one of, the token and the API key.
[0062] Upon authenticating the third party at the unified API gateway, the authentication unit 210 is further configured to determine an access control and the subscription plan for the request based on the authentication of at least one of, the third party. In one embodiment, the access control is defined by at least one of, the consumer or the service provider via the interface unit 208. Herein, the service provider refers to is an entity that offers services, resources, or functionalities to other entities and the consumer refers to an entity that consumes the services or resources provided by the service provider. In other words, using APIs the consumer or the service provider manages the access control settings. In one embodiment, the access control policies are essential elements of security, which ensures that third party can only access the one or more services using secure and pre-approved methods only after consent or permission from the consumer. In other words, the access control policies security are a set of rules or permissions that specify the specific consumer which is allowed to access the one or more services by at least one of, but not limited to, authenticating consumers credentials.
[0063] In an alternate embodiment, the access control is defined by the system 108 automatically using historical data related to the request received for retrieving the device identifier. The system 108 identifies the patterns related to request received for retrieving the device identifier and learn from the past attempts retrieving the device identifier. Based on the identified pattern, the system 108 defines the access control policies.
[0064] In one embodiment, the subscription plan stores information about one or more services subscribed by the at least one of, the consumer and the third party. In one embodiment, the one or more services includes at least one of, but not limited to, a calling service, a text message service, a video calling service, and a call recording service. In particular, the subscription plan includes an amount of money that is paid by the at least one of, the consumer and the third party to receive the subscribed one or more services.
[0065] In one embodiment, in order to determine the access control and the subscription plan for the API call/request based on the authentication of the third party, the authentication unit 210 is configured to extract data related to the subscription plan and the access control policy. In particular, the data is associated with the at least one of, the consumer and the third party, which is extracted from the storage unit 206 based on the validated key. Further, the authentication unit 210 checks whether the extracted data related to the subscription plan and the access control policy associated with the at least one of, the consumer and the third party matches with the data related to the subscription plan and the access control policy of the at least one of, the consumer and the third party extracted from the received API call/request. In particular, the subscription plan of the consumer is checked by the authentication unit 210 to determine a valid subscription plan in order to provide the third party with the device identifier.
[0066] In one embodiment, in response to checking if the authentication unit 210 determines that the data extracted from the storage unit 206 is not matching with the data extracted from the received request related to the subscription plan and the access control policy then the notification unit 220 of the processor 202 is configured to notify the third party regarding the invalidity of the subscription plan and the access control.
[0067] In one embodiment, in response to checking if the authentication unit 210 determines that the data extracted from the storage unit 206 is matching with the data extracted from the received request related to the subscription plan and the access control policy, then the authentication unit 210 infers that the third party requesting for the device identifier is valid.
[0068] Upon authenticating the at least one of, the third party at the unified API gateway by the authentication unit 210, the logging unit 216 of the processor 202 is configured to configured to maintain logs of the API call/request received at the storage unit 206. In particular, the log contains information pertaining to the API call/request such as, at least one of, but not limited to, a timestamp of the request, a Hyper Text Transfer Protocol (HTTP) status code, a request ID, a request URL, a response time, and a source IP of the third party. The timestamp of the request refers to a specific point in time when a request was made to the system 108 via the API. The HTTP status codes are essential for communication between clients and servers, providing insights into the outcome of requests. The request ID is a unique identifier assigned to each individual request made to the system 108. The request URL is the web address used to specify the location of a resource on the internet that the third party wants to access or interact with.
[0069] Upon maintaining the logs of the API call/request received, the enrichment unit 218 of the processor 202 is configured to enrich the API call/request to add additional information as per requirement to extract the device identifier from the unified data store 110. In some cases, the API call/request is not included with data which is required to extract the device identifier based on which the enrichment unit 218 modifies or add the required data in the API call/request. For example, the enrichment unit 218 adds historical data pertaining to the consumer due to which the overall experience of the third party is enhanced. In particular, enriching the request involves adding additional information to the request to ensure that the system 108 can process the request more effectively. For example, this additional information helps in tailoring the request to meet specific needs, enhance data retrieval, or ensure proper processing. The additional information may include, at least one of, but not limited to, user credentials, device details, and contextual information.
[0070] Upon enriching the API call/request, the extraction unit 212 of the processor 202 is configured to extract the device identifier from the unified data store 110 for the authenticated at least one of, the third party. In order to extract the device identifier from the unified data store 110, the extraction unit 212 is configured to generate a session identifier in order to establish a session between the UE 102 of the authenticated third party and the unified data store 110. In particular, the session identifier is a unique identification number that is generated by the extraction unit 212. This unique identification number includes at least one of, but not limited to, a number code, a numerical code, or an alphanumeric code. The session identifier is also known as a session token which is assigned to the third party for the duration of the session established between the authenticated third party and the unified data store 110.
[0071] Upon generating the session between the UE 102 of the authenticated third party and the unified data store 110, the extraction unit 212 extracts the device identifier of the consumer from the unified data store 110 and the transmission unit 214 of the processor 202 is configured to transmit the extracted device identifier to at least one of, the third party. Advantageously, the device identifier of the consumer is directly extracted from the unified data store 110. Therefore, direct communication between the one or more network elements 112 and the third party is avoided. This leads to a reduction in the load on the one or more network elements 112 which ensures that the performance of the one or more network elements 112 are not compromised when the API call/ request for the retrieval of the device identifier arrives at the network 106.
[0072] The interface unit 208, the authentication unit 210, the extraction unit 212, the transmission unit 214, the logging unit 216, the enrichment unit 218, and the notification unit 220 in an exemplary embodiment, are implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 202. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 202 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 204 may store instructions that, when executed by the processing resource, implement the processor 202. In such examples, the system 108 may comprise the memory 204 storing the instructions and the processing resource to execute the instructions, or the memory 204 may be separate but accessible to the system 108 and the processing resource. In other examples, the processor 202 may be implemented by electronic circuitry.
[0073] FIG. 3 illustrates an exemplary architecture for the system 108, according to one or more embodiments of the present invention. More specifically, FIG. 3 illustrates the system 108 for managing identity retrieval of the device 114 in the network 106. It is to be noted that the embodiment with respect to FIG. 3 will be explained with respect to the UE 102 for the purpose of description and illustration and should nowhere be construed as limited to the scope of the present disclosure.
[0074] FIG. 3 shows communication between the UE 102, the system 108, and the unified data store 110. For the purpose of description of the exemplary embodiment as illustrated in FIG. 3, the UE 102, uses network protocol connection to communicate with the system 108 and the unified data store 110. In an embodiment, the network protocol connection is the establishment and management of communication between the UE 102, the system 108, and the unified data store 110 over the network 106 (as shown in FIG. 1) using a specific protocol or set of protocols. The network protocol connection includes, but not limited to, Session Initiation Protocol (SIP), System Information Block (SIB) protocol, Transmission Control Protocol (TCP), User Datagram Protocol (UDP), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), Simple Network Management Protocol (SNMP), Internet Control Message Protocol (ICMP), Hypertext Transfer Protocol Secure (HTTPS) and Terminal Network (TELNET).
[0075] In an embodiment, the UE 102 includes a primary processor 302, and a memory 304 and a User Interface (UI) 306. In alternate embodiments, the UE 102 may include more than one primary processor 302 as per the requirement of the network 106. The primary processor 302, may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions.
[0076] In an embodiment, the primary processor 302 is configured to fetch and execute computer-readable instructions stored in the memory 304. The memory 304 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed for managing identity retrieval of the device 114 in the network 106. The memory 304 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0077] In an embodiment, the User Interface (UI) 306 includes a variety of interfaces, for example, a graphical user interface, a web user interface, a Command Line Interface (CLI), and the like. The User Interface (UI) 306 of the UE 102 transmits the request to the system 108 in response to instructions from the third party to retrieve the device identifier from the unified data store 110. In one embodiment, the user may be at least one of, but not limited to, a consumer, a network operator, and the service professional, etc.
[0078] For example, once the API call/request reaches the unified data store 110, the system 108 extracts the device identifier such as the IMEI of the consumers device 114 from the unified data store 110. Further, the extracted IMEI is provided to the third party. Advantageously, due to extracting the IMEI from the unified data store 110, the communication of the UE 102 with the one or more network elements 112 is avoided due to which the load on the one or more network elements 112 is reduced and a performance of the one or more network elements 112 is not degraded.
[0079] As mentioned earlier in FIG.2, the system 108 includes the processors 202, and the memory 204, for managing the call between the user and the third party 110, which are already explained in FIG. 2. For the sake of brevity, a similar description related to the working and operation of the system 108 as illustrated in FIG. 2 has been omitted to avoid repetition.
[0080] Further, as mentioned earlier the processor 202 includes the interface unit 208, the authentication unit 210, the extraction unit 212, the transmission unit 214, the logging unit 216, the enrichment unit 218 and the notification unit 220 which are already explained in FIG. 2. Hence, for the sake of brevity, a similar description related to the working and operation of the system 108 as illustrated in FIG. 2 has been omitted to avoid repetition. The limited description provided for the system 108 in FIG. 3, should be read with the description provided for the system 108 in the FIG. 2 above, and should not be construed as limiting the scope of the present disclosure.
[0081] FIG. 4 is an exemplary the system 108 architecture 400 for managing identity retrieval of the device 114 in the network 106, according to one or more embodiments of the present disclosure.
[0082] The architecture 400 includes an Application Programming Interface (API) consumer 402, an UI API dashboard 404, a unified API gateway 406, a Sim Swap API Exposure Function (SSA EF) 408, an API publisher 410, a one cache 416, a Sim Swap API Data Collector (SSA DC) 418, the UDM/HSS 420, a data exporter 422, a data ingestion 424 and a streaming platform 426 communicably coupled to each other via the network 106.
[0083] The architecture 400 of the present invention comprises of the API consumer 402. The API consumer 402 may be at least one of, an application, a developer or an enterprise that intend to use Application Programming Interfaces (APIs) for their respective use cases such as the identity retrieval of the device 114. In an embodiment, the UI API Dashboard 404 is a User Interface (UI) from where the third party/ the API consumer 402 transmits the API calls/ request for identity retrieval of the device 114. The UI API Dashboard 404 is a graphical user interface designed to interact with APIs, providing a visual representation of data and functionality accessed via those APIs. These UI API Dashboard 404 are used by developers, system administrators, or business users to oversee and interact with APIs in a more intuitive and user-friendly manner.
[0084] In an embodiment, the unified API gateway 406 may be a part of the system 108. The unified API gateway 406 is a data-plane entry point for the API calls/requests that represent API consumer 402 requests for identity retrieval of the device 114. The unified API gateway 406 streamlines the process of managing, securing, and integrating APIs by offering a consolidated interface for API access and management. The unified API gateway 406 typically performs the API calls/requests processing based on defined policies, including authentication, authorization, access control, routing, and load balancing.
[0085] In one embodiment, the common API gateway 406 is at least one of, a CAPIF. The CAPIF is API framework that covers functionality related to the identity retrieval of the device 114. The CAPIF is a unified API gateway 406 for API consumer 402. The CAPIF also deals with security and authorization of the APIs.
[0086] In one embodiment, similar to the API consumer 402, the API publisher 410 comprises an API developer, an API playground, and an enterprise architecture. The API publisher 410 is an individual, team, or organization responsible for creating, managing, and distributing APIs. The role of the API publisher 410 encompasses several key responsibilities, including designing APIs, documenting APIs, ensuring APIs functionality, and making APIs available to consumers. Further, the API publisher 410 comprises a subscription engine 412 which manages the consumers subscriptions, billing and quota enforcement and a marketplace engine 414 which serves as a platform for listing APIs, allowing consumers to discover, evaluate, and subscribe to APIs. In particular, the marketplace engine 414 are platforms for services or APIs are platforms that facilitate the buying, selling, and management of services and APIs.
[0087] In one embodiment, the SSA EF 408 is a microservice. The microservices are an architectural and organizational approach to software development where software is composed of small independent services that communicate over well-defined APIs. The SSA EF 408 refers to the functionality or method within a system that interacts with APIs to detect, manage, and respond to SIM swap activities. The SSA EF 408 assesses whether the data or notifications retrieved from the API indicate a possible SIM swap event. In one embodiment, the SSA DC 418 is a data collector microservice. The SSA DC 418 refers to a system or service designed to monitor and collect data related to SIM card swaps through APIs. In an embodiment, the one cache 416 is the unified data store 110 which stores the device identifiers of the consumers. In particular, the one cache 416 is a caching solution designed to enhance the performance and efficiency of web applications, APIs, and databases by reducing latency and minimizing the load on backend systems.
[0088] In one embodiment, the UDM/HSS 420 are the one or more network elements 112 that proactively provides information pertaining to the consumers to SSA EF 408 via the SSA DC 418. In one embodiment, the data exporter 422 exports the data from the UDM/HSS 420 to the unified data store 110. The data exporter 422is a tool or functionality that facilitates the extraction, transformation, and export of data from one system to another or from a database to a file. The data exporter 422is commonly used for data migration, backup, reporting, and integration purposes.
[0089] In one embodiment, the data ingestion 424 performs a data ingestion process of acquiring, importing, and processing data from various sources into the system 108 where the data can be stored, analysed, and used for further processing. The streaming platform 426 is a technology that allows for the real-time processing and analysis of continuous data streams. The streaming platform 426 are designed to handle large volumes of data that are generated continuously, enabling applications to process, analyze, and act on the large volumes of data in real time. The streaming platform 426 are essential for scenarios where immediate insights and actions are required, such as monitoring, analytics, and real-time decision-making.
[0090] In an embodiment, the API consumer 402 requests for retrieving the device identifier. The API consumer 402 is authenticated at the unified API gateway 406 based on the received request. The unified API gateway 406 validates the key and the token from the request. In particular, the key is extracted from the token and the key validation is performed. Based on the key, the consumers subscription plan and the access control policy are checked. Thereafter, the requests reach to the unified data store 110 via the SSA EF 408. Once call reaches the unified data store 110, the SSA EF 408 extracts the device identifier from the unified data store 110 and provides the extracted device identifier to the API consumer 402.
[0091] FIG. 5 is a signal flow diagram illustrating the flow for managing identity retrieval of the device 114 in the network 106, according to one or more embodiments of the present disclosure.
[0092] At step 502, the third party initiates a device identifier request using the UE 102 subsequent to the authentication of the third party. Further, the device identifier request is transmitted to a gateway such as the unified API gateway.
[0093] At step 504, from the unified API gateway, the device identifier request is forwarded to the SSA EF 408 to check for the device identifier of the consumer in the unified data store 110 based on the received device identifier request.
[0094] At step 506, the SSA EF 408 transmits a request to the unified data store 110 in order to extract the device identifier from the unified data store 110 subsequent to checking for the device identifier of the consumer in the unified data store 110.
[0095] At step 508, the unified data store 110 responds to the request transmitted by the SSA EF 408 by providing the device identifier to the SSA EF 408. In particular, the SSA EF 408 extracts the required device identifier details or consumers information from the unified data store 110.
[0096] At step 510, subsequent to the extracting of the device identifier from the unified data store 110, the SSA EF 408 transmits the extracted device identifier as a response to the unified API gateway.
[0097] At step 512, the unified API gateway transmits the extracted device identifier received from the SSA EF 408 to the UE 102 of the third party.
[0098] FIG. 6 is a flow diagram of a method 600 for managing identity retrieval of the device 114 in the network 106, according to one or more embodiments of the present invention. For the purpose of description, the method 600 is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0099] At step 602, the method 600 includes the step of receiving, the request in response to instructions from the third party to retrieve the device identifier from the network 106. In one embodiment, the interface unit 208 receives the request from the third party via the UE 102 for retrieving the device identifier related to the consumer. In an alternate embodiment, the API call is received at the interface unit 208 for retrieving the device identifier related to the consumer. For example, let us consider that the consumer wishes to purchase an insurance from the third party for his/her device 114 such as mobile. Further, let us consider that the third party is an insurance company which requests (API call) the system 108 in order to ensure that particular mobile is registered to the same consumer.
[00100] In one embodiment, when the device 114 is initially connected within the network 106, the device identifier pertaining to the device 114 is stored in the unified data store 110. More particularly, as per standard TS 123 502 V15.2.0, device 114 needs to register with the network 106 to get authorized to receive services, to enable mobility tracking and to enable reachability. During an initial registration a Permanent Equipment Identifier (PEI) is obtained from the UE i.e. device 114. The AMF operator may check the PEI with the Equipment Identity Register (EIR). The AMF passes the PEI (IMEISV) to the UDM, to the Session Management Function (SMF) and the PCF, then UDM may store this data in UDR by Nudr_SDM_Update.
[00101] At step 604, the method 600 includes the step of authenticating the third party at the unified API gateway. In one embodiment, the authentication unit 210 authenticates the third party based on the request received from the third party. For example, let us consider the third party such as the insurance company had subscribed for the service pertaining to retrieving the device identifier related to the consumer. Based on the token included in the received request the key is extracted. By validating the token and the key, the third party is authenticated. Further, the third party’s subscription plan and the access policy are validated such as whether the third party requesting for retrieving the device identifier had subscribed for the service pertaining to retrieving the device identifier, the access control policy pertains to a limited number of times the service is allowed to the third party in a month based on the subscription plan.
[00102] At step 606, the method 600 includes the step of extracting the device identifier from the unified data store 110 subsequent to authenticating the third party. In one embodiment, the extraction unit 212 is configured to extract the device identifier from the unified data store 110. For example, subsequent to the authentication of the third party such as the insurance company, the session between the insurance company and the unified data store 110 is generated. Utilizing the generated session the insurance company connects with the unified data store 110. Once the requests (API call) reach the unified data store 110, the device identifier such as the IMEI of the consumer who wishes to purchase the insurance from the third party for his/her device 114 such as mobile is extracted from the unified data store 110 to ensure that the mobile is registered to the same consumer. Herin, there is no requirement for connecting with the one or more network elements 112 for retrieving the device identifier. Therefore, the load on the one or more network elements 112 is reduced.
[00103] At step 608, the method 600 includes the step of transmitting the extracted device identifier to the third party. In one embodiment, the transmission unit 214 is configured to transmit the extracted device identifier to at least one of, the third party. For example, the extracted IMEI from unified data store 110 pertaining to the device 114 of the consumers is provided to the insurance company.
[00104] In yet another aspect of the present invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions that, when executed by the processor 202. The processor 202 is configured to receive a request in response to instructions from the third party to retrieve a device identifier from the network 106. The processor 202 is further configured to authenticate the third party at a unified Application Programming Interface (API) gateway. The processor 202 is further configured to extract the device identifier from a unified data store 110 subsequent to authenticating the third. The processor 202 is further configured to transmit the extracted device identifier to the third party.
[00105] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-6) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[00106] The present disclosure provides technical advancements of the present invention such as offloading the load from the actual one or more network elements by introducing the unified data store that stores the consumers current communication device details such as mobile phone accessible using one cache APIs. The consumers device identifiers details are access based on demand. The logs for each API calls are stored. Access Control and policy applied on every API call.
[00107] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS

[00108] Environment - 100;
[00109] User Equipment (UE) - 102;
[00110] Server - 104;
[00111] Network- 106;
[00112] System -108;
[00113] Unified data store – 110;
[00114] One or more network elements - 112;
[00115] Device – 114;
[00116] Processor - 202;
[00117] Memory - 204;
[00118] Storage unit – 206;
[00119] Interface unit– 208;
[00120] Authentication unit – 210;
[00121] Extraction unit – 212;
[00122] Transmission unit – 214;
[00123] Logging unit – 216;
[00124] Enrichment unit – 218;
[00125] Notifying unit - 220;
[00126] Primary Processor – 302;
[00127] Memory – 304;
[00128] User Interface (UI) – 306;
[00129] API consumer – 402;
[00130] UI API Dashboard – 404;
[00131] Unified API Gateway – 406;
[00132] SSA EF - 408;
[00133] API Publisher – 410;
[00134] Subscription Engine - 412;
[00135] Market Place – 414;
[00136] One cache - 416;
[00137] SSA DC MS – 418;
[00138] UDM/HSS – 420;
[00139] Data explorer – 422;
[00140] Data ingestion – 424;
[00141] Streaming platform – 426.

,CLAIMS:
CLAIMS
We Claim:
1. A method (600) of managing identity retrieval of a device (114) in a network (106), the method (600) comprising the steps of:
receiving, by one or more processors (202), a request in response to instructions from a third party to retrieve a device identifier from the network (106);
authenticating, by the one or more processors (202), the third party at a unified Application Programming Interface (API) gateway;
extracting, by the one or more processors (202), the device identifier from a unified data store (110) subsequent to authenticating the third party; and
transmitting, by the one or more processors (202), the extracted device identifier to one of, the third party.

2. The method (600) as claimed in claim 1, wherein the device identifier corresponds to an identity of the device (114).

3. The method (600) as claimed in claim 1, wherein the authentication is performed utilizing one of, tokens, and user identifier passwords.

4. The method (600) as claimed in claim 1, wherein the step of authenticating, by the one or more processors (202 the third party at the unified API gateway further comprises the step of:
determining, by the one or more processors (202), an access control for the request based on the authentication of the third party, wherein the access control is defined by one of, a consumer or a mobile service provider.

5. The method (600) as claimed in claim 1, wherein the method (600) further comprises the steps of:
maintaining, by the one or more processors (202), a log at a storage unit (206) of the request received; and
enriching, by the one or more processors (202), the request to add additional information as per requirement to extract the device identifier from the unified data store (110).

6. The method (600) as claimed in claim 1, wherein the third party is at least one of, a third-party application or an application server.

7. A system (108) for managing identity retrieval of a device (114) in a network (104), the system comprising:
an interface unit (208) configured to receive a request in response to instructions from, a third party to retrieve a device identifier from the network (106);
an authentication unit (210) configured to authenticate at a unified Application Programming Interface (API) gateway;
an extraction unit (212) configured to extract the device identifier from a unified data store (110) subsequent to authenticating the third party; and
a transmission unit (214) configured to transmit the extracted device identifier to at least one of, the third party.

8. The system (108) as claimed in claim 7, wherein the device identifier corresponds to an identity of the device (114).

9. The system as (108) claimed in claim 7, wherein the authentication unit (210) is further configured to determine an access control of the request based on the authentication of the third party, wherein the access control is defined by one of a consumer and a mobile service provider.

10. The system (108) as claimed in claim 7, wherein the authentication is performed utilizing one of, tokens, and user identifier passwords.

11. The system (108) as claimed in claim 7, further comprising:
a logging unit (216) configured to maintain a log of the request received at a storage unit (206); and
an enrichment unit (218) configured to enrich the request to add additional information as per requirement to extract the device identifier from the unified data store.

12. The system (108) as claimed in claim 7, wherein the third party is at least one of, a third-party application or an application server.

13. A User Equipment (UE) (102), comprising:
one or more primary processors (302) communicatively coupled to one or more processors (202), the one or more primary processors (302) coupled with a memory (304), wherein said memory (304) stores instructions which when executed by the one or more primary processors (302) causes the UE (102) to:
transmit, a request to the one or more processers (202) in response to instructions from the third party to retrieve a device identifier,
wherein the one or more processors (102) is configured to perform the steps as claimed in claim 1.