System and method for providing caller information in a network

Abstract

A system (108) and a method (600) for providing caller information in a network (106) are disclosed The system includes an MNP+ application (418) that receives a request from a Converged Telephony Application Server (CTAS) (412) for obtaining caller information. Upon receiving a request, the MNP+ application (418) determines a service applicability condition for at least one user based on the received request. Upon determining the service applicability condition, the MNP+ application retrieves the caller information from a database through a communication protocol based on one or more Session Initiation Protocol (SIP) parameters and transmits the caller information to the CTAS (412).

Description

SYSTEM AND METHOD FOR PROVIDING CALLER INFORMATION IN A NETWORK RESERVATION OF RIGHTS

[0001] A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, Integrated Circuit (IC) layout design, and / or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (hereinafter referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights. All rights to such intellectual property are fully reserved by the owner.TECHNICAL FIELD

[0002] The present disclosure relates generally to the field of communication systems. More particularly, the present disclosure relates to a system and method for providing caller information (e.g., display name and spam indication) in a network.DEFINITION

[0003] As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used to indicate otherwise.

[0004] The ‘MNP’, as used herein refers to a Mobile Number Portability. The MNP is a service that allows mobile subscribers to retain their mobile numbers when switching between multiple telecom service providers (TSPs).

[0005] The term ‘enhanced MNP (MNP+)’ (interchangeably referred to as Mobile Number Portability module), as used herein refers to an enhanced version of a Mobile Number Portability application. The MNP+ application retains traditional routing functionalities and incorporates capabilities for spam detection and Calling Name Presentation (CNAP) services.

[0006] The term ‘MSISDN’, as used herein refers to a Mobile Station International Subscriber Directory Number. The MSISDN is a unique number used to identify a mobile subscriber in a telecommunications network.

[0007] The term ‘CTAS’, as used herein refers to a Converged Telephony Application Server. The CTAS is responsible for managing telephony services in a network and interacting with the MNP+ to retrieve spam indications and display names for calling parties.

[0008] The term ‘CNAP’, as used herein refers to a Calling Name Presentation. The CNAP is a service that displays a calling party's name on a called party’s device during an incoming call.

[0009] The term ‘CNAP-DB’, as used herein refers to a Calling Name Presentation Database. The CNAP-DB is a centralized database maintained by telecom service providers to store the mapping of MSISDNs to corresponding display names.

[0010] The term ‘spam indication’, as used herein refers to a flag or parameter that denotes whether a call is potentially spam. Spam indications are mapped to the MSISDNs in the MNP+ application based on patterns identified by analytics systems.

[0011] The term ‘AI / ML unit’ as used herein refers to an Artificial Intelligence / Machine Learning-powered analytics unit that processes Call Detail Records (CDRs) to identify spam callers based on various behavioral patterns, such as call rejection rates, call volumes, and call durations of the users.

[0012] The term ‘MSISDN of the Called Party parameter’ (interchangeably referred to as a first SIP parameter), as used herein refers to a parameter that contains the MSISDN of the called party along with the country code and is used to identify specific users for spam detection or CNAP services.

[0013] The term ‘new MNP functionality parameter’ (interchangeably referred to as a second SIP parameter), as used herein refers to a flag that indicates a sequence of tasks to be executed by the MNP+, such as spam detection, display name retrieval, or both.

[0014] The term ‘HTTP API’ as used herein refers to a Hypertext Transfer Protocolbased Application Programming Interface. The HTTP API is used by the MNP+ to interact with CNAP-DBs hosted by other TSPs to retrieve display names and associated details.

[0015] The term ‘SIP’, as used herein refers to a Session Initiation Protocol. The SIP is a signaling protocol used to establish, modify, and terminate communication sessions in the network that is used by the CTAS and MNP+ to exchange information about spam indications and display names during call setups.

[0016] The term ‘cache’, as used herein refers to a temporary storage mechanism used by the MNP+ to store retrieved data, such as display names or spam indications, for a configurable duration to reduce repetitive queries and optimize network performance.

[0017] The term ‘routing number (RN)’, as used herein refers to a unique identifier used in the MNP application to determine the network to which a mobile number belongs.

[0018] The term ‘operator-circle mapping’, as used herein refers to the configuration in the MNP+ that links operators and their respective circles with CNAP-DB details to facilitate efficient querying.

[0019] The term ‘blacklist’, as used herein refers to a list of the MSISDNs that are flagged as spam callers. Calls from these numbers are blocked or marked as spam during incoming calls.

[0020] The term ‘grey list’, as used herein refers to a list of the MSISDNs suspected of being spam callers. The calls from these numbers may trigger spam warnings without immediate blocking.BACKGROUND

[0021] The following description of related art is intended to provide background information pertaining to the field of the disclosure. This section may include certainaspects of the art that may be related to various features of the present disclosure. However, it may be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of prior art.

[0022] In telecommunication networks, Mobile Number Portability (MNP) applications primarily serve to store and provide routing information for mobile numbers, enabling users to retain their numbers when switching between telecom service providers (TSPs). However, as the volume of unsolicited, fraudulent, and spam calls continues to rise, a need for more advanced capabilities in MNP systems has become apparent. The existing MNP applications are limited to routing functionalities and do not support identifying or marking spam calls, leaving users vulnerable to scams and reducing their trust in telecommunication networks.

[0023] Caller identification mechanisms, such as Calling Name Presentation (CNAP), have been introduced to display a calling party's name to the recipient. However, the current solutions often rely on third-party applications that utilize crowdsourced data, which may be unreliable and unavailable to users who do not have such applications installed. Furthermore, legacy networks lack standardized and secure mechanisms for retrieving and sharing CNAP information and spam indications across the TSPs, resulting in inconsistent service delivery and increased call setup delays.

[0024] Therefore, there is a need for an improved technique that can overcome the deficiencies of the conventional solutions to enable the telecommunication networks to provide accurate caller identification, reduce spam, and enhance the overall customer experience.SUMMARY OF THE DISCLOSURE

[0025] In an exemplary embodiment, a method for providing caller information in a network is disclosed. The method includes receiving, by a mobile number portability module, a request from a Converged Telephony Application Server (CTAS) to obtain caller information associated with a calling party. The method includes determining, by the mobile number portability module, a service applicability condition for at least one user based on the received request. Upon determining the service applicability condition, the method includes retrieving, by the mobile number portability module, the caller information from a database through a communication protocol based on one or more Session Initiation Protocol (SIP) parameters. The method further includes transmitting, by the mobile number portability module, the caller information to the CTAS.

[0026] In some embodiments, the caller information includes at least one of: a display name associated with the calling party, and a spam indication associated with the calling party.

[0027] In some embodiments, determining the service applicability condition includes identifying, by the mobile number portability module, whether a callerinformation service is enabled for at least one of: a predefined set of users, or a plurality of users in the network.

[0028] In some embodiments, when the caller information service is enabled for the predefined set of users, the method further includes inspecting, by the mobile number portability module, a first SIP parameter from the request representing a called party identifier. The method further includes comparing, by the mobile number portability module, the called party identifier with a configured list of users maintained in an internal memory of the mobile number portability module, and when the called party identifier matches an entry in the configured list of users, retrieving, by the mobile number portability module, the caller information from the database.

[0029] In some embodiments, retrieving the caller information includes determining, by the mobile number portability module, a type of caller information to be retrieved based on a second SIP parameter.

[0030] In some embodiments, the second SIP parameter represents a mobile number portability functionality parameter indicating whether the mobile number portability module retrieves at least one of: the display name associated with the calling party, the spam indication associated with the calling party, or a combination thereof.

[0031] In some embodiments, when the caller information service is enabled for the plurality of users, the method further includes retrieving, by the mobile number portability module, at least one of the display name, the spam indication, or a combination thereof from the database for the calling party based on the second SIP parameter.

[0032] In some embodiments, the method further includes storing, by the mobile number portability module, the retrieved caller information in the internal memory for a predefined duration, wherein the retrieved caller information is stored with an associated expiry time to reduce call setup delay.

[0033] In another exemplary embodiment, a system for providing caller information in a network is disclosed. The system includes a mobile number portability module configured to receive a request from a Converged Telephony Application Server (CTAS) to obtain caller information associated with a calling party, determine a service applicability condition for at least one user based on the received request, retrieve the caller information from a database through a communication protocol based on one or more Session Initiation Protocol (SIP) parameters upon determining the service applicability condition, and transmit the caller information to the CTAS.

[0034] In yet another exemplary embodiment, a computer program product comprising a non-transitory computer-readable medium is disclosed. The medium includes instructions that, when executed by one or more processors, cause the one or more processors to execute a method for retrieving caller information in a network. The method includes receiving, by a mobile number portability module, a request from a Converged Telephony Application Server (CTAS) to obtain caller information associated with a calling party, determining, by the mobile number portability module,a service applicability condition for at least one user based on the received request, retrieving, by the mobile number portability module, the caller information from a database through a communication protocol based on one or more Session Initiation Protocol (SIP) parameters upon determining the service applicability condition, and transmitting, by the mobile number portability module, the caller information to the CTAS.

[0035] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.OBJECTIVES OF THE PRESENT DISCLOSURE

[0036] Some of the objectives of the present disclosure, which at least one embodiment herein satisfies, are as follows:

[0037] An objective of the present is to provide a system and a method for enhancing a Mobile Number Portability (MNP) application to incorporate spam detection and Calling Name Presentation (CNAP) services, thereby improving the accuracy of caller identification and reducing fraudulent activities.

[0038] Another objective of the present disclosure is to ensure seamless and secure data exchange between telecom service providers (TSPs) through a standardized and encrypted Hypertext Transfer Protocol-based Application Programming Interface (HTTP API), enabling interoperability and confidentiality in data retrieval from a Calling Name Presentation (CNAP) database.

[0039] Another objective of the present disclosure is to reduce call setup delays by implementing a caching mechanism in an enhanced Mobile Number Portability (MNP) application (referred to as an MNP+ application), allowing for faster retrieval of display names and spam indications without repetitive database queries.

[0040] Another objective of the present disclosure is to integrate spam detection capabilities into the enhanced MNP application by mapping spam indications against Mobile Station International Subscriber Directory Numbers (MSISDNs) of unauthorized users, through an Artificial Intelligence / Machine Learning (AI / ML) unit to enhance detection accuracy.

[0041] Another objective of the present disclosure is to enable the MNP+ application to dynamically determine service applicability, supporting specific and universal user scenarios for the CNAP and spam detection based on configurable parameters.

[0042] Yet another objective of the present disclosure is to provide a system that improves overall network efficiency by isolating core network nodes from direct interactions with other TSPs, reducing touchpoints and ensuring scalability.

[0043] Other objects and advantages of the present disclosure will be more apparent from the following description, which is not intended to limit the scope of the present disclosure.BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

[0044] 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.

[0045] FIG. 1 illustrates an exemplary network architecture implementing a system for providing caller information in a network, in accordance with an embodiment of the present disclosure.

[0046] FIG. 2 illustrates an exemplary block diagram of the system for providing the caller information in the network, in accordance with an embodiment of the present disclosure.

[0047] FIG. 3 illustrates an existing system architecture implementing a Calling Name Presentation (CNAP) service for an off-net call scenario, in accordance with prior art.

[0048] FIG. 4 illustrates an exemplary system architecture depicting an enhanced Mobile Number Portability (MNP+) application for providing caller information for the off-net call scenario, in accordance with an embodiment of the present disclosure.

[0049] FIG. 5 illustrates an exemplary process flow for providing the caller information in the network, in accordance with an embodiment of the present disclosure.

[0050] FIG. 6 illustrates a flow diagram of a method for providing the caller information in the network, in accordance with an embodiment of the present disclosure

[0051] FIG. 7 illustrates an exemplary block diagram of a computer system in which or with which embodiments of the present disclosure may be implemented.

[0052] The foregoing shall be more apparent from the following more detailed description of the disclosure.List of reference numerals100 - Network architecture102 -User(s)104 -User Equipments (UEs)106 - Network108 - System200 - Block diagram202 - Processor(s)204 - Memory206 -Interface(s)208 - Mobile number portability module210 - Database300 - Existing system Architecture302 - Calling Party304 - Originating Telecommunications Service Provider (TSP) (TSP-1)306 - TSP-1 Calling Name Presentation (CNAP) database308 - Terminating TSP (TSP-2)310 - Mobile Number Portability (MNP) database312 - TSP-2 CNAP database314 - Called Party400 - System Architecture402 - Calling Party404 - Internet Protocol Multimedia Subsystem (IMS) of originating super core 406 - Home Subscriber Server (HSS)408 - Super core serving terminating user410 - Serving Call Session Control Function (SCSCF)412 - Converged Telephony Application Server (CTAS)414 - Mobile Number Portability (MNP)416 - Conventional MNP418 - Enhanced MNP (MNP+)420 - Cached Database422 - Calling Name Presentation (CNAP) database424 - Called Party500 - Process flow600 - Method700 - Computer system710 - External Storage Device720 - Bus730 - Main Memory740 - Read Only Memory750 - Mass Storage Device760 - Communication Port770 - ProcessorDETAILED DESCRIPTION

[0053] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussedabove or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein. Example embodiments of the present disclosure are described below, as illustrated in various drawings in which like reference numerals refer to the same parts throughout the different drawings.

[0054] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It may be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosure as set forth.

[0055] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0056] Also, it is noted that individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.

[0057] The word “exemplary” and / or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and / or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive like the term “comprising” as an open transition word without precluding any additional or other elements.

[0058] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included inat least one embodiment of the present disclosure. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0059] The terminology used herein is to describe particular embodiments only and is not intended to be limiting the disclosure. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context indicates otherwise. It will be further understood that the terms “comprises” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “and / or” includes any combinations of one or more of the associated listed items. It may be noted that the terms “mobile device”, “user equipment”, “user device”, “communication device”, “device” and similar terms are used interchangeably for the purpose of describing the invention. These terms are not intended to limit the scope of the invention or imply any specific functionality or limitations on the described embodiments. The use of these terms is solely for convenience and clarity of description. The invention is not limited to any particular type of device or equipment, and it may be understood that other equivalent terms or variations thereof may be used interchangeably without departing from the scope of the invention as defined herein.

[0060] While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment, as well as other embodiments of the disclosure, will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation.

[0061] In existing telecommunication systems, a Mobile Number Portability (MNP) application primarily serves as a routing database for mobile numbers but lacks capabilities to identify spam calls or retrieve caller names. Reliance on third-party applications for Calling Name Presentation (CNAP) services often leads to unreliable, inconsistent results. Furthermore, the direct integration of core network nodes with external databases introduces security risks, latency, and complexity, hampering the scalability and efficiency of the system.

[0062] Therefore, there is a need for an enhanced MNP application that not only retains its traditional routing functions but also incorporates spam detection and CNAP services, enabling telecommunication networks to provide accurate caller identification, reduce spam, and enhance the overall customer experience.

[0063] To address these challenges, the present disclosure provides a system and method for providing caller information in a network via an enhanced MNP application. In an embodiment, the enhanced MNP application is referred to as an MNP+ application (interchangeably used as a mobile number portability module). Upon receiving a request from a Converged Telephony Application Server (CTAS), the MNP+ application is configured to provide caller information, including display name and / or spam indication, to the CTAS. The MNP+ application integrates with Calling Name Presentation Database (CNAP-DBs) of telecom service providers via a secure Hypertext Transfer Protocol Application Programming Interface (HTTP API) to retrieve display names associated with mobile subscribers and deliver the retrieved information to the CTAS.

[0064] In an embodiment, the MNP+ application is configured to store spam indication and block indication mapped against the Mobile Station International Subscriber Directory Number (MSISDN) of calling parties identified as spammers. The spam-related data may be periodically curated and provided to the MNP+ application by an external analytics system, such as an Artificial Intelligence / Machine Learning (AIZML)-based system, which analyses Call Detail Records (CDRs) associated with CTAS to identify spam patterns and update blacklist and greylist entries. In an embodiment, the MNP+ application determines whether to perform spam detection, display name retrieval, or both, based on one or more Uniform Resource Identifier (URI) parameters, such as a new MNP functionality parameter and an MSISDN of the Called Party parameter. The new MNP functionality parameter indicates a sequence of tasks to be executed by the MNP+ application, while the MSISDN of the Called Party parameter is used to identify the applicability of the service for specific users. In an embodiment, the retrieved caller information, including display names and spam indications, is cached within the MNP+ application for a predefined duration with an associated expiry time to reduce call setup delay and minimize repeated database queries. The caching mechanism improves system efficiency, reduces latency, and enhances the scalability of the telecommunication network.

[0065] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings.

[0066] FIG. 1 illustrates an exemplary network architecture (100) implementing a system (108) for retrieving caller information in a network (106), in accordance with an embodiment of the present disclosure.

[0067] As illustrated in FIG. 1, the network architecture (100) may include one or more user equipments (UEs) (104-1, 104-2, .... 104-N) associated with one or more users (102-1, 102-2, ...., 102-N) in an environment. A person of ordinary skill in the art will understand that one or more users ( 102- 1 , 102-2, ... 102-N) may be individually referred to as the user (102) and collectively referred to as the users (102). Similarly, a person of ordinary skill in the art will understand that one or more UEs (104-1, 104-2,....104-N) may be individually referred to as the UE (104) and collectively referred to as the UEs (104). Although three UEs (104) are depicted in FIG. 1, however, any number of the user equipments (104) may be included without departing from the scope of the ongoing description. In an embodiment, each UE (104) may have a unique identifier attribute associated therewith. In an embodiment, the unique identifier attribute may be indicative of at least one of a Mobile Station International Subscriber Directory Number (MSISDN), International Mobile Equipment Identity (IMEI) number, an International Mobile Subscriber Identity (IMSI), a Subscriber Permanent Identifier (SUPI), and the like.

[0068] In an embodiment, the UE (104) may include smart devices operating in a smart environment, such as an Internet of Things (loT) system. In such an embodiment, the UE (104) may include, but is not limited to, smartphones, smart watches, smart sensors (e.g., mechanical, thermal, electrical, magnetic, etc.), networked appliances, networked peripheral devices, networked lighting system, communication devices, networked vehicle accessories, networked vehicular devices, smart accessories, tablets, smart television (TV), computers, a smart security system, a smart home system, other devices for monitoring or interacting with or for the users (102) and / or entities, or any combination thereof. A person of ordinary skill in the art will appreciate that the UE (104) may include, but is not limited to, intelligent, multi-sensing, network-connected devices that can integrate seamlessly with each other and / or with a central server or a cloud-computing system or any other device that is network-connected.

[0069] In an embodiment, the UE (104) may include, but is not limited to, a handheld wireless communication device (e.g., a mobile phone, a smart phone, a phablet device, and so on), a wearable computer device (e.g., a head-mounted display computer device, a head-mounted camera device, a wristwatch computer device, and so on), a Global Positioning System (GPS) device, a laptop computer, a tablet computer, or another type of portable computer, a media playing device, a portable gaming system, and / or any other type of computer device with a wireless communication capabilities, and the like. In an embodiment, the UE (104) may include, but is not limited to, any electrical, electronic, electro-mechanical, or an equipment, or a combination of one or more of the above devices, such as virtual reality (VR) devices, augmented reality (AR) devices, a laptop, a general-purpose computer, a desktop, a personal digital assistant, a tablet computer, a mainframe computer, or any other computing device. In addition, the UE (104) may include one or more in-built or externally coupled accessories including, but not limited to, a visual aid device such as a camera, an audio aid, a microphone, a keyboard, and input devices for receiving input from the user (102) or an entity such as touch pad, a touch enabled screen, an electronic pen, and the like. A person of ordinary skill in the art will appreciate that the UE ( 104) may not be restricted to the mentioned devices and various other devices may be used.

[0070] In FIG. 1 , the UE (104) may communicate with the system (108) via a network (106) to send data to the system (108). In an embodiment, the network (106) mayinclude at least one of a Fifth Generation (5G) network, a Sixth Generation (6G) network, or the like. The network (106) may enable the UEs (104) to communicate with other devices in the network architecture (100) and / or with the system (108). The network (106) may include a wireless card or some other transceiver connection to facilitate this communication. In another embodiment, the network (106) may be implemented as or include any of a variety of different communication technologies such as a wide area network (WAN), a local area network (LAN), a wireless network, a mobile network, a Virtual Private Network (VPN), the Internet, the Public Switched Telephone Network (PSTN), or the like. In an embodiment, the network (106) may 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.

[0071] In an embodiment, the UE (104) may be communicatively coupled with the network (106). The system (108) may receive a connection request from the UE (104). The system (108) may send an acknowledgment of the connection request to the UE (104). The UE (104) may transmit a plurality of signals in response to the connection request. Once the connection is established, the system (108) may be configured to provide caller information in the network (106) to the CTAS via the enhanced MNP application. A process for proving caller information in the network (106) is explained in greater detail in conjunction with FIGS. 2-7.

[0072] Although FIG. 1 shows exemplary components of the network architecture (100), in other embodiments, the network architecture (100) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 1. Additionally, or alternatively, one or more components of the network architecture (100) may perform functions described as being performed by one or more other components of the network architecture (100).

[0073] FIG. 2 illustrates an exemplary block diagram (200) of the system (108) for providing the caller information in the network (106), in accordance with an embodiment of the present disclosure.

[0074] In an embodiment, the system (108) may include one or more processor(s) (202). The one or more processor(s) (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and / or any devices that process data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the system (108). The memory (204) 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 to create or share data packets over a network service. The memory (204) may comprise any non-transitorystorage device including, for example, volatile memory such as random-access memory (RAM), or non-volatile memory such as erasable programmable read only memory (EPROM), flash memory, and the like.

[0075] In an embodiment, the system (108) may include an interface(s) (206). The interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output devices (I / O), storage devices, and the like. The interface(s) (206) may facilitate communication through the system (108). The interface(s) (206) may also provide a communication pathway for one or more components of the system (108). Examples of such components include, but are not limited to, a mobile number portability module (208) and a database (210).

[0076] In an embodiment, the mobile number portability module (208) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the mobile number portability module (208). In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the mobile number portability module (208) may be processor-executable instructions stored on a non-transitory machine-readable storage medium, and the hardware for the processing engine (208) may comprise a processing resource (for example, one or more processors) to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the mobile number portability module (208). In such examples, the system (108) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the system (108) and the processing resource. In other examples, the mobile number portability module (208) may be implemented by electronic circuitry.

[0077] In an embodiment, the mobile number portability module (208) is configured to provide caller information in the network (106). The mobile number portability module (208) is configured to receive a request from a Converged Telephony Application Server (CTAS) to obtain caller information associated with a calling party. The caller information may include a display name and a spam indication associated with a calling party. The calling party refers to an originating user initiating a communication session, such as a voice call, toward a called party. The calling party may be identified using a unique identifier, such as a Mobile Station International Subscriber Directory Number (MSISDN), which is included in the request received from the CTAS.

[0078] In an embodiment, the display name corresponds to a human-readable name associated with the calling party, retrieved from a Caller Name Presentation Database (CNAP-DB) or maintained within the mobile number portability module (208). The display name enables identification of the calling party at the receiving device of the called party, thereby enhancing user awareness and improving call transparency.

[0079] In an embodiment, the spam indication corresponds to an indicator associated with the calling party that identifies whether the calling party is suspected to be a spam caller or a potentially fraudulent entity. The spam indication may be derived based on comparison of the calling party identifier with entries stored in one or more lists, including a blacklist and a greylist, maintained within the mobile number portability module (208). The blacklist may include calling party identifiers confirmed as spam callers, while the greylist may include calling party identifiers suspected of spam behavior based on predefined criteria or analytical models.

[0080] In an embodiment, the mobile number portability module (208) may be implemented as an enhanced mobile number portability (MNP+) application. In particular, the MNP application may be enhanced with the MNP+ application to provide “Display Name” and “Spam Indication” information to the CTAS in MNP responses. In an embodiment, no changes are required to the existing number range data or the ported number database to accommodate the present enhancement, thereby ensuring backward compatibility with the existing MNP infrastructure while enabling additional functionality for caller identification and spam detection.

[0081] The mobile number portability module (208) is further configured to determine a service applicability condition for at least one user based on the received request, he service applicability condition defines whether caller information services, including display name retrieval and spam indication, are to be applied for a given communication request. In an embodiment, the service applicability condition may correspond to enabling the caller information service for a predefined set of users or for a plurality of users in the network. For example, the mobile number portability module (208) may be configured by a network operator such that caller information services are enabled only for a limited set of subscribers during an initial deployment phase, while in another configuration, the caller information service may be enabled for all subscribers in the network (106).

[0082] In an embodiment, the predefined set of users refers to a limited group of subscribers for whom the caller information service is selectively enabled. Such a predefined set of users may be configured by a network operator and stored within an internal memory (e.g., cache database) of the mobile number portability module (208). For example, during an initial deployment or trial phase, the network operator may enable the caller information service only for a specific group of subscribers, such as enterprise users or users within a particular geographical region. The predefined set of users may be represented as a list of identifiers, such as Mobile Station International Subscriber Directory Numbers (MSISDNs), maintained within the internal memory.

[0083] In an embodiment, the plurality of users refers to all or substantially all subscribers within the network (106) for whom the caller information service is enabled without restriction. In such a scenario, the mobile number portability module (208) applies the caller information service to every incoming request, irrespective of the identity of the called party.

[0084] In an embodiment, the mobile number portability module (208) identifies whether the caller information service is enabled for the predefined set of users or the plurality of users based on configuration data maintained within the mobile number portability module (208). For example, a configuration flag or a policy rule may indicate whether the service is to be applied selectively or universally. When the service is configured for the predefined set of users, the mobile number portability module (208) performs verification steps to determine whether the request corresponds to a user within the configured set.

[0085] In an embodiment, when the caller information service is enabled for the predefined set of users, the mobile number portability module (208) is configured to inspect a first Session Initiation Protocol (SIP) parameter from the received request representing a called party identifier. The SIP parameter may be carried within a Uniform Resource Identifier (URI) of the SIP message, such as in a Contact header field. The inspection process includes extracting specific parameters from the SIP message to identify relevant information associated with the communication request. In an embodiment, the first SIP parameter represents a called party identifier. In an embodiment, the first SIP parameter may correspond to a Mobile Station International Subscriber Directory Number (MSISDN) of the called party parameter, which contains a MSISDN of the called party along with a country code. For example, the first SIP parameter may contain a value such as “+91845213456”, which uniquely identifies the recipient of the communication.

[0086] The mobile number portability module (208) further compares the called party identifier with a configured list of users maintained in an internal memory (e.g., cached database) of the mobile number portability module (208). The comparison process includes matching the extracted called party identifier with entries in the configured list to determine whether the called party is eligible to receive caller information services. For example, if the configured list includes identifiers such as “+91845213456” and “+919876543210”, and the extracted called party identifier matches one of these entries, the module determines that the caller information service is applicable for the request. If the called party identifier does not match any entry in the configured list, the mobile number portability module (208) may refrain from performing further caller information retrieval for that request. When the called party identifier matches an entry in the configured list of users, the mobile number portability module (208) proceeds to retrieve the caller information from the database (210).

[0087] In an embodiment, retrieving the caller information includes determining a type of caller information to be retrieved based on a second SIP parameter. The second SIP parameter represents a new mobile number portability functionality parameter that specifies a sequence of tasks to be executed by the mobile number portability module (208). In an embodiment, the second SIP parameter indicates a type of caller information to be retrieved, including whether to retrieve a display name, determine a spam indication, or perform both operations. For example, a first value of the secondSIP parameter may correspond to performing only spam detection, a second value may correspond to retrieving only a display name, and a third value may correspond to performing both display name retrieval and spam detection.

[0088] In an embodiment, when the caller information service is enabled for the plurality of users in the network (106), the mobile number portability module (208) bypasses inspection and comparison of the called party identifier and directly processes the request based on the second SIP parameter. In such a configuration, the number portability module (208) applies the caller information service to all incoming requests without verifying whether the called party belongs to the predefined set of users.

[0089] In an embodiment, retrieving the caller information includes querying a database (212) through a communication protocol, such as a Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) interface. The database (212) may correspond to a Caller Name Presentation Database (CNAP-DB) storing mappings between a calling party identifier (e.g., MSISDN) and a corresponding display name. For example, the mobile number portability module (208) may send a request containing the calling party identifier “+917012140496” to the CNAP-DB and receive a response including a display name such as “telecom provider name.”

[0090] In an embodiment, the spam indication associated with the calling party may be determined by comparing the calling party identifier with entries stored in one or more lists maintained within the mobile number portability module (208), such as a blacklist or a greylist. For example, if the calling party identifier is present in the blacklist, the mobile number portability module (208) may generate a blocking indication, whereas if the calling party identifier is present in the greylist, the mobile number portability module (208) may generate a spam indication.

[0091] In an embodiment, to ensure accurate processing of caller information requests, the mobile number portability module (208) (interchangeably referred to as the MNP+ application) maintains a configuration file that maps network-related attributes such as circle, operator, and CNAP-DB address. The configuration may be dynamically updated at runtime, allowing addition, modification, or deletion without service interruption. The configuration file may include parameters such as Routing Number (RN), circle associated with the Mobile Station International Subscriber Directory Number (MSISDN), operator associated with the MSISDN, Fully Qualified Domain Name (FQDN) or Internet Protocol (IP) details of the CNAP-DB, X-Application Programming Interface (API)-Key for authentication, and HOST header information of the CNAP-DB.

[0092] In an embodiment, to reduce call setup delays and optimize system performance, the MNP+ application temporarily stores retrieved caller information in its internal memory using a caching mechanism. The cached information is assigned a predefined expiry time to maintain data accuracy while minimizing redundant database queries. When subsequent requests are received within the expiry period, the MNP+application serves the caller information directly from the internal memory, thereby significantly improving response time and reducing network overhead.

[0093] In an embodiment, the MNP+ application further enhances efficiency by maintaining configurable limits on cache entries along with defined expiration policies. When the cache reaches its capacity, entries nearing expiration may be removed first, and entries that exceed the expiry time are purged from the internal memory. In cases where errors occur during retrieval from the CNAP-DB, such as timeouts, error responses, or absence of display name information, the MNP+ application may generate and transmit a ‘302 response’ without including the display name.

[0094] In an embodiment, to support effective spam detection, the MNP+ application maintains separate data structures for blacklisted and grey-listed numbers. Each entry in these lists may include the MSISDN of the calling party and associated circle information, which may be represented as an array.

[0095] In an embodiment, the circle information may be represented as a comma-separated array of circle identifiers. For scenarios where a number is applicable across all circles, a predefined indication such as “ALL” may be used to represent universal applicability.

[0096] In an embodiment, the blacklisted and grey-listed number data may be periodically updated via a Network Management System (NMS). The updates may be pushed as complete datasets rather than incremental changes, ensuring consistency and synchronization across the system.

[0097] In an embodiment, to enhance spam detection capabilities, the MNP+ application may include an Artificial Intelligence / Machine Learning (AI / ML) unit. The AI / ML unit is configured to analyze Call Detail Records (CDRs) collected from Converged Telephony Application Server (CTAS) nodes, for example, through an interface such as ATOM, to identify behavioral patterns associated with calling parties. The CDRs may include parameters such as calling party identifier (MSISDN), called party identifier, call initiation time, call duration, call termination cause, call success or failure status, frequency of outgoing calls, and response behavior of called parties.

[0098] In an embodiment, the AI / ML unit preprocesses the collected CDR data by performing operations such as data normalization, filtering of incomplete records, aggregation of call statistics over predefined time windows, and extraction of relevant features indicative of calling behavior. The extracted features may include, but are not limited to, a ratio of outgoing calls to incoming calls, average call duration, rate of call rejections by distinct called parties, frequency of short-duration calls, and temporal calling patterns such as burst calling behavior within a specific time interval.

[0099] In an embodiment, the AI / ML unit employs one or more machine learning models to classify calling parties as normal users or potential spammers. The machine learning models may include, but are not limited to, supervised learning models such as decision trees, random forest classifiers, support vector machines, or neuralnetworks, and / or unsupervised learning models such as clustering algorithms (e.g., k-means clustering or density-based clustering) for identifying anomalous calling patterns. In certain embodiments, the AI / ML unit may also utilize semi-supervised learning techniques to improve classification accuracy when labeled data is limited.

[0100] In an embodiment, the AI / ML unit is trained using historical CDR datasets, where known spam and non-spam calling patterns are used as training inputs. The trained model generates a classification score or probability for each calling party indicating the likelihood of being a spam caller. Based on the classification output, the AI / ML unit updates one or more data structures, including a blacklist for confirmed spam callers and a greylist for suspected spam callers.

[0101] In an embodiment, the AI / ML unit operates in a periodic or near real-time manner, continuously analyzing incoming CDR data to update the spam classification dynamically. The updated blacklist and greylist entries are then synchronized with the MNP+ application, enabling real-time spam indication and blocking decisions during call processing. The AI / ML unit may further incorporate feedback mechanisms, such as user-reported spam or call rejection patterns, to continuously refine the model and improve detection accuracy over time.

[0102] In an embodiment, for retrieving display names, the MNP+ application supports secure HTTPS-based communication with the CNAP-DB and may maintain a persistent connection with the CNAP-DB for a configurable duration. The MNP+ application may also utilize configurable timers, defined at millisecond granularity, to manage timeouts for communication between the MNP+ application and the CNAP-DB, ensuring reliable and timely data retrieval.

[0103] In an embodiment, the MNP+ application supports separate public IPv6 or dual-stack interfaces for communication with the CNAP-DB. Additionally, when the CNAP-DB is configured using a Fully Qualified Domain Name (FQDN), the MNP+ application performs Domain Name System (DNS) resolution to obtain the corresponding IP address before initiating communication.

[0104] In an embodiment, the MNP+ application applies service logic based on the value of the “new MNP functionality parameter” received in the request. This parameter determines whether the application performs only spam detection, only display name retrieval, or both operations. For example, a first value may indicate execution of only spam detection logic, a second value may indicate execution of only display name retrieval logic, and a third value may indicate execution of both operations. When both operations are requested, the MNP+ application may follow a defined sequence that includes checking the calling party number against the blacklist, then the greylist, and subsequently retrieving the display name from the CNAP-DB.

[0105] In an embodiment, the MNP+ application extracts the MSISDN of the calling party from the Request-URI of the SIP MESSAGE method. Additionally, the application extracts multiple URI parameters from the Contact header of the MESSAGE request, which may include the “new MNP functionality parameter,” the“home circle of the serving CTAS parameter,” the “operator of the calling party parameter,” and the “home circle of the calling party parameter.” These parameters are typically separated by semicolons and provide contextual information required for processing the request.

[0106] In an embodiment, the greylist may be maintained as circle-specific, enabling the MNP+ application to perform more granular spam detection. The application may utilize the home circle identifier to determine whether a calling party number is included in a circle-specific greylist in addition to a default list.

[0107] In an embodiment, the parameters representing the operator and home circle of the calling party are particularly useful for identifying fixed-line numbers and unidentified numbers, as the MNP+ application may not inherently distinguish between mobile and fixed-line users. These parameters assist in determining the appropriate CNAP-DB for retrieving display name information.

[0108] In an embodiment, to enhance spam detection granularity, an additional parameter, referred to as the “MSISDN of the Called Party parameter,” is included in all MNP+ requests irrespective of the value of the “new MNP functionality parameter.” This parameter contains the MSISDN of the called party along with the country code and is used to determine whether the caller information service should be applied for specific users.

[0109] In an embodiment, the MNP+ application may be configured to enable spam detection for all incoming requests or selectively for a predefined set of called party users. When enabled for specific users, the application inspects the “MSISDN of the Called Party parameter” and compares it with a configured list. A match may trigger spam indication or blocking for the corresponding request, whereas if the feature is disabled, the parameter may be ignored.

[0110] In an embodiment, the MNP+ application supports display name retrieval for both mobility users and fixed-line users. For mobility users, the application may utilize routing number (RN) information to determine the circle and operator of the calling party and select the appropriate CNAP-DB. For fixed-line users, the application may rely on the operator and home circle parameters received from the CTAS to identify the correct CNAP-DB.

[0111] In an embodiment, if the mapping between RN or circle / operator and the CNAP-DB is unavailable, the MNP+ application may skip the display name retrieval process and respond with a ‘302 response’ without including the display name. When display name information is successfully retrieved, it may be included in the displayname portion of the Contact header in the response message.

[0112] In an embodiment, the MNP+ application implements a caching mechanism to store mappings between display names and MSISDNs with an associated expiry time. When a request is received, the application first checks the local cache for the required information. If available, the cached data is returned; otherwise, the application retrieves the information from the CNAP-DB and updates the cache.

[0113] In an embodiment, the caching mechanism includes configurable limits and expiry durations. When the cache reaches its limit, entries nearing expiration are removed first, and expired entries are deleted to maintain optimal performance.

[0114] In an embodiment, if the circle and operator combination is not mapped to any CNAP-DB, the MNP+ application may skip the “Display Name” retrieval procedure and provide a ‘302 response’ without the display name. In an embodiment, if the MESSAGE request includes a spam check indication, a spam check may be performed, and the results may be included in the response. Additionally, if the CNAP-DB provides a “Display Name” that exceeds 80 characters, the MNP+ application may truncate the display name to 80 characters before including it in the response.

[0115] In an embodiment, to support seamless integration, the MNP+ application may support the shared API DOC (documentation) finalized between Network Processing Engine (NPE) and International Organization for Standardization (ISO) and also comply with the shared API response format finalized between the entities.

[0116] In an embodiment, for spam detection, the MNP+ application may match the MSISDN with entries in the blacklist and grey list tables. If a particular number is blacklisted or grey listed in a specific circle, the MNP+ application may also match the home circle of the serving CTAS parameter field received in the contact header of the MESSAGE request and block the number only if it matches the circle listed in the blacklist or grey list.

[0117] In addition to these functionalities, the MNP+ application may provide the blocking and spam indication parameter as part of the Contact Header URI in the 302 response. This parameter indicates blocking and spam statuses, where blocking and spam indication parameter = Y is used for blocked calls and blocking and spam indication parameter = S is used for spam calls.

[0118] In an embodiment, the behavior of the MNP+ application is determined based on a combination of the value of the new MNP functionality parameter, the presence or absence of the home circle of the serving CTAS parameter, and the availability of the operator of the calling party parameter and the home circle of the calling party parameter. These parameters collectively influence whether the system performs spam detection, display name retrieval, or both, and whether internal database queries are required.

[0119] In an embodiment, when the new MNP functionality parameter indicates a value corresponding to spam detection (e.g., value “1”), and the home circle of the serving CTAS parameter is set, and both the operator of the calling party parameter and the home circle of the calling party parameter have values equal to a predefined identifier, the system (108) performs only a spam check as indicated in the MESSAGE request, and no internal Mobile Number Portability Database (MNP-DB) queries are executed.

[0120] In an embodiment, when the new MNP functionality parameter indicates spam detection, and the home circle of the serving CTAS parameter is set, and the operatorof the calling party parameter and the home circle of the calling party parameter are present with valid identifiers, the system performs only a spam check as indicated in the MESSAGE request, and no internal MNP-DB queries are executed.

[0121] In an embodiment, when the new MNP functionality parameter indicates spam detection, and the home circle of the serving CTAS parameter is set, but the operator of the calling party parameter and the home circle of the calling party parameter are absent, the system first queries the internal MNP-DB to identify the Routing Number (RN) associated with the calling party, and subsequently performs the spam check as indicated in the MESSAGE request.

[0122] In an embodiment, when the new MNP functionality parameter indicates a value corresponding to display name retrieval (e.g., value “2”), and the home circle of the serving CTAS parameter is not set, and the operator of the calling party parameter and the home circle of the calling party parameter are present with valid identifiers, the system performs a display name lookup using the CNAP database based on the operator of the calling party parameter and the home circle of the calling party parameter, and no internal MNP-DB query is performed.

[0123] In an embodiment, when the new MNP functionality parameter indicates display name retrieval, and the home circle of the serving CTAS parameter is not set, and the operator of the calling party parameter and the home circle of the calling party parameter are absent, the system first queries the internal MNP-DB to identify the Routing Number (RN), and subsequently performs a display name lookup using the CNAP database.

[0124] In an embodiment, when the new MNP functionality parameter indicates a value corresponding to both spam detection and display name retrieval (e.g., value “3”), and the home circle of the serving CTAS parameter is set, and the operator of the calling party parameter and the home circle of the calling party parameter are present with valid identifiers, the system first performs a spam check, followed by a display name lookup using the CNAP database based on the operator of the calling party parameter and the home circle of the calling party parameter, without performing any internal MNP-DB query.

[0125] In an embodiment, when the new MNP functionality parameter indicates both spam detection and display name retrieval, and the home circle of the serving CTAS parameter is set, and the operator of the calling party parameter and the home circle of the calling party parameter are absent, the system first performs a spam check, followed by querying the internal MNP-DB to identify the Routing Number (RN), and subsequently performs a display name lookup using the CNAP database.

[0126] In an embodiment, if a MESSAGE request pertains to a mobile number that is marked as blocked, the MNP+ application may still perform an internal database query to provide a complete MNP+ response.

[0127] In an embodiment, the MNP+ application may have the feasibility to disable the “Display Name” retrieval mechanism. In this state, the MNP+ application may only provide spam detection service.

[0128] In an embodiment, the MNP+ application may have the feasibility to disable “Spam Detection”. In this state, the MNP+ application may only provide the display name retrieval service.

[0129] In an embodiment, the MNP+ application may have the feasibility to enable “Spam Detection” service for the list of users. In this state, the list may be runtime configurable. Bulk addition / modification / deletion may be supported.

[0130] In the MNP+ application maintains a plurality of operational counters to monitor performance, track system behavior, and support analytics. The operational counters may include operator-wise or endpoint-wise CNAP-DB query statistics, including total number of queries, number of successful queries, and number of failed queries. The MNP+ application may further maintain counters corresponding to different types of failures, as defined in an associated API specification. Additionally, the MNP+ application maintains a count of total queries received from the CTAS and a count of successful responses transmitted to the CTAS. The counters may also include a count of total block detections and a count of total spam detections, enabling monitoring of spam-related activities within the network.

[0131] In an embodiment, the MNP+ application further records additional fields in Call Detail Records (CDRs) for enhanced tracking and analysis. The CDR fields may include a service type field indicating the type of caller information processing performed, wherein a first value represents spam detection, a second value represents display name retrieval, and a third value represents a combination of spam detection and display name retrieval. The CDR fields may further include a CNAP-DB dip status indicating whether the CNAP database query was successful or unsuccessful. Additionally, the CDR may store information related to display name characteristics, such as the length of the retrieved display name, along with timing parameters including request time and response time associated with the CNAP-DB query.

[0132] In an embodiment, the CDR may further include a blacklist indication field associated with the calling party, wherein a first value indicates that the calling party is classified as blocked, and a second value indicates that the calling party is identified as spam. These additional fields enable detailed monitoring, auditing, and analysis of caller information processing and spam detection within the MNP+ application.

[0133] Upon retrieving the caller information from the database (212), the mobile number portability module (208) is further configured to transmit the retrieved caller information to the CTAS. The transmitted caller information may include the display name and / or the spam indication, enabling the CTAS to present the identity of the calling party to the called party and to alert the called party regarding potential spam or fraudulent calls. For example, the CTAS may display “Spam Call” or the retrieved display name on a user device based on the received caller information.

[0134] In an embodiment, the mobile number portability module (208) is configured to store the retrieved caller information in the internal memory for a predefined duration. The retrieved caller information is stored with an associated expiry time to reduce call setup delay. For example, once a display name corresponding to a calling party identifier is retrieved from the database (212), the mobile number portability module (208) may store the mapping in the internal memory for a predefined duration, such as 24 hours. For subsequent requests received within the predefined duration, the mobile number portability module (208) may retrieve the caller information directly from the internal memory without querying the database, thereby reducing latency and improving system performance.

[0135] Although FIG. 2 shows exemplary components of the system (108), in other embodiments, the system (108) may include fewer components, different components, differently arranged components, or additional functional components than depicted in FIG. 2. Additionally, or alternatively, one or more components of the system (108) may perform functions described as being performed by one or more other components of the system (108).

[0136] FIG. 3 illustrates an existing system architecture (300) implementing a Calling Name Presentation (CNAP) service for an off-net call scenario, in accordance with prior art. In an embodiment, the off-net call scenario is where the calls between a calling party and a called party belong to different network operators. Additionally, in the on-net call scenario, the calls between a calling party and a called party belong to the same network operator.

[0137] Referring to FIG. 3, the existing system architecture (300) depicts an A party (calling party) (302) initiating a call via an originating telecom service provider (TSP-1) (304). In an embodiment, the TSP-1 (304) maintains a CNAP database (306) containing subscriber name information for its own customers. When the call originates from a TSP-1 subscriber and is destined for a terminating telecom service provider (TSP-2) (308), the call flow involves multiple interactions for accurate CNAP data retrieval.

[0138] The terminating TSP (308) initially performs a Mobile Number Portability (MNP) dip to determine whether the calling party belongs to the originating TSP-1 (304) or any other operator. The MNP dip involves querying an MNP database (310) to retrieve MNP data, which includes routing and operator-related information for ported and non-ported numbers. The MNP dip enables identification of the originating operator associated with the calling party.

[0139] If the MNP dip reveals that the originating and terminating TSPs are the same, the terminating TSP performs a lookup from its own CNAP database (e.g., TSP-2 CNAP database (312)) to retrieve the display name associated with the calling party. In such scenarios, the display name is fetched locally, resulting in relatively lower latency.

[0140] However, in the case of off-net calls where the originating TSP differs from the terminating TSP, the terminating TSP performs a lookup from the originating TSP CNAP database (e.g., TSP-1 CNAP database (306)) over a secure and encrypted channel using an HTTP-based API. The retrieved CNAP data is combined with Calling Line Identification (CLI) and delivered to the called party (314).

[0141] While the existing system architecture (300) enables CNAP functionality for off-net calls, it introduces several technical limitations. The reliance on external CNAP database queries for each off-net call results in increased latency and higher network load due to repeated HTTPS transactions. Additionally, the architecture lacks a caching mechanism, leading to redundant database queries for repeated calls from the same calling party.

[0142] Further, the existing system architecture (300) is limited to display name retrieval and does not support spam detection or identification of potentially fraudulent callers. As a result, the system is incapable of providing enhanced caller intelligence, such as spam indication or call blocking, thereby reducing user safety and awareness. Moreover, the direct interaction between telecom service providers for CNAP data retrieval introduces security and scalability challenges, as core network elements are required to communicate with external systems. The absence of a centralized or intermediate processing entity further increases system complexity and limits flexibility in managing caller information services. Additionally, the existing architecture does not provide mechanisms to selectively enable caller information services for specific users or groups of users. This lack of service-level control restricts the ability of network operators to perform phased deployments, targeted service offerings, or controlled feature rollouts.

[0143] FIG. 4 illustrates an exemplary system architecture (400) depicting an enhanced Mobile Number Portability (MNP) application (referred to as an MNP+ application) configured to provide the caller information for the off-net call scenario in the network (106), in accordance with an embodiment of the present disclosure. The present system architecture (400) overcomes the limitations of the system architecture (300) by introducing an MNP+ application (418) (analogous to the Mobile number portability module 208) as an intermediate processing entity deployed within a super core (408).

[0144] In the on-net call scenario, Internet Protocol Multimedia Subsystem (IMS) network architecture inherently supports the CNAP service, which has an option of including a ‘Display Name’ parameter in each subscriber’s profile. The customer's name, as provided in a Customer Application Form (CAF), can be utilized as the ‘Display Name’ parameter and provisioned in a Home Subscriber Server (HSS) (406) for each user.

[0145] During IMS (404) registration, the ‘Display Name’ is downloaded by the IMS network and appended to Session Initiation Protocol (SIP) requests during calls. The ‘Display Name’ is then displayed on the called party’s handset. Currently, because the‘Display Name’ parameter is not provisioned in the subscriber profile in the HSS, CNAP information is not displayed to the called party.

[0146] After provisioning the ‘Display Name’ for the end users in HSS (406), CNAP may be automatically displayed to each end-user on every on-net call, with no additional changes to the network configuration. As a result, the solution may be seamlessly rolled out across the country, requiring minimal configuration changes and zero capacity augmentation without compromising on call setup delay.

[0147] For the off-net call scenario, to minimize the challenges of capacity augmentation and call setup delays, the conventional MNP (416) is enhanced to MNP+ (418). The MNP+ application (418) may be deployed in super-core locations.

[0148] The system architecture (400) integrates multiple features into the MNP+ application (418) to efficiently handle CNAP requirements. For example, the MNP+ application (418) may support a display name and spam indication feature. In an embodiment, the MNP+ application (418) may map spam indications against a Mobile Station International Subscriber Directory Number (MSISDN) of spammers (e.g., unauthorized users or fraudsters).

[0149] In an embodiment, the MNP+ application (418) establishes a secured HTTP connection with other TSPs, reducing the number of touchpoints and isolating the core network from external operator networks. This secure connection allows the MNP+ application (418) to interact with CNAP databases (422) (CNAP-DB) maintained by TSPs, which store mappings of MSISDNs to customer display names.

[0150] In an embodiment, to minimize repetitive database queries and improve performance, the MNP+ application (418) employs a caching mechanism that retains mappings for a predefined duration, thus significantly reducing call setup delays.

[0151] In an embodiment, the MNP+ application (418) interacts with CNAP databases (422) maintained by TSPs, which store mappings of MSISDNs to customer display names. In an embodiment, the TSPs collaborate to standardize, secure and encrypted HTTP API for CNAP lookups, ensuring seamless and confidential data exchange.

[0152] In an embodiment, the MNP+ application (418) processes requests received from the CTAS (412) at a terminating leg of the call. Based on the received request parameters, the MNP+ application (418) determines whether to perform display name retrieval, spam detection, or both, and accordingly retrieves the required caller information. The retrieved caller information is then provided to the CTAS (412), which facilitates presentation of the information to the called party (424).

[0153] In an embodiment, the MNP+ application (418), integrated into the MNP architecture (414), is specifically designed to retrieve customer names from the CNAP-DB (422) and provide the information (customer names) to CTAS (412) in response to incoming queries. The microservice is equipped with point-to-point Point of Interconnection (POI) connectivity to CNAP-DBs (422) hosted by other TSPs, ensuring real-time and accurate data retrieval.

[0154] Referring to FIG. 4, the system architecture (400) includes a calling party (402) originating a call from the IMS (404) of the originating super core (404), which interacts with the HSS (406) to authenticate and process the call. The call is directed to the super core (408) serving the terminating user (called party (424)), which includes key functional modules for managing CNAP and spam detection.

[0155] In an embodiment, the super core (408) contains an enhanced MNP module (418), referred to as MNP+, which includes a cached database (420) (e.g., internal database) for storing frequently accessed CNAP data from other TSPs. This enhancement over the conventional MNP (416) reduces latency and network load by minimizing the number of HTTPS transactions required for off-net CNAP lookups. When an off-net call is received, the super core (408) performs an MNP dip to identify the originating TSP and determines whether the CNAP data is available in the cached database. If the data is unavailable, the system queries the CNAP database (422) hosted by the other TSP over secure channels using the HTTP API to fetch the required CNAP data.

[0156] The CNAP data, along with the CLI, is processed by the Call Session Control Function (SCSCF) (410) and the CTAS (MMTEL telephony application servers) (412) to ensure accurate CNAP presentation to the called party (424). By utilizing the cached database (420) and optimized CNAP lookup mechanisms, the architecture significantly improves the efficiency and reliability of CNAP services for both on-net and off-net scenarios.

[0157] In an embodiment, the increasing threat of spam calls necessitates network flexibility to either block these calls or alert users to potential spam. Therefore, to protect users from spam calls, the system architecture (400) further incorporates intelligent spam detection capabilities within the MNP+ application (418) and CTAS (412). Intelligent spam detection analyzes call patterns, CLI data, and historical call records to detect and flag potential spam calls. Upon identifying a spam call, the system can notify the called party (424) with a warning label or reject the call entirely based on predefined spam management policies.

[0158] To detect spam calls, intelligent spam detection may include an AI / ML unit and a network node enhancement unit. The AI / ML unit may utilize AI / ML algorithms to identify a list of spammers by analysing Call Detail Records (CDRs). The enhancements provided by the network node enhancement unit allow network nodes to act on the spammer list in real time, marking calls as spam.

[0159] In an embodiment, the AI / ML unit may be integrated with CTAS nodes (via ATOM) to retrieve call records for all calls within the network. The AI / ML unit may analyze the CDRs to identify traffic patterns associated with each user. Using the AI / ML algorithms, the system may learn individual calling behaviours and classify users as spammers.

[0160] The analysis is based on a combination of the following criteria:• Calling party numbers whose calls are repeatedly rejected by multiple unique called parties.• Calling party numbers where the volume of Mobile Originated (MO) calls significantly exceeds the number of Mobile Terminated (MT) calls.• Calling party numbers whose calls typically have very short durations.• Calling party numbers with a low call success rate.• Other relevant factors and anomalies identified by the AI / ML unit through machine learning.

[0161] The AI / ML unit may run this analysis at periodic intervals and generate a list of identified spam users. This list may then be uploaded to the MNP+ application for further action.

[0162] To support real-time spam call marking, the following enhancements are being implemented in MNP and CTAS nodes:

[0163] MNP Enhancement to MNP+: Conventional MNP application (416) may be upgraded to the MNP+ application (418), which may be deployed in super-core locations. The MNP+ application (418) may maintain the spammer list provided by the AI / ML unit and may continuously update the list with the latest data received from the AI / ML unit in real-time. This list may contain phone numbers suspected of being spam callers. Calls from these numbers may be allowed to terminate to the intended recipient. The AI / ML unit may remove calling party numbers, for example, commencing with ‘+91140’ and ‘+91160’ from a final grey spam list. Department of Telecommunications has assigned these number series to TSPs for business and financial use.

[0164] SIP Headers Support: The MNP+ application (418) may support headers on the SIP interface to exchange spam indications for calling users across the network.

[0165] Pre-configured Called User List: The MNP+ application (418) may support a pre-configured list of called users for whom spam services are enabled. This allows for a field trial with a limited set of called users before the spam service is rolled out to all users, enabling evaluation of the spam indication experience. After the trial, the spam service can be fully enabled for all users.

[0166] CTAS Integration with MNP+: The CTAS (412) may be enhanced to query MNP+ application (418) for all terminating-leg calls related to the calling party. If the calling party is listed in the spam database, the MNP+ application (418) may respond to the query with a spam indication.

[0167] Display Name Update: Upon receiving the spam indication, the CTAS (412) may update the "Display Name" to "Spam Calls," which may be displayed on the called party's handset when receiving the call.

[0168] Block Spam List: The MNP+ application (418) supports maintaining another list of user details in a “Block Spam List”. This list will include numbers confirmed as spam callers. A designated authority, such as the Lraud and Analytics Team, may verifyand authenticate the list. CTAS (412) may reject incoming calls from these numbers without forwarding the call to the intended recipient. Upon call rejection, CTAS may leverage existing vProbe capabilities to trigger an SMS notification to the Called Party, informing them of a “potential fraud attempt by the Calling Party.” RAFM / NOC / NPE will transmit the file to the MNP+ application (418) via NMS. It is important to note that each circle can maintain an independent blocklist.

[0169] Thus, the system architecture (400) overcomes the limitations of the existing system architecture (300) by introducing the MNP+ application (418) as an intermediate processing layer within the network (106). Unlike the existing architecture (300), which relies on direct and repetitive interactions between terminating telecom service providers and external CNAP databases, the present architecture (400) enables centralized processing of caller information within the MNP+ application (418). The incorporation of a caching mechanism reduces redundant database queries and minimizes call setup delays. Further, the MNP+ application (418) provides integrated support for both display name retrieval and spam detection, which are not addressed in the existing architecture. The use of secured communication interfaces limits direct exposure of core network elements to external systems, thereby improving security and scalability. Additionally, the system architecture (400) enables flexible service applicability, allowing caller information services to be selectively applied to specific users or universally across the network. Accordingly, the present system architecture (400) enhances efficiency, reduces latency, improves user awareness, and provides a scalable and secure framework for delivering caller information services in telecommunication networks.

[0170] FIG. 5 illustrates an exemplary process flow (500) for retrieving the caller information in the network (106), in accordance with an embodiment of the present disclosure. FIG. 5 is explained in conjunction with FIGS. 1, 2, 3, and 4.

[0171] At step 502, the MNP+ application (418) may receive a query (e.g., request) from the CTAS (412). In an embodiment, the request may be received to retrieve calling party information. The calling party information may include a display name and a spam indication associated with the calling party.

[0172] At step 504, the MNP+ application (418) may determine whether a service for the requested query is applicable to specific users. In an embodiment, the service applicable for specific users may refer to a situation where the spam detection and calling party information (e.g., display name and spam indication) are applied only to certain designated users. These designated users are identified based on specific criteria, such as the MSISDN of the called party indicated in the URI parameter (a first SIP parameter) ‘MSISDN of the Called Party parameter’. The MNP+ application (418) processes requests targeted at these specific users and retrieves the display name and spam indication accordingly. For example, if a particular organization wants to enable spam detection only for its employees or a specific group of users, the service will be tailored to that specific group only.

[0173] At step 506, the MNP+ application (418) may determine whether a service for the query is applicable to all users. In an embodiment, the service applicable for all users may refer to a scenario where the spam detection and calling party information retrieval are provided universally to all users of the network. In such case, the service is not restricted to any subset of users, and the MNP+ application (418) provides the display name and spam indication for all incoming requests. The determination of the display name and spam indication is based on the URI parameter ‘new MNP functionality parameter, which helps the MNP+ application (418) to decide the sequence of tasks to be executed. For example, a telecom provider may enable spam detection for all its subscribers as a general service to improve user safety.

[0174] At step 508, if the service is applicable for specific users, the MNP+ application (418) may provide the display name and spam indication based on the second SIP parameter (e.g., new MNP functionality parameter) value for those specific users as indicated in the MSISDN of the called party parameter.

[0175] At step 510, if the service is applicable to all users, the MNP+ application (418) may provide the display name (DN) and spam indication based on the new MNP functionality parameter value (a flag that helps the MNP+ application (418) to identify a sequence of tasks to be executed). In an embodiment, the MNP+ application (418) may retrieve the display name from the CNAP-DB (422).

[0176] In an embodiment, the MNP+ application (418) may store spam and block indications against the MSISDN of the calling party (e.g., spammers). The list may be curated and uploaded to the MNP+ application (418) by the AI / ML unit, leveraging AI / ML capabilities to analyze CTAS CDRs.

[0177] In an embodiment, the MNP+ application (418) may have secured HTTP connectivity with the CNAP-DB (422) hosted by TSPs to retrieve the display name. This retrieved information may be cached in the MNP+ application with a certain expiry time to reduce call setup delay. In an embodiment, the CNAP-DB (422) details are identified from the mapping present in its configuration against RN or operator +circle.

[0178] For the sake of explanation, consider an exemplary scenario of a calling party having MSISDN “+917012140496” initiating a call toward a called party having MSISDN “+91845213456”. The CTAS (412) sends a request to theMNP+ application (418) to retrieve caller information for the calling party. The request includes one or more URI parameters, including the MSISDN of the Called Party parameter and the new MNP functionality parameter.

[0179] In an embodiment, the MNP+ application (418) first determines whether the caller information service is enabled for specific users or for all users. For example, if the service is configured only for a predefined set of users and the MSISDN “+91845213456” of the called party matches an entry in the configured list, the MNP+ application proceeds with processing the request. Otherwise, the request may not be processed for caller information retrieval.

[0180] In an embodiment, upon determining that the service is applicable, the MNP+ application (418) evaluates the value of the new MNP functionality parameter to determine a type of caller information to be retrieved. For example, if the parameter indicates retrieval of only display name, the MNP+ application retrieves only the display name. If the parameter indicates spam detection, the MNP+ application performs spam detection. If the parameter indicates both operations, the MNP+ application performs both display name retrieval and spam detection.

[0181] In an embodiment, for display name retrieval, the MNP+ application queries the CNAP-DB (422) using the calling party MSISDN “+917012140496” to retrieve the display name. In parallel or sequentially, the MNP+ application checks whether the calling party MSISDN is present in a blacklist or greylist. If the MSISDN is present in the greylist, a spam indication is generated, and if present in the blacklist, a block indication may be generated.

[0182] In an embodiment, the retrieved caller information is transmitted to the CTAS (412), which appends the information to the signaling message for presentation at the called party device (424). The information may include the display name and / or a spam indication such as “Spam Call”.

[0183] In an embodiment, the retrieved caller information is stored in the internal cache (420) of the MNP+ application (418) with an associated expiry time, enabling faster retrieval for subsequent requests involving the same calling party.

[0184] The present disclosure provides the enhanced MNP application (e.g., MNP+ application (418)) to map spam indications against the MSISDN of spammers. Upon request from CTAS (412), the MNP+ application (418) checks whether the service is applicable for specific users or for all users, and when the service is applicable to all users, the MNP+ application (418) provides display name and spam indication based on new MNP functionality parameter value (flag which helps MNP+ to identify sequence of tasks to be executed). In case the service is applicable for specific users, the MNP+ application provides a display name and spam indication based on the new MNP functionality parameter value (as indicated in the MSISDN of the Called Party parameter). The MNP+ application integrates with the CNAP database (CNAP-DB) of TSPs using secure HTTP connectivity to retrieve display names and deliver this information to CTAS whenever a request is received. The retrieved information is cached in the MNP+ application with a certain expiry time to reduce call setup delay. In an embodiment, the CNAP-DB details are identified from the mapping present in its configuration against RN or operator +circle.

[0185] FIG. 6 illustrates a flow diagram of a method 600 for providing caller information in the network 106, in accordance with an embodiment of the present disclosure. FIG. 6 is explained in conjunction with FIGS. 1, 2, 3, 4 and 5.

[0186] At step 602, the mobile number portability module (208) may receive a request from the CTAS to obtain caller information associated with a calling party. In an embodiment, the caller information includes at least one of a display nameassociated with the calling party and a spam indication associated with the calling party. The request may include one or more Session Initiation Protocol (SIP) parameters embedded within a Uniform Resource Identifier (URI), which are used by the mobile number portability module (208) for processing the request.

[0187] At step 604, the mobile number portability module (208) determines a service applicability condition for at least one user based on the received request. In an embodiment, determining the service applicability condition includes identifying whether a caller information service is enabled for a predefined set of users or for a plurality of users in the network. The predefined set of users may correspond to a configured list of users stored in an internal memory, whereas the plurality of users may correspond to all users in the network.

[0188] In an embodiment, when the caller information service is enabled for the predefined set of users, the mobile number portability module (208) inspects a first SIP parameter from the request representing a called party identifier. The called party identifier may correspond to a Mobile Station International Subscriber Directory Number (MSISDN) of a called party. The mobile number portability module (208) compares the called party identifier with entries in the configured list of users maintained in the internal memory. When the called party identifier matches an entry in the configured list, the mobile number portability module (208) determines that the service is applicable for the request.

[0189] In an embodiment, when the caller information service is enabled for the plurality of users in the network, the mobile number portability module (208) bypasses inspection and comparison of the called party identifier and directly proceeds with processing the request.

[0190] At step 606, upon determining the service applicability condition, the mobile number portability module (208) retrieves the caller information from a database through a communication protocol based on one or more SIP parameters. In an embodiment, retrieving the caller information includes determining a type of caller information to be retrieved based on a second SIP parameter. The second SIP parameter represents a mobile number portability functionality parameter that indicates whether the mobile number portability module (208) retrieves at least one of the display name, the spam indication, or a combination thereof.

[0191] In an embodiment, when the second SIP parameter indicates display name retrieval, the mobile number portability module (208) queries a Caller Name Presentation Database (CNAP-DB) using the calling party identifier to obtain the display name. When the second SIP parameter indicates spam detection, the mobile number portability module (208) determines the spam indication by comparing the calling party identifier with entries in a blacklist or a greylist maintained within the mobile number portability module (208). When the second SIP parameter indicates both operations, the mobile number portability module (208) performs both display name retrieval and spam detection.

[0192] At step 608, the mobile number portability module (208) transmits the retrieved caller information to the CTAS. The transmitted caller information may include the display name and / or the spam indication, enabling the CTAS to present the identity of the calling party and provide spam alerts to a called party.

[0193] In an embodiment, the mobile number portability module (208) further stores the retrieved caller information in the internal memory for a predefined duration. The retrieved caller information is stored with an associated expiry time to reduce call setup delay. For subsequent requests received within the predefined duration, the mobile number portability module (208) retrieves the caller information from the internal memory instead of querying the database, thereby improving system efficiency and reducing latency.

[0001] FIG. 7 illustrates an exemplary computer system 700 in which or with which embodiments of the present disclosure may be implemented.

[0002] As shown in FIG. 7, the computer system 700 may include an external storage device 710, a bus 720, a main memory 730, a read-only memory 740, a mass storage device 750, communication port(s) 760, and a processor 770. A person skilled in the art will appreciate that the computer system 700 may include more than one processor and communication ports. The processor 770 may include various modules associated with embodiments of the present disclosure. The communication port(s) 760 may be any of an RS-232 port for use with a modem-based dialup connection, a 10 / 100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. The communication port(s) 760 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which the computer system 700 connects.

[0003] The main memory 730 may be a Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. The read-only memory 740 may be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or Basic Input / Output System (BIOS) instructions for the processor 770. The mass storage device 750 may be any current or future mass storage solution, which can be used to store information and / or instructions. Exemplary mass storage device 750 includes, but is not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and / or Firewire interfaces), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks.

[0004] The bus 720 communicatively couples the processor 770 with the other memory, storage, and communication blocks. The bus 720 may be, e.g. a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), Universal Serial Bus (USB), or the like, for connecting expansioncards, drives, and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor 770 to the computer system 700.

[0194] Optionally, operator and administrative interfaces, e.g. a display, keyboard, joystick, and a cursor control device, may also be coupled to the bus 720 to support direct operator interaction with the computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port(s) 760. Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system 700 limit the scope of the present disclosure.

[0195] The present disclosure provides significant technical advancements in telecommunication networks by introducing an enhanced mobile number portability module (MNP+) configured to provide caller information, including display name and spam indication, in an efficient, scalable, and secure manner. Unlike conventional systems that rely on direct and repetitive interactions with external Caller Name Presentation databases (CNAP-DBs), the present disclosure introduces an intermediate processing layer within the network that centralizes caller information processing, thereby reducing signaling overhead and minimizing call setup delay. The present disclosure further provides a technical improvement by enabling dynamic determination of service applicability based on configurable conditions, allowing caller information services to be selectively applied to a predefined set of users or universally to a plurality of users. This selective applicability introduces flexibility in service deployment, enabling phased rollouts and targeted service provisioning, which is not supported in existing architectures. The present disclosure further enhances system efficiency by utilizing one or more Session Initiation Protocol (SIP) parameters to dynamically determine a type of caller information to be retrieved, including display name, spam indication, or a combination thereof. This parameter-driven approach enables optimized processing by executing only required operations, thereby reducing unnecessary database queries and computational overhead.

[0196] The present disclosure further improves performance by incorporating a caching mechanism within the mobile number portability module to store retrieved caller information with an associated expiry time. The caching mechanism reduces repeated queries to external CNAP-DBs for frequently occurring requests, thereby significantly reducing latency and improving call setup time. The present disclosure also enhances user safety and network intelligence by integrating spam detection capabilities within the mobile number portability module. By maintaining and processing blacklist and greylist data, and optionally leveraging Artificial Intelligence / Machine Learning (AI / ML)-based analysis of call detail records, the system enables real-time identification of potential spam or fraudulent callers, which is not addressed in conventional CNAP-only solutions. Additionally, the present disclosure improves network security and scalability by limiting direct interaction between core network elements and external telecom service provider databases. Theuse of secured communication interfaces and centralized processing reduces exposure of network nodes, minimizes inter-network dependencies, and enhances overall system robustness.

[0197] The method and system of the present disclosure may be implemented in a number of ways. For example, the methods and systems of the present disclosure may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order for the steps of the method is for illustration only, and the steps of the method of the present disclosure are not limited to the order specifically described above unless specifically stated otherwise. Further, in some embodiments, the present disclosure may also be embodied as programs recorded in a recording medium, the programs including machine-readable instructions for implementing the methods according to the present disclosure. Thus, the present disclosure also covers a recording medium storing a program for executing the method according to the present disclosure.

[0198] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the disclosure and not as a limitation.ADVANTAGES OF THE PRESENT DISCLOSURE

[0199] Enhanced Spam Detection and Mitigation: The present disclosure integrates Artificial Intelligence (Al) capabilities to analyse call records and detect spam patterns based on factors like rejected call rates, call duration, and Mobile Originated (MO) vs. Mobile Terminated (MT) call volumes. The present disclosure enables real-time marking of spam calls to protect users from unwanted or fraudulent communication.

[0200] Efficient Calling Name Presentation (CNAP): The present disclosure introduces a CNAP service that displays the calling party’s name for both on-net and off-net calls without requiring third-party apps, improving customer trust and user experience by reducing reliance on external applications.

[0201] Secure and Isolated Network Integration: The present disclosure ensures that the CNAP and spam detection services remain isolated from the core telecom network, enhancing security and reducing vulnerabilities associated with external Telecom Service Provider (TSP) interaction.

[0202] Improved Data Accuracy and Efficiency: The present disclosure isolates Telco nodes from external TSP databases, ensuring the accuracy of display names and spam indicators while minimizing unnecessary data exchange.

[0203] Regulatory Compliance and Scalability: By adhering to standardized and secure protocols for data exchange, the present disclosure complies with regulatory requirements. Further, the present disclosure scalable design supports nationwidedeployments without additional hardware for the enhanced Mobile Number Portability (MNP+) application.

[0204] Reduced Call Setup Delays: The present disclosure achieves faster call setup times by minimizing the number of network touchpoints involved in the retrieval of the calling party information. Further, the present disclosure provides lower latency, simpler transport layer requirements, and is suitable for real-time communication scenarios.

[0205] Selective Service Applicability and Flexible Deployment: The present disclosure enables dynamic determination of caller information service applicability, allowing the service to be selectively applied to a predefined set of users or universally to a plurality of users. This capability enables controlled rollouts, targeted service provisioning, and flexible deployment strategies that are not supported in conventional architectures.

Claims

CLAIMSWe Claim:

1. A method (600) for providing caller information in a network (106), the method (600) comprising:receiving (602), by a mobile number portability module (208), a request from a Converged Telephony Application Server (CTAS) (412) to obtain caller information associated with a calling party;determining (604), by the mobile number portability module (208), a service applicability condition for at least one user based on the received request;upon determining the service applicability condition, retrieving (606), by the mobile number portability module (208), the caller information from a database through a communication protocol based on one or more Session Initiation Protocol (SIP) parameters; andtransmitting (608), by the mobile number portability module (208), the caller information to the CTAS (412).

2. The method (600) as claimed in claim 1 , wherein the caller information comprises at least one of: a display name associated with the calling party, and a spam indication associated with the calling party.

3. The method (600) as claimed in claim 1, wherein determining the service applicability condition comprises:identifying, by the mobile number portability module (208), whether a caller information service is enabled for at least one of: a predefined set of users, or a plurality of users in the network (106).

4. The method (600) as claimed in claim 3, wherein when the caller information service is enabled for the predefined set of users, the method (600) further comprises:inspecting, by the mobile number portability module (208), a first SIP parameter from the request representing a called party identifier;comparing, by the mobile number portability module (208), the called party identifier with a configured list of users maintained in an internal memory of the mobile number portability module (208); andwhen the called party identifier matches an entry in the configured list of users, retrieving, by the mobile number portability module (208), the caller information from the database.

5. The method (600) as claimed in claim 4, wherein retrieving the caller information comprises:determining, by the mobile number portability module (208), a type of caller information to be retrieved based on a second SIP parameter.

6. The method (600) as claimed in claim 5, wherein the second SIP parameter represents a mobile number portability functionality parameter indicating whether the mobile number portability module (208) retrieves at least one of: the display name associated with the calling party, the spam indication associated with the calling party, or a combination thereof.

7. The method (600) as claimed in claim 3, wherein when the caller information service is enabled for the plurality of users, the method (600) further comprises: retrieving, by the mobile number portability module (208), at least one of the display name, the spam indication, or a combination thereof from the database for the calling party based on the second SIP parameter.

8. The method (600) as claimed in claim 1, further comprising:storing, by the mobile number portability module (208), the retrieved caller information in the internal memory for a predefined duration, wherein the retrieved caller information is stored with an associated expiry time to reduce call setup delay.

9. A system (108) for providing caller information in a network (106), the system (108) comprising:a mobile number portability module (208) configured to:receive a request from a Converged Telephony Application Server (CTAS) (412) to obtain caller information associated with a calling party; determine a service applicability condition for at least one user based on the received request;upon determining the service applicability condition, retrieve the caller information from a database through a communication protocol based on one or more Session Initiation Protocol (SIP) parameters; andtransmit the caller information to the CTAS (412).

10. The system (108) as claimed in claim 9, wherein the caller information comprises at least one of: a display name associated with the calling party, and a spam indication associated with the calling party.

11. The system (108) as claimed in claim 9, wherein to determine the service applicability condition, the mobile number portability module (208) is configured to:identify whether a caller information service is enabled for at least one of: a predefined set of users, or a plurality of users in the network (106).

12. The system (108) as claimed in claim 11, wherein when the caller information service is enabled for the predefined set of users, the mobile number portability module (208) is configured to:inspect a first SIP parameter from the request representing a called party identifier;compare the called party identifier with a configured list of users maintained in an internal memory of the mobile number portability module (208); and when the called party identifier matches an entry in the configured list of users, retrieve the caller information from the database.

13. The system ( 108) as claimed in claim 12, wherein to retrieve the caller information, the mobile number portability module (208) is configured to:determine a type of caller information to be retrieved based on a second SIP parameter.

14. The system (108) as claimed in claim 13, wherein the second SIP parameter represents a mobile number portability functionality parameter indicating whether the mobile number portability module (208) retrieves at least one of: the display name associated with the calling party, the spam indication associated with the calling party, or a combination thereof.

15. The system (108) as claimed in claim 11, wherein when the caller information service is enabled for the plurality of users, the mobile number portability module (208) is configured to:retrieve at least one of the display name, the spam indication, or a combination thereof from the database for the calling party based on the second SIP parameter.

16. The system (108) as claimed in claim 9, wherein the mobile number portability module (208) is configured to:store the retrieved caller information in the internal memory for a predefined duration, wherein the retrieved caller information is stored with an associated expiry time to reduce call setup delay.

17. A computer program product comprising a non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to execute a method (600) for providing caller information in a network (106), the method (600) comprising:receiving (602), by a mobile number portability module (208), a request from a Converged Telephony Application Server (CTAS) (412) to obtain caller information associated with a calling party;determining (604), by the mobile number portability module (208), a service applicability condition for at least one user based on the received request;upon determining the service applicability condition, retrieving (606), by the mobile number portability module (208), the caller information from a database through a communication protocol based on one or more Session Initiation Protocol (SIP) parameters; andtransmitting (608), by the mobile number portability module (208), the caller information to the CTAS (412).

Images