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 VERIFYING A NUMBER OF A CONSUMER
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 systems, more particularly relates to verifying a number of a consumer associated with a User Equipment (UE) of the consumer in wireless communication systems.
BACKGROUND OF THE INVENTION
[0002] Generally, in mobile networks, a mobile number of a user is used for conducting various financial and commercial transactions. The mobile number of a subscriber is known to the mobile network in the form of a Mobile Station International Subscriber Directory Number (MSISDN), which can be checked OnDemand by asking information from a service provider. Every network provider or a service provider stores mobile number related information of every mobile subscriber. In existing systems, a mobile number is verified at the backend by generating a one-time password (OTP). Generation of such OTP loads the network elements by introducing cache service.
[0003] There is a need for a method and system where OTP is not generated, and the mobile number is verified at the backend without generation of OTP. Hence an API based mobile verification method and system is disclosed.
SUMMARY OF THE INVENTION
[0004] One or more embodiments of the present disclosure provides a method and a system for verifying a number of a consumer associated with a User Equipment (UE) of the consumer.
[0005] In one aspect of the present invention, the method of verifying the number of the consumer associated with the User Equipment (UE) of the consumer is disclosed. The method includes the step of receiving, by one or more processors, an Application Programming Interface (API) call from a UE of a user. The method further includes the step of validating, by the one or more processors, a token upon receipt of the API call, the token is included in the API call. The method further includes the step of retrieving, by the one or more processors, information associated with the consumer from a data repository on validation of the token. The method further includes the step of transmitting, by the one or more processors, a response indicating successful verification of the number of the consumer to the UE of the user the retrieved information matches with the number of the consumer.
[0006] In another embodiment, the method comprises the step of maintaining the data repository to include information pertaining to the consumer.
[0007] In yet another embodiment, the API call pertains to verification of the number of the consumer associated with the UE of the consumer.
[0008] In yet another embodiment, the information comprises a pairing of the number of the consumer and an identifier associated with the UE of the consumer.
[0009] In yet another embodiment, the one or more processors validate the token by at least one of, a parsing the token, and verifying a token signature.
[0010] In yet another embodiment, verifying the number of the consumer associated with the UE of the consumer is done by at least one of, a user interaction and without a user interaction.
[0011] In another embodiment, the information associated with the consumer is retrieved from the data repository based on at least one of, a POST request transmitted by the one or more processors to the data repository. The POST request includes at least one of, the number of the consumer to be verified and the token.
[0012] In another embodiment, the information associated with the consumer is retrieved from the data repository based on at least one of, a GET request transmitted by the one or more processors to the data repository. The GET request includes the token.
[0013] In another aspect of the present invention, the system of verifying a number of a consumer associated with a User Equipment (UE) of the consumer is disclosed. The system includes a receiving unit configured to receive, an Application Programming Interface (API) call from a UE of a user. The system includes a validating unit configured to validate, a token generated upon receipt of the API call, the token is included in the API call. The system further includes a retrieving unit configured to retrieve information associated with the consumer from a data repository on validation of the token. The system further includes a transmitting unit configured to transmit a response indicating successful verification of the number of the consumer to the UE of the user the retrieved information matches with the number of the consumer.
[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 an Application Programming Interface (API) call from a UE of a user. The processor is further configured to validate, a token generated upon receipt of the API call, the token is included in the API call. The processor is further configured to retrieve information associated with the consumer from a data repository on validation of the token. The processor is further configured to transmit a response indicating successful verification of the number of the consumer to the UE of the user the retrieved information matches with the number of the consumer.
[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 of the user to transmit an Application Programming Interface (API) call from the UE of the user to one or more processors.
[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 verifying a number of a consumer associated with a User Equipment (UE) of the consumer, according to one or more embodiments of the present invention;
[0019] FIG. 2 is an exemplary block diagram of a system for verifying the number of the consumer associated with the UE of the consumer, 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 for verifying the number of the consumer associated with the UE of the consumer, according to one or more embodiments of the present disclosure;
[0022] FIG. 5a is an exemplary signal flow diagram illustrating the flow for verifying the number of the consumer associated with the UE of the consumer, according to one or more embodiments of the present disclosure;
[0023] FIG. 5b is an exemplary signal flow diagram illustrating the flow for verifying the number of the consumer associated with the UE 110, according to one or more embodiments of the present disclosure; and
[0024] FIG. 6 is a flow diagram of a method for verifying the number of the consumer associated with the UE of the consumer, according to one or more embodiments of the present invention.
[0025] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0026] 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.
[0027] 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.
[0028] 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.
[0029] Various embodiments of the present invention provide an optimized solution for verifying a number of a consumer associated with a UE of the consumer by using an Application Programming Interface (API). Generally, the number is a mobile/phone number that is used in a mobile device of the consumer. The API provides a service provider with an ability to verify/validate an authorized mobile number. In an embodiment, the API is used to verify the mobile number while performing financial transactions. As a result, business transactions can be protected from fraud. To verify the mobile number of the consumer, the system is designed in such a way that actual network element performance is not compromised during the mobile number verification/validation.
[0030] Referring to FIG. 1, FIG. 1 illustrates an exemplary block diagram of an environment 100 to verify a number of a consumer associated with a User Equipment (UE) 110 of the consumer, according to one or more embodiments of the present invention. The environment 100 includes a UE 102 of a user, a server 104, a network 106, a system 108 and the UE 110 of the consumer. In particular, the number of the consumer is a mobile/phone number of the consumer. In particular, the invention verifies the number of the consumer associated with UE 110 of the consumer to avoid fraud while performing at least one of, but not limited to, a financial transaction.
[0031] Herein, the UE 110 of the consumer is associated with the consumer which may be at least one of, but not limited to, a subscriber of a service provider. The UE 102 of the user is associated with the user who intends to verify the number of the consumer associated with UE 110 of the consumer. Hereinafter, the UE 110 of the consumer is referred to the UE 110 and the UE 102 of the user is referred to the UE 102 without limiting the scope of the invention.
[0032] For the purpose of description and explanation, the description will be explained with respect to one or more user equipment’s (UEs) 102, 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, 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.
[0034] In an embodiment, the UE 110 is configured to connect to the server 104 via the network 106. Herein the UE 110 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 further includes the system 108 communicably coupled to the server 104, the UE 102, and the UE 110 via the network 106. The system 108 is adapted to be embedded within the server 104 or embedded as the individual entity.
[0039] Operational and construction features of the system 108 will be explained in detail with respect to the following figures.
[0040] FIG. 2 is an exemplary block diagram of the system 108 for verifying the number of the consumer associated with the UE 110, according to one or more embodiments of the present invention.
[0041] As per the illustrated and preferred embodiment, the system 108 for verifying the number of the consumer associated with the UE 110, includes one or more processors 202, a memory 204 and a data repository 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.
[0042] 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 verifying the number of the consumer associated with the UE 110. 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.
[0043] As per the illustrated embodiment, the data repository 206 is configured to store information associated with the consumer. The data repository 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 data repository 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.
[0044] In particular, the data repository 206 stores information associated with the consumer such as at least one of, but not limited to, a Subscriber Identity Module (SIM) information, a Mobile Station International Subscriber Directory Number (MSISDN), an International Mobile Subscriber Identity (IMSI), a Subscription Permanent Identifier (SUPI), and an International Mobile Equipment Identity (IMEI) of the UE 110.
[0045] In one embodiment, the SIM card is an Integrated Circuit (IC) intended to securely store an IMSI number and its related key, which are used to identify and authenticate the consumers of UE 110 such as mobile phones.
[0046] In one embodiment, the MSISDN is a unique identifier assigned to the UE 110 such as a mobile device in a (Global System for Mobile Communications) GSM network. The MSISDN is a number of the consumer associated with the SIM card which is utilized to call or send a Short Messaging Service (SMS). More particularly, the MSISDN is the phone/mobile number of the consumer.
[0047] In one embodiment, the IMSI is a unique number automatically generated and stored in the SIM. The IMSI identifies every mobile phone consumer on a mobile communication network 106.
[0048] In one embodiment, the IMEI number is a unique 15–17-digit serial number which is used by service providers to uniquely identify the UE 110. Each UE 110 such as a mobile phone is identified by the IMEI number.
[0049] In one embodiment, the SUPI is usually a string of 15 decimal digits. The first three digits represent the Mobile Country Code (MCC), the next two or three represent the Mobile Network Code (MNC) identifying the network operator. In 2G, 3G, and 4G networks an identifier is referred to as IMSI. In 5G networks, the identifier is called the SUPI.
[0050] As per the illustrated embodiment, the system 108 includes the processor 202 for verifying the number of the consumer associated with the UE 110. The processor 202 includes a receiving unit 208, a validating unit 210, a retrieving unit 212, a transmitting unit 214, and a maintaining unit 216. The processor 202 is communicably coupled to the one or more components of the system 108 such as the memory 204 and the data repository 206. In an embodiment, operations and functionalities of the receiving unit 208, the validating unit 210, the retrieving unit 212, the transmitting unit 214, the maintaining unit 216 and the one or more components of the system 108 can be used in combination or interchangeably.
[0051] In one embodiment, when the consumer inserts the SIM for a first time in the UE 110, the information pertaining to the consumer is stored in the one or more network elements within the network 106. In one embodiment, triplet information is stored in the one or more network elements which includes one or more identifiers pertaining to the consumer. For example, the one or more identifiers includes, at least one of, but not limited to, MSISDN, the IMEI, the IMSI, and any other identifiers. Herein, the MSISDN, the IMEI, the IMSI and the any other identifiers may be used individually or in combination to identify the consumer uniquely. Further, when at least one specific information among the triplet including the one or more identifiers (the MSISDN, the IMEI and the IMSI) is changed, then the change in the triplet is stored by one or more network elements. Thereafter, the one or more network elements interact with the data repository 206 to store information pertaining to the consumer. In particular, the information stored within the one or more network elements is stored in the data repository 206. The one or more network elements is one of, but not limited to, a Home Subscriber Server (HSS) and a Unified Data Management (UDM).
[0052] The Home Subscriber Server (HSS) serves as the primary database repository of subscriber information within a Long-Term Evolution (LTE)/ Evolved Packet Core (EPC) or IP Multimedia Subsystem (IMS) network core. The Unified Data Management (UDM) manages subscriber information data in a single centralized element. UDM technology is similar to the 4G network's Home Subscriber Server (HSS) but is cloud-native and designed for 5G specifically.
[0053] In one embodiment, initially the user transmits at least one of, but not limited to, an Application Programming Interface (API) call from the UE 102 for verifying the number of the consumer associated with the UE 110. Thereafter, the receiving unit 208 of the processor 202 is configured to receive at least one of, but not limited to, the API call from the user via the UE 102. In one embodiment, the user is at least one of, a network operator. In an alternate embodiment, a request is received from the user for verifying the number of the consumer associated with the UE 110. The API calls are the medium by which the user interacts with the at least one of, the system 108 or the server 104 within the network 106. In particular, the API call is a message sent to at least one of, the system 108 or the server 104 for verifying the number of the consumer associated with the UE 110.
[0054] In one embodiment, 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. 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.
[0055] In one embodiment, the system 108 verifies the number of the consumer associated with the UE 110 by at least one of, but not limited to, a user interaction and without a user interaction. In particular, the system 108 verifies the number of the consumer associated with the UE 110 without receiving any inputs from the user such as the UE 102. For example, the APIs verifies the number of the consumer associated with the UE 110 without communicating with the one or more network elements. In an exemplary embodiment, the number of the consumer is in one of a plain text or hashed format.
[0056] In one embodiment, the API generates tokens typically as part of an authentication and authorization process of the consumer. The token is a string of codes containing comprehensive data that identifies a specific consumer. In other words, the token is a piece of data that often includes encoded information about the consumer. The tokens are used to securely verify the identity of the consumer and to grant access to certain resources or actions. For example, a client such as the UE 102 sends the request to the API which usually includes credentials like a username and a password. The server 104 validates the provided credentials. If the credentials are valid, the server 104 of the API generates the token. Thereafter, the server 104 sends the token back to the UE 102 as a response to the request.
[0057] In an alternate embodiment, the system 108 checks for an access control policies related to the API call. The access control policies security are a set of rules or permissions that specify the specific user which is allowed to access one or more services such as verification of the number of the consumer. For example, based on the access control policies, the system 108 checks whether the user has subscribed for the service to verify the number of the consumer.
[0058] In one embodiment, when the UE 102 transmits the API call or request for verifying the number of the consumer associated with the UE 110, the API call or the request is received at the receiving unit 208 of the processor 202 within the system 108 so that the performance of the one or more network elements will not be compromised. Subsequent to receiving the request, logs pertaining to the request are stored in the data repository 206. Herein, the UE 102 includes the token in the API call or the request.
[0059] In one embodiment, the token is included in the header of the API call or the request. The header is part of the request which contains crucial metadata about the request and the UE 110. The metadata is related to at least one of, but not limited to, token and the identifiers of the UE 110. For example, the identifier associated with the UE 110 is at least one of, but not limited to, the IMEI number. In one embodiment, the tokens may be of various forms, such as at least one of, but not limited to, JSON Web Tokens (JWTs), OAuth tokens, or custom tokens.
[0060] Upon receiving the request, the validating unit 210 of the processor 202 is configured to validate a token associated with the received request. In particular, token is included within the API call or the request. In order to validate the token, the validating unit 210 extracts the token from the API call. Thereafter, the validating unit 210 compares the extracted token with pre-stored information of the consumer stored in the data repository 206 for validation. The pre-stored information of the consumer includes at least one of, but not limited to, triplet information related to the consumer. In one embodiment, the maintaining unit 216 maintains the data repository 206 to include information pertaining to the consumer. In particular, the validating unit 210 validates the token included in the API call by at least one of, but not limited to, parsing the token, and verifying a token signature. In one embodiment, the validating unit 210 validates the token to authenticate the consumer.
[0061] For example, let us assume that the token is a JSON Web Token (JWT) token which consists of three parts such as a header, a payload and a signature. In order to validate the token, the validating unit 210 splits the JWT token into three parts such as the header, the payload and the signature. Further, the validating unit 210 decodes the header and the payload. Thereafter, using the decoded header and payload the signature is recomputed by the validating unit 210 using the at least one of, a secret/public key which was used to sign the token. Furthermore, the validating unit 210 checks whether the recomputed signature matches the signature part of the token. If the recomputed signature matches with the signature part of the token, then the validating unit 210 infers that the token is valid.
[0062] In one embodiment, the token signature is a cryptographic mechanism used to verify the authenticity of the token. The tokens often include the token signature to ensure that the token is not tampered, and the token are indeed issued by a trusted source. In one embodiment, parsing tokens involves breaking down a sequence of data into meaningful components and then analyzing these components to extract useful information or to ensure proper syntax and structure.
[0063] Upon successfully validating of the token, the retrieving unit 212 of the processor 202 is configured to retrieve the information associated with the consumer from the data repository 206. In particular, the retrieving unit 212 transmits request to an API service such as at least one of, but not limited to, number verification API service to retrieve information from the data repository 206 related to the consumer using the UE 110 connected in the network 106. In one embodiment, the data repository 206 includes the information associated with the consumer such as at least one of, but not limited to, pairing of the number of the consumer and an identifier associated with the UE 110. For example, the identifier is at least one of, but not limited to, the MSISDN, the IMEI, the IMSI and the any other identifiers of the UE 110. Herein, the MSISDN, the IMEI, the IMSI and the any other identifiers may be used individually or in any combination in order to identify the consumer associated with the UE 110 uniquely.
[0064] Upon retrieving the information associated with the consumer, the validating unit 210 utilizes the API service and checks in real time whether the retrieved information associated with the consumer matches with the number of the consumer. In one embodiment, when the number of the consumer and the token received in the API call, then the validating unit 210 compares the retrieved information such as the pairing of the number of the consumer and the identifier of the UE 110 with the number of the consumer and the token. In an alternate embodiment, when only token received in the API call, then the validating unit 210 provides the number of the consumer retrieved by the retrieving unit 212 from the data repository 206.
[0065] In one embodiment, based on comparing, if the validating unit 210 determines that the retrieved information from the data repository 206 is not matching with the number of the consumer, then the transmitting unit 214 of the processor 202 is configured to transmit a response to the user via the UE 102 indicating a status of unsuccessful verification of the number of the consumer.
[0066] In another embodiment, based on comparing, if the validating unit 210 determines that the retrieved information from the data repository 206 is matching with the number of the consumer, then the transmitting unit 214 of the processor 202 is configured to transmit a response to the user via the UE 102 indicating the status of successful verification of the number of the consumer. In particular, the response includes a comparison result for verifying the number of the consumer associated with the UE 110 of the consumer.
[0067] In an alternate embodiment, the transmitting unit 214 is configured to transmit the response indicating the number of the consumer associated with the UE 110 of the consumer to the UE 102 of the user. More specifically, the retrieving unit 212 retrieves the number of the consumer associated with the token from the data repository 206 and transmits the response with an actual number of the consumer to the UE 102 of the user via the transmitting unit 214.
[0068] Advantageously, utilizing the data repository 206 and the processor 202 the user verifies the number of the consumer without communicating with the one or more network elements. Due to verifying the number of the consumer without communicating with the one or more network elements, the load on the one or more network elements associated with the requests are reduced and the performance of the one or more network elements is not degraded.
[0069] The receiving unit 208, the validating unit 210, the retrieving unit 212, the transmitting unit 214, and the maintaining unit 216 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.
[0070] 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 verifying the number of the consumer associated with the UE 110. 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.
[0071] FIG. 3 shows communication between the UE 102 and the system 108. 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. In an embodiment, the network protocol connection is the establishment and management of communication between the UE 102 and the system 108, 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).
[0072] 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.
[0073] 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 verifying the number of the consumer associated with the UE 110. 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.
[0074] 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 allows the user to transmit the API call to the system 108 for verifying the number of the consumer associated with the UE 110. In one embodiment, the user may be at least one of, but not limited to, the network operator and a third party etc.
[0075] For example, based on the request received from the UE 102, the system 108 verifies the number of consumers associated with the UE 110 using the API. For example, the API verifies that the consumer is using the UE 110 with the same mobile phone number as it is declared when the UE 110 is initially connected with the one or more network elements. The API also enables the service provider to verify the number of the consumer by extracting the number associated to the authenticated user's access token from the data repository 206. In other words, the user can verify the number of the consumer either by getting a comparison result or by receiving the actual number of the consumer associated with the UE 110 so that the user can verify themselves. Advantageously, without communicating with the one or more network elements, the user verifies the number of the consumer associated with the UE 110.
[0076] As mentioned earlier in FIG.2, the system 108 includes the processors 202, the memory 204, and the data repository 206 for verifying the number of the consumer associated with the UE 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.
[0077] Further, as mentioned earlier the processor 202 includes the receiving unit 208, the validating unit 210, the retrieving unit 212, the transmitting unit 214, and the maintaining unit 216 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.
[0078] FIG. 4 is an exemplary the system 108 architecture 400 for verifying the number of the consumer associated with the UE 110, according to one or more embodiments of the present disclosure.
[0079] 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, a UDM/HSS 420, a data explorer 422 , an analyzer 424 and an API analytics 426 communicably coupled to each other via the network 106.
[0080] 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 intends to use Application Programming Interfaces (APIs) for their respective use cases such as verifying the number of the consumer associated with the UE 110. In an embodiment, the UI API Dashboard 404 is a User Interface (UI) from where the API consumer 402 transmits the API calls/ request via the API for verifying the number of the consumer associated with the UE 110.
[0081] 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 verifying the number of the consumer. 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.
[0082] In one embodiment, the common API gateway 406 is at least one of, a CAPIF. The CAPIF is a complete 3rd Generation Partnership Project (3GPP) API framework that covers functionality related to verifying the number of the consumer. The CAPIF is a unified API gateway 406 for API consumer 402. The CAPIF also deals with security and authorization of the APIs.
[0083] In one embodiment, similar to the API consumer 402, the API publisher 410 comprises an API developer, an API playground, and an enterprise architecture. 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. The API analytics 426 involves the collection, analysis, and reporting of data related to the usage and performance of APIs. The analyzer 424 is an Artificial Intelligence/Machine Learning (AI/ML) analyzer that tracks APIs by integrating with various tools and techniques to monitor, evaluate, and improve the performance and behavior of APIs.
[0084] 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. In one embodiment, the SSA DC 418 is a data collector microservice. In an embodiment, the one cache 416 acta as the data repository 206, the one cache 416 is the unified data store 110 which stores the information associated with the consumer.
[0085] In one embodiment, the UDM/HSS 420 are the one or more network elements 112 that proactively provides information pertaining to the consumers to the one cache 416. In one embodiment, the data exporter 422 exports the data from the UDM/HSS 420 to the one cache 416.
[0086] In an embodiment, usually when the phone/mobile number of the consumer is registered with the system 100 for the first time, or when the SIM related event such as the SIM change occurs for the first time, the event reaches the SSA DC 418 which is data collector. The data collector keeps information related to the event in the one cache 416. For example, information such as the MSISDN, the IMEI, and the IMSI are related to such events and are stored in the one cache 416. When an API call from the API consumer 402 is reached the CAPIF, the CAPIF verifies the token in the API call. Once the token is validated, the SSA EF 408 retrieves the information of the consumer from the one cache 416 and provides the retrieved information to the CAPIF. Herein the CAPIF determines whether the retrieved information is related to the phone/mobile number of the consumer. For example, if the retrieved information matches with phone/mobile number is associated with the UE 110, then the CAPIF sends a positive response to the API consumer 402, else a negative response is sent to the API consumer 402.
[0087] FIG. 5a is an exemplary signal flow diagram illustrating the flow for verifying the number of the consumer associated with the UE 110, according to one or more embodiments of the present disclosure.
[0088] At step 502, the API call is transmitted from the UE 102 of the user to the system 108 for verifying the number of the consumer associated with the UE 110. Herein, the request includes at least one of, but not limited to, the token and the number of the consumer.
[0089] At step 504, the system 108 and the server 104 validate the token included in the API call. Then token is validated based on the network-based authentication. While validating tokens the system 104 ensures that the token has valid signatures or credentials. For example, the token is an authentication token.
[0090] At step 506, the system 108 retrieves the information related to consumer from the data repository 206 on validation of the token. In one embodiment, a POST request is transmitted to the data repository 206 to retrieve the information related to consumer. In computing, POST is a request method supported by a Hypertext Transfer Protocol (HTTP) used by the World Wide Web. In particular, the POST request includes the number of the consumer and the token. Herein, based on the POST request, the number of the consumer associated with the token is retrieved from the data repository 206.
[0091] At step 508, the system 108 verifies the number of the consumer included in the POST request based on the retrieved information. In one embodiment, the system 108 compares the retrieved information with the number of the consumer. Based on the comparison, if the retrieved information matches with the number of the consumer, then the number of the consumer is verified.
[0092] At step 510, the system 108 transmits the response related to the verification result of the number of the consumer to the UE 102. For example, the response includes the status related to the verification of the number of the consumer such as successful verification or unsuccessful verification, positive or negative and true or false.
[0093] FIG. 5b is an exemplary signal flow diagram illustrating the flow for verifying the number of the consumer associated with the UE 110, according to one or more embodiments of the present disclosure.
[0094] At step 502, the UE 102 transmits the number to be verified to a device application. In particular, the device application is a type of software specifically designed to run on the device such as the UE 102. Further at step 504, the device application transmits the request to a backend application to verify the number. In particular, the backend application is a part of a software system that operates behind the scenes, managing the server-side operations, business logic, and data handling. At step 506, the backend application initiates the verification of the number and notifies the device application regarding the same. At step 508, the device application requests the backend application to get an auth token. In particular, obtaining an auth token is a common process in modern applications, particularly for mobile applications that need to authenticate users and authorize their access to resources. At step 510, the backend application transmits request to the auth server 104 for getting the auth request based on the request received from the device application. At step 512, the auth server 104 provides the access token to the backend application based on the request received from the backend application.
[0095] In one scenario such as the phone number verification case, at step 514, the backend application transmits the POST request to the data repository 206 via the auth server 104 which includes the phone number, and the access token received from the auth server 104. At step 516, the backend application receives a verification result from the data repository 206 via the auth server 104 based on the POST request. Herein, the auth server 104 compares either the phone number alone or the access token and the phone number included in the POST request with the phone number included in the data repository 206 and provides the verification result such as the compared result. At step 518, the backend application transmits the verification result to the device application. The verification result may include at least one of, but not limited to, a successful result and a non-successful result. The successful rest indicates that the number is verified. The non-successful result indicates that the number verification is failed. The verification result is displayed on the UE 102.
[0096] In another scenario such as the phone number share case, at step 520, the backend application transmits the GET request to the data repository 206 via the auth server 104 which includes the access token received from the auth server 104. At step 522, the backend application receives a verification result from the data repository 206 via the auth server 104 based on the GET request. The GET request is a fundamental Hypertext Transfer Protocol (HTTP) method used to retrieve data from the auth server 104. Herein, the auth server 104 provides the verification result which includes the actual phone number to the backend application. At step 524, the backend application transmits the verification result to the device application. At step 526, the device application transmits the verification result to the UE 102. The verification result may include at least one of, but not limited to, a successful result and a non-successful result. The successful rest indicates that the number is verified. The non-successful result indicates that the number verification is failed. The verification result is displayed on the UE 102.
[0097] FIG. 6 is a flow diagram of a method 600 for verifying the number of the consumer associated with the UE 102, 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.
[0098] At step 602, the method 600 includes the step of receiving the API call from the UE 102 for verifying the number of the consumer associated with UE 110. In one embodiment, the receiving unit 208 receives the API call from the user via the UE 102 for verifying the number of the consumer associated with UE 110. In an alternate embodiment, the request is received at the receiving unit 208 for verifying the number of the consumer. For example, the third party transmits the request to the system 108 for verifying the number of the consumer.
[0099] At step 604, the method 600 includes the step of validating the token upon receipt of the API call. Herein, the token is included in the API call and the token may include the number of the consumer and details of the UE 110. In one embodiment, the validating unit 210 validates the token included in the API call. For example, the API call includes the token which is validated by verifying at least one of, but not limited to, the token signature by the validating unit 210. If the token included in the received API call is an invalid token, then a negative response is transmitted to user via the UE 102.
[00100] At step 606, the method 600 includes the step of retrieving information associated with the consumer from the data repository 206 on validation of the token. In one embodiment, the retrieving unit 212 retrieves information associated with the consumer from the data repository 206. For example, let us assume there is triplet information stored in the data repository 206. The triplet information includes the pairing of the at least one of, the MSISDN which is the number of the consumer, the IMSI which is identifier of the consumer, and the IMEI which is the identifier of the UE 110. So, the retrieving unit 212 retrieves the triplet information associated with the consumer from the data repository 206. For example, the triplet information pairing for a consumer A is retrieved.
[00101] Upon retrieving information associated with the consumer from the data repository 206, the validating unit 210 checks whether the number of the consumer included in the request is matching with the number of the consumer included in the retrieved triplet information. In one scenario, if the number of the consumer included in the request is not matching with the number of the consumer included in the retrieved triplet information, then the transmitting unit 214 transmits the negative response the user via the UE 102, indicating the status of unsuccessful verification of the number of the consumer.
[00102] In an alternate embodiment, if the number of the consumer included in the request is matching with the number of the consumer included in the retrieved triplet information, but the other information triplet included in the triplet such as the IMEI and the IMSI is not matching with the consumer, then the transmitting unit 214 transmits the negative response the user via the UE 102, indicating the status of unsuccessful verification of the number of the consumer.
[00103] For example, let us assume that the consumer A had requested the user such as the third party for a financial transaction. Then based on the request, the user intends to verify the number of the consumer A. So, the user transmits request including the token, details of the UE 110 and the number of the consumer A to the system 108 for verifying the number of the consumer A. Based on the received request, the system retrieves the triplet information associated with the consumer A and compares retrieved triplet information with the number of the consumer A included in the request. Based on comparison, if the system 108 determines that the number of the consumer A is matching but the IMEI of the UE 110 of the consumer A is not matching with the IMEI included in the retrieved triplet information, then the system 108 transmits the negative response to the user such as the UE 110 used by the consumer A is not registered with the number of the consumer A. In other words, the negative response indicates the fraudulent attempt to use the number of the consumer A for the financial transaction.
[00104] At step 608, the method 600 includes the step of transmitting the response indicating successful verification of the number of the consumer to the UE 102 if the retrieved information matches with the number of the consumer. In one embodiment, the transmitting unit 214 transmits the response indicating successful verification of the number of the consumer to the UE 102. In particular, the validating unit 210 compares the retrieved information from the data repository 206 with the number of the consumer. Based on comparison if the number of the consumer included in the request is matching with the number of the consumer included in the retrieved triplet information, then the transmitting unit 214 transmits the positive response the user which indicates the successful verification of the number of the consumer. In an alternate embodiment, transmitting unit 214 transmits the response to the user which includes the actual mobile number of the consumer.
[00105] In yet another aspect of the present invention, a non-transitory computer-readable medium stored thereon computer-readable instructions that, when executed by the processor 202. The processor 202 is configured to receive the Application Programming Interface (API) call from the UE 102 of the user. The processor 202 is further configured to validate the token generated upon receipt of the API call, the token is included in the API call. The processor 202 is further configured to retrieve information associated with the consumer from the data repository 206 on validation of the token. The processor 202 is further configured to transmit the response indicating successful verification of the number of the consumer to the UE 102 of the user if the retrieved information matches with the number of the consumer.
[00106] 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.
[00107] The present disclosure provides technical advancements of the present invention such as the number of the consumer is verified without generating a One Time Password (OTP). The disclosed method and system help in offloading the load from the one or more network elements by introducing the data repository that stores the information associated with the consumer along with the user current device details. From the data repository, the user can access the information associated with the consumer such as the mobile number of the consumer using the APIs without communicating with one or more network elements. Easy and secure integration of APIs on REST for number verification on demand is achieved by the present invention. Further, monitoring and logging of each API call is facilitated by the disclosed method. Furthermore, access control and policy rules are implemented on every API call to verify the number of the consumer.
[00108] 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

[00109] Environment - 100;
[00110] User Equipment (UE) of the consumer - 102;
[00111] Server - 104;
[00112] Network- 106;
[00113] System -108;
[00114] UE of the consumer – 110;
[00115] Processor - 202;
[00116] Memory - 204;
[00117] Data repository– 206;
[00118] Receiving unit– 208;
[00119] Validating unit – 210;
[00120] Retrieving unit – 212;
[00121] Transmitting unit – 214;
[00122] Maintaining unit – 216;
[00123] Primary Processor – 302;
[00124] Memory – 304;
[00125] User Interface (UI) – 306;
[00126] API consumer – 402;
[00127] UI API Dashboard – 404;
[00128] Unified API Gateway – 406;
[00129] SSA EF - 408;
[00130] API Publisher – 410;
[00131] Subscription Engine - 412;
[00132] Market Place – 414;
[00133] One cache – 416;
[00134] SSA DC- 418;
[00135] UDM/HSS – 420;
[00136] Data exporter – 422;
[00137] Analyzer - 424;
[00138] API analytics - 426.

,CLAIMS:
CLAIMS
We Claim:
1. A method (600) of verifying a number of a consumer associated with a User Equipment (UE) (110) of the consumer, the method (600) comprising the steps of:
receiving, by one or more processors (202), an Application Programming Interface (API) call from a UE (102) of a user;
validating, by the one or more processors (202), a token upon receipt of the API call, wherein the token is included in the API call;
retrieving, by the one or more processors (202), information associated with the consumer from a data repository (206) on validation of the token; and
transmitting, by the one or more processors (202), a response indicating successful verification of the number of the consumer to the UE (102) of the user the retrieved information matches with the number of the consumer.

2. The method (600) as claimed in claim 1, wherein the method (600) comprises the step of maintaining, by the one or more processors (202), the data repository (206) to include information pertaining to the consumer.

3. The method (600) as claimed in claim 1, wherein the API call pertains to verification of the number of the consumer associated with the UE (110) of the consumer.

4. The method (600) as claimed in claim 1, wherein the information comprises a pairing of the number of the consumer and an identifier associated with the UE (110) of the consumer.

5. The method (600) as claimed in claim 1, wherein the one or more processors (202) is validating the token by at least one of, a parsing the token, and verifying a token signature.

6. The method (600) as claimed in claim 1, wherein verifying the number of the consumer associated with the UE (110) is done by at least one of, a user interaction and without a user interaction.

7. The method (600) as claimed in claim 1, wherein the information associated with the consumer is retrieved from the data repository (206) based on at least one of, a POST request transmitted by the one or more processors (202) to the data repository (206), wherein the POST request includes at least one of, the number of the consumer to be verified and the token.

8. The method (600) as claimed in claim 1, wherein the information associated with the consumer is retrieved from the data repository (206) based on at least one of, a GET request transmitted by the one or more processors (202) to the data repository (206), wherein the GET request includes the token.

9. A system (108) for verifying a number of a consumer associated with a User Equipment (UE) (110) of the consumer, the system (108) comprising:
a receiving unit (208) configured to receive, an Application Programming Interface (API) call from a UE (102) of a user;
a validating unit (210) configured to validate, a token generated upon receipt of the API call, wherein the token is included in the API call;
a retrieving unit (212) configured to retrieve, information associated with the consumer from a data repository (206) on validation of the token; and
a transmitting unit (214) configured to transmit, a response indicating successful verification of the number of the consumer to the UE (102) of the user the retrieved information matches with the number of the consumer.

10. The system (108) as claimed in claim 11, comprising a maintaining unit (216) configured to maintain, the data repository (206) to include information pertaining to the consumer.

11. The system (108) as claimed in claim 11, wherein the API call pertains to verification of the number of the consumer associated with the UE (110) of the consumer.

12. The system (108) as claimed in claim 11, wherein the information comprises a pairing of the number of the consumer and an identifier associated with the UE (110) of the consumer.

13. The system (108) as claimed in claim 11, wherein the validating unit (210) is validating the token by at least one of, a parsing the token, and verifying a token signature.

14. The system (108) as claimed in claim 11, wherein verifying the number of the consumer associated with the UE (110) is done by at least one of, a user interaction and without a user interaction.

15. The system (108) as claimed in claim 11, wherein the information associated with the consumer is retrieved from the data repository (206) based on at least one of, a POST request transmitted by the one or more processors (202) to the data repository (206), wherein the POST request includes at least one of, the number of the consumer to be verified and the token.

16. The system (108) as claimed in claim 11, wherein the information associated with the consumer is retrieved from the data repository (206) based on at least one of, a GET request transmitted by the one or more processors (202) to the data repository (206), wherein the GET request includes the token.

17. 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) of the user to:
transmit, an Application Programming Interface (API) call from the UE (102) of the user to one or more processors (202); and
wherein the one or more processors (202) is configured to perform the steps as claimed in claim 1.