Technology used for call authentication

Abstract

Various embodiments described herein are directed to authenticating a call by using one or more keys associated with a specific user. In an example, the user is the sender of the call. In various embodiments, when a call is made, an identification payload is encrypted using a private key associated with the user. The encrypted identification payload is attached to the call data stream. The identification payload can be decrypted using a public key. In an embodiment, the identification payload can be verified. In various embodiments, further verification methods can be performed using an object such as a contactless card to provide one or more components of the identification payload and / or key. In an embodiment, based on the verification of the identification payload, a connection can be made between the sender of the call and the intended recipient.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to U.S. Patent Application No. 16 / 517,074, filed on July 19, 2019, entitled “Technology for Call Authentication” (U.S. Patent No. 10,506,426, issued on December 10, 2019). The contents of the above patent application are incorporated herein by reference in their entirety. Background Art

[0003] Unsolicited phone calls present annoyance and security risks to the recipient of the call. The recipient may be subjected to nuisance calls such as telemarketing, prank calls, and / or silent calls. Unsolicited calls may also be used to initiate phone scams, in which an imposter impersonates a legitimate entity in an attempt to steal information or funds.

[0004] Telephone call authentication involves attempting to identify the calling party. However, current methods lack the ability to reliably authenticate the calling device and the calling party. Furthermore, such methods are sparsely implemented at best and are subject to practices such as spoofing, where a caller may use a false identity and / or number to trick the call recipient into answering. As a result, users often do not trust the communication system at best. At worst, they may be subject to harassment and / or security risks. Summary of the invention

[0005] According to one aspect of the present invention, a method for performing point-to-point authentication of a call includes the following steps: receiving an incoming call data stream from a first mobile phone device, the incoming call data stream including an incoming call number of a second mobile phone device, and the encrypted payload includes payload data encrypted using a private key associated with the first mobile phone device. In some embodiments, the private key includes a dynamic key of the first mobile phone device, and the encrypted payload includes a password. The method may include authenticating the incoming call data stream in response to a match between the encrypted payload and stored information related to the first mobile phone device. In various aspects, the authentication includes forwarding the password to an authentication server, wherein the authentication server maintains and modifies a copy of the dynamic password simultaneously with the first mobile phone device as stored information related to the first mobile phone device. In some embodiments, the authentication further includes receiving verification of the first mobile phone device from the authentication server in response to a counter match between a counter extracted from the password using a copy of the dynamic key and an expected counter associated with the first mobile phone device. The method may further include selectively establishing a call connection between the first mobile phone device and the second mobile phone device in response to the step of authentication.

[0006] According to another aspect of the present invention, a system for authenticating calls between devices includes an interface configured to receive an incoming call data stream from a first mobile phone device. In some embodiments, the incoming call data stream includes an incoming call number associated with a second mobile phone device, and an encrypted payload containing payload data encrypted using a private key associated with the first mobile phone device. In some embodiments, the system includes a processor coupled to the interface and a non-volatile memory having program code stored thereon, the program code being operable when executed by the processor to authenticate the incoming call data stream in response to a match between information in the encrypted payload and stored information associated with the first mobile phone device. The system further includes a communication interface coupled to the processor and configured to selectively establish a call connection between the first mobile phone device and the second mobile phone device in response to an authentication step.

[0007] According to another aspect of the present invention, a method for authenticating a call between mobile devices includes the following steps: receiving an incoming call data stream from a first mobile device. In some embodiments, the incoming call data stream includes an incoming call number associated with a second mobile phone device, and the encrypted payload includes payload data encrypted using a private key associated with the first mobile phone device, and voice message attributes. The method includes retrieving a public key of the incoming call number from a data storage device, and decrypting the encrypted payload using the public key of the incoming call number to generate a decrypted payload including an identifier. The method includes comparing the identifier of the decrypted payload with an expected identifier associated with the incoming call number to determine a first factor authentication match, and comparing the attributes of the voice message with the expected voice message attributes to identify a second factor authentication match. The method further includes selectively establishing a connection between the first mobile phone device and the second mobile phone device in response to the first factor authentication match and the second factor authentication match.

[0008] By such arrangement, a system and method for reliably authenticating an incoming call is provided. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 is a first block diagram of a data transmission system configured to authenticate a user call according to an example embodiment;

[0010] Figure 2 It shows that it can be Figure 1 A detailed block diagram of exemplary components used in the system;

[0011] Figure 3 can be utilized to support aspects of the present invention Figure 1 A detailed block diagram of the components of the system.

[0012] Figure 4 is a diagram showing a sequence for providing authenticated access according to an example embodiment.

[0013] Figure 5 is a second block diagram of a data transmission system configured to authenticate a user call according to an example embodiment.

[0014] Figure 6 is a first logic flow diagram provided to describe exemplary steps that may be performed during one embodiment of a call authentication process; and

[0015] Figure 7 is a second logic flow diagram provided to describe exemplary steps that may be performed during one embodiment of a call authentication process. DETAILED DESCRIPTION

[0016] Some embodiments of the present disclosure are directed to the use of one or more keys that have been incorporated into one or more contactless cards, as described in U.S. patent application Ser. No. 16 / 205,119, filed on Nov. 29, 2018 by Osborn et al., entitled “Systems and Methods for Cryptographic Authentication of Contactless Cards,” and incorporated herein by reference (hereinafter the '119 application). Contactless cards can be used to perform authentication as well as many other functions that might otherwise require a user to carry a separate physical token in addition to the contactless card. By utilizing a contactless interface, a contactless card can be provided with a method for interaction and communication between a user device (e.g., a mobile phone) and the card itself. For example, the near field communication (NFC) protocol that underlies many credit card transactions includes an authentication process that is sufficient to satisfy the requirements of the present disclosure. Operating system needs but for iOS, The latter is more restrictive regarding the use of NFC, as it can only be used in a read-only manner. Exemplary embodiments of contactless cards described in the '119 application can utilize NFC technology. Authentication of a user via a contactless card interface can overcome the identity theft problem of the prior art by verifying the endpoints of the call link.

[0017] Various embodiments described herein are directed to authenticating a call by using one or more keys associated with a particular user. In an example, the user is the sender of the call. In various embodiments, when a call is made, an identification payload is encrypted using a private key associated with the user. The encrypted identification payload is attached to the call data stream. The identification payload can be decrypted using a public key. In an embodiment, the identification payload can be verified. In various embodiments, further verification methods can be performed using an object such as a contactless card to provide one or more components of an identification payload and / or key. In an embodiment, based on the verification of the payload, a connection can be made between the sender of the call and the intended recipient.

[0018] In some embodiments described herein, the private key used to encrypt the identification payload can be stored or published relative to a specific user device. Such a user device can be a network-supported computer. As mentioned herein, the network-supported computer can include, but is not limited to: for example, a computer device, or a communication device including, for example, a server, a network appliance, a personal computer (PC), a workstation, a mobile device, a phone, a handheld PC, a personal digital assistant (PDA), a thin client, a fat client or other devices.

[0019] In some embodiments described herein, the private key used to encrypt the identification payload may be stored or published relative to a separate object associated with the user. For example, as described in the incorporated '119 application and referenced in greater detail herein, the separate object may be a contactless card. The embodiments are not limited in this context.

[0020] In various embodiments described herein, the identification payload may include text data, audio data, digital data, or a combination thereof. For example, the identification payload may include information about an association between a user and a communication service provider, a voice message, or a counter associated with a contactless card. The embodiments are not limited to this context.

[0021] Although unsolicited calls may come from a variety of callers with a variety of purposes, they are often difficult to be identified by the recipients, resulting in a poor user experience for the communication system client and the user's distrust of the communication system.

[0022] For example, caller ID can indicate to the call recipient that the caller is a known contact or display the caller's phone number so that the recipient can recognize the area code therein. However, caller ID can be turned off by the caller. In addition, in the example, the recipient is still notified of the incoming call and must intentionally reject it. In a further example, the harasser can avoid proper identification, such as by spoofing or blocking the caller ID. In a further example, a voice-over-IP user can send a fake caller ID or route the call through servers in multiple countries.

[0023] For the field of telephone communications, the FCC has advocated the implementation of "Signature-based Assertion Information Processing Using toKEN" (SHAKEN) and Secure Telephone Identity Revisit (STIR) standards, but these processes cannot fully authenticate the identity of the caller either. In SHAKEN / STIR, the caller's service provider can create a digital signature based on its knowledge of the origin of the call, such as the customer and its right to use the called number, the customer (but not the number), or the point where the call enters its network. An origin identifier can be assigned to uniquely identify the origin of the call. However, in these processes, the final verification is that the caller has the right to appear in front of the recipient as a certain calling party. The call may not actually come from the number displayed as the caller. For example, fraud approved by the service provider may always occur. Even after the implementation of such a method, the recipient will not be able to determine the identity of the other end of the incoming call communication. An improved system is needed to authenticate the identities of the parties initiating the communication.

[0024] Various embodiments described herein include components capable of enabling one or more of: (1) authentication of a communication initiator associated with a device used to initiate communication, (2) authentication of a communication initiator associated with a device used to initiate communication and separate identification information provided by and / or related to the communication initiator, and (3) authentication of a communication initiator associated with a device used to initiate communication and a separate object unique to the communication initiator (e.g., a contactless card).

[0025] Authentication based on communications from the device to which the communications are sent reduces the likelihood of nuisance communications, including fraud attempts, reaching the receiving client, thereby improving the security of its information. In some embodiments, selective connection of a first client device and a second client device for communications based on the result of authentication or multi-factor authentication can reduce the load of unwanted communications on the client, thereby improving the user experience.

[0026] Therefore, the embodiments disclosed herein utilize the authentication features of at least one client device and / or service provider in practical applications to improve the security of network communications and / or improve the client confidence in the authenticity of the received communications. In multiple embodiments, the components described herein can provide a specific and particular way of authenticating communications and / or managing communications based on the authentication results. In some embodiments, one or more components described herein can be implemented as a set of rules that improve computer-related technologies by allowing functions that the computer could not previously perform, thereby enabling improved technical results. For example, authenticating communications based on identification information associated with the initiator of the communication is such an improved technical result. In another example, the function can include obtaining multi-factor authentication via the features of the client device and / or a separate object (e.g., a contactless card). In another example, the function can include managing communications by selectively connecting devices used for communication based on the results of the multi-factor authentication.

[0027] These and other features of the present invention will now be described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout.

[0028] As used in this application, the terms "system", "component" and "unit" are intended to refer to computer-related entities, which can be hardware, a combination of hardware and software, software, or software in execution, examples of which will be described herein. For example, a component can be, but is not limited to: a process running on a processor, a processor, a hard drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program and / or a computer. By way of illustration, both an application running on a server and a server can be a component. One or more components can reside in a process and / or execution thread, and a component can be located on one computer and / or distributed between two or more computers.

[0029] In addition, components can be communicatively coupled to each other via various types of communication media to coordinate operations. The coordination can involve a one-way or two-way exchange of information. For example, components can transmit information in the form of signals transmitted via communication media. The information can be implemented as signals assigned to various signal lines. In such an assignment, each information is a signal. However, further embodiments can alternatively use data messages. Such data messages can be sent via various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0030] Figure 1A system 100 is shown that includes two or more client devices 125 and 130 coupled via a network 115. In various embodiments, the client devices 125 and 130 include network-enabled computers and communicate with each other via the network 115. In particular, various embodiments include each client device being associated with a private key and a public key. In an embodiment, the client device 125 initiating the communication may send a message 140 that includes a telephone number and a payload encrypted using its own private key 126. The message may be delivered through an authentication router 120 (which is part of the network 115). The encrypted payload of the message 140 may be decrypted using a public key 127 associated with the client device 125. The communication may be delivered to the client device 130. The embodiments are not limited to this context.

[0031] In various embodiments, first client device 125 may initiate communications with the intent to reach one or more client devices 130. Figure 1 Only one device is shown in FIG. 1 , but it will be understood that the communication may have multiple recipients, such as in a group message, conference call, or group video call. The embodiments are not limited in this context.

[0032] Client devices 125 and 130 may include a processor and memory, and it is understood that the processing circuit may contain additional components, including a processor, memory, error and parity check / CRC checker, data encoder, anti-collision algorithm, controller, command decoder, security primitives and anti-tampering hardware, which are necessary for performing the functions described herein. Client devices 125 and 130 may further include a display and an input device. The display may be any type of device for presenting visual information, such as a computer display, a flat panel display, and a mobile device screen, including a liquid crystal display, a light emitting diode display, a plasma panel, and a cathode ray tube display. The input device may include any device for inputting information into a user device, which is available to the user device and supported by the user device, such as a touch screen, a keyboard, a mouse, a cursor control device, a touch screen, a microphone, a digital camera, a video recorder, or a video camera. These devices may be used to input information and interact with the software and other devices described herein.

[0033] One or more of the client devices 125 and 130 may also be mobile computing devices, such as from iPhone, iPod, iPad or any other device running Apple Any mobile device running Microsoft mobile operating system, and / or any other smartphone, or similar wearable mobile device.

[0034] The client devices 125 and 130 may include a thin client application specifically adapted for communicating with a service provider. A service provider may be a business or other entity that provides computer-related services via a network. The thin client application may be stored in a memory of the client device and, when executed by the client device, is operable to control an interface between the client device and the service provider application, thereby allowing a user at the client device to access content and services of the service provider.

[0035] In an embodiment, client device 125 is associated with private key 126 and public key 127. Private key 126 and public key 127 may be related so as to be able to encrypt and decrypt data, such as in a symmetric key encryption or asymmetric key encryption (also referred to as public key encryption). In an embodiment, private key 126 and public key 127 may be different, public key 127 may be used for systems external to client device 125 and private key 126 is intended to be known only to client device 125. In such an embodiment, system 100 may be directed to using asymmetric key encryption. In some embodiments, the same public key may be used for and / or associated with multiple client devices, such as client device 125 and client device 130.

[0036] In various embodiments, private key 126 may be permanent or static. In other embodiments, private key may be a dynamic key. For example, private key 126 may be a rolling key. Private key 126 may be changed, for example, over time, by a counter or other dynamic condition. In various embodiments, the counter by which private key 126 is updated may be advanced by the client's use of client device 125 or a separate object (e.g., a contactless card as described in the '119 application and in more detail herein). It will be readily appreciated that dynamic keys may be updated in response to other events, changes in circumstances, and / or any combination of the foregoing.

[0037] In various embodiments, the association between the private key 126 and / or the public key 127 and the client device 125 can be established at or before the issuance of the client device 125 to the client. For example, the key can be set by the manufacturer of the device, by a service provider, or other entity. In other embodiments, the private key 126 and / or the public key 127 can be linked to the device subsequently. For example, the client device 125 can receive updated keys 126 and 127. In various embodiments, the private key 126 and / or the public key 127 can be stored in a memory on the client device 125, or stored in an external server or database. In various embodiments, the private key 126 and / or the public key 127 can be updated by using an application on the client device and / or by using a separate computer. For example, the private key 126 and / or the public key 127 can be updated or diversified according to dynamic data such as a counter. Such an example can be found in the '119 reference, which is incorporated herein by reference.

[0038] The client device 125 can initiate communication with another client device 130 by generating a message 140. In an embodiment, the message 140 may include an encrypted payload and a phone number. The encrypted payload may be encrypted using a private key 126. The phone number may include the phone number of the client device 125 and / or the client device 130. In an embodiment, the payload encrypted as the encrypted payload of the message 140 may include text, numbers, audio, other data, or a combination thereof. The payload may include unique identification information for a client, a client device 125, or a combination thereof. In addition, the encrypted payload may contain hash data. Such information may be stored in a memory accessible to the client device 125, such as a memory local to the client device or accessible via a network connection. In various embodiments, the encrypted payload may include dynamic information associated with the client, the client device 125, or a separate object (e.g., a contactless card as described in more detail herein). The dynamic information may change with each communication sent by the client device 125 or at another rate. In some embodiments, the public key 127 may be included in the message 140.

[0039] In some embodiments, the encrypted payload and / or message 140 may be appended to the communication from the client device 125. For example, the encrypted payload may be appended to the call data stream. In some embodiments, the communication from the client device 125 may be included in the encrypted payload.

[0040] Message 140 may be sent from client device 125. In various embodiments, message 140 may be passed through authentication router 120. Authentication router 120 may be associated with network 115.

[0041] In some examples, the network 115 may be one or more of a wireless network, a wired network, or any combination of a wireless network and a wired network, and may be configured to connect the client device 125 to the service provider 320. For example, the network 115 may include one or more of the following: a fiber optic network, a passive optical network, a cable network, an Internet network, a satellite network, a wireless local area network (LAN), a global system for mobile communications, a personal communications service, a personal area network, a wireless application protocol, a multimedia messaging service, an enhanced messaging service, a short message service, a time division multiplexing-based system, a code division multiple access (CDMA)-based system, D-AMPS, Wi-Fi, fixed wireless data, IEEE 802.11b, 802.15.1, 802.11n, and 802.11g, Bluetooth, NFC, radio frequency identification (RFID), Wi-Fi, and the like.

[0042] In addition, network 115 may include, but is not limited to, telephone lines, optical fiber, IEEE Ethernet 902.3, a wide area network ("WAN"), a wireless personal area network ("WPAN"), a local area network ("LAN"), or a global network such as the Internet. In addition, network 115 may support an Internet network, a wireless communication network, a cellular network, etc., or any combination thereof. Network 115 may further include one network or any number of networks of the above exemplary types, which operate as independent networks or cooperate with each other. Network 115 may utilize one or more protocols of one or more network elements communicatively coupled thereto. Network 115 may convert to one or more protocols of a network device, or convert from other protocols to one or more protocols of a network device.

[0043] In addition, it should be understood that according to one or more examples, network 115 can be part of multiple interconnected networks, such as the Internet, a service provider's private network, a cable television network, an enterprise network such as a credit card association network, and a home network. In some embodiments, authentication router 120 and / or network 115 can be associated with a communications service provider. In addition, the private network can be implemented as a virtual private network layered on top of network 115.

[0044] For example, network 115 may include a public switched telephone network (PSTN), and the authentication router may be associated with a communications service provider used by a customer of client device 125 and / or client device 130 .

[0045] Authentication router 120 may access a public key 127 associated with client device 125. In some examples, authentication router 120 may receive public key 127 from client device 125 via message 140. In other embodiments, authentication router 120 may access a database, table, or other storage device or memory in which public key 127 is stored. In these embodiments, the memory may be local to authentication router 120 or otherwise available via network 115.

[0046] In some embodiments, authentication router 120 accesses a storage device as described above, which includes dynamic information subordinate to the encrypted payload of message 140. For example, the dynamic information included in the encrypted payload can be reflected by information available to the authentication router. For example, if the payload includes current information about the client account and the communication service provider, the memory can include separately maintained current information about the client account and the service provider. In another example, if the encrypted payload includes a counter that increases each time the client makes a call using client device 125, the counter can be updated in a memory accessible to authentication router 120 each time the client device 125 makes a call.

[0047] Once the client device 125 is activated or released to the client, such information as belonging to the client and / or the client device 125 can be initially used to authenticate the router 120. In addition, such information should be associated with the client and / or the client device. For example, a counter associated with the client device can be set to zero or some other predetermined value in response to the activation of the device, or the initial account information of the client can be entered by a communication service provider employee in response to the account creation of the client. However, such information is updated independently of the content of the message 140.

[0048] In some embodiments, the public key 127 is stored in such a memory accessible to the authentication router 120. In an embodiment, once the client device 125 is released to the client and / or service is started by the communication service provider, the public key 127 can be entered together with the memory location associated with the client and / or client device 125. For example, if the public key is updated to match the updated private key, the public key 127 in the memory can be updated. In some embodiments, such an update can be automatic. In other embodiments, such an update can be performed in response to an event, such as sending a message 140 from the client device 125. In some embodiments, the public key 127 can be updated in response to being received as part of the message 140.

[0049] In various embodiments, authentication router 120 may decrypt message 140 using public key 127. In embodiments where the decrypted payload contains hash data, a hash function may be applied to the decrypted payload to extract information, such as an identifier. In embodiments, the contents of the decrypted payload of message 140 may then be compared to information known by an authentication router belonging to a client and / or client device. For example, if the payload contains a counter, the counter may be compared to a counter known by the authentication router. The matching of the information of the decrypted payload with the information known by authentication router 120 allows message 140 to be authenticated as being truly sent from client device 125.

[0050] Since the public key 127 is associated with the private key 126 (which is only known to the client device 125), the successful decryption of the message 140 using the public key 127 indicates that the message 140 was actually sent from the client device 125. However, the mismatch between the payload of the message sent from the client device and the message available to the authentication router belonging to the client and / or the client device 125 may indicate malicious activity. For example, a hacker or imposter may have gained access to the private key 126 of the client device 125, and the message received by the authentication router may not be from the identified client device 125. In the case where the incoming message cannot be decrypted using the public key 127 and / or the decrypted payload of the message cannot be authenticated, the communication may be marked for the recipient client device 130. In some embodiments, the connection for communication between the client devices 125 and 130 may not be completed based on such an authentication failure. Based on such an authentication failure, information belonging to the client device 125 and / or the message 140 may be marked, stored in a database, and / or sent to a service provider or other entity (e.g., a law enforcement agency). In some embodiments, based on successful authentication of initiating client device 125 , client devices 125 and 130 may be connected for communication.

[0051] In some embodiments, client device 130 has its own associated private key 136 and public key 137. It will be appreciated that these keys can allow return communication from client device 130 to client device 125 by the same method described with respect to communication from client device 125 to client device 130.

[0052] In various embodiments, the authentication process may occur locally to the recipient client device 130, rather than locally to the authentication router 120. Specifically, the message 140 may be routed by the network 115 to the client device 130 while still being encrypted.

[0053] In such embodiments, client device 130 may access a public key 127 associated with client device 125. In some cases, client device 130 may receive public key 127 from client device 125 via message 140. In other embodiments, client device 130 may access a database, table, or other storage or memory in which public key 127 is stored. In these embodiments, the memory may be local to client device 130 or otherwise available via network 115.

[0054] In some embodiments, client device 130 accesses a storage device as described above, which includes dynamic information subordinate to the encrypted payload of message 140. For example, the dynamic information included in the encrypted payload can be reflected by information that can be used to authenticate the router. For example, if the payload includes current information about the client account and the communication service provider, the memory can include separately maintained current information about the client account and the service provider. In another example, if the encrypted payload includes a counter that increases each time the client uses client device 125 to make a call, each time the client device 125 makes a call, the counter can be updated in a memory accessible to client device 130. In such an example, a counter associated with client device 125 local to client device 125 and client device 130 local to client device 125 can be specifically updated in response to the communication between client device 125 and client device 130.

[0055] Once the client device 125 is activated or released to the client, such information as belonging to the client and / or the client device 125 can be used for the client device 130 initially. In addition, such information should be associated with the client and / or the client device. For example, a counter associated with the client device 125 can be set to zero or some other predetermined value in response to the activation of the client device 125, or the initial account information of the client can be entered by a communication service provider employee in response to the account creation of the client. In this example, the information can be stored in a memory external to the client device 130, such as a database located on an Internet server. However, such information is updated independently of the content of the message 140.

[0056] In some embodiments, the public key 127 is stored in such a memory accessible to the client device 130. In an embodiment, once the client device 125 is released to the client and / or service is started by the communication service provider, the public key 127 can be entered into a memory associated with the client and / or the client device 125. For example, if the public key is updated to match the rolling private key, the public key 127 in the memory can be updated. In some embodiments, such an update can be automatic. In other embodiments, such an update can be performed in response to an event, such as sending a message 140 from the client device 125 to the client device 130. In some embodiments, the public key 127 can be updated in a memory available to the client device 130 in response to being received as part of the message 140.

[0057] In various embodiments, client device 130 may decrypt message 140 using public key 127. In embodiments, the decrypted payload of message 140 may then be compared to information known by client device 130 that is a slave to a client and / or client device. For example, if the payload contains a counter, the counter may be compared to a counter known by client device 130. A match between the information of the decrypted payload and the information known by client device 130 allows message 140 to be authenticated as being genuinely sent from client device 125.

[0058] Since the public key 127 is associated with the private key 126 (which is only known to the client device 125), the successful decryption of the message 140 using the public key 127 indicates that the message 140 was actually sent from the client device 125. However, a mismatch between the encrypted payload of the message sent from the client device and the information available to the authentication router belonging to the client and / or the client device 125 may indicate malicious activity. For example, a hacker or imposter may have gained access to the private key 126 of the client device 125, and the message received by the authentication router may not be from the identified client device 125. In the event that the incoming message cannot be decrypted using the public key 127 and / or the decrypted payload of the message cannot be authenticated, the communication may be marked for the recipient client device 130. In some embodiments, the connection for communication between the client devices 125 and 130 may not be completed or continued based on such an authentication failure. Based on such an authentication failure, information belonging to the client device 125 and / or the message 140 may be marked, stored in a database, and / or sent to a service provider or other entity (e.g., a law enforcement agency). In some embodiments, based on successful authentication of initiating client device 125 , client devices 125 and 130 may be connected for communication.

[0059] Figure 2 is a block diagram showing various exemplary components that may be used to implement, for example, Figure 1 The method discussed. System 200 can, for example, be implemented to allow encryption and / or decryption of data. Likewise, similar components can be implemented as client device 125, authentication router 120, and / or client device 130. System 200 is particularly directed to communications including telephone calls. Embodiments are not limited in this manner.

[0060] In an embodiment, the system 200 may include a processor 210. It is understood that the processing circuit may include additional components, including processors, memories, error and parity check / CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and anti-tampering hardware, which are necessary to perform the functions described herein. In addition, the processor 210 may be any of a variety of commercially available computer processors, including but not limited to: and processor; Application, embedded and security processors; and and Processors; IBM and Cell processor; Core(2) and processor; and the like. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be utilized as processor 210. Such processors may enable network-enabled devices to communicate with other network-enabled devices via a PSTN interface 215 managed using an SS7 network interface 220.

[0061] In particular, PTSN interface 215 allows system 200 to connect with network 115 and associated services. A Signaling System No. 7 (SSN) network interface is used to manage system 200's use of network 115 via PSTN interface 215 by using different paths and facilities than voice channels to establish signaling and release communications.

[0062] In some instances, memory systems such as those referenced with respect to client device 125, authentication router 120, and client device 130 may be embodied as memory 225. Memory 225 may be a read-only memory, a write-once read-many memory, or a read / write memory, such as a RAM, ROM, and EEPROM, and the system 200 may include one or more of these memories. Read-only memory may be programmable by the manufacturer to be read-only or one-time programmable. One-time programmability provides the possibility of writing once and then reading multiple times. Write-once / read-many memory may be programmed at a certain point in time after the memory chip has been shipped. Once the memory is programmed, it cannot be rewritten, but it can be read multiple times. Read / write memory may be programmed and reprogrammed multiple times after leaving the factory. It may also be read multiple times.

[0063] Memory 225 may be configured to store one or more of key data 230, encryption / decryption code 235, and key verification code 240. Key data may include keys used to encrypt and / or decrypt information such as messages (such as message 140), identification payloads, or other information. For example, key data 230 may include private key 126 and public key 127.

[0064] Encryption / decryption code 235 may include code that uses key data 230 to encrypt and / or decrypt information such as a message (such as message 140 ), an identification payload, or other information.

[0065] Key verification code 240 may include code to verify the results of encryption and / or decryption of information such as a message (such as message 140), an identification payload, or other information using key data 230 in accordance with encryption / decryption code 235. In some embodiments, key verification code 240 may include a payload that identifies a client and / or client device, such as an identification payload of message 140.

[0066] Figure 3 3 is a block diagram illustrating a system 300 in which a client device 125 is coupled to a service provider 320 via a network 315. The embodiments are not limited in this manner.

[0067] In one embodiment, service provider 320 is a business organization that provides computer-based services to clients via network 115. Almost all modern service providers use networks to provide service items to potential consumers. The service items are generally provided in the form of software applications that use the dedicated resources of the service provider to run. The combination of software and hardware that provides specific services to the client is referred to as a 'server' in this article. The server can communicate via the service provider's private network 350 (commonly referred to as a company or enterprise network). The private network 350 may include a wireless network, a wired network, or any combination of a wireless network and a wired network as described above with respect to network 115.

[0068] In system 300, service provider 320 is shown to include authentication server 360. Although the server is shown as a discrete device, it will be appreciated that applications and servers may be distributed throughout an enterprise, or throughout network 115 in the case of distributed resources such as 'cloud' resources.

[0069] Database 330 comprises a data storage resource that can be used, for example, to store customer accounts, credentials, and other authentication information for use by authentication server 360. Database 330 can be comprised of coupled data resources including any combination of local storage, distributed data center storage, or cloud-based storage.

[0070] The contactless card 305 may include a payment card, such as a credit card, a debit card, or a gift card, issued by a service provider 320 displayed on the front or back of the card 305. In some instances, the contactless card 305 is not related to a payment card and may include, but is not limited to, an identification card. In some examples, the payment card may include a dual-interface contactless payment card. The contactless payment card 305 may include a substrate, which may include a single layer or one or more laminates composed of plastic, metal, and other materials. Exemplary substrate materials include: polyvinyl chloride, polyvinyl chloride-vinyl acetate, acrylonitrile-butadiene-styrene, polycarbonate, polyester, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 305 may have physical properties that conform to the ID-1 format of the ISO / IEC 7810 standard, or the contactless card may conform to the ISO / IEC 14443 standard. However, it will be appreciated that a contactless card 305 according to the present disclosure may have different characteristics and that the present disclosure does not require the implementation of a contactless card in a payment card.

[0071] The contactless card 305 may also include identification information displayed on the front and / or back of the card, and a contact pad. The contact pad may be configured to establish contact with another communication device, such as a user device, a smartphone, a laptop, a desktop computer, or a tablet computer. The contactless card 305 may also include processing circuitry, an antenna, and a Figure 3 Other components not shown in the figure. These components may be located behind the contact pad or at other locations on the substrate. The contactless card 305 may also include a magnetic stripe or magnetic tape, which may be located on the back of the card ( Figure 3 not shown).

[0072] According to one aspect, the contactless card 305 can communicate wirelessly, such as NFC, with one or more client devices 125. For example, the contactless card 305 can include one or more chips such as a radio frequency identification chip that is configured to communicate via NFC or other short-range protocols. In other embodiments, the contactless card 305 can communicate with the client device 410 via other means, including but not limited to: Bluetooth, satellite and / or Wi-Fi. As described in the '119 application, the contactless card 305 can be configured to communicate with one of the client devices 125 via NFC when the contactless card 305 is within the range of the respective client device. As will be described in more detail below, the contactless card 305 can generate a password used by the service provider to authenticate the client device.

[0073] Contactless card 305 can be used to generate a message authentication code (MAC) password, which can play the role of a digital signature for verification purposes. Other digital signature algorithms, such as public key asymmetric algorithms, such as the digital signature algorithm and the RSA algorithm, or zero-knowledge protocols can be used to perform the verification.

[0074] More specifically, the contactless card 305 may be used to generate a session key. The session key may be received via communication between the contactless card 305 and the client device 125 and serve as a proxy for the session key. Figure 1 In an embodiment, this process can replace the private key described in Figure 1 The client device 125 generates or stores a local private key.

[0075] In an embodiment, the contactless card 305 can be used to communicate an identifier to the client device 125. The identifier can be, for example, a counter. In various embodiments, a private key associated with the client device 125 can be diversified using the counter and / or used to encrypt the identifier from the contactless card 305 as part of the encrypted identification payload.

[0076] Client device 125 may send a message, such as message 140. In an embodiment, the message may be appended to the call data stream. The message may include an encrypted identifier payload associated with the client and / or client device 125. The identifier payload may include audio data, such as a voice message. The message may further include at least one phone number, such as found in message 140.

[0077] In an embodiment, audio data can be recorded from a human voice, such as from a client or from a server provider employee. In some embodiments, audio data can include a client voice message. In other embodiments, audio data can be generated by a computer. In such an embodiment, audio data can be generated in response to the interpretation of text and / or digital data by a computer device, such as by a text-to-speech application and program. The interpretation of text and / or digital data can be performed locally on client device 125 or on another network-supported device. The interpreted data can include identification information of a client and / or client device. This information can be stored in a memory accessible to client device 125, such as a local, contactless card or via a network connection. For example, information for a specific client can be found in a database, which is associated with the telephone number of the client device to which the message is sent. In some embodiments, the information can include dynamic information, such as a counter.

[0078] In some embodiments, the payload may contain further information including at least one identifier. Such an identifier may include a counter from contactless card 305, for example, as described in more detail herein and in the '119 application.

[0079] In an embodiment, network 315 may include an interactive voice response (IVR) enabled system. The IVR system may receive and decrypt the encrypted identification payload sent by client device 125. Encryption may be performed by any method necessary, such as by the methods described in the '119 application or by the methods described in connection with the present invention. Figure 1 The method described.

[0080] The identifier of the decrypted payload, such as a counter, can be compared with an expected identifier associated with the client device to which the message is sent. In an embodiment, the expected identifier can be associated with the client device by referencing a telephone number associated with the client device. For example, once a communication is received from the client device, regardless of the content of the message received from the client device, the counter can be increased. In another example, when the message contains a certain type of information, the counter can be increased for each message received from the client device. The comparison between the identifier of the decrypted payload and the expected identifier can be performed by the IVR system, another network-enabled device, by an application on the IVR system, or another capable processor. The embodiments are not limited in this manner.

[0081] A match between the identifier of the decrypted payload and the expected identifier may determine a first factor authentication match. By requiring not only a successful decryption, but also a match between an identifier known only to the client device 125 and the memory in which the expected identifier is stored, this authentication adds a further layer of security over symmetric key or asymmetric key authentication alone. For example, a counter value of number X from the decrypted payload matching the expected value may indicate not only that the payload has been able to be decrypted correctly, but also that the sending client device has a record of number X of past communications with the server that is identical to the server's record.

[0082] In an embodiment, the IVR system can perform second factor authentication using audio data included in the identification payload. In particular, the IVR system can interpret the audio data included in the identification payload. In some embodiments, the audio data of the decrypted payload can be interpreted by a voice transcription program such as a voice-to-text application. In some embodiments, the audio data can be analyzed for features of the audio data itself. In an embodiment, attributes such as voice message attributes can be identified from the audio data. Voice message attributes can include recognized vocabulary, human voice vs. computer-generated sound, sound characteristics such as tone, voice, accent, rhythm, background noise, volume, and other characteristics that can be identified by a computer in the audio data. Such attributes can be identified by using methods well known in the field of language processing, such as keyword recognition or recognition based on a model trained by one or more machine learning algorithms, a neural network, or another training method. In some embodiments, at least one confidence level can be calculated based on the possibility that the audio data contains at least one attribute.

[0083] In an embodiment, the interpreted audio data may be received by a service provider 320. The service provider 320 may include a private enterprise network 350, an authentication server 360, and a database 330. In an embodiment, aspects of the audio data analysis may occur on the enterprise network 350, rather than on the public network 315. In the case where the analysis is performed on the network 315 as described above, the identification attributes of the audio data may be sent to the enterprise network.

[0084] The authentication server 360 can compare the identification attributes of the audio data from the decrypted payload with the expected attributes of the audio data from a specific client and / or client device 125. Such attributes can be stored in the database 330 in association with the client and / or client device. For example, a customer voice message from the decrypted payload can be compared with a previously known customer voice message associated with the client device 125 stored in the database 330. In some embodiments, a binary analysis of attribute matching can be used. In other embodiments, the attributes can be matched according to a confidence within a certain range. This confidence can be calculated by, for example, one or more machine learning methods, keyword recognition methods, and / or other methods well known in the art. Based on the comparison between the identified attributes of the audio data and the expected attributes, the authentication server 360 may or may not be able to establish a second factor authentication match. Since it is this second factor authentication match that can be based on information and / or audio data that is unique to the expected user of the client device 125, the authentication can provide confidence that the actual user of the client device 125 is the expected user rather than an imposter.

[0085] In an embodiment, based on the results of the first and / or second factor authentication matches, the IVR system may selectively establish a connection between the first client device 125 and the second client device 130. In some embodiments, the authentication server 360 may transmit the results of the first and / or second factor authentication matches to the IVR system. In some embodiments, based on the results of one or more factor authentication matches, the authentication server 360 may further transmit instructions to connect or not connect the first client device 125 and the second client device 130. In other embodiments, based on the results of one or more factor authentication matches, the PSTN or IVR system on the network 315 may receive the results of the first and / or second authentication matches and determine whether to connect the first client device 125 and the second client device 130 for communication. In some embodiments, based on the first client device 125 being authenticated as one of at least one known authenticated caller, the IVR system may be used to restrict access of the first client device 125 to the second client device 130. For example, such authenticated callers may be known and / or marked in the system as making problematic unsolicited calls.

[0086] Figure 4 is a timing diagram illustrating an example sequence for providing authenticated access according to one or more embodiments of the present disclosure. System 400 may include contactless card 305 and client device 410, which may include application 422 and processor 424. Embodiments are not limited in this manner.

[0087] In step 402, application 422 communicates with contactless card 405 (e.g., after being brought near contactless card 305). Communication between application 422 and contactless card 305 may involve contactless card 305 being sufficiently close to a card reader (not shown) of client device 110 to enable NFC data transfer between application 122 and contactless card 105.

[0088] In step 404, after communication has been established between the client device 410 and the contactless card 305, the contactless card 305 generates a message authentication code (MAC) password. In some examples, this may occur when the contactless card 305 is read by the application 422. In particular, this may occur when reading (e.g., NFC reading) a near field data exchange (NDEF) tag, which can be created according to the NFC data exchange format. For example, a reader such as the application 422 can send a message with an applet ID of an applet that generates NDEF, such as an applet selection message. Once the selection is confirmed, a selection file message sequence of read file messages can then be transmitted. For example, the sequence can include "select capacity file", "read capacity file" and "select NDEF file". At this time, the counter value maintained by the contactless card 305 can be updated or incremented, which can be followed by "read NDEF file". At this time, a message that can include a header and a shared secret can be generated. Then a session key can be generated. The MAC password can be created from the message, which can include a header and a shared secret. The MAC password can then be concatenated with one or more blocks of random data, and the MAC password and random number (RND) can be encrypted using the session key. Thereafter, the password and the header can be concatenated and encoded as ASCII hexadecimal and returned in the NDEF message format (in response to the "Read NDEF File" message).

[0089] In some examples, the MAC password may be transmitted as an NDEF tag, and in other examples, the MAC password may be included with a uniform resource indicator (eg, as a formatted string).

[0090] In some examples, application 422 may be configured to transmit a request to contactless card 105 including instructions to generate a MAC password.

[0091] In step 406, the contactless card 305 sends the MAC password to the application 422. In some examples, the transmission of the MAC password occurs via NFC. However, the present disclosure is not limited to this. In other examples, the communication can occur via Bluetooth, Wi-Fi, or other methods of wireless data communication.

[0092] In step 408 , application 422 transmits the MAC password to processor 424 .

[0093] In step 412, processor 424 verifies the MAC password according to instructions from application 422. For example, the MAC password may be verified as described below.

[0094] In some examples, verifying the MAC password may be performed by a device other than client device 410, such as service provider 320 in data communication with client device 410. For example, processor 424 may output the MAC password for transmission to service provider 320, which may verify the MAC password.

[0095] In some examples, the MAC password can be used as a digital signature for verification purposes. Other digital signature algorithms such as public key asymmetric algorithms (eg, digital signature algorithm and RSA algorithm) or zero-knowledge protocols can be used to perform the verification.

[0096] More specifically, according to one aspect, the contactless card 305 can be used in combination with a first authentication credential provided by a service provider (such as service provider 320) to authenticate communications (e.g., calls) from client device 410. The use of a contactless card as a second factor of authentication enables a specific device / phone number to be associated with a specific individual (e.g., the owner of the card), thereby eliminating the ability of a malicious third party to impersonate (i.e., posing as a client). According to another aspect of the present invention, the authentication communication protocol described herein identifies or uses a specific communication channel for call processing, thereby reducing the possibility of client impersonation.

[0097] Security factor authentication may include multiple processes. In some embodiments, a first authentication process may include logging in and verifying a user via one or more applications executed on a device. A second authentication process may be run after successful login and authentication to allow the user to participate in one or more behaviors associated with one or more contactless cards. In fact, the security factor authentication process includes a multi-factor authentication process, which may include securely providing a user identification and encouraging the user to participate in one or more behaviors, including but not limited to, one or more tap gestures associated with a contactless card. In some examples, one or more tap gestures may include a user tapping a contactless card to a device. In some examples, a device may include a mobile device, a terminal, a tablet computer, or any other device configured to process a received tap gesture.

[0098] For example, to provide a first layer of authentication, the client may access an application running on the client device. In other examples, the client may access the service provider's website by linking to the service provider's web page using an Internet browser application running on the client device. The browser is a software application such as Internet etc., and includes programming code for translating a Hypertext Markup Language (HTML) web page of a service provider application into a format suitable for a client running a client device.

[0099] As part of accessing an application or service provider website, the service provider may request first authentication information, including password information, responses to pre-stored queries, biometric information, images, or other mechanisms to verify that the user of the client device is authenticated to access content and services (including accounts) managed by the service provider. Additionally, this level of authentication provides confidence that the user of the client device 125 is the intended client. In other words, while the above methods are particularly useful for at least authenticating communications from an authenticated device, these steps may further authenticate that the communications are from an authenticated user of the device.

[0100] According to one aspect, the contactless card 305 can be used to provide a second authentication for the user of the client device. In one embodiment, and as described in more detail below, the contactless card includes a key, a counter, and cryptographic processing functionality that can be used to generate a password that can be used to authenticate the user of the client device. The counter advantageously reflects the cardholder's past behavior. For example, the counter can reflect the number of times the user has previously communicated with a particular party, information that is almost impossible to accurately obtain by a malicious third party.

[0101] A further level of authentication may be achieved by using a contactless card 305 (e.g., by tapping or otherwise communicatively coupling the card 305 to one of the client devices 410 as described above). In some embodiments, this constitutes a second authentication. In other embodiments, such as with respect to Figure 3 As described, the second authentication is continued using, for example, analysis of the identified payload.

[0102] After the second authentication, and as described in more detail below, data may be returned to the client device. For example, the data may include data that allows the client to initiate a communication link with the second client device, or information about the success or failure of the authentication attempt.

[0103] It should be noted that while in the above description the first authentication is described as using personal, biometric, question or other authentication information, it can be appreciated that in some examples, a client application executing on a device can respond to the tapping of a contactless card to initially activate or launch an application of the device. In such examples, both the first and second authentication processes use the key / counter contactless card authentication process described in more detail below.

[0104] In some embodiments, if the client-side application is not installed on the client device, a tap of the contactless card near the card reader can initiate download of the application (e.g., navigate to the application download page). After installation, the tap of the contactless card can activate or launch the application and then initiate (e.g., via the application or other backend communication) activation of the contactless card. In some examples, one or more applications can be configured to determine that it is initiated via one or more tap gestures of the contactless card, so that the activation occurs at 3:51 pm and the transaction is processed or occurs at 3:56 pm to verify the identity of the user.

[0105] In some examples, data can be collected as a biometric / gesture authentication through the act of tapping. For example, a unique identifier that is cryptographically protected and not easily intercepted can be transmitted to one or more backend services. The unique identifier can be configured to look up secondary information about an individual. The secondary information can include personally identifiable information about the user. In some examples, the secondary information can be stored in a contactless card.

[0106] Figure 5An exemplary system 500 is shown in which authenticated calls can be made. The system 500 includes two or more client devices 125 and 130. As shown, a single client device 125 is a device used to initiate communications, and a single client device 130 is a device used to receive communications. However, it will be readily appreciated that communications can be transmitted from client device 130 to client device 125 and / or each client device as shown can include multiple client devices, such as in a group call. Embodiments are not limited in this manner.

[0107] Client device 125 may be associated with private key 126 and public key 127. Client device 130 may be associated with private key 136 and public key 137. In embodiments where at least one of client device 125 or client device 130 represents a plurality of client devices, each client device may be associated with one private key and one public key.

[0108] For each client device, the private key and the public key may be related so that one decrypts data encrypted by the other. In some embodiments, for a device, the private key and the public key may be the same, so that it can perform symmetric key encryption. In other examples, the private key and the public key may be different, so that it can perform asymmetric key encryption. The key may be permanent or dynamic. In some embodiments, as described above, the private key may be diversified by the use of dynamic information local to the client device, or a session key provided by an external object or device (such as a contactless card).

[0109] In various embodiments, client device 125 may initiate a communication, such as a call data stream, with client device 130. Message 505 may be attached to the communication. Message 505 may include an encrypted payload, at least one phone number, including a phone number associated with recipient client device 130, and a voice memo. In embodiments, the voice memo may be customizable by the owner of the sender client device 125, such as a phrase or greeting. In some embodiments, message 505 may further include a public key 127 of client device 125.

[0110] The encrypted payload may be encrypted using a private key of the client device 125. The encrypted payload may include at least one identifier. In some cases, the voice memo may be included in the encrypted payload.

[0111] The second client device 130 may access the public key 127 of the first client device 125 associated with the phone number, or other identification data for the client device 125. For example, the public key 127 of the first client device 125 may be received using message 505, stored locally to a memory of the client device 130 after a previous communication between the two devices, or available via another memory or database (such as an Internet-linked database). In addition, the second client device 130 may access an expected identifier associated with the client device 125. For example, the same database may be used to store at least one client device 125, an associated public key, and an expected identifier associated with the client device 125.

[0112] Message 505 may be received by client device 130 . Client device 130 may retrieve public key 127 associated with client device 125 , and use public key 127 to decrypt the encrypted payload of message 505 .

[0113] Failure to decrypt the payload using public key 127 may indicate potential fraudulent behavior. As a result, the communication connection from client device 125 may be denied. In some embodiments, feedback may be provided to the user of client device 130, the service provider, or a third party (e.g., law enforcement).

[0114] In some embodiments, the voice memo of message 505 may be displayed to the user of client device 130, for example, via a user interface that plays the voice memo audio data to the user of client device 130 when the user of client device 130 answers the incoming call. The user interface may be part of an application on client device 130. In some embodiments, the voice memo of message 505 may be displayed only to the user of a successful first authentication based on the identifier of the encrypted payload.

[0115] If the user recognizes or does not recognize the voice memo from the user of the first client device 125, the client device 130 can receive feedback from its user. For example, the feedback can be received via the user interface. This verification of the recognition of the voice memo from the first client by the second client provides a further authentication layer. In some embodiments, the client device 130 can receive instructions from the user via the user interface to indicate the continuation or rejection of the communication connection between the client devices 125 and 130.

[0116] Based on the feedback received from the user regarding the voice memo recognition, the client device 130 may selectively establish a connection between the client device 125 and the client device 130. In some embodiments, based on the feedback, the client device 130 may save the public key 127 of the client device 125 to a local memory, or add the client device 125 to a list of recognized and / or trusted devices.

[0117] In some embodiments, continued communication between identified and / or trusted devices may be performed using a streamlined authentication method. For example, only a first level of authentication may be required.

[0118] Figure 6 600 is a logic flow diagram illustrating a method for selectively connecting a first client device and a second client device for communication based on an authentication result. Specifically, Figure 6 An example is shown where both the first and second client devices are mobile phone devices and the communication is a call data flow. The embodiments are not limited in this regard.

[0119] In step 610, an incoming call data stream is received from a first mobile phone device. The incoming call stream includes a telephone number associated with a second mobile phone device, and an encrypted payload. The encrypted payload is encrypted using a private key associated with the first mobile device. In an embodiment, the encrypted payload may be appended to the incoming call data stream. The payload data may include information belonging to the first client and / or client device.

[0120] In step 620, in response to a match between the information of the encrypted payload and the stored information associated with the first mobile telephone device, the incoming call data stream may be authenticated. In various embodiments, the match between the information of the encrypted payload and the stored information associated with the first mobile telephone device may be determined by a successful decryption of the payload. For example, the payload may have been encrypted using a public key diversified using a counter. In this example, successful decryption of the payload using a public key diversified by an independently maintained counter may indicate appropriate authentication.

[0121] In step 630, the system may establish a call connection between the first mobile telephone device and the second mobile telephone device in response to the step of authenticating.

[0122] In some embodiments, the failure of the system to properly authenticate the call may prompt other methods of rejecting the call or canceling the call. In some embodiments, the first client device and / or the second client device may be notified of the failed attempt and provided with details of the attempt, such as the caller and / or recipient's phone number. In some embodiments, the recipient may be prompted via the user interface of the second client device to add the phone number that called the first client device to a list of numbers to be blocked. In various embodiments, the system may provide information related to the unauthenticated call to a service provider or a third party (e.g., a law enforcement agency).

[0123] In some embodiments, successful authentication of the call by the system may prompt the establishment of a connection between the first mobile device and the second mobile device. In various embodiments, information about the first mobile device may be saved to / or by the second mobile device, which identifies the first mobile device as having been engaged via the authenticated call. Such registration may be referenced in subsequent communications between the two client devices to efficiently check the possible authenticity of subsequent communications based on the authentication of previous communications.

[0124] In some embodiments, in response to the authentication step, a call connection can be established between the first and second mobile phone devices, and the result of the authentication step can be indicated to the recipient, for example, via the user interface of the second client device. For example, despite the failure of authentication, the call connection can still be established, but a warning that the call is unauthenticated can be transmitted to the recipient via the user interface of the recipient's mobile phone. In a further example, in response to successful authentication, a call connection can be established, wherein a verification result that the call has been authenticated is transmitted to the recipient via the user interface of the recipient's mobile phone.

[0125] Figure 7 700 is a logic flow diagram illustrating a method for selectively connecting a first client device and a second client device for communication based on the results of a multi-factor authentication. Specifically, Figure 7 An example is shown where both the first and second client devices are mobile phone devices and the communication is a call data flow. The embodiments are not limited in this manner.

[0126] Step 710 discloses the retrieval of the public key of the incoming call number from the data storage device. In some embodiments, the data storage device can be local to the second client device. In other embodiments, the data storage device can be an external memory, such as discussed above with reference to the authentication router 120 or the database 330.

[0127] Step 720 discloses decryption of the encrypted payload using the public key of the incoming calling number retrieved in step 710 to produce a decrypted payload including the identifier. The encrypted payload may be received with the incoming calling number, for example in message 140. The identifier may be associated with the sending client and / or the first client device.

[0128] Step 730 discloses a comparison of the identifier of the decrypted payload and the expected identifier associated with the incoming call number to determine a first factor authentication match. In various embodiments, the expected identifier associated with the incoming call number can be retrieved from a memory, which can be the same data storage device referenced in step 710, or a separate data storage device.

[0129] Step 740 discloses comparing the attributes of the voice message to the expected voice message attributes to identify a second factor authentication match.The voice message may be associated with the encrypted payload, or received as part of the encrypted payload.

[0130] Step 750 discloses selectively establishing a connection between the first mobile telephone device and the second mobile telephone device in response to the first factor authentication and the second factor authentication matching.

[0131] In some embodiments, the failure of the system to match the correct authentication call via the first factor and / or the second factor authentication may prompt other methods of rejecting the call, interrupting the call, or canceling the call. In some embodiments, the first client device and / or the second client device may be notified of the failed attempt and provided with details of the attempt, such as the caller and / or the recipient's phone number. In some embodiments, the recipient may be prompted via the user interface of the second client device to add the phone number calling the first client device to a list of numbers to be blocked. In various embodiments, the system may provide information related to unauthenticated calls to a service provider or a third party (e.g., a law enforcement agency). Such a message may specify which factor of the authentication failed and include further details of the attempt.

[0132] In some embodiments, successful authentication of a call of a match via first factor and / or second factor authentication of the system may prompt establishment of a connection between the first mobile device and the second mobile device. In various embodiments, information about the first mobile device may be saved to / or by the second mobile device, which identifies the first mobile device as having participated in a call via multi-factor authentication. Such registration may be referenced in subsequent communications between the two client devices to efficiently check the possible authenticity of subsequent communications based on the authentication of previous communications.

[0133] In some embodiments, in response to a first factor and / or second factor authentication match, a call connection can be established between the first and second mobile phone devices, and the results of the authentication steps can be indicated to the recipient, for example, via a user interface of the second client device. For example, despite a multi-factor authentication failure, a call connection can still be established, but a warning that the call is unauthenticated may be transmitted to the recipient via the user interface of the recipient's mobile phone. In a further example, in response to a multi-factor authentication success, a call connection can be established, wherein the call is transmitted to the recipient via the user interface of the recipient's mobile phone that it has been verified via the multi-factor authentication.

[0134] Various embodiments can be realized using hardware elements, software elements or a combination of the two. Examples of hardware elements may include: processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include: software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, characters, numerical values, symbols or any combination thereof. However, determining whether an embodiment is implemented using hardware elements and / or software elements may change according to many factors, such as desired computing rate, power level, thermal tolerance, processing cycle budget, input data rate, output data rate, memory resources, data bus speed and other design or performance limitations.

[0135] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represents various logics within the memory, which when read by the machine causes the machine to manufacture logic to perform the techniques described herein. Such representations, referred to as "IP cores", may be stored in tangible machine-readable media and provided to various users or production facilities to be loaded into manufacturing machines that actually manufacture logic or processors. For example, some embodiments may be implemented using machine-readable media or articles, which may store instructions or sets of instructions that, if executed by a machine, may cause the machine to perform methods and / or operations according to the embodiments. Such machines may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article of manufacture may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory card or disk, various types of digital versatile disks (DVD), magnetic tape strips, cassettes, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled or interpreted programming language.

Claims

1. A computing device, include: a memory configured to store instructions; as well as a processing circuit coupled to the memory, the processing circuit being configured to execute the instructions, and the instructions, when executed, causing the processing circuit to: Determining to establish a communication connection with a second computing device; detecting a contactless card within wireless communication range of a computing device; receiving an encrypted payload from the contactless card, the encrypted payload comprising an identifier, wherein the encrypted payload is generated by the contactless card using a dynamic key of the computing device and an encryption algorithm, the identifier being associated with the contactless card; sending the encrypted payload and the calling number to an authentication router to initiate establishment of a communication connection with the second computing device; as well as Based on successful authentication performed by the authentication router using an encrypted payload including the identifier, a communication connection is established with the second computing device.

2. The computing device according to claim 1, in, The identifier is a counter.

3. The computing device according to claim 1, in, The encrypted payload includes audio data, and the audio data is unique to an intended user of the computing device.

4. The computing device according to claim 1, in, The calling number is associated with the second computing device to establish a communication connection with the second computing device.

5. The computing device according to claim 1, in, A public key is stored in the memory, and the service provider system is configured to decrypt the encrypted payload with the public key to authenticate the identifier.

6. A computer-implemented method, include: a memory configured to store instructions; and Determining, by a processor of the computing device, to establish a communication connection with a second computing device; detecting a contactless card within wireless communication range of a computing device; receiving an encrypted payload from the contactless card, the encrypted payload comprising an identifier, wherein the encrypted payload is generated by the contactless card using a dynamic key and an encryption algorithm of the computing device, and wherein the identifier is associated with the contactless card; sending the encrypted payload and the calling number to an authentication router to initiate establishment of a communication connection with the second computing device, wherein the calling number is associated with the second computing device; as well as Communicating with the second computing device via the communication connection based on successful authentication performed by the authentication router using an encrypted payload including the identifier.

7. The computer-implemented method of claim 6, in, The identifier is a counter.

8. The computer-implemented method of claim 6, in, The encrypted payload includes audio data, and the audio data is unique to an intended user of the computing device.

9. The computer-implemented method of claim 6, in, The identifier comprises data received from a contactless card.

10. The computer-implemented method of claim 6, in, The contactless card is used to communicate an identifier, which is a counter, to the client device.

11. The computer-implemented method of claim 6, in, The encrypted payload includes a message authentication code cryptogram, which acts as a digital signature for verification purposes.

12. The computer-implemented method of claim 6, in, The dynamic key is a private key of a key pair, and the authentication router is configured to decrypt the encrypted payload with a public key to authenticate the identifier.

13. A computer-readable medium storing instructions configured, when executed, to cause one or more processors of a first computing device to: Determining to establish a communication connection with a second computing device; detecting a contactless card within wireless communication range of the computing device; receiving an encrypted payload from the contactless card, the encrypted payload comprising an identifier, wherein the encrypted payload is generated by the contactless card using a dynamic key and an encryption algorithm of the first computing device, the identifier being associated with the contactless card; sending the encrypted payload and the calling number to an authentication router to initiate establishment of a communication connection with the second computing device, wherein the calling number is associated with the second computing device; as well as Communicating with the second computing device via the communication connection based on successful authentication performed by the authentication router using an encrypted payload including the identifier.

Images