Service for displaying name of calling party to called party

A display name service in the IMS network addresses the issue of unknown callers by appending and verifying the caller's name, improving answer rates and reducing missed calls.

WO2026115193A1PCT designated stage Publication Date: 2026-06-04ELISA OYJ

Patent Information

Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
ELISA OYJ
Filing Date
2025-06-25
Publication Date
2026-06-04

AI Technical Summary

Technical Problem

Mobile subscribers often avoid answering incoming calls if the caller's number is unknown, leading to missed calls and delayed communication, particularly for urgent information, causing frustration for public institutions and businesses.

Method used

Implementing a display name service in the IMS network to append and verify the calling party's name on the called party's terminal device, ensuring trustworthiness through a verification mechanism.

Benefits of technology

Enhances call answer rates by identifying the caller, reducing missed calls and delays, and ensuring reliable information display.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure FI2025050360_04062026_PF_FP_ABST
    Figure FI2025050360_04062026_PF_FP_ABST
Patent Text Reader

Abstract

According to an aspect, there is provided an application server for an Internet protocol multimedia subsystem, IMS, network. The application server maintains, in a database, a plurality of entries for a plurality of subscribers of a display name service. Each entry comprises a phone number and a display name of a subscriber. The application server receives, from a node of the IMS network, a session initiation request. The application server determines whether a calling party has subscribed to the display name service by searching the database based on a phone number of the calling party. In response to finding, from the database, an entry comprising the phone number, the application server appends the display name comprised in the entry to at least one part of the session initiation request to be displayed to the called party, and routes the session initiation request to the node of the IMS network.
Need to check novelty before this filing date? Find Prior Art

Description

SERVICE FOR DISPLAYING NAME OF CALLING PARTY TO CALLEDPARTYTECHNICAL FIELD

[0001] Various example embodiments relate to mobile communications.BACKGROUND

[0002] Some mobile subscribers have been observed to have an aversion for answering incoming calls if the phone number of the calling party is not shown upon call reception or the shown phone number is unknown to the mobile subscriber (e.g., it has not been stored to the contacts of the mobile subscriber). This behavior, though understandable in view of prevalence of aggressive telemarketing and scam calls, is frustrating from the point of view of, e.g., public institutions or agencies (e.g., a social insurance institution or the police), some companies (e.g., private healthcare companies), organizations, and professional groups whose phone number is most likely not known to the called party. Such missed calls may cause extra costs and delays for the calling party and delayed communication of urgent information (e.g., health-related information) and missed appointments and / or administrative deadlines.SUMMARY

[0003] According to some aspects, there is provided the subject-matter of the independent claims. Some embodiments are defined in the dependent claims. The scope of protection sought for various embodiments of the invention is set out by the independent claims.

[0004] According to a first further aspect, there is provided a serving call session control function, S-CSCF, for an Internet protocol multimedia subsystem, IMS, network. The S-CSCF comprises means for performing: receiving, from a node of the IMS network, a session initiation request for initiating a session between a calling party and a called party;executing initial filter criteria, IFC, triggers associated with the calling party and the called party based on the session initiation request, trigger points of the IFC triggers and priority of the IFC triggers, wherein the IFC triggers comprise at least one originating IFC trigger for the telephony application server and at least one originating IFC trigger for an application server hosting a display name service, the at least one originating IFC trigger for the telephony application server being defined to have a higher priority compared to the at least one originating IFC trigger for the application server hosting the display name service, the display name service being a service for appending a display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception, wherein the executing of the IFC triggers comprises:- based on firing of any of the at least one originating IFC trigger for the telephony application server, causing execution of one or more originating services by routing the session initiation request to the telephony application server;- based on firing of any of the at least one originating IFC trigger for the application server hosting the display name service, causing execution of the display name service by routing the session initiation request to the application server hosting the display name service; and following the executing of the IFC triggers, routing the session initiation request towards a terminal device of the called party.

[0005] According to an embodiment of said first further aspect, the IFC triggers comprise at least one terminating IFC trigger for the telephony application server having lower priority compared to the at least one originating IFC trigger for the application server hosting the display name service, and the means are further configured to perform: based on firing of any of the at least one terminating IFC trigger for the telephony application server, causing execution of one or more terminating services by routing the session initiation request to the telephony application server.

[0006] According to a second further aspect, there is provided a method comprising: maintaining, in a database, one or more identifiers of one or more trusted display name services; receiving, from a node of an IMS network or from a server of a private branch exchange, a session initiation request for initiating a session between a calling party and a called party;determining whether at least one part of the session initiation request to be displayed to the called party upon call reception comprises a display name of the calling party; in response to the display name being comprised in the session initiation request, determining whether the session initiation request comprises a header comprising an identifier of one of the one or more trusted display name services; and in response to the session initiation request comprising the header comprising the identifier of one of the one or more trusted display name services,- removing the header from the session initiation request, and- routing the session initiation request to a terminal device corresponding to the called party.

[0007] According to a third further aspect, there is provided a method comprising: receiving, from a node of an IMS network, a session initiation request for initiating a session between a calling party and a called party; executing initial filter criteria, IFC, triggers associated with the calling party and the called party based on the session initiation request, trigger points of the IFC triggers and priority of the IFC triggers, wherein the IFC triggers comprise at least one originating IFC trigger for the telephony application server and at least one originating IFC trigger for an application server hosting a display name service, the at least one originating IFC trigger for the telephony application server being defined to have a higher priority compared to the at least one originating IFC trigger for the application server hosting the display name service, the display name service being a service for appending a display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception, wherein the executing of the IFC triggers comprises:- based on firing of any of the at least one originating IFC trigger for the telephony application server, causing execution of one or more originating services by routing the session initiation request to the telephony application server;- based on firing of any of the at least one originating IFC trigger for the application server hosting the display name service, causing execution of the display name service by routing the session initiation request to the application server hosting the display name service; andfollowing the executing of the IFC triggers, routing the session initiation request towards a terminal device of the called party.

[0008] According to a fourth further aspect, there is provided a method comprising: receiving, from a terminal device, a session initiation request for initiating a session between a calling party and a called party, wherein at least one of the calling party or the called party is a subscriber of a PBX; determining whether a display name for the calling party is available to the PBX; and in response to the display name for the calling party being available,- appending the display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception, adding, to the session initiation request, a header comprising an identifier of the display name service, and- routing the session initiation request towards a terminal device of the called party.

[0009] According to a fifth further aspect, there is provided a computer program comprising instructions for performing the method according to the second, third or fourth further aspect.

[0010] According to a sixth further aspect, there is provided a non-transitory computer readable medium comprising program instructions stored thereon for performing according to the second, third or fourth further aspect or any of the aspects defined in the independent claims.

[0011] According to a seventh further aspect, there is provided a computer program comprising instructions for performing or a non-transitory computer readable medium comprising program instructions stored thereon for performing: receiving, from a node of an IMS network or from a server of a private branch exchange, a session initiation request for initiating a session between a calling party and a called party; determining whether at least one part of the session initiation request to be displayed to the called party upon call reception comprises a display name of the calling party;in response to the display name being comprised in the session initiation request, determining whether the session initiation request comprises a header comprising an identifier of one of one or more trusted display name services based on a database storing one or more identifiers of the one or more trusted display name services; and in response to the session initiation request comprising the header comprising the identifier of one of the one or more trusted display name services,- removing the header from the session initiation request, and- routing the session initiation request to a terminal device corresponding to the called party.

[0012] The embodiments, examples and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the invention.BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 illustrates an exemplary system according to embodiments;

[0014] FIGs. 2 and 3 illustrate processes according to embodiments carried out by an application server for an Internet protocol multimedia subsystem (IMS) network;

[0015] FIG. 4 illustrates a process according to embodiments carried out by a proxy call session control function (P-CSCF);

[0016] FIG. 5 illustrates signaling according to embodiments between terminal devices and elements of an IMS network;

[0017] FIG. 6 illustrates a process according to embodiments carried out by a private branch exchange; and

[0018] FIG. 7 illustrates an apparatus according to embodiments.DETAIEED DESCRIPTION OF SOME EMBODIMENTS

[0019] The following embodiments are only presented as examples. Although the specification may refer to “an”, “one”, or “some” embodiment(s) and / or example(s) inseveral locations of the text, this does not necessarily mean that each reference is made to the same embodiment(s) or example(s), or that a particular feature only applies to a single embodiment and / or example. The verbs “to comprise” and “to include” are used in this document as open limitations that neither exclude nor require the existence of also un-recited features. Single features of different embodiments and / or examples may also be combined to provide other embodiments and / or examples.

[0020] The term “terminal device” refers herein to a (typically portable) computing device comprising a subscriber identification module (SIM) and being capable of wireless communication in one or more wireless communication networks. A terminal device may be, for example, a mobile station (mobile phone), a smartphone, a laptop, a table computer, a mobile hotspot, an Internet of Things device, a smartwatch or a wearable device. The terminal device may also be called a user device, a user terminal or user equipment (UE).

[0021] The term “mobile operator” (or simply “operator”) refers herein to a mobile (tele)communications company or organization that provides mobile communications services for mobile device users (i.e., to terminal devices of users). The operator provides a SIM card to the customer who inserts it into the mobile device to gain access to said services. A mobile operator may be equally called a mobile phone operator, a wireless provider or a carrier. The mobile operator(s), in embodiments, may be a mobile network operator (MNO), that is, a mobile operator which owns the underlying network and spectrum assets required to run the provided service.

[0022] A general architecture of a system 100 according to embodiments is shown in FIG. 1. FIG. 1 illustrates a simplified system architecture only showing some elements and functional entities (namely, elements and functional entities relevant in view of embodiments). It is apparent to a person skilled in the art that the system may also comprise other functions and structures. At least some of the elements (e.g., some of elements 103 to 110) may be logical elements which may be implemented using a variety of different physical means (e.g., using one or more network nodes and / or computing devices).

[0023] The system 100 of FIG. 1 comprises an Internet protocol multimedia subsystem (IMS) network 110 and two terminal devices 101, 102 (e.g., smart phones) connected to the IMS network 110. The IMS network 110 may be an IMS network of a particular mobile operator (or telecom service provider) or an IMS network shared between multiple mobile operators (or telecom service providers). Specifically, FIG. 1 illustratessome control layer elements 103 to 106 and service / application layer elements 107 to 109 of the IMS network 110 which are relevant in view of embodiments. Any transport layer elements of the IMS network 110 are not shown in FIG. 1.

[0024] Each of the two terminal devices 101, 102 may be connected to the IMS network 110 via an access network (not shown in FIG. 1). The access network may be, for example, a cellular network or a Wi-Fi network. Here, the cellular network may be, e.g., a Fong Term Evolution (ETE) network, a 4G network, a 5G NR network or a 6G network. The connection for a terminal device 101, 102 may be enabled via session initiation protocol (SIP) client of the terminal device.

[0025] The control layer of the IMS network 110 is used for managing signaling and control of multimedia sessions. In the simplified presentation of FIG. 1, the control layer of the IMS network 110 comprises a call session control function (CSCF) 106 for processing SIP signaling packets in the IMS network 110. The CSCF 106 comprises at least two proxy call session control functions (P-CSCFs) 103, 104 and at least one serving call session control functions (S-CSCFs) 105.

[0026] A P-CSCF 103, 104 is a SIP proxy that is the first point of contact for the terminal device 101, 102 accessing the IMS network 110. Thus, the P-CSCF 103, 104 manages initial SIP requests received from the terminal devices 101, 102. It can be located either in the visited network (in full IMS networks) or in the home network (when the visited network is not IMS compliant yet). Each P-CSCF 103, 104 may be connected to at least one S-CSCF 105, 106. The P-CSCF may form a part of an access session border controller (SBC). In the illustrated example, the two P-CSCFs 103, 104 are connected both at least to the S-CSCF 105.

[0027] A S-CSCF 105 is the central node of the SIP signaling plane acting as a SIP server. The S-CSCF 105 may be configured to manage session control, authentication, and other core functions related to service delivery. The S-CSCF 105 may be connected (via Diameter Cx and Dx interfaces) to a home subscriber server (HSS) (now shown in FIG. 1) for enabling, e.g., downloading of subscriber profile information and / or uploading user-to- S-CSCF associations. Moreover, the S-CSCF 105 is connected to one or more application servers 107 of the IMS network 110. The S-CSCF 105 is configured to evaluate various initial filter criteria (IFC) triggers and, based on each fired IFC trigger, invoke an associated application server 107.

[0028] The one or more application servers 107 are configured to host various services (e.g., voice calling, video calling and / or messaging). Said services may, in general, comprise, e.g., at least voice over X (VoX) services and / or video calling. The VoX services may comprise, for example, one or more voice over LTE (VoLTE) services, one or more voice over (5G) NR (VoNR) services and / or one or more voice over Wi-FI (VoWiFi) services. Each or at least some of the one or more application servers 107 may be associated with a respective structured query language (SQL) backend. Said one or more services (and, thus, said one or more application servers 107) may be provided by the one or more mobile operators associated with the IMS network and / or one or more third-party vendors.

[0029] The one or more application servers 107 may comprise a telephony application server (TAS) 108. In general, the TAS 108 may host various telephony services such as voice (e.g., via VoLTE or VoNR), video, and / or messaging over IP -based networks. In embodiments, the TAS 108 may be configured to execute one or more originating services of a calling party of a call and / or one or more terminating services of a called party of the call. The one or more originating services may comprise, for example, a call blocking service (for enabling blocking of calls) and / or a calling line identification restriction service (for enabling preventing of displaying of the phone number of the calling party to the called party upon call reception). The one or more terminating services may comprise, for example, an incoming call blocking service and / or a call transfer service.

[0030] The system 100 of FIG. 1 also comprises a private branch exchange 111 to which the terminal devices 101, 102 (e.g., smart phones) may be connected. According to a general definition, a PBX 111 is a telephone exchange or switching system that serves a particular private entity (e.g., a private organization or company) or a particular set of private entities. In embodiments, the one or more private entities may comprise (or consist of) a one or more mobile operators. The PBX is used for managing internal and external communication of said private entity (e.g., communication involving one or two or more than two subscribers of a mobile operator). The PBX 111 may be connected to the IMS network 110 and / or the public switched telephone network. The PBX 111 may be or comprise, in particular, an Internet protocol (IP) PBX (sometimes called VoIP PBX). An IP PBX is a PBX which uses Internet protocol to handle voice traffic (that is, it employs Voice over IP, VoIP). The IP PBX may comprise, for example, a call server (or a PBX core) which acts as the central processing unit of the IP PBX, a database server for storing, e.g., system information, subscriber information, extension number and / or call routing rules and one ormore interfaces and / or gateways for enabling connections to, e.g., operator networks and / or the Internet. Here, the operator networks may comprise, e.g., one or more IMS networks of one or more mobile operators, one or more public switched telephone networks (PSTNs) of one or more mobile operators and / or one or more public land mobile networks (PLMNs) of one or more mobile operators. The call server may, e.g., manage call setup, routing, and termination and handle signaling protocols such as SIP for call control. The (IP) PBX 111 may be hosted on-premises of the private entity or in a computing cloud.

[0031] Some embodiments may involve only one of the IMS network 110 or the PBX 111.

[0032] Due to, e.g., prevalence of aggressive telemarketing and scam calls, some mobile subscribers have been observed to have an aversion for answering incoming calls if the phone number of the calling party is not shown upon call reception or the shown phone number is unknown to the mobile subscriber. This behavior is frustrating from the point of view of, e.g., public institutions or agencies (e.g., a social insurance institution, emergency services, or the police), businesses (e.g., a private healthcare provider), organizations and professional groups and other parties whose phone number is most likely not known to the called party. Such missed calls may cause extra costs and delays for the calling party and delayed communication of urgent information (e.g., health-related information) and missed appointments and / or administrative deadlines. To solve this problem, the called party should be enabled to view, via the display of their terminal device, the name of the calling party (optionally along with the phone number) upon call reception. It is expected that the called party is more likely to answer the call if the calling party is identified upon call reception. Ideally, it should also be ensured that the displayed information is trustworthy. The calling party should be enabled to decide which name is sent and displayed to the called party.

[0033] To implement such a solution, the one or more application servers 107 of the IMS network 110 comprise, in some embodiments, an application server 109 for hosting a display name service. This application server 109 may be called display name application server (DN AS). The DN AS 109 may be a SIP server. The display name service hosted by the DN AS 109 is a service which enables appending a display name (to be displayed to a called person upon call reception) to a session initiation request, as will be described in detail in connection with FIGs. 2 to 3 & 5. Additionally, a verification functionality for verifying that the display name service used for adding the display name to the session initiationrequest is trustworthy may be implemented in the P-CSCFs 103, 104, as will be described in connection with FIGs. 4 & 5. Alternatively (or additionally), the display name service and the verification functionality may be hosted by the PBX 111 or, respectively, by the PBX and an edge node of an operator network, as will be described in detail in connection with FIG. 6.

[0034] FIG. 2 illustrates a process according to embodiments for implementing a display name service. The process of FIG. 2 may be implemented using an application server located in an IMS network of a mobile operator (or multiple mobile operators). The application server may be an application server provided by a mobile operator of the IMS network or by a third-party vendor. The application server may be a SIP application server (providing, e.g., VoX services such as VoLTE and / or VoNR services). The application server may correspond to the DN AS 109 of FIG. 1.

[0035] Referring to FIG. 2, the application server is initially assumed to maintain, in block 201, in a database (being an external or internal database), a plurality of entries for a (respective) plurality of subscribers of a display name service. Each of the plurality of entries comprises at least a phone number of a subscriber of the display name service and a display name of the subscriber. The phone number may be stored, e.g., in an E. 164 format. The purpose of the display name service is enabling displaying of information (i.e., the display name) relating to the calling party to a called party (via a display of a terminal device of the called party) upon call reception. The display name is a name that the subscriber (of the display name service) has selected for display at a terminal device of the called party upon receiving a call from a phone number of subscriber. The display name may be the (actual) name of the subscriber. If the subscriber is person, the display name may comprise the (actual) name of the subscriber and / or a name of a business (e.g., a company or a corporation), an organization or a public institution or agency to which the person belongs. In general, the subscriber may be, for example, a private person, a business (e.g., a company or a corporation), an organization or a public institution or agency.

[0036] In some alternative embodiments, the application server may be initially assumed to maintain, in block 201, in a database (being an external or internal database), a plurality of entries for a (respective) plurality of subscribers of a plurality of (different) display name services.

[0037] Multiple different phone numbers in the plurality of entries may have the same display name. For example, multiple phone numbers associated with a business, an organization or a public institution or agency may be associated with the same display name (e.g., the name of said business, organization or public institution or agency). Alternatively, at least some of the plurality of entries may comprise a plurality of phone numbers associated with the subscriber and the display name of the subscriber. For example, if the subscriber is a business, an entry in the database for that business subscriber may comprise phone numbers of multiple employees of that company and a display name corresponding to the name of the business.

[0038] The subscribers of the display name service may be, for example, subscribers of an existing VoX service who have elected to adopt also the display name service (in addition to the base VoX service). An entry may be added to the database each time a user subscribes to the display name service. Correspondingly, when a user no longer wishes to use the display name service, the entry associated with said user should be removed from the database.

[0039] In some embodiments, each entry in the database may be defined to have the fields indicated in the Table below:Here, “ID” is an identifier, “From number” is a phone number of calling party, “int(l 1)” is indicates an integer of size 11, “varchar(16)” indicates a variable-length string of size 16, PRI is a primary key (i.e., a column in the database table that uniquely identifies each record (or row) in that table), “Null” column indicates whether a value of a field may be left undefined (i.e., given a null value) when a new entry is created, “Default” column indicates the default value of each row, “auto increment” is a property applied to a column thatautomatically generates a unique sequential number for each new row inserted into the table. The sizes of the fields are exemplary. In some embodiments, the “Extra” column may be omitted.

[0040] In some embodiments, the application server may host one or more further services, in addition to said display name service.

[0041] In some embodiments, the IMS network may comprise multiple application server instances with separate backends. In such embodiments, database replication (e.g., Galera Cluster) may be employed for maintaining the multiple application server instances (i.e., for keeping the multiple application server instances in sync). If database replication is not used, any database provisioning actions should be carried out for each cluster separately.

[0042] The application server receives, in block 202, from a node (e.g., an S-CSCF) of the IMS network, a session initiation request for initiating a (voice) session between a calling party and a called party. The session initiation request may be a SIP request. For example, the session initiation request may be an INVITE message or other (SIP) message for initiating a multimedia session between users. The application server (and said node of the IMS network) may be located, e.g., at an originating side of the call (i.e., an originating side of the session initiation request).

[0043] The session initiation request (e.g., the INVITE message) may originate from a terminal device of a calling party (e.g., the terminal device 101 of FIG. 1). In other words, the session initiation request may be received from the terminal device of the calling party via various nodes of the IMS networks. Here said various nodes may comprise at least a P- CSCF and an S-CSCF.

[0044] For enabling routing of the session initiation request, the received session initiation request may comprise, in its topmost route header or in other routing data field, application server address information (equally called DN AS address information). This information may have been added to the session initiation request by the S-CSCF. For example, the application server address information may comprise an address of the application server. The address may be a (fully qualified) domain name. Optionally, the application server address information may also comprise an identifier of the display name service (i.e., a special secret code associated with the display name service) and / or other service-specific information. In other words, the application server address information maybe used for identifying to which service (of one or more services hosted by the application server) the session initiation request relates. Here, the identifier may be any information which may be used for (uniquely) identifying the display name service. Ideally, the identifier of the display name service should be kept secret so that it may be used dependably for verifying (e.g., at the P-CSCF closest to the called party) which service was used for appending the display name to a session initiation request, as will be described in connection with FIG. 4.

[0045] The session initiation request may comprise at least a phone number of the calling party (i.e., the so-called A number). The phone number may be provided, e.g., in an E.164 format. For example, the phone number may be comprised in a From header and / or a P-Asserted-Identity (PAI) header of the session initiation request (being, e.g., the INVITE message). Specifically, the From header and / or the P-Asserted-Identity header may comprise a SIP uniform resource identifier (URI) which may comprise the phone number (in the E.164 format).

[0046] The application server determines, in block 203, whether the calling party has subscribed to the display name service by searching the database based on the phone number of the calling party comprised in the session initiation request. In other words, the application server searches the database based on the phone number of calling party to try to identify an entry containing said phone number.

[0047] In response to (or based on) finding, from the database, an entry comprising the phone number of the calling party in block 204, the application server performs the actions of blocks 205 to 207. Namely, the application server appends, in block 205, the display name comprised in the entry (i.e., the display name of the calling party) to at least one part of the session initiation request to be displayed to the called party upon call reception. Said at least one part of the session initiation request appended in block 205 may comprise the From header of the session initiation request or a part thereof to be displayed to the called user and / or the PAI header of the session initiation request or a part thereof to be displayed to the called user. It should be noted that, in some instances, the From header and / or the PAI header may comprise certain elements which are not displayed to a user. These elements may comprise, for example, a tag parameter (for uniquely identifying the call leg from the sender’s side), URI parameters (e.g., for routing or session handling) and / or URI domain.

[0048] Moreover, the application server adds, in block 206, to the session initiation request, a header (i.e., a SIP header) comprising an identifier of the display name service. The added header may be a proprietary header. The added header may be an X-header (equally called an X-SIP header). According to a general definition, an X-header is a custom header used in SIP requests to carry specific information that is not part of the official SIP protocol specification.

[0049] In some alternative embodiments, actions pertaining to block 206 may precede actions pertaining to block 205.

[0050] Then, the application server routes, in block 207, the appended session initiation request (e.g., the INVITE message) back to the node (e.g., the S-CSCF) of the IMS network. Said node may subsequently forward the appended session initiation request further towards a terminal device of the called party. Following the routing of the session initiation request back to the node (e.g., the S-CSCF) of the IMS network in block 207 and subsequent routing further to a P-CSCF associated with the called party, the identifier of the display name service comprised in the added header may be used by the P-CSCF for verifying that the display name has been added to the session initiation request using a known trusted display name service. This functionality will be described in detail in connection with FIG. 4

[0051] In response to (or based on) failing to find, from the database, an entry comprising the phone number of the calling party in block 204, the application server routes, in block 208, the session initiation request back to the node (e.g., the S-CSCF) of the IMS network. Said node may subsequently forward the session initiation request further towards the terminal device of the called party.

[0052] In some embodiments, the routing in block 207 and / or block 208 may comprise removing the topmost route header from the session initiation request and, thereafter, sending the session initiation request back to the node of the IMS network. As described above, the topmost route header may comprise application server address information.

[0053] In some embodiments, the operation of the application server in blocks 202 to 208 may be carried out after the execution of one or more originating services of the calling party at a telephony application server (TAS) for the same session initiation request. The one or more originating services may comprise, for example, a call blocking service and / or acalling line identification restriction service. This order of execution may be considered preferable as the one or more originating services may end up blocking the call or routing the traffic out of the IMS network (e.g., in case SIP with encapsulated integrated services digital network, ISDN, user part, SIP-I, is used). In some embodiments, one of the one or more originating services may also cause appending of a display name to the session initiation request. This functionality is discussed in further detail in connection with FIG. 5.

[0054] In some alternative embodiments, block 206 may be omitted.

[0055] In some alternative embodiments, the process of FIG. 2 may be implemented at an application server located at a terminating side of the call (i.e., a terminating side of the session initiation request received in block 202), as opposed to at an originating side of the call. The process of FIG. 2 as discussed above may apply, mutatis mutandis, also in this case. Thus, in these embodiments, terminated calls (i.e., session initiation requests at terminating side) of all or at least certain subscribers are routed via an (IMS) application server. Said certain subscribers may comprise subscribers of one or more display name services on which the application server is maintaining subscriber information. Similar to as described above, the application server compares the phone number of the calling party (i.e., the A-number) against entries of a database (which may contain subscriber information relating to one or more display name services) and, if match is found, it adds the display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception and further adds a header comprising at least an identifier of the display name service to the session initiation request. When the call is routed forward, it goes (similar to all other calls) through separate SIP session border controller (SBC) element. In SBC (or in the P-CSCF comprised in or associated with the SBC), there may be defined one or more rules for preventing the added (display name) header from going through with the exception of calls identifying a trusted display name service, as will be described below in detail.

[0056] In other words, in some embodiments, the application server (executing the process of FIG. 2) and the node of the IMS network (e.g., the S-CSCF) associated with blocks 202, 208 of FIG. 2 are originating side entities for the received session initiation request (i.e., from the point of view of the received session initiation request) while, in other embodiments, said application server and node of the IMS network are terminating side entities for the received session initiation request. It should be noted that, in the secondalternative, the calling party does not necessarily have to be registered with the IMS network as the display name service is a service associated with the called party (not with the calling party).

[0057] FIG. 3 illustrates another process according to embodiments for implementing a display name service. Similar to FIG. 2, the process of FIG. 3 may be implemented using an application server located in an IMS network of a mobile operator (or multiple mobile operators). The application server may be an application server provided by a mobile operator of the IMS network or by a third-party vendor. The application server may correspond to the DN AS 109 of FIG. 1. The application server may be a SIP application server (providing, e.g., VoX services such as VoLTE and / or VoNR services).

[0058] The process of FIG. 3 corresponds to another implementation of the process of FIG. 2. Any of the features and definitions discussed in connection with FIG. 2 may apply, mutatis mutandis, also for the process of FIG. 3. Namely, blocks 301, 302, 305 to 310 may correspond fully to blocks 201 to 208 of FIG. 2. Thus, said blocks 301, 302, 305 to 310 are not discussed in detail in the following.

[0059] Similar to FIG. 2, it is assumed that the application server maintains, in block 301 , in a database (being an external or internal database), a plurality of entries for a plurality of subscribers of a display name service, where each of the plurality of entries comprises a phone number of a subscriber of the display name service and a display name of the subscriber. Following reception of a session initiation request (being, e.g., an INVITE message) for initiating a (voice) session between a calling party and a called party from a node (e.g., an S-CSCF) of the IMS network in block 302, the application server does not directly check whether the calling party has subscribed to the display name service. Instead, the application server determines, in block 303, whether routing information comprised in the session initiation request identifies the display name service. In practice, the determination of block 303 may comprise determining whether a topmost route header of the session initiation request comprises an identifier (or a service tag) of the display name service. The topmost route header is, in general, used to indicate the next hop that the associated SIP request should follow as it is routed through a SIP network. As was described in connection with FIG. 2, the S-CSCF may add said topmost route header to the session initiation request before sending the session initiation request to the application server. In general, said topmost route header may comprise application server address informationcomprising an address (e.g., a domain name) of the application server and optionally the identifier of the display name service.

[0060] In response to (or based on) the routing information of the session initiation request identifying the display name service in block 304, the application server moves on to determine, in block 305, whether the calling party has subscribed to the display name service by searching the database based on the phone number of the calling party, similar to block 203 of FIG. 2. In response to (or based on) the routing information of the session initiation request failing to identify the display name service in block 304, the application server may route, in block 310, the session initiation request back to the node (e.g., the S- CSCF) of the IMS network, similar to block 208 of FIG. 2.

[0061] As mentioned above, the actions of blocks 305 to 310 may be carried out as described in connection with blocks 203 to 208 of FIG.2.

[0062] Similar to as described above for the process of FIG. 2, the process of FIG. 3 may be implemented at the originating side or terminating side of a call.

[0063] As was described above, following the processing of the session initiation request at the application server, the session initiation request may be routed from the application server via an S-CSCF to a P-CSCF associated with the called party. The P-CSCF may, then, evaluate whether the session initiation request comprising the display name of the calling party can be trusted. FIG. 4 illustrates a process according to embodiments for implementing this verification functionality. Thus, the process of FIG. 4 may be implemented using a P-CSCF located in an IMS network of a mobile operator. The P-CSCF may be the P-CSCF closest to the terminal device of the called party. The P-CSCF server may correspond to a P-CSCF 104 of FIG. 1 with the terminal device 102 being the terminal device of the called party and the terminal device 101 being the terminal device of the calling party. The P-CSCF may form a part of an access SBC.

[0064] The P-CSCF is assumed to maintain, in a database (being an external or internal database), in block 401, one or more identifiers of one or more trusted display name services. These different trusted display name services may be associated, for example, with different mobile operators and / or different third-party vendors providing services at the IMS network. Here, an identifier of a trusted display name service may be defined as anyinformation suitable for (uniquely) identifying the display name service which is known to be trustworthy.

[0065] The P-CSCF receives, in block 402, from a node of the IMS network, a session initiation request (e.g., an INVITE message) for initiating a (voice) session between a calling party and a called party. The node of the IMS network may be an S-CSCF. The session initiation request may or may have not been appended with the display name of the calling party in an application server hosting the display name service, as described in connection with FIG. 2 and / or 3. In this particular embodiment, it is assumed that the header adding functionality of block 206 of FIG. 2 or block 308 of FIG. 3 has been implemented at least in one or more application servers hosting the one or more trusted display name services.

[0066] The P-CSCF determines, in block 403, whether at least one part of the session initiation request to be displayed to the called party upon call reception comprises a display name of the calling party. Said at least one part of the session initiation request to be displayed to the called party upon call reception may comprise (or consist of) a From header of the session initiation request (or a part thereof) and / or a PAI header of the session initiation request (or a part thereof). The P-CSCF may check, in block 403, both From and PAI headers or (pre-defined) one of them.

[0067] In response to (or based on) said at least one part of the session initiation request to be displayed to the called party upon call reception failing to comprise any display name of the calling party in block 404, the application server routes, in block 408, the session initiation request to the terminal device corresponding to the called party. Thus, in this case, the routing of the session initiation request may be carried out in a conventional manner.

[0068] In response to the display name being comprised in the session initiation request in block 404, the P-CSCF determines, in block 405, whether the session initiation request comprises a header which comprises an identifier of one of the one or more trusted display name services. In other words, the P-CSCF determines whether the session initiation request comprises any header comprising an identifier of any display name service and, if such a header is found, searches the database to find a match for the identifier included in the header. As was described in connection with FIG. 3, the application server may have added such a header to the session initiation request, in addition to the display name, for enabling identification of the used display name service.

[0069] In response to (or based on) the session initiation request comprising the header comprising the identifier of one of the one or more trusted display name services in block 406, the application server removes, in block 407, the header from the session initiation request, and routes, in block 408, the session initiation request to a terminal device corresponding to the called party. Subsequently, the display name of the calling party will be displayed, upon call reception, to the called party via a display of the terminal device of the called party.

[0070] In response to (or based on) the session initiation request failing to comprise the header comprising the identifier of one of the one or more trusted display name services in block 406, the application server removes, in block 409, the display name from the session initiation request and routes, in block 408, the session initiation request to the terminal device corresponding to the called party. The application server may remove the display name from the From header and / or the PAI header in block 409. Thus, in this case, no display name of the calling party will be displayed to the called party upon call reception as the display name couldn’t be verified as being trustworthy. This could enable, for example, preventing a scammer from impersonating a representative of a business (e.g., a bank) or a public institution or agency (e.g., the police).

[0071] The process of FIG. 4 may apply irrespective of whether the process of FIG. 2 or 3 is (or was) implemented at the originating or terminating side of the call. Moreover, the process of FIG. 4 may be implemented either at the originating side or the terminating side of the call. In other words, in some embodiments, the P-CSCF (executing the process of FIG. 4) and the node (e.g., the S-CSCF) of the IMS network associated with block 402 are originating side entities for the received session initiation request (i.e., from the point of view of the received session initiation request), while, in other embodiments, said P-CSCF and node of the IMS network are terminating side entities for the received session initiation request.

[0072] FIG. 5 illustrates signaling between two terminal devices (called terminal device A and terminal device B) and various entities of an IMS network for connecting a voice call or session (e.g., a VoX call) while using the display name service to enable displaying of name of the calling party. Namely, said various entities comprise a first P- CSCF (being the closest P-CSCF to terminal device A), a second P-CSCF (being the closest P-CSCF to terminal device B), an S-CSCF, a TAS and a DN AS. Said entities of FIG. 5 maycorrespond to corresponding entities of FIG. 1. In FIG. 5, it is assumed that the process of FIG. 2 or 3 is implemented at the originating side of the call (though, in other embodiments, said process may be implemented, instead, at the terminating side).

[0073] Referring to FIG. 5, the terminal device A initially triggers, via message 501, voice call or session from the terminal device A (i.e., the terminal device of the calling party) to the terminal device (i.e., the terminal device of the called party). Specifically, the terminal device A transmits a session initiation request (or equally a SIP request) 501 for initiating a (voice) session between the terminal devices A & B to the first P-CSCF, which is the closest P-CSCF to the terminal device A. In FIG. 5, the session initiation request 501 as well as the subsequent session initiation requests 502, 503, 504, 506, 507, 509, 510, 512, 513, 515 are specifically INVITE messages.

[0074] The first P-CSCF receives the session initiation request 501 and routes it, in message 502, to the S-CSCF. The S-CSCF receives the session initiation request transmitted by the first P-CSCF and starts to execute, in block 503, initial filter criteria (IFC) triggers based on the session initiation request, trigger points of the IFC triggers (i.e., rules according to which the IFC triggers are fired) and priorities of the IFC triggers. According to a general definition, an IFC trigger is a set of predefined conditions (or trigger points) in an IMS network that, when satisfied, causes the S-CSCF to route the session initiation requests (or SIP requests) to specific application servers for further processing (e.g., for call blocking or call forwarding). The trigger points may depend on various factors such as SIP method used, an identity of the user and / or or session parameters. The priorities of the IFC triggers define in which order the IFC triggers are evaluated.

[0075] The IFC triggers evaluated in block 503 comprise both originating IFC triggers (i.e., triggers applied when the user is initiating a call or session) and one or more terminating IFC triggers (i.e., triggers applied when the user is receiving a call or session). The originating IFC triggers comprise at least one IFC trigger for the DN AS and at least one originating IFC trigger for the TAS. The one or more terminating IFC triggers comprise at least one IFC trigger for the TAS. At least some of the IFC triggers may be shared IFC triggers, i.e., IFC triggers shared among multiple subscribers. In some alternative embodiments, no terminating IFC triggers may be defined.

[0076] The IFC for a user (e.g., a called or calling party) may be maintained in the HSS, where the IFC comprise the IFC triggers and the associated trigger points. Thus, theS-CSCF may retrieve the IFCs of the calling and called parties from the HSS, before starting the execution of the IFC triggers in block 503.

[0077] The at least one originating IFC trigger for the TAS may be defined to have the highest priority, that is, higher priority compared to the at least one IFC trigger for the DN AS and the at least one terminating IFC trigger for the TAS. Thus, initially based on firing of any of the at least one originating IFC trigger for TAS, the S-CSCF routes the session initiation request, in message 504, to the TAS for triggering execution of one or more originating services of the calling party. In other words, at least one originating IFC trigger is triggered so as to cause the routing of the session initiation request in message 504. The TAS executes, in block 505, the one or more originating services. The one or more originating services may comprise, for example, a call blocking service (for enabling blocking of calls) and / or a calling line identification restriction service (for enabling preventing of displaying of the phone number of the calling party to the called party upon call reception).

[0078] In the example scenario of FIG. 5, it is assumed that the call is not blocked and is not routed to another network as a result of the execution of the one or more originating services in block 505. However, in some cases, either of these may occur. Therefore, triggering of execution of the one or more originating services before triggering execution of, e.g., the display name service is beneficial as it enables reduction of unnecessary processing at the IMS network or specifically at the DN AS. In other words, the priority of the at least one originating IFC trigger for the TAS should, preferably, be higher than at least the priority of the at least one originating IFC trigger for the DN AS (and optionally also higher than the priority of the at least one terminating IFC trigger for the TAS).

[0079] Following the execution of the one or more originating services of the calling party in block 505, the TAS routes the session initiation request, in message 506, back to the S-CSCF.

[0080] After reception of the session initiation request from the TAS, based on firing of any of the at least one originating IFC trigger for the DN AS, the S-CSCF routes the session initiation request, in message 507, to the DN AS for triggering execution of the display name service. The at least one originating IFC trigger may have higher priority than the at least one terminating IFC trigger for the TAS. The at least one originating IFC trigger for the DN AS may be defined only for subscribers of the display name service.

[0081] The S-CSCF may add the DN AS address information to the session initiation request 507 before routing, as described in connection with FIG. 2. For example, the DN AS address information may comprise an address of the DN AS. The address may be a (fully qualified) domain name. Optionally, the DN AS address information may also comprise an identifier of the display name service and / or other service-specific information.

[0082] Thereafter, the DN AS executes, in block 508, the display name service and routes the session initiation request, in message 509, back to the S-CSCF. Execution of elements 508, 509 may correspond to successful execution of the process of FIG. 2 or 3. Thus, the transmitted session initiation request of message 509 may comprise both a display name of the calling party (e.g., in a From and / or PAI header) and an identifier of the display name service (e.g., in an X-header).

[0083] After reception of the session initiation request from the DN AS, based on firing of any of the at least one terminating IFC trigger for the TAS, the S-CSCF routes the session initiation request, in message 510, to the TAS for triggering execution of one or more terminating services of the called party. The TAS executes, in block 511, the one or more terminating services. The one or more terminating services may comprise, for example, an incoming call blocking service and / or a call transfer service. In FIG. 5, it is assumed that the call is neither blocked nor transferred as a result of the execution of the one or more terminating services. Following the execution of the one or more terminating services of the called party in block 511, the TAS routes the session initiation request, in message 512, back to the S-CSCF.

[0084] After reception of the session initiation request from the TAS a second time, the execution of the IFC triggers may be considered completed and, thus, the S-CSCF routes the session initiation request, in message 513, towards the terminal device B (namely, to the second P-CSCF). Said routing may be performed via one or more network elements not shown in FIG. 5. Said one or more network elements may comprise at least a second S- CSCF (possibly also, e.g., an interrogating-CSCF, I-CSCF). Upon receiving the session initiation request, the second PCSCF verifies, in block 514, that the received session initiation request has been appended for including the display name using one of one or more trusted display name services known to the second P-CSCF. This verification is based on the identifier of the display name service included in the session initiation request. Based on the verification, the second P-CSCF transmits the session initiation request, in message 515,to the terminal device B. Execution of elements 514, 515 may correspond to the process ofFIG. 4.

[0085] Upon reception of the session initiation request from the second P-CSCF, the terminal device B shows, in block 516, the display name of the calling party on a screen of the terminal device B. Additionally, the phone number of the calling party may also be shown (unless it has been hidden as a part of the execution of the one or more originating services). In general, the terminal device B may be configured to display on the screen of the terminal device B any information contained in the From and / or PAI header. The terminal device B may carry out also any conventional actions relating to establishing a voice session between the calling and called parties.

[0086] As was described in connection with FIG. 1, a terminal device may be connected to a private branch exchange (PBX), instead of or in addition to an IMS network. The PBX may be an IP PBX. The user of the terminal device may be a subscriber of the PBX. In some alternative embodiments, the display name service described in connection with any of the above embodiments may be implemented in the PBX, instead of or in addition to the IMS network. The display name service may be provided by a mobile operator associated with the PBX or a third-party vendor. FIG. 6 illustrates a process according to embodiments for implementing a display name service at a PBX. The process of FIG. 6 may, thus, be carried out by a PBX such as the PBX 111 of FIG. 1 or by a particular component or entity of the PBX (e.g., a server of the PBX such as a call server of the PBX).

[0087] The process of FIG. 6 corresponds substantially to the process of FIG. 2. Any of the features and definitions discussed in connection with FIG. 2 or any of FIGs. 3 to 5 may apply, mutatis mutandis, for the process of FIG. 6, unless otherwise stated.

[0088] Referring to FIG. 6, the PBX may be initially assumed to maintain, in a database, subscriber information for a plurality of subscribers of the PBX. The database may be, e.g., a database server of the PBX. The subscriber information may comprise, for each subscriber, information such as a name of the subscriber, a subscriber identifier, a phone number of the subscriber, login credentials, device information (e.g., associated phone numbers and / or IP addresses) and / or contacts of the subscriber. Said subscriber information may comprise, at least for some subscribers, a display name of the subscriber (which may be the same as the name of the subscriber or a separate data field). Similar to previous embodiments, the purpose of the display name service, implemented here in the PBX, isenabling displaying of information (i.e., the display name) relating to the calling party to a called party (via a display of a terminal device of the called party) upon call reception. The display name may be a name that the subscriber (of the display name service) has selected for display at a terminal device of the called party upon receiving a call from a phone number of subscriber. Alternatively, the PBX may determine the display name of the subscriber based on the subscriber information (i.e., no separate display name may have been explicitly defined by the user). For example, the display name may correspond to a name of the subscriber (being a person) and / or a name of an organization, business or public institution or agency to which the subscriber belongs.

[0089] The PBX receives, in block 602, from a terminal device of a calling party, a session initiation request for initiating a session between a calling party and a called party. At least one of the calling party or the called party may be a subscriber of the PBX. The session initiation request may be received, e.g., via the Internet. If the calling party is a subscriber of the PBX, the calling party may have triggered the sending of the session initiation request, e.g., via an application associated with the PBX installed to the terminal device (after having signed in using their login credentials). The session initiation request may comprise a phone number of the calling party.

[0090] The PBX determines, in block 602, whether a display name for the calling party is available to the PBX (or to the call server thereof), i.e., whether the PBX (or the call server) has access to or is able to determine the display name.

[0091] If the calling party is a subscriber of the PBX, the determination in block 602 may be based at least on the subscriber information of the calling party maintained in the database. The display name may correspond, in this case, to a name of the subscriber (being, e.g., a person) and / or a name of an organization, business or public institution or agency to which the subscriber belongs. The name of the subscriber may be defined directly in the subscriber information. The name of the organization, business or public institution or agency to which the subscriber belongs may be also defined directly in the subscriber information or determined based on the subscriber information. Regarding the latter option, the determination may be based, e.g., on a label of a PSTN / PLMN number of the subscriber, where said PSTN / PLMN number and the label may be included in the subscriber information. Said database may comprise a mapping between labels and associated displaynames of organizations, business or public institutions or agencies. Alternatively, said label may correspond directly to the display name.

[0092] If the calling party is not a subscriber of the PBX but the called party is, the determination in block 602 may be based on at least one of:- a private contact name defined in the subscriber information of the called party (namely, in the contacts of the called party),- a shared contact name defined in the subscriber information associated with the called party (namely, in the contacts of the called party),- a name defined in an external directory (e.g., a yellow page directory), or- a name defined in the session initiation request itself.Here, the shared contact name may refer to a contact name shared within an organization, business or public institution or agency to which the subscriber belongs. The PBX may be configured to consider all or at least one of the listed options. Optionally, the PBX may look for the different types of names in the listed order (i.e., first look for a private contact name from the subscriber information of the called party, then for a shared contact name from the subscriber information associated with the called party and so on).

[0093] In response to (or based on) finding the display name of the calling party in block 603, the PBX appends, in block 604, the display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception.

[0094] The PBX adds, in block 605, to the session initiation request, a header (i.e., a SIP header) comprising an identifier of the display name service. The added header may be a proprietary header. The added header may be an X-header (equally called an X-SIP header). According to a general definition, an X-header is a custom header used in SIP requests to carry specific information that is not part of the official SIP protocol specification.

[0095] The PBX routes, in block 606, the appended session initiation request towards a terminal device of the called party. For example, the PBX may route the appended session initiation request to an operator network which, subsequently, routes it to the terminal device of the called party. Assuming that the process of FIG. 6 is carried out by a particular server (e.g., a call server) of the PBX, the appended session initiation request may be routed from said server via an interface or connection point of the PBX to the operator network.

[0096] In response to (or based on) failing to finding a display name of the calling party in block 603, the PBX routes, in block 607, the session initiation request towards a terminal device of the called party. The routing may be carried out similar to as described in connection with block 606.

[0097] Similar to as described for the IMS-based implementation in connection with FIG. 4, following the processing of the session initiation request at the PBX according to the process of FIG. 6, it may be evaluated, before the session initiation request is routed to the terminal device of the called party, whether the session initiation request comprising the display name of the calling party can be trusted. The process of FIG. 4 may apply, mutatis mutandis, in this case, apart from the following differences. Here, the process of FIG. 4 may be carried out specifically by the PBX (namely, by an interface or connection point of the PBX) or by a node of an operator network (i.e., not by a P-CSCF). Said node of the operator network may be an edge node (i.e., a node located at an edge of the operator network). Said node of the operator network may be a physical or virtual entity. The routing in blocks 606, 607 may be directed to said entity performing the process of FIG. 4 (and which is located between the apparatus performing the process of FIG. 6 and the terminal device). Moreover, the session initiation request is received, in block 402, from the PBX (not from the IMS network). If the process is executed by the interface or connection point of the PBX, the session initiation request may be received, in block 402, specifically from another entity of the PBX (e.g., a server such as a call server or another entity of the PBX executing the process of FIG. 6).

[0098] The blocks, related functions, and information exchanges described above by means of FIGs. 2 to 6 are in no absolute chronological order, and some of them may be performed simultaneously or in an order differing from the given one. Other functions can also be executed between them or within them, and other information may be sent, and / or other rules applied. Some of the blocks or part of the blocks or one or more pieces of information can also be left out or replaced by a corresponding block or part of the block or one or more pieces of information.

[0099] FIG. 7 provides an apparatus 701 according to some embodiments. Specifically, FIG. 7 may illustrate a computing device or system 701 configured to carry out at least some of the functions described above. The computing device 701 may be, for example, a server or a desktop computing device. The computing system 701 may be acloud-based computing system. The apparatus 701 may correspond to the DN AS such as the DN AS 109 of FIG. 1 or to a P-CSCF such as the P-CSCF 103, 104 of FIG. 1. In other embodiments, the apparatus 701 may correspond to a S-CSCF such as the S-CSCF 105 of FIG. 1. In yet further embodiments, the apparatus 701 may correspond to a PBX such as the PBX 111 of FIG. 1 or a part thereof (e.g., a server of the PBX such as a call server). In yet further embodiments, the apparatus 701 may correspond to a connection or interface point of a PBX (e.g., the PBX 111 of FIG. 1) or an (edge) node of an operator network.

[0100] The apparatus 701 may comprise one or more communication control circuitry 720, such as at least one processor, and at least one memory 740, including one or more algorithms 731, such as a computer program code (software) wherein the at least one memory and the computer program code (software) are configured, with the at least one processor, to cause the apparatus 701 to carry out any one of the exemplified functionalities of the DN AS, the P-CSCF, the S-CSCF, the PBX (e.g., the call server or connection or interface point thereof) or the (edge) node of the operator network described above. Said at least one memory 740 may also comprise at least one database 732.

[0101] When the one or more control circuitry 720 comprises more than one processor, the apparatus 701 may be a distributed device wherein processing of tasks takes place in more than one physical unit. Each of the at least one processor may comprise one or more processor cores. A processing core may comprise, for example, a Cortex-A8 processing core manufactured by ARM Holdings or a Zen processing core designed by Advanced Micro Devices Corporation. The one or more control circuitry 720 may comprise at least one Qualcomm Snapdragon and / or Intel Atom processor. The one or more control circuitry 720 may comprise at least one application-specific integrated circuit (ASIC). The one or more control circuitry 720 may comprise at least one field-programmable gate array (FPGA).

[0102] Referring to FIG. 7, the one or more control circuitry 720 of the apparatus 701 is configured to carry out functionalities described above by means of any of elements any of elements of FIGs. 2 to 6 using one or more individual circuitries. It is also feasible to use specific integrated circuits, such as ASIC (Application Specific Integrated Circuit) or other components and devices for implementing the functionalities in accordance with different embodiments.

[0103] Referring to FIG. 7, the apparatus 701 may further comprise different interfaces 710 such as one or more communication interfaces comprising hardware and / or software for realizing communication connectivity according to one or more communication protocols. Specifically, if the apparatus is a node of the IMS network, the one or more communication interfaces 710 may comprise, for example, interfaces providing connections between the apparatus 701 and other elements or nodes of the IMS network. If the apparatus 701 is the DN AS 109 of FIG. 1 or either of the P-CSCFs 103, 104 of FIG. 1, the one or more communications interfaces 710 may enable at least connections as shown in or discussed in connection with FIG. 1. If the apparatus is a PBX, the one or more communication interfaces 710 may comprise, for example, interfaces providing connections between the apparatus 701 and the Internet and / or between the apparatus 701 and an operator network. If the apparatus is a (call) server of the PBX, the one or more communication interfaces 710 may comprise, for example, interfaces providing connections between the apparatus 701 and one or more connection or interface points of the PBX. If the apparatus is a connection or interface point of the PBX, the one or more communication interfaces 710 may comprise, for example, interfaces providing connections between the apparatus 701 and the (call) server of the PBX and / or between the apparatus 701 and an operator network. If the apparatus is an (edge) node of the operator network, the one or more communication interfaces 710 may comprise, for example, interfaces providing connections between the apparatus 701 and one or more other nodes of the operator network, between the apparatus 701 and one or more terminal device and / or between the apparatus 701 and the PBX.

[0104] In some embodiments, the one or more communication interfaces 710 may comprise at least one interface providing a connection to a database maintaining plurality of entries for a plurality of subscribers of a display name service (in the case where the apparatus 701 is the DN AS, the PBX or the (call) server of the PBX) or to database maintaining one or more identifiers of one or more trusted display name services (in the case where the apparatus 701 is the P-CSCF, the PBX, the interface or connection point of the PBX or the (edge) node of the operator network). Alternatively, either of said databases may be or be comprised in the database 732 (i.e., either of said databases may be an internal database of the apparatus 701).

[0105] Referring to FIG. 7, the memory 740 may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory,magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.

[0106] According to an embodiment, there is provided an application server for an Internet protocol multimedia subsystem, IMS, network, the application server comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the application server at least to perform: maintaining, in a database, a plurality of entries for a plurality of subscribers of a display name service, wherein each of the plurality of entries comprises a phone number of a subscriber of the display name service and a display name of the subscriber; receiving, from a node of the IMS network, a session initiation request for initiating a session between a calling party and a called party; determining whether the calling party has subscribed to the display name service by searching the database based on a phone number of the calling party comprised in the session initiation request; and in response to finding, from the database, an entry comprising the phone number of the calling party,- appending the display name of the calling party comprised in the entry to at least one part of the session initiation request to be displayed to the called party upon call reception,- adding, to the session initiation request, a header comprising an identifier of the display name service, and- routing the session initiation request back to the node of the IMS network.

[0107] According to an embodiment, there is provided a proxy call session control function, P-CSCF, for an Internet protocol multimedia subsystem, IMS, network, the P- CSCF comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the application server at least to perform: maintaining, in a database, one or more identifiers of one or more trusted display name services;receiving, from a node of the IMS network, a session initiation request for initiating a session between a calling party and a called party; determining whether at least one part of the session initiation request to be displayed to the called party upon call reception comprises a display name of the calling party; in response to the display name being comprised in the session initiation request, determining whether the session initiation request comprises a header comprising an identifier of one of the one or more trusted display name services; and in response to the session initiation request comprising the header comprising the identifier of one of the one or more trusted display name services,- removing the header from the session initiation request, and- routing the session initiation request to a terminal device corresponding to the called party.

[0108] According to an embodiment, there is provided a serving call session control function, S-CSCF, for an Internet protocol multimedia subsystem, IMS, network, the S- CSCF comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from a node of the IMS network, a session initiation request for initiating a session between a calling party and a called party; executing initial filter criteria, IFC, triggers associated with the calling party and the called party based on the session initiation request, trigger points of the IFC triggers and priority of the IFC triggers, wherein the IFC triggers comprise at least one originating IFC trigger for the telephony application server and at least one originating IFC trigger for an application server hosting a display name service, the at least one originating IFC trigger for the telephony application server being defined to have a higher priority compared to the at least one originating IFC trigger for the application server hosting the display name service, the display name service being a service for appending a display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception, wherein the executing of the IFC triggers comprises:- based on firing of any of the at least one originating IFC trigger for the telephony application server, causing execution of one or more originating services by routing the session initiation request to the telephony application server;- based on firing of any of the at least one originating IFC trigger for the application server hosting the display name service, causing execution of the display name service by routing the session initiation request to the application server hosting the display name service; and following the executing of the IFC triggers, routing the session initiation request towards a terminal device of the called party.

[0109] According to an embodiment, there is provided a private branch exchange (or a call server thereof), the private branch exchange (or the call server) comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the private branch exchange at least to perform: receiving, from a terminal device, a session initiation request for initiating a session between a calling party and a called party, wherein at least one of the calling party or the called party is a subscriber of the PBX; determining whether a display name for the calling party is available to PBX; and in response to the display name for the calling party being available,- appending the display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception, adding, to the session initiation request, a header comprising an identifier of the display name service, and- routing the session initiation request towards a terminal device of the called party.

[0110] According to an embodiment, there is provided an apparatus (e.g., an interface or connection point of a PBX or an edge node of an operator network) comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: maintaining, in a database, one or more identifiers of one or more trusted display name services;receiving, from a PBX or a server (e.g., a call server) of the PBX, a session initiation request for initiating a session between a calling party and a called party; determining whether at least one part of the session initiation request to be displayed to the called party upon call reception comprises a display name of the calling party; in response to the display name being comprised in the session initiation request, determining whether the session initiation request comprises a header comprising an identifier of one of the one or more trusted display name services; and in response to the session initiation request comprising the header comprising the identifier of one of the one or more trusted display name services,- removing the header from the session initiation request, and- routing the session initiation request to a terminal device corresponding to the called party.

[0111] As used in this application, the term ‘circuitry’ may refer to one or more or all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and / or digital circuitry, and (b) combinations of hardware circuits and software (and / or firmware), such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software, including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus, such as a terminal device or an access node, to perform various functions, and (c) hardware circuit(s) and processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g. firmware) for operation, but the software may not be present when it is not needed for operation. This definition of ‘circuitry’ applies to all uses of this term in this application, including any claims. As a further example, as used in this application, the term ‘circuitry’ also covers an implementation of merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware.

[0112] In an embodiment, at least some of the processes described in connection with FIGs. 2 to 6 may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter,encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, filter (low-pass, high-pass, bandpass and / or bandstop), sensor, circuitry, inverter, capacitor, inductor, resistor, operational amplifier, diode and transistor. In an embodiment, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of FIGs. 2 to 6 or operations thereof. In some embodiments, at least some of the processes may be implemented using discrete components.

[0113] Embodiments as described may also be carried out, fully or at least in part, in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with FIGs. 2 to 6 may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be provided as a computer readable medium comprising program instructions stored thereon or as a non-transitory computer readable medium comprising program instructions stored thereon. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

[0114] The term “non-transitory”, as used herein, is a limitation of the medium itself (that is, tangible, not a signal) as opposed to a limitation on data storage persistency (for example, RAM vs. ROM).

[0115] Reference throughout this specification to one embodiment or an embodiment means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various placesthroughout this specification are not necessarily all referring to the same embodiment.

[0116] As used herein, a plurality of items, structural elements, compositional elements, and / or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present invention may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as de facto equivalents of one another, but are to be considered as separate and autonomous representations of the present invention.

[0117] Even though embodiments have been described above with reference to examples according to the accompanying drawings, it is clear that the embodiments are not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.INDUSTRIAL APPLICABILITY

[0118] At least some embodiments of the present invention find industrial application in mobile communications.

Claims

CLAIMS1. An application server for an Internet protocol multimedia subsystem, IMS, network, the application server comprising means for performing: maintaining, in a database, a plurality of entries for a plurality of subscribers of a display name service, wherein each of the plurality of entries comprises a phone number of a subscriber of the display name service and a display name of the subscriber; receiving, from a node of the IMS network, a session initiation request for initiating a session between a calling party and a called party; determining whether the calling party has subscribed to the display name service by searching the database based on a phone number of the calling party comprised in the session initiation request; and in response to finding, from the database, an entry comprising the phone number of the calling party,- appending the display name of the calling party comprised in the entry to at least one part of the session initiation request to be displayed to the called party upon call reception,- adding, to the session initiation request, a header comprising an identifier of the display name service, and- routing the session initiation request back to the node of the IMS network.

2. The application server of claim 1, wherein the means are further configured to perform: determining whether routing information comprised in the session initiation request identifies the display name service; and performing the determining whether the calling party has subscribed to the display name service by searching the database based on the phone number of the calling party in response to the routing information comprised in the session initiation request identifying the display name service.

3. The application server according to any preceding claim, wherein the at least one part of the session initiation request to be displayed to the called party upon call receptioncomprises a From header of the session initiation request or a part thereof and / or a P- Asserted-Identity, PAI, header of the session initiation request or a part thereof4. The application server according to any preceding claim, wherein the means are further configured to perform: in response to failing to find, from the database, any entry comprising the phone number of the calling party, routing the session initiation request back to the node of the IMS network.

5. The application server according any preceding claim, wherein the added header is an X-header.

6. The application server according to any preceding claim, wherein the routing of the session initiation request comprises: removing a topmost route header from the session initiation request; and sending the session initiation request back to the node of the IMS network.

7. The application server according to any preceding claim, wherein the session initiation request is an INVITE request and / or the node of the IMS network is a serving call session control function, S-CSCF.

8. A proxy call session control function, P-CSCF, for an Internet protocol multimedia subsystem, IMS, network, the P-CSCF comprising means for performing: maintaining, in a database, one or more identifiers of one or more trusted display name services; receiving, from a node of the IMS network, a session initiation request for initiating a session between a calling party and a called party; determining whether at least one part of the session initiation request to be displayed to the called party upon call reception comprises a display name of the calling party; in response to the display name being comprised in the session initiation request, determining whether the session initiation request comprises a header comprising an identifier of one of the one or more trusted display name services; andin response to the session initiation request comprising the header comprising the identifier of one of the one or more trusted display name services,- removing the header from the session initiation request, and- routing the session initiation request to a terminal device corresponding to the called party.

9. The P-CSCF of claim 8, further comprising means for performing: in response to the session initiation request failing to comprise the header comprising any identifier of the one or more trusted display name services,- removing the display name from the session initiation request, and- routing the session initiation request to the terminal device corresponding to the called party.

10. The P-CSCF of claim 8 or 9, wherein the at least one part of the session initiation request to be displayed to the called party upon call reception comprises a From header of the session initiation request and / or a P-Asserted-Identity, PAI, header of the session initiation request.

11. The P-CSCF according to any of claims 8 to 10, wherein the session initiation request is an INVITE request and / or the node of the IMS network is a serving call session control function, S-CSCF.

12. A private branch exchange, PBX, comprising means for performing: receiving, from a terminal device, a session initiation request for initiating a session between a calling party and a called party, wherein at least one of the calling party or the called party is a subscriber of the PBX; determining whether a display name for the calling party is available to the PBX; and in response to the display name for the calling party being available,- appending the display name of the calling party to at least one part of the session initiation request to be displayed to the called party upon call reception, adding, to the session initiation request, a header comprising an identifier of the display name service, and- routing the session initiation request towards a terminal device of the called party.

13. An apparatus, being a connection or interface point of a private branch exchange, PBX, or an edge node of an operator network, comprising means for performing: maintaining, in a database, one or more identifiers of one or more trusted display name services; receiving, from a server of the PBX, a session initiation request for initiating a session between a calling party and a called party; determining whether at least one part of the session initiation request to be displayed to the called party upon call reception comprises a display name of the calling party; in response to the display name being comprised in the session initiation request, determining whether the session initiation request comprises a header comprising an identifier of one of the one or more trusted display name services; and in response to the session initiation request comprising the header comprising the identifier of one of the one or more trusted display name services,- removing the header from the session initiation request, and- routing the session initiation request to a terminal device corresponding to the called party.

14. A method comprising: maintaining, in a database, a plurality of entries for a plurality of subscribers of a display name service, wherein each of the plurality of entries comprises a phone number of a subscriber of the display name service and a display name of the subscriber; receiving, from a node of an IMS network, a session initiation request for initiating a session between a calling party and a called party; determining whether the calling party has subscribed to the display name service by searching the database based on a phone number of the calling party comprised in the session initiation request; and in response to finding, from the database, an entry comprising the phone number of the calling party,- appending the display name of the calling party comprised in the entry to at least one part of the session initiation request to be displayed to the called party upon call reception,- adding, to the session initiation request, a header comprising an identifier of the display name service, and- routing the session initiation request back to the node of the IMS network15. A computer program comprising instructions for performing the following: receiving, from a node of an IMS network, a session initiation request for initiating a session between a calling party and a called party; determining, based on a phone number of the calling party comprised in the session initiation request, whether the calling party has subscribed to a display name service by searching a database storing a plurality of entries for a plurality of subscribers of the display name service, wherein each of the plurality of entries comprises a phone number of a subscriber of the display name service and a display name of the subscriber; and in response to finding, from the database, an entry comprising the phone number of the calling party,- appending the display name of the calling party comprised in the entry to at least one part of the session initiation request to be displayed to the called party upon call reception,- adding, to the session initiation request, a header comprising an identifier of the display name service, and- routing the session initiation request back to the node of the IMS network.