Caller verification method

GB202418914D0Pending Publication Date: 2025-02-05THE COURT OF EDINBURGH NAPIER UNIV
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
GB2024018914
Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-12-20
Publication Date
2025-02-05

AI Technical Summary

Technical Problem

Impersonation and impersonator fraud in voice communications, exacerbated by AI and voice cloning technologies, result in significant financial losses and erode trust, with global statistics showing billions lost annually due to phone-based scams.

Method used

A telecommunication method using public key encryption and a trusted third-party network to verify caller identities through encrypted messages, ensuring secure communication channels without revealing personal information, and utilizing a public immutable ledger to validate phone numbers.

Benefits of technology

Enhances caller verification, reducing financial losses and bolstering trust by ensuring legitimate calls are recognized, while maintaining privacy and security, and providing a credible source of truth for phone numbers.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader

Abstract

A telecommunication method comprising: a caller entity 110 initiating a communication link to a callee entity 120 using a public switched telephone network; the caller generating a first encrypted mes
Need to check novelty before this filing date? Find Prior Art

Description

Field of the Invention Aspects of the present disclosure relate generally to phone call fraud detection and more specifically to privacy preserving caller verification. Background of the Invention The menace of impersonation and / or impostor fraud is prevalent in voice communications and may result in significant financial losses, eroding trust in society. An attacker may pose as a representative from a legitimate business, manipulate callerID information, and deceive victims into sharing sensitive information and / or making fraudulent payments. The emergence of Al and voice cloning technologies further complicates the identification of legitimate counterparties. Impersonation fraud is a global issue that costs businesses and their customers billions annually. United Kingdom Victims in the United Kingdom lost £2.35 billion to fraud in 2021 and the banking and finance industry lost £1.3 billion. The UK’s Finance's Fraud Report in 2022 reported financial losses owing to authorized push payment (APP) fraud reaching £583 million, a significant increase from previous years. This often involved phone-based scams including impersonation fraud. Ofcom's 2022 update reported that nearly 60 million UK citizens were targeted by scam calls and texts in 2022, further underscoring the increasing prevalence and sophistication of such frauds. Europe Europol's Internet Organized Crime Threat Assessment (IOCTA) in 2022 noted a sharp increase in voice phishing (vishing) and other telephone-based frauds across the EU. Europol has highlighted the evolving threat of cyber-enabled frauds, including those using telecommunication platforms to exploit individuals and businesses. The European Union Agency for Cybersecurity (ENISA) Threat Landscape reported in 2022 that telecommunications fraud, including vishing, remained a significant threat in the EU, with losses amounting to hundreds of millions of Euros annually. According to a 2023 Statists survey on cybersecurity issues, approximately 30% of Ell internet users reported experiencing some form of communication fraud, including unsolicited calls and messages in the past year. USA Nearly 1 in 3 Americans fell victim to a phone scam in 2021, with 19% having fallen victim more than once. The estimated loss from phone scams in the US alone in 2020 / 21 was $29.8 billion. The Federal Trade Commission (FTC) reported on consumers losing over $8.8 billion to fraud in 2022, up from $5.8 billion in 2021. Phone calls remained one of the primary means of contact for scams. In 2023, U.S. residents received over 4 billion robocalls per month on average, many of which are attempts at fraud or scams. The Federal Communications Commission (FCC) reports that unwanted calls - including illegal and spoofed robocalls - are the FCC's top consumer complaint. Globally The Global Economic Crime and Fraud Survey 2020 by PricewaterhouseCoopers (PwC) found that 47% of companies experienced fraud in the past 24 months, with customer fraud being one of the top incidents, and a significant part of these frauds involved communication via telephone. The Truecaller Insights Report 2022 reported that global scam calls continued to rise, with users in several countries reporting an increase in scam and fraud attempts via telephone. First Orion's 2023 Scam Call Report found that international scam call rates are increasing, with an estimate that one in every ten calls globally could be a scam attempt by 2025. These recent statistics paint a clear picture of an escalating problem. Accordingly, there is a desire for improved solutions to protect consumers and businesses worldwide. Summary of the Invention In a first aspect, there is provided a telecommunication method comprising: initiating, by a caller entity, a communication link between said caller entity and a callee entity using a public switched telephone network; generating, by the caller entity, a first encrypted message comprising a telephone number associated with the caller entity; sending, by the caller entity to a network entity, the first encrypted message including a unique device ID associated with the callee entity; sending, by the network entity, the first encrypted message to the callee entity based on the unique device ID; decrypting, by the callee entity, the first encrypted message; and verifying the caller entity based on the telephone number comprised in the first encrypted message and an incoming telephone number associated with the communication link. The method may comprise, prior to the initiating of the communication link; sharing, from the caller entity to the callee entity, a message comprising a unique device ID and the telephone number associated with the caller entity; generating, by the callee entity, a second encrypted message comprising the unique device ID associated with the callee entity; and sending, to the caller entity from the callee entity, the second encrypted message via the network entity using the unique device ID associated with the caller entity. The message may comprise a public key associated with the caller entity; the second encrypted message may comprise a public key associated with the callee entity; and the first encrypted message may be encrypted using the public key associated with the callee entity and the second encrypted message may be encrypted using the first public key associated with the caller entity. The message may be communicated via a short message service or a web-based communication protocol. The method may further comprise decrypting, by the caller entity, the second encrypted message based on a private key associated with the caller entity. The method may comprise decrypting, by the callee entity, the first encrypted message based on a private key associated with the callee entity. The method may comprise encrypting the first encrypted message and / or the second encrypted message based on a homomorphic encryption method. The step of verifying the caller entity may comprise comparing the telephone number comprised in the first encrypted message to the incoming telephone number associated with the communication link. The first encrypted message may further comprise any of a message type, a request to the network entity to push the message to the callee entity and / or call purpose. The method may further comprise storing, by the network entity, a database of registered unique device IDs. The method may further comprise storing, by the caller entity and / or callee entity, a local database comprising any of a telephone number, a public key, a unique device ID and / or incoming messages associated with other caller entities and / or callee entities. The method may further comprise sending the encrypted message to the callee entity using a token-based messaging service. The unique device ID associated with the caller and / or callee entity may comprise a randomised identifier, and the method may further comprise; associating, by the network entity, a plurality of caller and / or callee entities with the randomised identifier; synchronising the randomised identifier with the caller and / or callee entities; and routing the first encrypted message and / or second encrypted message based on the randomised identifier. The randomised identifier may comprise a first random identifier and a second random identifier. The the first random identifier and the second random identifier may be alternatively updated periodically by the network entity. The method may further comprise determining by the callee entity that there is no corresponding entry in a local database associated therewith for the incoming telephone number; and sending a request to the network entity to validate the incoming telephone number. The method may further comprise receiving, by the callee device from the network entity, and indication that the telephone number is associated with a registered caller entity; receiving, by the callee device from the network entity, a unique device ID and public key associated with the registered caller entity; and sending, by the callee entity to the caller entity via the network entity, an encrypted message based on the unique device ID and public key associated with the registered caller entity via the network entity, said encrypted message comprising the unique device ID and a public key associated with the callee entity. The method may further comprise publishing, by the caller entity in a public immutable ledger, a list of telephone numbers associated with the caller entity, wherein the network entity validates the telephone number based on the public immutable ledger. The public immutable ledger may comprise a blockchain. The method may further comprise generating, by the caller entity and / or callee entity, a backup file comprising user-related data; encrypting and storing the backup file; and sharing an encryption key associated with the encryption step among a plurality of other caller entities and / or callee entities. In a second aspect, there is provided a telecommunications system comprising: a caller entity; a callee entity; and a network entity; wherein the telecommunications system is configured to perform the method according to the first aspect. In a third aspect there is provided a computer readable medium comprising instructions stored thereon such that when executed by a suitable electronic device, cause the device to perform the method according to the first aspect. Brief Description of the Drawings Figure 1 depicts a telecommunications system in accordance with some embodiments; Figure 2 depicts a telecommunications method in accordance with some embodiments; and Figure 3 depicts a telecommunications method in accordance with some embodiments. Detailed Description Aspects of the present disclosure relate to the provision of a mechanism that assures users that they will be notified if they receive a spoofed or impersonated phone call. Methods and systems are provided that facilitate trust between a caller (e.g., a business agent or a personal contact) and a user (i.e., the receiver of a telephone call). In some embodiments, a third-party service may be deployed to facilitate verification. Advantageously, owing to the various aspects and embodiments described herein, said third party does not have the ability to discern the identity of a calling or receiving party. Aspects of the present disclosure allow, for example, business-to-customer authentication, enabling a business to authenticate themselves to a customer, thus allowing organizations to securely interact with their customers, conduct business, preserve their reputation, and reduce financial losses. Aspects of the present disclosure also allow, for example, human-to-human authentication, allowing individuals to protect themselves and their friends, families, contacts and the like, and counter the emerging challenge of Al and deepfakes. The solutions proposed herein leverage public key encryption technology to establish an infrastructure that enables a trusted third party (TTP) to determine if an outbound call is intended for a specific phone number (e.g., a user device) without disclosing information about the caller or the recipient. With reference to Figure 1, a system according to the present disclosure may comprise a caller entity 110, a callee entity 120 and a network entity 130. In some examples, caller entity 110 may comprise a software application installed on a user device such a mobile telephone. In other example, for example when the caller is an agent of a business, caller entity may comprise a client application programming interface (API) Similarly, callee entity 120 may comprise a software application installed on a user device such a mobile telephone, or, for example when the caller is an agent of a business, callee entity 120 may comprise a client application programming interface (API). The terms caller and callee are used herein to discern between an entity that initiates a call (caller) and an entity that receives said call (callee) for the purposes of demonstration only. In practice, a callee entity may comprise the same functions as a caller entity and vice versa, and a callee entity may implement all the steps implemented by a caller entity and vice versa. For example, the caller entity 110 and the callee entity 120 may both be associated with respective mobile devices having the same capabilities. Network entity 130 may comprise a core network managed by a trusted third party and may comprise a core network API. Network entity 130 may further comprise a web-based messaging service such as a cloud messaging service CMS for receiving from and / or pushing messages to the caller entity 110 and / or callee entity 120. Caller entity 110 and / or callee entity 120 may be configured to generate a public / private key pair that may be used for encrypting messages. Caller entity 110 and / or callee entity 120 may further be configured to generate a unique device ID that may serve to identify a device associated with the caller entity 110 and / or callee entity 120 (e.g., a mobile device) without revealing any personal identifying information related to the device, e.g., a telephone number. Caller entity 110 and / or callee entity 120 may register an associated device (i.e., a respective device associated with each of caller entity 110 and / or callee entity 120) with network entity 130. Said registration may comprise storing, by the network entity 130, the public key and the unique device ID as provided by a respective caller entity 110 and / or callee entity 120. In some examples, upon registration with the network entity, caller entity 110 and / or callee entity 120 may retrieve a token from the network entity that serves to identify a respective device associated with the caller entity 110 and / or callee entity 120, said token enabling messages to be pushed from the network entity (e.g., using the afore-mentioned web based messaging service) to the respective caller entity 110 and / or callee entity 120. In some examples, caller entity 110 and / or callee entity 120 may use a suitable communication channel such as short message service (SMS), web-based messaging service, email, or any other suitable communication channel to share between them their respective public key and unique device ID (e.g., using a deep link embedded in a message). The caller entity 110 and / or callee entity 120 may thus receive and store (e.g., in a local database) respective telephone numbers, public keys and unique device IDs of other caller entities and / or callee entities prior to the initiation of a telephone call. In this way, a caller entity 110 may encrypt a message that may be routed anonymously to a callee entity 120 using their respective device ID via network entity 130. In some examples, a public key and unique device ID from a caller entity 110 and / or callee entity 120 may be comprised in an invitation to a respective caller entity 110 and / or callee entity 120 (i.e., a message comprising an invitation to establish a secure connection), said invitation sent using the afore-mentioned suitable communication channel (e.g., SMS). The caller entity 110 and / or callee entity 120 in receipt of said invitation may store the public key and unique device ID of the inviting caller entity 110 and / or callee entity 120 (e.g., in a local database), and generate a first encrypted message based on said public key. The invited caller entity 110 and / or callee entity 120 my then send the first encrypted message via network entity 130 to the inviting caller entity 110 and / or callee entity 120, said first encrypted message indicating their own respective public key and unique device ID and sent to the inviting caller entity 110 and / or callee entity 120 using the unique device ID comprised in the initial invitation. The first encrypted message may include an indication that the invited caller entity 110 and / or callee entity 120 initially accepts the invitation. The inviter caller entity 110 and / or callee entity 120 may decrypt the first encrypted message and thus receive and store the public key and unique device ID associated with the invitee caller entity 110 and / or callee entity 120. The inviter caller entity 110 and / or callee entity 120 may further generate a second encrypted message based on the received public key and unique device ID associated with the invitee caller entity 110 and / or callee entity 120, said second encrypted message comprising a telephone number associated with the inviter 110 and / or callee entity 120. The inviter caller entity 110 and / or callee entity 120 may send the second encrypted message to the invitee caller entity 110 and / or callee entity 120 (i.e., via network entity 130). The invitee caller entity 110 and / or callee entity 120 may decrypt the second encrypted message to receive the telephone number associated with the inviter caller entity 110 and / or callee entity 120, and compare the received telephone number to entries in the local database of invitee caller entity 110 and / or callee entity 120. Upon determining a match between the received telephone number and a database entry, said invitee caller entity 110 and / or callee entity 120 may generate a third encrypted message to the inviter caller entity 110 and / or callee entity 120 formally accepting the invitation. In this way a secure channel may be generated via the network entity 130 without revealing (to the network entity 130) identifying information related to caller entity 110 and / or callee entity 120. Still referring to Figure 1, in a purely exemplary embodiment a caller entity 110 may be enabled to initiate a public switched telephone network (PSTN) communication link 115 with a callee entity 120. A user of a device associated with callee entity 120 may receive a notification that there is an incoming communication link, e.g., that they are being called. Said device may display a telephone number to the user associated with the caller entity 110. Typically, a user of such a device has no recourse to determine the legitimacy of the telephone call, e.g., if the telephone number displayed to them has been spoofed. Aspects of the present disclosure may serve to mitigate any ambiguity of the legitimacy of an incoming telephone call as described further below. Upon initiating the PSTN communication link with the callee entity 120, caller entity 110 may generate an encrypted message based on the public key associated with the callee entity 120. Said encrypted message may comprise a telephone number associated with the caller entity 120 and an indication that the PSTN communication link has been initiated. In some examples, the encrypted message may further comprise any of an indication of the call purpose and / or an indication of the message type (e.g., contact is calling, business is calling and / or customer is calling). Other message types may include, for example, an invitation to create a secure communications channel, and acceptance of said invitation. In other examples as will become apparent later, the message type may include a store request to store a share of an encryption key associated with a data backup associated with a caller entity 110 and / or callee entity 120, an acceptance of said store request, or a withdraw request to withdraw said share. In some examples, the encrypted message may be generated based on homomorphic encryption methods, for example full homomorphic encryption. The caller entity 110 may send the encrypted message to the network entity 130 including the device ID of the callee entity 120 using a web-based communication link 125. The network entity 130 may subsequently push the encrypted message using a web-based messaging service link 135 to the callee device 120 using the unique device ID included with the encrypted message. The encrypted message may be sent including a request to push the encrypted message by the network entity 130 to the callee entity 120. Callee entity 120 may determine the telephone number of the incoming PSTN communication link (e.g., by retrieving from the operating system of a mobile device comprising said callee entity 120). The callee entity may look up the telephone number associated with the incoming call on the local database which has entries comprising respective telephone numbers and unique device IDs of known associates (i.e., respective caller entity 110 and / or callee entity 120 with which public keys and unique device IDs have been shared). Said local database may comprise corresponding entries for messages received from network entity 130. Thus, upon receipt of a telephone call, callee entity 120 may compare the incoming telephone number against the local database and determine if there is a corresponding incoming message associated with that telephone number. Thus, when there is a corresponding incoming message in the local database, callee entity 120 may make a determination that the incoming telephone call is legitimate. In some examples, when a telephone call is determined to be legitimate, the callee entity may indicate to a user of a device associated with the callee entity 120 that the call is legitimate, e.g., display a message on the screen of a mobile device that the call is legitimate. In other examples, for example when there is no corresponding incoming message in the local database, callee entity 120 may make a determination that the incoming telephone call is not legitimate and indicate to a user of the device associated with the callee entity 120 that the call is not legitimate, e.g., display a message on the screen of a mobile device that the call is not legitimate. With reference to Figure 2, and by way of further explanation, at step 200, caller entity 110 may initiate a PSTN communication link with callee entity 120. At step 210, caller entity 110 may generate an encrypted message M based on a public key associated with the callee entity 120. Encrypted message M may include a telephone number associated with the caller entity 110. At step 220, caller entity 110 may send the encrypted message M to network entity 130 including the unique device ID associated with callee entity 120. At step 230, the network entity 130 may push the encrypted message M to callee entity 120 using the unique device ID associated with callee entity 120. At step 240, callee entity 120 may decrypt the encrypted message (e.g., using a private key associated with the callee entity 120) and compare an incoming telephone number associated with the PSTN communication link to information comprised in the incoming message M (e.g., the telephone number associated with the caller entity 110). With reference to Figure 3, in a first aspect of the present disclosure there is provided a telecommunication method 300 comprising initiating 310, by a caller entity 110, a communication link between said caller entity 110 and a callee entity 120 using a public switched telephone network. The method further comprises generating 320, by the caller entity 110, an encrypted message comprising the telephone number associated with the caller entity 110 and used to initiate the communication link. In some examples, caller entity 110 may generate the encrypted message based on a public key associated with the callee entity 120. Caller entity 110 may store the public key in a local database associated therewith along with a unique device ID and telephone number associated with the callee entity 120. The method further comprises sending 330, by the caller entity 110 to a network entity 130, the encrypted message including a unique device ID associated with the callee entity 120. The method further comprises sending 340, by the network entity 130, the encrypted message to the callee entity 120 based on the unique device ID. The method further comprises decrypting 350, by the callee device 120, the encrypted message (e.g., based on a private key associated with the callee entity 120); and verifying the caller entity based on the telephone number indicated in the encrypted message and an incoming telephone number associated with the first communication link. In some examples, the callee device may compare the telephone number indicated in the encrypted message with the incoming telephone number associated with the first communication link. In some examples, e.g., when a callee entity 120 receives an initiation of a PSTN communication link from an unknown number (i.e., not comprised in local database comprised in the callee entity 120), the callee entity 120 may send a request to the network entity 130 to determine whether the incoming telephone number is currently associated with a business registered with the network entity 130. If the telephone number is associated with a business registered with the network entity 130, the callee device may retrieve the public key and unique device ID associated with the business from the network entity 130 and create a local database entry for that business. The callee device may generate an encrypted message including the public key associated with the callee device and send the encrypted massage to the business via the network entity 130 using the unique device ID associated with the business. In this way, the callee may register (and be registered) with the business thus creating a secure communication channel. In some examples, establishing a credible source of truth that associates phone numbers with businesses without relying on a vulnerable crowd-based method is proposed. To this end, businesses may publish telephone numbers associated therewith, accessible by the network entity (for example through a domain-prefixed URL) and stored in a public immutable ledger (e.g., a blockchain). In this way, an immutable record of active or obsolete phone numbers may be created, thus enhancing forensic capabilities. Manual verification may ensure accurate linkage between enterprise names and domain names, bolstering the system's integrity. In that regard, in some examples businesses may host a record of telephone numbers on their domain (e.g., a .json file). For example, if a business domain is business.com, the corresponding file can be accessed via https: / / business.com / phones.json. In some examples, a blockchain smart contract may navigate through designated domain names (e.g., using a blockchain oracle), recording and storing phone numbers in an immutable ledger. Said ledger serves as a definitive source of truth for phone numbers, utilized to determine the legitimacy of customer-received phone calls. Thus, there is provided a centralized storage of telephone numbers, ensuring traceability for forensic purposes. To minimize an exposure risk, user-related data may be retained on a user device (a mobile device associated with caller entity 110 and / or callee entity 120). User-related data may comprise, for example, connections with individuals and businesses and call logs. In some examples there is proposed a distributed data backup method, comprising exporting user-related data of a user to a file, and encrypting said file (e.g., using AES-256 encryption). The encrypted file may be stored, for example, using cloud-based storage methods. To enhance the security of the encrypted file, in some examples an encryption key associated with the encrypted file may be shared amongst trusted users associated with the user (e.g., users having details stored in the local database comprised in caller entity 110 and / or callee entity 120 associated with the user). That is, a sharing algorithm such as Shamir's Secret Sharing algorithm may be used to split the encryption key into multiple shares, said shares distributed to devices associated with the trusted users. Caller entity 110 and / or callee entity 120 may generates said encryption key associated with the encrypted file and divide it into e.g., m shares such that the key can be recovered based on k shares, wherein m is a total number of shares and k is a minimum number of shares required to decrypt the encrypted file. In the case of a lost or replaced device, a user of said device may perform the steps of verifying their telephone number (e.g., using a third-party telephone number verification service), selecting the encrypted file from the stored location, and sending a request to trusted users to retrieve the shares. To decrypt the backup file, the user may gather the necessary number of shares (i.e., k) from the trusted users. Once the encryption key is reconstructed from the k shares, the backup file can be decrypted, and data can be restored on the user’s new or replacement device. The proposed enhanced backup process mitigates the risks associated with storing user data e.g., on a backend server (for example, the network entity 130) and provides a secure method for data recovery. By leveraging a sharing algorithm, it is ensured that the encryption key is securely managed and can only be reconstructed with a quorum of trusted connections, significantly reducing the risk of unauthorized access. As previously discussed, messages from caller entity 120 to callee entity 110 are encrypted and sent to network entity 130 which then routes the encrypted message to the callee entity 120 based on a unique device ID included with the encrypted message. The network entity 130 cannot decrypt the message or determine which user is calling whom. In some scenarios, an attacker may attempt to perform statistical analysis, e.g., a collaboration between a malicious actor at the caller entity 110 and a malicious actor at the network entity 130 to link a specific unique device ID to a particular user. With knowledge of the telephone number of a target user, a malicious actor at the caller entity 110 side may provide message details to a malicious actor at the network entity 130, who may identify the unique device ID that the message is pushed to. In this way, both malicious actors may link the unique device ID to a target user, allowing the monitoring calls involving that device. In order to mitigate this scenario, there is proposed a unique mixing mechanism by the network entity 130. In such an example, when a caller entity 110 and / or callee entity 120 registers with the network entity 130, the unique device ID may comprise a randomised identifier. In some examples, the randomised identifier may comprise first and second random identifiers, e.g., group_id_1 and group_id_2. The randomised identifier may be stored by the network entity 130 (e.g., along with details such as the public key associated with said caller entity 110 and / or callee entity 120). The randomised identifier (e.g., group_id_1 and group_id_2) may be assigned a random value(s) which may be updated periodically by the network entity. The network entity may associate a predetermined number of callee entities with the randomised identifier (e.g., 5, 10, 15 and so on). Values for the randomised identifier may be synchronised with a caller entity 110. Upon initiating a PSTN communication link with a callee entity 120 as described previously, the caller entity 120 may generate an encrypted message and send the encrypted message to the network entity 130 including the randomised identifier (i.e., rather than using the unique device ID). When the network entity 130 receives the encrypted message, it may identify all callee entities 120 associated with the randomised identifier. This may return the predetermined number of callee entities 120 (e.g., 5, 10, 15... etc.). The network entity 130 then sends the message to the returned number of callee entities 120. Owing to the encryption of the message, only the intended recipient is able to decrypt the message, whilst no malicious user is able to determine the specific target recipient from the predetermined number of callee entities 120. In an example, the network entity 130 may alternately update group_id_1 and group_id_2 hourly. In the first hour, group_id_1 for a predetermined number of corresponding caller entities 110 and / or callee entities 120 may be updated to a random value. In the next hour, the network entity may update group_id_2 in the same manner. The hourly rotation may continue alternately for group_id_1 and group_id_2. In a second aspect, there is provided a telecommunications system comprising: a caller entity; a callee entity; and a network entity; wherein the telecommunications system is configured to perform the method according to the first aspect. In a third aspect, there is provided a computer readable medium comprising instructions stored thereon such that when executed by a suitable electronic device, cause the device to perform the method according to the first aspect. The description provided herein may be directed to specific implementations. It should be understood that the discussion provided herein is provided for the purpose of enabling a person with ordinary skill in the art to make and use any subject matter defined herein by the subject matter of the claims. It should be intended that the subject matter of the claims not be limited to the implementations and illustrations provided herein, but include modified forms of those implementations including portions of implementations and combinations of elements of different implementations in accordance with the claims. It should be appreciated that in the development of any such implementation, as in any engineering or design project, numerous implementation-specific decisions should be made to achieve a developers’ specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort may be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having benefit of this disclosure. For example, the presently disclosed systems and methods may be implemented in parallel or in combination with other substrate characterization methods including, for example, the use of camera technologies. Reference has been made in detail to various implementations, examples of which are illustrated in the accompanying drawings and figures. In the detailed description, numerous specific details are set forth to provide a thorough understanding of the disclosure provided herein. However, the disclosure provided herein may be practiced without these specific details. In some other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure details of the embodiments. It should also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and, similarly, a second element could be termed a first element. The first element and the second element are both elements, respectively, but they are not to be considered the same element. The terminology used in the description of the disclosure provided herein is for the purpose of describing particular implementations and is not intended to limit the disclosure provided herein. As used in the description of the disclosure provided herein and appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The terms “includes,” “including,” “comprises,” and / or “comprising,” when used in this specification, specify a presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof. While the foregoing is directed to implementations of various techniques described herein, other and further implementations may be devised in accordance with the disclosure herein, which may be determined by the claims that follow. Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A telecommunication method comprising:initiating, by a caller entity, a communication link between said caller entity and a callee entity using a public switched telephone network;generating, by the caller entity, a first encrypted message comprising a telephone number associated with the caller entity;sending, by the caller entity to a network entity, the first encrypted message including a unique device ID associated with the callee entity;sending, by the network entity, the first encrypted message to the callee entity based on the unique device ID;decrypting, by the callee entity, the first encrypted message; andverifying the caller entity based on the telephone number comprised in the first encrypted message and an incoming telephone number associated with the communication link.

2. The method of claim 1, further comprising:prior to the initiating of the communication link;sharing, from the caller entity to the callee entity, a message comprising a unique device ID and the telephone number associated with the caller entity ;generating, by the callee entity, a second encrypted message comprising the unique device ID associated with the callee entity; andsending, to the caller entity from the callee entity, the second encrypted message via the network entity using the unique device ID associated with the caller entity. .

3. The method of claim 2, wherein:the message comprises a public key associated with the caller entity;the second encrypted message comprises a public key associated with the callee entity;and wherein the first encrypted message is encrypted using the second public key and the second encrypted message is encrypted using the first public key.

4. The method of claim 2 or 3, wherein the message comprises a deep link and wherein the message is communicated via a short message service or a web-based communication protocol.

5. The method of claims 2 to 5, further comprising decrypting, by the caller entity, the second encrypted message based on a private key associated with the caller entity.

6. The method of any previous claim, further comprising decrypting, by the callee entity, the first encrypted message based on a private key associated with the callee entity.

7. The method of any previous claim, further comprising encrypting the first encrypted message and / or the second encrypted message based on a homomorphic encryption method.

8. The method of any previous claim, wherein the step of verifying the caller entity comprises comparing the telephone number comprised in the first encrypted message to the incoming telephone number associated with the communication link.

9. The method of any previous claim, wherein the first encrypted message further comprises any of a message type, a request to the network entity to push the message to the callee entity and / or call purpose.

10. The method of any previous claim, further comprising storing, by the network entity, a database of registered unique device IDs.

11. The method of any previous claim, further comprising storing, by the caller entity and / or callee entity, a local database comprising any of a telephone number, a public key, a unique device ID and / or incoming messages associated with other caller entities and / or callee entities.

12. The method of any previous claim further comprising sending the encrypted message to the callee entity using a token-based messaging service.

13. The method of any previous claim, wherein the unique device ID associated with the caller and / or callee entity comprises a randomised identifier, and wherein the method further comprises;associating, by the network entity, a plurality of caller and / or callee entities with the randomised identifier;synchronising the randomised identifier with the caller and / or callee entities; androuting the first encrypted message and / or second encrypted message based on the randomised identifier.

14. The method of claim 13, wherein the randomised identifier comprises a first random identifier and a second random identifier.

15. The method of claim 14, wherein the first random identifier and the second random identifier are alternatively updated periodically by the network entity.

16. The method of any previous claim further comprising:determining by the callee entity that there is no corresponding entry in a local database associated therewith for the incoming telephone number; andsending a request to the network entity to validate the incoming telephone number.

17. The method of claim 16 further comprising:receiving, by the callee device from the network entity, and indication that the telephone number is associated with a registered caller entity;receiving, by the callee device from the network entity, a unique device ID and public key associated with the registered caller entity; andsending, by the callee entity to the caller entity via the network entity, an encryptedmessage based on the unique device ID and public key associated with the registered callerentity via the network entity, said encrypted message comprising the unique device ID and a public key associated with the callee entity.

18. The method of any of claims 16 or 17, further comprising:publishing, by the caller entity in a public immutable ledger, a list of telephone numbers associated with the caller entity, wherein the network entity validates the telephone number based on the public immutable ledger.

19. The method of claim 18, wherein the public immutable ledger is a blockchain.

20. The method of any previous claim further comprising;generating, by the caller entity and / or callee entity, a backup file comprising user-related data;encrypting and storing the backup file; andsharing an encryption key associated with the encryption step among a plurality of other caller entities and / or callee entities.

21. A telecommunications system comprising:a caller entity;a callee entity; anda network entity; whereinthe telecommunications system is configured to perform the method of any of claims 1 to 20.

22. A computer readable medium comprising instructions stored thereon such that when executed by a suitable electronic device, cause the device to perform the method of any of claims 1 to 20.