Verifying a Calling Party

Example embodiments of this disclosure relate to verifying a calling party, such as a calling party of a voice or video call.

Voice calls and video calls may originate from several different sources, such as fixed (landline) phones, mobile phones, private branch exchanges (PBXs), Voice over Internet Protocol (VolP), and others. Usually, one of two signaling protocols may be used for communication between the network functions and interconnections, and these are Signaling System 7 (SS7) and Session Initiation Protocol (SIP). This signaling was or is transported over various technologies, such as time division multiplexing (TDM), Asynchronous Transfer Mode (ATM), and Internet Protocol (IP).

Native SS7, which is used in Public Switched Telephone Networks (PSTNs) and in 2G and 3G Public Land Mobile Networks (PLMNs), does not provide any authentication capability of the calling party. If transported Internet Protocol Security (IPsec) tunnels are used, this may allow the authentication of interconnections and thus of the calling party. SIP, which is used in 4G and 5G PLMNs, can be transported over secure transport protocols (i.e. Transport Layer Security, TLS), which only allows authentication of peer Session Initiation Protocol (SIP) User Agents (SUAs) but not the originator of the call.

This native lack in the signaling protocols that control the calls has led to the emergence of caller ID spoofing. A user may spoof caller ID information using VolP, an Internet calling card service, open source telephone exchange software, or a number of other spoofing techniques. A bridge device may implement such spoofing techniques by calling a receiving device and providing the spoofed caller ID information to the receiving device, calling a sending device using the real caller ID information (e.g., the real phone number), and bridging the calls. The impact of illegitimate uses of caller ID spoofing presents unique challenges for the industry in addressing consumer concerns with fraudulent calls. The consumers must be protected against calls from parties that impersonate trusted persons, companies and agencies and can lead the consumer to share information that he or she should be sharing only with the person, company, or agency he or she is supposed to be talking to.

A solution that can be effective for all scenarios is challenging. The Alliance for Telecommunications Industry Solutions (ATIS), “Calling Party Spoofing Mechanisms and Mitigation Techniques”, April 2016, https://access.atis.org/apps/group_public/download.php/28385/ATIS-I-0000051.pdf, outlines practical mitigation techniques being developed and emphasizes that caller ID spoofing is not a static problem that can be solved with a single solution.

The IETF STIR Working Group (draft-ietf-stir-rfc4474bis) has for some time been working on a mechanism that would allow individual phone numbers to be signed at the origin, and verified at the termination (e.g. the called party). The Federal Communications Commission (FCC) has mandated all telecom providers in the US to implement STIR/SHAKEN, an industry-driven solution based on digital signatures and applicable only to SIP calls.

In addition to STIR/SHAKEN, other solutions have been proposed and developed. For example, SEISMIC is based on transferring off-path call metadata for verifying the authenticity of the calling party. Mobile networks can check the plausibility of the originating international call by checking the location of the calling party using SS7 messages.

Examples of this disclosure may have certain advantages. For example, embodiments of this disclosure may allow a calling party to be verified, regardless of the underlying technology or channel over which the call or a request for the call is made, e.g. SS7 or SIP, or other technologies.

One aspect of the present disclosure provides a method of verifying a calling party. The method comprises receiving, on a first communication channel, a call request, the call request identifying a calling party, and sending, to the calling party on a second communication channel different from the first communication channel, a verification request to verify that the calling party is an originator of the call request, the verification request identifying a first value. The method also comprises, if a reply to the verification request is received from the calling party indicating that the calling party is the originator of the call request, and the reply identifies a second value based on the first value, determining that the calling party is the originator of the call request.

Another aspect of the present disclosure provides a method of verifying a calling party. The method comprises receiving, on a second communication channel different from a first communication channel for calls and/or requests for calls, a verification request to verify that a calling party is an originator of the call request, the verification request identifying a first value, and, if the calling party is the originator of the call request, sending a reply to a sender of the verification request indicating that the calling party is the originator of the call request, the reply identifying a second value based on the first value.

A further aspect of the present disclosure provides apparatus for verifying a calling party. The apparatus comprises a processor and a memory. The memory contains instructions executable by the processor such that the apparatus is operable to receive, on a first communication channel, a call request, the call request identifying a calling party, send, to the calling party on a second communication channel different from the first communication channel, a verification request to verify that the calling party is an originator of the call request, the verification request identifying a first value, and, if a reply to the verification request is received from the calling party indicating that the calling party is the originator of the call request, and the reply identifies a second value based on the first value, determine that the calling party is the originator of the call request.

A still further aspect of the present disclosure provides apparatus for verifying a calling party. The apparatus comprises a processor and a memory. The memory contains instructions executable by the processor such that the apparatus is operable to receive, on a second communication channel different from a first communication channel for calls and/or requests for calls, a verification request to verify that a calling party is an originator of the call request, the verification request identifying a first value, and, if the calling party is the originator of the call request, send a reply to a sender of the verification request indicating that the calling party is the originator of the call request, the reply identifying a second value based on the first value.

Another aspect of the present disclosure provides apparatus for verifying a calling party. The apparatus is configured to receive, on a first communication channel, a call request, the call request identifying a calling party, send, to the calling party on a second communication channel different from the first communication channel, a verification request to verify that the calling party is an originator of the call request, the verification request identifying a first value, and, if a reply to the verification request is received from the calling party indicating that the calling party is the originator of the call request, and the reply identifies a second value based on the first value, determine that the calling party is the originator of the call request.

Another aspect of the present disclosure provides apparatus for verifying a calling party. The apparatus is configured to receive, on a second communication channel different from a first communication channel for calls and/or requests for calls, a verification request that a calling party is an originator of the call request, the verification request identifying a first value, and, if the calling party is the originator of the call request, send a reply to a sender of the verification request indicating that the calling party is the originator of the call request, the reply identifying a second value based on the first value.

A further aspect of the present disclosure provides a method in a system for verifying a calling party. The system comprises a calling party and a called party. The method comprises receiving, at the called party on a first communication channel, a call request, the call request identifying the calling party; sending, by the called party to the calling party on a second communication channel different from the first communication channel, a verification request to verify that the calling party is an originator of the call request, the verification request identifying a first value; receiving, at the calling party on the second communication channel, the verification request; if the calling party is the originator of the call request, sending, by the calling party, a reply to the verification request to the called party indicating that the calling party is the originator of the call request, the reply identifying a second value based on the first value; and if a reply to the verification request is received from the calling party indicating that the calling party is the originator of the call request, and the reply identifies a second value based on the first value, determining, by the called party, that the calling party is the originator of the call request.

A still further aspect of the present disclosure provides a system for verifying a calling party. The system comprises a calling party and a called party. The system is configured to receive, at the called party on a first communication channel, a call request, the call request identifying the calling party; send, by the called party to the calling party on a second communication channel different from the first communication channel, a verification request to verify that the calling party is an originator of the call request, the verification request identifying a first value; receive, at the calling party on the second communication channel, the verification request; if the calling party is the originator of the call request, send, by the calling party, a reply to the verification request to the called party indicating that the calling party is the originator of the call request, the reply identifying a second value based on the first value; and if a reply to the verification request is received from the calling party indicating that the calling party is the originator of the call request, and the reply identifies a second value based on the first value, determine, by the called party, that the calling party is the originator of the call request.

The following sets forth specific details, such as particular embodiments or examples for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other examples may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g. analog and/or discrete logic gates interconnected to perform a specialized function, Application Specific Integrated Circuits (ASICs), Programmable Logic Arrays (PLAs), etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, where appropriate the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g. digital or analogue) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.

Except from STIR/SHAKEN, referred to above, there is no proposed solution that allows to verify that the caller ID really belongs to the person/company that initiated a call, i.e. that the calling party (which may be associated with the caller ID) is the originator of the call. Many mitigations are trying to block already known malicious caller IDs, e.g. via black listing, white listing, or rejection of anonymous calls. However, these do not verify that the party initiating a call (the originator of the call) is the legitimate owner of the caller ID used in the call, and hence that the calling party (identified by the caller ID) is the originator of the call. The mitigation techniques described in the ATIS document referred to above rely to some extent on the accuracy of the calling party information, and this is what a spoofing attack relies on.

STIR/SHAKEN has two main limitations. First, it requires a new public key infrastructure (PKI), but scaling up this PKI for the global telecom industry is difficult. Implementing STIR/SHAKEN within one country is not sufficient, as many spoofed caller ID calls originate from abroad. Second, it only works with the SIP (VOIP) system, leaving the traditional SS7 (landline and cellular) systems unprotected. SEISMIC and other “off-path” solutions require a central authority (registry or distributed ledger) for maintaining call metadata. The SS7-based solutions apply only to calling line identification (CLI) spoofing cases where the calling subscriber is a mobile subscriber, and don't work if the spoofed subscriber is roaming abroad.

Embodiments of this disclosure may provide solutions to these or other problems. For example, some examples of this disclosure provide methods of verifying a calling party, i.e. that the caller ID or calling party identified in a call or call request is the originator of the call, and is not another party spoofing the caller ID. Examples of this disclosure may provide for example a channel, different from the channel over which the call takes place or is initiated, over which the calling party (the party identified in the call or request for the call) can be verified. For example, a verification value may be sent over the different channel to the calling party, and if the calling party originated the call, a reply may be sent including the verification value (or a value based on or derived from the verification value) to indicate that the calling party is the genuine originator of the call.

Some examples propose a system, referred to as caller ID OTP Verification (CIOV), which uses a One-Time-Password (OTP) to verify to the called party that the call really comes from the presented caller ID, i.e. that the calling party associated with the caller ID is the originator of the call. OTP is used by various enterprises and bank institutes to authenticate users using two-factor authentication. Two factor authentication may authenticate a user for example by confirming that the user's device registered with the authentication system—typically a mobile device—is in fact in the user's possession.

In a particular example, a calling party is referred to as A (Alice) and a called party is referred to as B (Bob). When B (Bob) receives a call or a request for a call that identifies A (Alice) as the calling party, in some examples, an application of Bob's device generates an One-Time-Password and sends it out-of-band to A (Alice). When the application on the device of Alice receives the OTP, it sends it back to Bob, or a different value derived from the OTP. Once the application on Bob's device receives the OTP (or value derived from it) and confirms that it is the OTP it generated and sent to Alice, it may be determined or concluded that Alice was the originator of the call. Thus, in some examples, appropriate action may be taken, e.g. Bob may receive a notification that the caller ID has been verified, the call may be accepted or allowed to continue, etc.

1 FIG. 100 100 100 is a flow chart of an example of a methodof verifying a calling party. In some examples, the methodmay be performed by the called party that receives a call request. The calling party, i.e. the party that is identified in the call request, may or may not be the party that originated the call, and hence the methodmay for example verify whether or not the apparent calling party is the originator of the call request.

100 102 The methodcomprises, in step, receiving, on a first communication channel, a call request, the call request identifying a calling party. The call request may be a request for a voice call or a video call for example. The request may identify the calling party by including for example a caller ID. The request may be for example a Signaling System No. 7 (SS7) message or a Session Initiation Protocol (SIP) message.

104 100 Stepof the methodcomprises sending, to the calling party on a second communication channel different from the first communication channel, a verification request to verify that the calling party is an originator of the call request, the verification request identifying a first value. In some examples, the first value (e.g. the verification value referred to above) may be randomly or pseudorandomly generated. The first value may be an OTP for example. The verification request may in some examples identify the calling party, a subscriber ID or caller ID of the calling party, the called party and/or the subscriber ID or caller ID of the called party. In some examples, the first communication channel may be a channel for calls and/or call requests. In some examples, a “channel” may include a route for communications through one or more particular networks or network nodes, or additionally or alternatively a protocol for communications (e.g. SS7, SIP etc).

The second channel may comprise for example one or more of: a network different from a network of the first channel, the internet, a channel for push notifications, a channel for an Instant Messaging Service (IMS), and/or a channel for a Short Messaging Service (SMS). For example, the verification request may be a SMS message sent to the calling party, where the SMS message contains the first value. The verification request may in some examples be a request to send a push notification to the calling party, a Short Messaging Service (SMS) message; and/or an Instant Messaging Service (IMS) message. Where the verification request is a request to send a push notification to the calling party, this may be sent to an application server for example.

106 100 In stepof the method, if a reply to the verification request is received from the calling party indicating that the calling party is the originator of the call request, and the reply identifies a second value based on the first value, it may be determined or concluded that the calling party is the originator of the call request. This is because the calling party has responded with the second value. If the call request was spoofed by a third party, then the third party is not aware of the first value or the second value, as the verification request is sent to the calling party instead of the originator of the call (though these are the same party in the case of a genuine call from the calling party). The second value may be the same as the first value or may be based on or derived from the first value. For example, the calling party may modify the first value in a manner known to the called party to derive the second value, such that the second value may also be derived by the called party and compared to the second value in the reply to the verification request.

106 The reply to the verification request may in some examples be received in stepon the second channel or a third channel different from the second channel. The reply may be for example a push notification, a Short Messaging Service (SMS) message, and/or an Instant Messaging Service (IMS) message. Where the reply is a push notification, this may be received from a push notification server for example.

The method may in some examples, on determining that the calling party is the originator of the call, allow the call request (e.g. by allowing it to be accepted, by accepting it, or forwarding it to a device used by the called party), and/or sending or displaying to a called party for the call a notification that the calling party is the originator of the call request. Thus for example the user may be informed that the called party has been verified and is hence trustworthy, or is otherwise the originator of the call request.

100 100 In some examples, the methodmay comprise determining or concluding that the calling party is not or may not be the originator of the call request if a timer started on receiving the call request times out (and a reply including the second value is not received from the calling party in that time). Alternatively, for example, the methodmay comprise determining or concluding that the calling party is not or may not be the originator of the call request if the reply from the calling party does not identify the first value or the second value (and hence may be spoofed), or if a reply is received from the calling party indicating that the calling party is not the originator of the call request, which reply the calling party may send in some examples if it is not the originator.

100 On determining that the calling party is not or may not be the originator of the call request, in some examples, the methodmay comprise performing appropriate actions. These may include, for example, rejecting or blocking the call request, terminating the call (if the call has already started), and/or sending or displaying to a called party for the call a notification that the calling party is not or may not be the originator of the call request. The latter may allow the user for example to terminate the call themselves or to avoid disclosing personal information to a third party.

100 100 The methodmay in some examples be performed by a device associated with a called party of the call request. Alternatively, in some examples, the methodmay be performed by a network node in a network to which the device associated with the called party is connected. For example, the network may be a cellular or mobile network to which the called party's device is connected or to which the called party is a subscriber.

2 FIG. 200 200 200 100 is a flow chart of an example of a methodof verifying a calling party. In some examples, the methodmay be performed by a calling party (e.g. a party associated with a caller ID), or the calling party's device. In some examples, the methodis performed by the calling party that may or may not have originated a call to a called party, whereas the methodmay be performed by the called party that receives a call request.

200 202 The methodcomprises, in step, receiving, on a second communication channel different from a first communication channel for calls and/or requests for calls, a verification request that a calling party is an originator of the call request, the verification request identifying a first value. The call request may be for example a voice or video call, and may be for example a Signalling System No. 7 (SS7) message or a Session Initiation Protocol (SIP) message. The verification request may in some examples identify the calling party, a subscriber ID or caller ID of the calling party, the called party and/or the subscriber ID or caller ID of the called party.

200 204 The methodalso comprises, in step, if the calling party is the originator of the call request, sending a reply to a sender of the verification request indicating that the calling party is the originator of the call request, the reply identifying a second value based on the first value.

100 As for the method, the first value may be for example a randomly or pseudorandomly generated value, and/or comprises a One Time Password (OTP). The second value is equal to the first value or may be different, such as derived from the first value.

204 The reply may be sent for example on the second channel or a third channel different from the first channel in step.

The second channel may comprise in some examples one or more of a network different from a network of the first channel, the internet, a channel for push notifications, a channel for an Instant Messaging Service (IMS), and a channel for a Short Messaging Service (SMS). The verification request may for example comprise one or more of a push notification (e.g. from a push notification server), a SMS message and/or an IMS message. The reply may in some examples comprise the reply comprises one or more of a request (e.g. to an application server) to send a push notification to the sender of the verification request, a SMS message and/or an IMS message.

In some examples, if the calling party is not the originator of the call request, a reply may be sent to the sender of the verification request indicating that the source device is not the originator of the call request. The sender of the verification request may be, for example, the called party of the call request, a device associated with the called party, or a network node in a network to which the device associated with the called party of the call request is connected. Alternatively, for example, if the calling party is not the originator of the call request, the calling party may instead ignore the verification request.

Advantages of embodiments of this disclosure may include one or more of the following. For example, the caller ID may be verified on a second channel, e.g. out of band, providing a separate verification channel discrete from the call signaling channel which might be compromised from the attacker that spoofs the caller ID. This out of band channel can in some examples be secured by using a secure transport layer. Another advantage is for example that the verification process may be initiated by the terminating side, and the verification request is routed based on the caller ID, allowing to address the actual owner of the caller ID. In some examples, the caller ID verification service is independent from the service provider network, allowing it to be used by any subscription or network. However, service providers may in some examples choose to integrate embodiments of this disclosure and offer it as an added value service to their subscribers. Enterprises may in some examples choose to deploy a server where all enterprise mobile subscriptions are registered, authorize the applications or devices of their employees. This may for example prevent attempts for corporate espionage. When it comes to users, the advantage of example embodiments is that it enables the called party to check first if the caller ID can be verified, and if it is, feel confident that this is not a spoofed call. Depending on the content of the call, the called party can decide how to react to the calling party's requests. For instance, if the calling party is a bank, the called party might choose to hang up if the caller ID cannot be verified. Alternatively, in some examples, the user may not even be presented with unverified calls.

Particular example embodiments will now be described for illustration purposes.

3 FIG. 300 300 302 304 302 306 304 308 As indicated above, in a particular example, a calling party is referred to as A (Alice) and a called party is referred to as B (Bob). When B (Bob) receives a call or a request for a call that identifies A (Alice) as the calling party, in some examples, an application of Bob's device generates a One-Time-Password (OTP) and sends it out-of-band to A (Alice). This is illustrated in, which shows an example of a systemin which examples of this disclosure may be implemented. The systemincludes Aliceand Bob. Alicesends a call requestto Bobvia a telecoms networkon a first channel, which may be for example a landline network, mobile network, and/or any other network.

302 304 302 302 304 When the application on the device of Alicereceives the OTP, it sends it back to Bob, or a different value derived from the OTP. Once the application on Bob's device receives the OTP (or value derived from it) and confirms that it is the OTP it generated and sent to Alice, it may be determined or concluded that Alicewas the originator of the call. Thus, in some examples, appropriate action may be taken, e.g. Bobmay receive a notification that the caller ID h as been verified, the call may be accepted or allowed to continue, etc.

The OTP is sent on a second channel, out of band (that is, for example, without using the same channel or communication method as the call request or call). This may be done in a number of suitable ways, and some examples are illustrated.

3 FIG. 304 310 312 314 302 316 312 318 304 In the example shown in, Bobsends a CallerID Verification Requestto an application server. The application server may then send a CallerID Verification Requestto Alice(e.g. an application on Alice's device). The verification requests may identify the caller ID, the called party ID (e.g. the ID of Bob or Bob's device) and the OTP. Alice (assuming that Alice originated the call) sends a reply, a CallerID Verification Response, to the application server, which sends a CallerID Verification Responseto Bob(e.g. an application on Bob's device). The verification response may identify the caller ID, the Called party ID, and the OTP (or a value derived from or based on the OTP).

4 FIG. 400 402 404 406 406 402 404 In some examples, the verification request and/or the reply may be sent using push notifications. Mobile push notifications are small, pop-up messages that can appear on a mobile device even when a user isn't actively using an app. They are sent using a push notification service. Mobile platforms, such as iOS and Android, have their own push notification service. Commercial push notification services are similar in their architectural design, as shown in, which shows an example of such an architectural design. When an application launches in a mobile device, it needs to register to the push service with a push serverto get a unique ID (it may have different names in different platforms, e.g., device token in iOS and push URI in Windows), and then send the unique ID to an application server. When the application serverwants to send a push notification to an application on the mobile device, it sends the ID together with the payload to the push server, which then forwards the payload to the application.

In some examples of this disclosure, both the calling party and the called party have an application (e.g. a CIOV application) installed on their devices, which registers the subscription (e.g. MSISDN) with a Push Notification Service (deployed in the Cloud) and handles the verification of the caller ID as described below. When a call is received (e.g. by Bob), the application sends an OTP over the internet to the calling party using the push notification service. The caller ID may also be presented on the screen of the called party's device. It is important that the calling party has the application and has been registered in a push notification service and has been successfully authenticated by that service. The OTP can then reach the calling party via the push notification server in a verification request, with the intervention of the application server in the Cloud. When the application on the Calling party's device receives the OTP (and Bob's caller ID in some examples), it verifies that there is really was call to Bob by Alice and sends back the OTP in a reply to the verification request. The reply to the follows the reverse logical path and reaches eventually the device of the called party, where the OTPs are compared (i.e. the sent OTP is compared to the received OTP). Once the OTP is verified, Bob's device may for example notify the user that the caller ID has been verified by the CIOV service.

Other ways to transfer the OTP to the calling party include Viber®, Messenger® or any other instant messaging service (IMS) that has an API and could be integrated with the application. The instant messaging service may also provide end to end encryption in some examples.

In case there is no internet access to either the calling party or the called party, or in other examples, the SMS service may be used. In this solution, the application on the called party's device sends a verification request as an SMS message to the calling party, including the OTP generated by the application. Once the application on the called party's device receives the SMS message, if it originated the call or call request, it sends a short message back to the called party, including the same OTP (or a value based on it). This may for example be used as a fallback solution where internet access is unavailable for the push notification service, or the push notification service itself is unavailable.

100 1 FIG. Some operators could in some examples choose to deploy embodiments of this disclosure in a network node instead of a user's device. Thus, for example, a network node between the calling party and the called party may perform the methodshown in. For example, this may be implemented in a terminating network segment and may ensure that called parties receive only calls that have been successfully verified.

5 FIG. 500 500 502 504 502 506 504 508 504 510 512 512 514 516 516 518 502 502 506 520 512 522 516 516 524 504 504 524 502 shows another example of a systemin which examples of this disclosure may be implemented. In this example, push notifications are used. The systemincludes Aliceand Bob. Alicesends a call requestto Bobvia a telecoms networkon a first channel, which may be for example a landline network, mobile network, and/or any other network. Bobsends a CallerID Verification Requestto an application server. The application servermay then send a CallerID Verification Requestto a push notification server. The push notification serversends a push notificationto Aliceincluding the OTP (or a value based on it). If Aliceoriginated the call request, Alice sends a CallerID Verification Response push notification requestincluding the OTP/value to the application server, which sends a requestto send the push notification including the OTP/value to the push notification server. The push notification serverthen sends a push notificationto Bobincluding the OTP or value. Bobcan then compare the original OTP with the OTP or value in the push notificationto determine whether the call came from Alice.

6 FIG. 600 600 602 604 604 606 Step: Alicedials a callto Bob. 608 610 608 612 Step: An application on Alice's device (referred to as CIOVapp on Caller) forwards a call requestto an application (referred to as CIOVapp on Called party) on Bob's device. 614 612 616 Step: the applicationon Bob's device generates an OTP. Bob's device may also display a notificationthat there is an incoming call and that the caller ID has not (or has not yet) been verified. 618 612 618 620 622 624 Step: The applicationon Bob's device sends a CallerID Verification Requestto an application serverincluding the OTP and Alice's caller ID. This may also include Bob's called party ID in some examples. A timermay also be started, and Bob's device may also display a notificationthat caller ID verification is in progress. 626 620 618 Step: The application serversearches for a subscription that corresponds to the caller ID in the verification request. 628 626 628 630 602 Step: If a subscription is found, the application serversends a push notification requestto the push notification serverincluding the ID of Alice(e.g. the push notification ID), and a payload including the OTP and the called party ID. 632 630 632 610 Step: The push notification serversends a push notificationto the applicationon Alice's device, including the called party ID and OTP. 634 610 602 Step: The applicationdetermines whether a call was made to the called party ID by Alice. 636 602 610 636 620 Step: If Alicedid make the call, then the applicationsends a Verify CallerID Response push notification requestincluding the OTP (or a value based on it) to the application server. This may also include Alice's caller ID in some examples. 638 620 638 630 Step: The application serversends a Request Push Notificationincluding Bob's push notification ID, the caller ID, and the OTP to the push notification server. 640 630 640 612 Step: The push notification serversends a push notificationto the applicationon Bob's device including the caller ID and OTP/value. 642 618 Step: If the received OTP (or value) matches the originally sent OTP in step, Bob's device may display a notification that the caller ID has been verified. shows an example of communications in an example methodof verifying a calling party. The methodincludes the following steps and communications.

7 FIG. 6 FIG. 7 FIG. 700 604 608 614 616 622 624 634 624 600 614 700 612 702 704 602 704 706 708 706 shows another example of communications in an example methodof verifying a calling party. In this example, an Instant Messaging Service (IMS) is used to verify the calling party. In this example, steps,,,,,,andare the same as described above for the methodof. Following step, however, in the methodof, the applicationon Bob's device sends a requestto an instant messaging applicationon Bob's device to send an instant message to Aliceincluding the caller ID and OTP. Next, the instant messaging applicationsends an instant messageto an instant messaging applicationon Alice's device. This may in some examples be sent via the instant message service provider's infrastructure. This instant messagemay also include the caller ID and OTP.

708 710 610 610 634 602 610 712 708 604 Next, the instant messaging applicationon Alice's device forwards the instant message (or at least the caller ID and OTP)to the application. The applicationmay then in stepdetermine whether a call was made to the called party ID by Alice. If so, the applicationsends a requestto the instant messaging applicationto send an instant message to Bobincluding the called party ID and OTP (or value based on it).

708 714 704 708 716 612 618 642 The instant messaging applicationsends the instant messageto the instant messaging applicationon Bob's device, and this may also go via the service provider's infrastructure in some examples, and may include the called party ID and OTP/value. Bob's instant messaging appforwards the instant message (or at least the caller ID and OTP/value)to the application. Next, if the received OTP (or value) matches the originally sent OTP in step, Bob's device may display a notificationthat the caller ID has been verified.

8 FIG. 800 800 802 804 806 Step: Alicedials a call to Bob. 808 810 808 812 Step: An application on Alice's device (referred to as CIOVapp on Calling party) forwards a call requestto an application (referred to as CIOVapp on Called party) on Bob's device. 814 812 Step: the applicationon Bob's device generates an OTP. Bob's device may also display a notification that there is an incoming call and that the caller ID has not (or has not yet) been verified. 816 812 818 Step: The applicationon Bob's device sends an SMS message to a SMS service center (SMS SC). A timer may also be started, and Bob's device may also display a notification that caller ID verification is in progress. 820 820 810 Step: The SMS SC forwards the SMS messageto the applicationon Alice's device. 822 810 804 Step: The applicationdetermines whether a call was made to the called party ID by Alice. 824 804 810 824 818 620 Step: If Alicedid make the call, then the applicationsends an SMS messageto the SMS SCincluding the OTP (or a value based on it) to the application server. This may also include Alice's and/or Bob's caller ID in some examples. 826 826 812 Step: The SMS SC forwards the SMS messageto the applicationon Bob's device. 828 826 618 Step: If the received OTP (or value) in the SMS messagematches the originally sent OTP in step, Bob's device may display a notification that the caller ID has been verified. shows another example of communications in an example methodof verifying a calling party. The methodincludes the following steps and communications.

In some examples that use SMS messaging, this could be used as a fallback option from other options (e.g. using push notifications or IMS messaging) in case the called party device does not have internet access. The verification procedure may be slower using SMS in some examples, but if it is done while the call has been answered, it will not impact the user's experience.

When a call or call request is received, there shall be a message on the called party's device informing the user that the caller ID has not (or has not yet) been verified. Once the verification process is started, the message will tell the user that verification is ongoing. If the verification process cannot be started, there will be a message saying the caller ID cannot be verified. If the verification process fails (e.g. timer timeout), the message will inform the user that the verification process failed. If the verification process is completed and the OTP or value is correct, the message will indicate that the caller ID has been verified. If the verification process is completed and the OTP is not correct, the message will say that the caller ID may be spoofed. In some examples of this disclosure, the called party (e.g. Bob) may be kept informed about the verification status of the caller ID. For example, one or more of the following actions may be performed:

The procedure may in some examples be supervised by a timer which will be started on the Called party device once a call or call request is received, or when the verification request is sent. If the service that takes the responsibility to transfer the OTP to the Calling party (e.g. push notification service, IMS or SMS) cannot achieve this, e.g. service unavailable or no internet access, the verification procedure may terminate and the Called party may be informed accordingly. When the Calling party receives the OTP, but it does not verify that there is an ongoing call to the Called party, the calling party (or the calling party's application or device) may in some examples respond back to the called party with the same OTP (or derived value), but with an indication that no call to B is ongoing. Alternatively, the OTP may for example omit the OTP, return a deliberately incorrect OTP or value, or simply ignore the verification request. In any case, the verification procedure may be terminated in the called party's device or application on expiry of the timer if no reply to the verification request is received in that time. There are several scenarios where the verification procedure will be unsuccessful. For example:

9 FIG. 6 FIG. 604 640 900 600 902 640 606 604 shows another example of communications in an example method of verifying a calling party where the verification fails, due to the timer expiring. Steps-of the methodare the same as in the methoddescribed above with reference to. However, in step, before the push notificationis received by Bobincluding the OTP/value from Alice, the timer times out. At this point, in this example, a notification is presented to Bob to indicate that the caller ID verification process has failed.

10 FIG. 1000 610 810 1002 614 618 626 628 600 620 630 630 620 1004 628 620 1006 612 1008 shows another example of communications in an example methodof verifying a calling party where the verification fails, due to Alice not supporting caller ID verification. For example, Alice's device may not have the applicationorinstalled. In step, Alice calls Bob's caller ID. This does not happen via the application on Alice's device as in the methods described above. Steps,,andare the same as for the methoddescribed above. However, Alice is not registered with the push notification server(e.g. the appropriate application is not registered with the push notification server), and hence a push notification cannot be sent to Alice's device by the push notification server. Therefore, the push notification serverinforms the application serverin stepthat the push notification requestis rejected. The application serverthen indicatesto the applicationon Bob's device that the verification request is rejected, and in stepa notification may be displayed to Bob that the notification process failed, for example by indicating that Alice does not support caller ID verification.

In some examples the use of out of band verification requests and that the verification is performed in the opposite direction to the call or call request (i.e. it addresses the device to which the caller ID has been registered) may assure that the request for verification reaches the owner of the caller ID. This could be compromised for example if an attacker manages to register a caller ID as their own with a verification service (e.g. push notification service or instant messaging service, or any other possible solution). However, this is considered to be very improbable.

In some examples, security is maintained as long as the spoofer cannot spoof the out of band verification response messages that the calling party sends to the called party, and at the same time sniff or guess the OTP sent by the called party. The former may be possible, but the latter may require that the attacker has compromised the service that is used to transfer the OTP. This is considered improbable in the case of a service that provides end-to-end encryption, like a push notification service over secure transport layer or an instant messaging service such as Viber. The use of SMS may be considered to be less secure, but still may be advantageous as compared to not having an additional mechanism that verifies the caller ID.

11 FIG. 1100 1100 1102 1104 1102 1104 1110 1102 1100 1106 1102 1106 1102 1104 is a schematic of an example of an apparatusfor verifying a calling party. The apparatuscomprises processing circuitry(e.g. one or more processors) and a memoryin communication with the processing circuitry. The memorycontains instructions, such as computer program code, executable by the processing circuitry. The apparatusalso comprises an interfacein communication with the processing circuitry. Although the interface, processing circuitryand memoryare shown connected in series, these may alternatively be interconnected in any other way, for example via a bus.

1104 1102 1100 1100 100 1 FIG. In one embodiment, the memorycontains instructions executable by the processing circuitrysuch that the apparatusis operable/configured to receive, on a first communication channel, a call request, the call request identifying a calling party; send, to the calling party on a second communication channel different from the first communication channel, a verification request that the calling party is an originator of the call request, the verification request identifying a first value; and if a reply to the verification request is received from the calling party indicating that the calling party is the originator of the call request, and the reply identifies a second value based on the first value, determine that the calling party is the originator of the call request. In some examples, the apparatusis operable/configured to carry out the methoddescribed above with reference to.

12 FIG. 1200 1200 1202 1204 1202 1204 1210 1202 1200 1206 1202 1206 1202 1204 is a schematic of an example of an apparatusfor verifying a calling party. The apparatuscomprises processing circuitry(e.g. one or more processors) and a memoryin communication with the processing circuitry. The memorycontains instructions, such as computer program code, executable by the processing circuitry. The apparatusalso comprises an interfacein communication with the processing circuitry. Although the interface, processing circuitryand memoryare shown connected in series, these may alternatively be interconnected in any other way, for example via a bus.

1204 1202 1200 1200 200 2 FIG. In one embodiment, the memorycontains instructions executable by the processing circuitrysuch that the apparatusis operable/configured to receive, on a second communication channel different from a first communication channel for calls and/or requests for calls, a verification request that a calling party is an originator of the call request, the verification request identifying a first value; and if the calling party is the originator of the call request, send a reply to a sender of the verification request indicating that the calling party is the originator of the call request, the reply identifying a second value based on the first value. In some examples, the apparatusis operable/configured to carry out the methoddescribed above with reference to.

It should be noted that the above-mentioned examples illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative examples without departing from the scope of the appended statements. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the statements below. Where the terms, “first”, “second” etc. are used they are to be understood merely as labels for the convenient identification of a particular feature. In particular, they are not to be interpreted as describing the first or the second feature of a plurality of such features (i.e., the first or second of such features to occur in time or space) unless explicitly stated otherwise. Steps in the methods disclosed herein may be carried out in any order unless expressly otherwise stated. Any reference signs in the statements shall not be construed so as to limit their scope.