Patent Grant
10506426
Unsolicited phone calls present an annoyance and a security risk for call recipients. Recipients may be subject to nuisance calls such as telemarketing calls, prank calls, and/or silent calls. Unsolicited calls may also be used to initiate telephone frauds, wherein imposters pose as legitimate entities in an attempt to steal information or funds.
Telephone call authentication involves attempting to identify a calling party. However, current methods lack the ability to reliably authenticate the devices called from and the parties calling from them. Furthermore, such methods are at best sparsely implemented and subject to practices such as spoofing, in which a caller may use a false identity and/or number in order to trick a call recipient into answering. As a result, users often have a mistrust of communication systems at best. At worst, they may be subject to nuisances and/or security risks.
According to one aspect of the invention, a method for performing peer to peer authentication of calls includes the steps of receiving an incoming call data stream from a first mobile phone device, the incoming call data stream comprising an incoming call number of a second mobile phone device and an encrypted payload comprising payload data encrypted using a private key associated with the first mobile phone device. In some embodiments, the private key comprises a dynamic key of the first mobile phone device and the encrypted payload comprises a cryptogram. 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 cryptogram to an authentication server, wherein the authentication server maintains and modifies a copy of the dynamic key concurrently with the first mobile phone device as the stored information related to the first mobile phone device. In some embodiments, the authentication further includes receiving a validation of the first mobile phone device from the authentication server in response to a counter match between a counter extracted from the cryptogram using the 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 authenticating.
According to another aspect of the invention, a system for authenticating calls between devices comprises an interface configured to receive an incoming call data stream from a first mobile phone device. In some embodiments, the incoming call data stream comprises an incoming call number associated with a second mobile phone device and an encrypted payload comprising 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 operable when executed upon by the processor to authenticate the incoming call data stream in response to a match between information of the encrypted payload and stored information related to 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 the step of authenticating.
According to yet another aspect of the invention, a method for authenticating calls between mobile devices includes the steps of receiving an incoming call data stream from a first mobile phone device. In some embodiments, the incoming call data stream comprises an incoming call number associated with a second mobile phone device, and an encrypted payload comprises payload data encrypted using a private key associated with the first mobile phone device and a voice message an attribute. 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 produce a decrypted payload comprising an identifier. The method includes comparing the identifier of the decrypted payload to an expected identifier associated with the incoming call number to determine a first factor authentication match and comparing the attribute of the voice message to an expected voice message attribute 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.
With such an arrangement, a system and method are provided for reliably authenticating incoming calls.
An objective of some embodiments of the present disclosure is 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 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). The contactless card may be used to perform authentication and numerous other functions that may otherwise require the user to carry a separate physical token in addition to the contactless card. By employing a contactless interface, contactless cards may be provided with a method to interact and communicate between a user's device (such as a mobile phone) and the card itself. For example, the near-field communication (NFC) protocol, which underlies many credit card transactions, includes an authentication process which suffices for operating systems for Android® but presents challenges for iOS,®, which is more restrictive regarding NFC usage, as it can be used only in a read-only manner. Exemplary embodiments of the contactless cards described in the '119 Application may utilize NFC technology. Authenticating users via the contactless card interface may overcome prior art identity theft issues by validating endpoints of a call link.
Various embodiments described herein are directed towards authenticating calls by using one or more keys associated with a specific user. In examples, the user is the sender of a call. In various embodiments, when a call is made, an identifying payload is encrypted using a private key associated with the user. The encrypted identifying payload is appended to the call data stream. The identifying payload may be decrypted with a public key. In embodiments, the identifying payload may be verified. In various embodiments, further authentication methods may be performed by using an object such as a contactless card to provide one or more components of the identifying payload and/or keys. In embodiments, a connection may be made between the sender and the intended recipient of a call based on the verification of the identifying payload.
In some embodiments described herein, the private key used to encrypt the identifying payload may be stored or issued with respect to a particular user device. Such a user device may be a network-enabled computer. As referred to herein, a network-enabled computer may include, but is not limited to: e.g., a computer device, or communications device including, e.g., 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 device, a fat client device, or other device.
In some embodiments described herein, the private key used to encrypt the identifying payload may be stored or issued with respect to a separate object associated with the user. For example, the separate object may be a contactless card, as referenced in the incorporated '119 application and in greater detail herein. Embodiments are not limited in this context.
In various embodiments described herein, the identifying payload may comprise text data, audio data, numerical data, or a combination thereof. For example, an identifying payload may comprise information about a user's association with a communication service provider, a voice message, or a counter as associated with a contactless card. Embodiments are not limited in this context.
While unsolicited calls may come from a variety of callers with a variety of purposes, they are often difficult for a recipient to identify, leading to poor user experience for communication system clients and user mistrust of the communication system.
For example, caller ID may indicate to a call recipient that a caller is a known contact or show the caller's phone number so that the recipient may recognize an area code in it. However, caller ID can be turned off by the caller. Furthermore, in this example, the recipient is still notified of the incoming call and must still deliberately deny it. Furthermore, harassers can avoid proper identification, for example, by spoofing or blocking caller ID. In further examples, voice over IP users may send false caller ID or route calls through servers in multiple countries.
For the field of phone communications, the FCC has called for the implementation of Signature-based Handling of Asserted Information Using toKENs (SHAKEN) and the Secure Telephone Identity Revisited (STIR) standards, but these procedures also fall short of fully authenticating the identity of a caller. In SHAKEN/STIR, the service provider of a caller may create a digital signature based on what it knows about the call origination, such as the customer and their right to use the number called from, the customer (but not the number), or the point from which the call enters their network. An origination identifier may be assigned to uniquely identify the call origination. However, in these procedures, the end verification is that a caller has a right to appear as a certain calling party to the recipient. The call may not actually come from the number that appears as the caller. For example, service provider-approved spoofing may still take place. Even after the implementation of such methods, recipients will not have certainty of the identity on the other end of an incoming communication. There is a need for an improved system to authenticate identities of parties originating communication.
Various embodiments described herein include components that can enable one or more of the following: (1) authentication of a communication initiator in association with the device used to initiate the communication, (2) authentication of a communication initiator in association with the device used to initiate the communication and separate identifying information provided by and/or relating to the communication initiator, and (3) authentication of a communication initiator in association with the device used to initiate the communication and a separate object uniquely possessed by the communication initiator, for example, a contactless card.
Authentication of communications based on the device from which they were sent reduces the potential for nuisance communications, including fraud attempts, to reach a receiving client, thereby improving the security of their information. In some embodiments, selective connection of a first client device and second client device for communication-based on the results of the authentication or multifactor authentication may reduce the load of unwanted communications on clients and thereby improve client experience.
Embodiments disclosed herein thus leverage authentication features of at least one client device and/or service provider in practical applications to increase security of network communications and/or improve client confidence in the authenticity of received communications. In several embodiments, components described herein may provide specific and particular manners of authenticating communications and/or managing communications based on the results of authentication. In many embodiments, one or more of the components described herein may be implemented as a set of rules that improve computer-related technology by allowing a function not previously performable by a computer that enables an improved technological result to be achieved. For example, authenticating a communication based on identifying information related to the communication initiator is such an improved technological result. In another example, the function may include secure multifactor authentication via leveraging of features of a client device and/or separate object, such as a contactless card. In another example, the function may include managing communications by selectively connecting devices for communication according to the results of multifactor authentication.
These and other features of the invention will now be described with reference to the figures, wherein like reference numerals are used to refer to like elements throughout.
As used in this application, the terms “system”, “component” and “unit” are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are described herein. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers.
Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.
In various embodiments, a first client device 125 may initiate a communication with the intention of reaching one or more client devices 130. While only one device is illustrated in
The client devices 125 and 130 can include a processor and a memory, and it is understood that the processing circuitry may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives, and tamper-proofing hardware, as necessary to perform the functions described herein. The client devices 125 and 130 may further include a display and input devices. The display may be any type of device for presenting visual information such as a computer monitor, a flat panel display, and a mobile device screen, including liquid crystal displays, light-emitting diode displays, plasma panels, and cathode ray tube displays. The input devices may include any device for entering information into the user's device that is available and supported by the user's device, such as a touch-screen, keyboard, mouse, cursor-control device, touch-screen, microphone, digital camera, video recorder or camcorder. These devices may be used to enter information and interact with the software and other devices described herein.
One or more client devices 125 and 130 also may be a mobile device for example, such as an iPhone, iPod, iPad from Apple® or any other mobile device running Apple's iOS operating system, any device running Microsoft's Windows® Mobile operating system, and/or any other smartphone or like wearable mobile device.
Client devices 125 and 130 may include a thin client application specifically adapted for communication with a service provider. A service provider may be a business or other entity providing computer-related services over a network. The thin client application may be stored in a memory of the client device and be operable when executed upon by the client device to control an interface between the client device and a service provider application, permitting a user at the client device to access service provider content and services.
In embodiments, the client device 125 is associated with a private key 126 and a public key 127. The private key 126 and the public key 127 may be related so as to be able to encrypt and decrypt data, such as in symmetric key encryption or asymmetric key encryption (also known as public key encryption). In embodiments, the private key 126 and the public key 127 may be different, with the public key 127 being available to systems external to the client device 125 and the private key 126 intended only to be known by the client device 125. In such embodiments, the system 100 may be directed to use asymmetric key encryption. In some embodiments, the same public key may be available to and/or associated with multiple client devices, for example, with client device 125 and with the client device 130.
In various embodiments, the private key 126 may be persistent or static. In other embodiments, the private key may be a dynamic key. For example, a private key 126 may be a rolling key. A private key 126 may be changed, for example, as a function of time, of a counter, or other dynamic condition. In various embodiments, a counter by which a private key 126 is updated may be advanced by a client's use of the client device 125 or of a separate object, such as a contactless card as described in the '119 application and in more detail herein. It will be readily understood that a dynamic key may be updated in response to other events, changes in circumstance, and/or a combination of any described above.
In various embodiments, association of the private key 126 and/or the public key 127 with the client device 125 may be established at or before the issuance of the client device 125 to the client. For example, the keys may be set by a manufacturer of the device, by a service provider, or other entity. In other embodiments, the private key 126 and/or the public key 127 may be linked to the device later. For example, a client device 125 may receive updated keys 126 and 127. In various embodiments, the private key 126 and/or the public key 127 may be stored to memory on the client device 125 or to an external server or database. In various embodiments, the private key 126 and/or the public key 127 may 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 public key 127 may be updated or diversified in accordance with dynamic data such as a counter. Such examples are found in the '119 reference, incorporated herein by reference.
The client device 125 may initiate communication with another client device 130 by generating a message 140. In embodiments, the message 140 may comprise an encrypted payload and a phone number. The encrypted payload may be encrypted using the private key 126. The phone number may comprise the phone number of the client device 125 and/or the client device 130. In embodiments, the payload encrypted as the encrypted payload of message 140 may comprise text, numerical, audio, other data, or a combination thereof. The payload may comprise uniquely identifying information for the client, the client device 125, or a combination thereof. Furthermore, the encrypted payload may contain hashed data. Such information may be stored in memory accessible to the client device 125, for example, local to the client device or accessible via a network connection. In various embodiments, the encrypted payload may comprise dynamic information relating to the client, the client device 125, or a separate object, for example, a contactless card as described in greater detail herein. 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.
In some embodiments, the encrypted payload and/or message 140 may be appended to a communication from the client device 125. For example, the encrypted payload may be appended to a call data stream. In some embodiments, a communication from the client device 125 may be included in the encrypted payload.
The message 140 may be sent from the client device 125. In various embodiments, the message 140 may pass through an authentication router 120. The authentication router 120 may be associated with a network 115.
In some examples, network 115 may be one or more of a wireless network, a wired network or any combination of wireless network and wired network and may be configured to connect client device 125 to service provider 320. For example, network 115 may include one or more of a fiber optics 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 Communication, a Personal Communication Service, a Personal Area Network, Wireless Application Protocol, Multimedia Messaging Service, Enhanced Messaging Service, Short Message Service, Time Division Multiplexing based systems, Code Division Multiple Access based systems, 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/or the like.
In addition, network 115 may include, without limitation, telephone lines, fiber optics, 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, or the like, or any combination thereof. Network 115 may further include one network, or any number of the exemplary types of networks mentioned above, operating as a stand-alone network or in cooperation with each other. Network 115 may utilize one or more protocols of one or more network elements to which they are communicatively coupled. Network 115 may translate to or from other protocols to one or more protocols of network devices.
Furthermore, it should be appreciated that according to one or more examples, network 115 may be part of a plurality of interconnected networks, such as, for example, the Internet, a service provider's private network, a cable television network, corporate networks, such as credit card association networks, and home networks. In some embodiments, the authentication router 120 and/or network 115 may be associated with a communication service provider. In addition, a private network may be implemented as a virtual private network layered upon network 115.
For example, network 115 may comprise a public switched telephone network (PSTN), and the authentication router may be associated with the communication service provider used by the client of client device 125 and/or client device 130.
The authentication router 120 may have access to the public key 127 associated with the client device 125. In some cases, the authentication router 120 may receive the public key 127 from the client device 125 via the message 140. In other embodiments, the authentication router 120 may have access to a database, table, or other storage or memory in which the public key 127 is stored. In these embodiments, the memory may be local to the authentication router 120 or otherwise available via the network 115.
In some embodiments, the authentication router 120 has access to storage as described above which includes dynamic information pertaining to the encrypted payload of the message 140. For example, dynamic information included in the encrypted payload may be reflected by the information available to the authentication router. For example, if the payload comprises current information about a client's account with a communication service provider, the memory may comprise separately maintained current information about the client's account with the service provider. In another example, if the encrypted payload comprises a counter that is increased each time a client uses the client device 125 to make a call, a counter may be updated in the memory accessible to the authentication router 120 each time the client device 125 makes a call.
Such information as pertaining to the client and/or client device 125 may be made initially available to the authentication router 120 upon activation of a client device 125 or issuance of a client device 125 to a client. Furthermore, such information should be associated with the client and/or client device. For example, a counter associated with a client device may be set to zero or some other predetermined number in response to activation of a device, or initial account information for a client may be entered by a communication service provider employee in response to account creation for the client. However, such information is updated independently from the content of the message 140.
In some embodiments, the public key 127 is stored in such memory accessible to the authentication router 120. In embodiments, the public key 127 may be entered with a memory location associated with the client and/or client device 125 upon the issuance of the client device 125 to the client and/or beginning of service by the communication service provider. If the public key is updated, for example, to match an updated private key, the public key 127 in the memory may be updated. In some embodiments, this update may be automatic. In other embodiments, this update may be performed in response to an event, for example, the sending of a message 140 from the client device 125. In some embodiments, the public key 127 may be updated in response to being received as part of a message 140.
In various embodiments, the authentication router 120 may decrypt the message 140 using the public key 127. In embodiments wherein the encrypted payload comprises hashed data, a hash function may be applied to the decrypted payload to extract information, for example, an identifier. In embodiments, contents of the decrypted payload of message 140 may then be compared to information known by the authentication router pertaining to the client and/or client device. For example, if the payload comprises a counter, that counter may be compared to the counter known by the authentication router. The matching of the information of the decrypted payload and the information known by the authentication router 120 allows for authentication of the message 140 as being genuinely sent from the client device 125.
As the public key 127 is related to the private key 126, which is known only to the client device 125, successful decryption of the message 140 using the public key 127 indicates that the message 140 was in fact sent from the client device 125. However, a mismatch between the encrypted payload of a message sent from a client device and the information available to the authentication router pertaining to the client and/or client device 125 may indicate nefarious activity. For example, a hacker or imposter may have gained access to the private key 126 of client device 125 and the message received by the authentication router may not be from the client device 125 as identified. In cases where an incoming message was unable to be decrypted using the public key 127 and/or the decrypted payload of the message could not be authenticated, the communication may be flagged for recipient client device 130. In some embodiments, the connection for the communication between client devices 125 and 130 may not be completed based upon such a failure of authentication. Information pertaining to the client device 125 and/or the message 140 may be flagged, stored in a database, and/or sent to the service provider or other entity, for example, law enforcement, based upon such failure of authentication. In some embodiments, client devices 125 and 130 may be connected for communication based upon successful authentication of the initiating client device 125.
In some embodiments, the client device 130 has an associated private key 136 and public key 137 of its own. It will be understood that these keys may allow for returned communication from client device 130 to client device 125 by the same methods described with respect to communications from client device 125 to client device 130.
In various embodiments, authentication processes may take place locally to recipient client device 130 as opposed to locally to an authentication router 120. Specifically, a message 140 may be routed by network 115 to client device 130 while still encrypted.
In such embodiments, the client device 130 may have access to the public key 127 associated with the client device 125. In some cases, the client device 130 may receive the public key 127 from the client device 125 via the message 140. In other embodiments, the client device 130 may have access to a database, table, or other storage or memory in which the public key 127 is stored. In these embodiments, the memory may be local to the client device 130 or otherwise available via the network 115.
In some embodiments, the client device 130 has access to storage as described above which includes dynamic information pertaining to the encrypted payload of the message 140. For example, dynamic information included in the encrypted payload may be reflected by information available to the authentication router. For example, if the payload comprises current information about a client's account with a communication service provider, the memory may comprise separately maintained current information about the client's account with the service provider. In another example, if the encrypted payload comprises a counter that is increased each time a client uses the client device 125 to make a call, a counter may be updated in the memory accessible to the client device 130 each time the client device 125 makes a call. In such an example, counters relating to client device 125 local to client device 125 and local to client device 130 may be updated specifically in response to communications between client device 125 and client device 130.
Such information as pertaining to the client and/or client device 125 may be made initially available to the client device 130 upon activation of a client device 125 or issuance of a client device 125 to a client. Furthermore, such information should be associated with the client and/or client device. For example, a counter associated with a client device 125 may be set to zero or other predetermined number in response to activation of the client device 125, or initial account information for a client may be entered by a communication service provider employee in response to account creation for the client. In this example, information may be stored in memory external to client device 130, such as a database located on a network server. However, such information is updated independently from the content of the message 140.
In some embodiments, the public key 127 is stored in such memory accessible to the client device 130. In embodiments, the public key 127 may be entered into the memory in association with the client and/or client device 125 upon the issuance of the client device 125 to the client and/or beginning of service by the communication service provider. If the public key is updated, for example, to match a rolling private key, the public key 127 in the memory may be updated. In some embodiments, this update may be automatic. In other embodiments, this update may be performed in response to an event, for example, the sending of a message 140 from the client device 125 to the client device 130. In some embodiments, the public key 127 may be updated in memory available to client device 130 response to being received as part of a message 140.
In various embodiments, the client device 130 may decrypt the message 140 using the public key 127. In embodiments, the decrypted payload of message 140 may then be compared to information known by the client device 130 pertaining to the client and/or client device. For example, if the payload comprises a counter, that counter may be compared to the counter known by the client device 130. The matching of the information of the decrypted payload and the information known by the client device 130 allows for authentication of the message 140 as being genuinely sent from the client device 125.
As the public key 127 is related to the private key 126, which is known only to the client device 125, successful decryption of the message 140 using the public key 127 indicates that the message 140 was in fact sent from the client device 125. However, a mismatch between the encrypted payload of a message sent from a client device and the information available to the authentication router pertaining to the client and/or client device 125 may indicate nefarious activity. For example, a hacker or imposter may have gained access to the private key 126 of client device 125 and the message received by the authentication router may not be from the client device 125 as identified. In cases where an incoming message was unable to be decrypted using the public key 127 and/or the decrypted payload of the message could not be authenticated, the communication may be flagged for recipient client device 130. In some embodiments, the connection for the communication between client devices 125 and 130 may not be completed or continued based upon such a failure of authentication. Information pertaining to the client device 125 and/or the message 140 may be flagged, stored in a database, and/or sent to the service provider or other entity, for example, law enforcement, based upon such failure of authentication. In some embodiments, client devices 125 and 130 may be connected for communication based upon successful authentication of the initiating client device 125.
In embodiments, system 200 may include a processor 210. It is understood that the processing circuitry may contain additional components, including processors, memories, error and parity/CRC checkers, data encoders, anti-collision algorithms, controllers, command decoders, security primitives and tamper-proofing hardware, as necessary to perform the functions described herein. Furthermore, the processor 210 can be any of various commercially available computer processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® DragonBall® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core®, Core (2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processor 210. Such a processor may enable a network-enabled device to communicate with other network-enabled devices via using a PSTN interface 215 managed by an SS7 network interface 220.
Specifically, the PSTN interface 215 allows the system 200 to connect with a network 115 and associated services. A signaling system no. 7 (SSN) network interface is used to manage the system's 200 use of the network 115 via the PSTN interface 215 by using a path and facility distinct from the voice channel to signal set up and release of a communication.
Memory systems such as those referenced with respect to the client device 125, authentication router 120, and client device 130 may be embodied as memory 225, in some examples. The memory 225 may be a read-only memory, write-once read-multiple memory or read/write memory, e.g., RAM, ROM, and EEPROM, and the system 200 may include one or more of these memories. A read-only memory may be factory programmable as read-only or one-time programmable. One-time programmability provides the opportunity to write once then read many times. A write once/read-multiple memory may be programmed at a point in time after the memory chip has left the factory. Once the memory is programmed, it may not be rewritten, but it may be read many times. A read/write memory may be programmed and re-programmed many times after leaving the factory. A read/write memory may also be read many times after leaving the factory.
The memory 225 may be configured to store one or more of key data 230, encrypt/decrypt code 235, and key validation code 240. Key data may comprise keys used to encrypt and/or decrypt information such as a message such as message 140, an identifying payload, or other information. For example, key data 230 may comprise a private key 126 and a public key 127.
Encrypt/decrypt code 235 may comprise code to encrypt and/or decrypt information such as a message such as message 140, an identifying payload, or other information using key data 230.
Key validation code 240 may comprise code to validate the encryption and/or decryption of information such as a message such as message 140, an identifying payload, or other information using the key data 230 according to the encrypt/decrypt code 235. In some embodiments, key validation code 240 may comprise a payload identifying the client and/or client device, for example, an identifying payload of message 140.
The service provider 320 is, in one embodiment, a business providing computer-based services to clients over a network 115. Almost all modern service providers use the internet to provide service offerings to potential consumers. The service offerings are generally provided in the form of software applications which operate using dedicated resources of the service provider. The combination of the software and hardware that provides a particular service to a client is referred to herein as a ‘server.’ The servers may communicate over a private network 350 of the service provider, often referred to as a corporate or enterprise network. The private network 350 may comprise a wireless network, a wired network or any combination of wireless network and wired network as described above with regard to network 115.
In system 300, service provider 320 is shown to include an authentication server 360. Although the server is illustrated as a discrete device, it is appreciated that the applications and servers may be distributed throughout the enterprise or, in the case of distributed resources such as ‘cloud’ resources, throughout the network 115.
Database 330 comprises data storage resources that may be used, for example, to store customer account, credential and other authentication information for use by the authentication server 360. The database 330 may be comprised of coupled data resources comprising any combination of local storage, distributed data center storage or cloud-based storage.
A contactless card 305 may comprise a payment card, such as a credit card, debit card, or gift card, issued by a service provider 320 displayed on the front or back of the card 305. In some examples, the contactless card 305 is not related to a payment card, and may comprise, without limitation, an identification card. In some examples, the payment card may comprise a dual interface contactless payment card. The contactless card 305 may comprise a substrate, which may include a single layer, or one or more laminated layers composed of plastics, metals, and other materials. Exemplary substrate materials include polyvinyl chloride, polyvinyl chloride acetate, acrylonitrile butadiene styrene, polycarbonate, polyesters, anodized titanium, palladium, gold, carbon, paper, and biodegradable materials. In some examples, the contactless card 305 may have physical characteristics compliant with the ID-1 format of the ISO/IEC 7810 standard, and the contactless card may otherwise be compliant with the ISO/IEC 14443 standard. However, it is understood that the contactless card 305 according to the present disclosure may have different characteristics, and the present disclosure does not require a contactless card to be implemented in a payment card.
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, smart phone, laptop, desktop, or tablet computer. The contactless card 305 may also include processing circuitry, antenna and other components not shown in
According to one aspect, a contactless card 305 may be in wireless communication, for example, NFC, with one or more client devices 125. For example, contactless card 305 may comprise one or more chips, such as a radio frequency identification chip, configured to communicate via NFC or other short-range protocols. In other embodiments, contactless card 305 may communicate with client devices 410 through other means including, but not limited to, Bluetooth, satellite, and/or WiFi. As described in the '119 application, contactless card 305 may be configured to communicate with one of a client device 125 through NFC when the contactless card 305 is within range of the respective client device. As will be described in more detail below, the contactless card 305 may generate a cryptogram for use by the service provider to authenticate the client device.
The contactless card 305 may be used to generate a message authentication code (MAC) cryptogram which may function as a digital signature for purposes of verification. Other digital signature algorithms, such as public key asymmetric algorithms, e.g., the Digital Signature Algorithm and the RSA algorithm, or zero knowledge protocols, may be used to perform this verification.
More specifically, the contactless card 305 may be used to generate a session key. The session key may be received via the communication between the contactless card 305 and the client device 125 and act as a private key as described with respect to
In embodiments, the contactless card 305 may be used to pass an identifier to the client device 125. An identifier could be a counter, for example. In various embodiments, a private key associated with the client device 125 may be diversified using the counter and/or used to encrypt the identifier from the contactless card 305 as part of an encrypted identifying payload.
The client device 125 may send a message, for example, message 140. In embodiments, the message may be appended to a call data stream. The message may comprise an encrypted identifier payload associated with the client and/or client device 125. The identifier payload may comprise audio data, for example, a voice message. The message may further comprise at least one phone number, for example, as found in message 140.
In embodiments, the audio data may be recorded from a human voice, for example, from the client or from a service provider employee. In some embodiments, the audio data may comprise a custom voice message. In other embodiments, the audio data may be generated by a computer. In such embodiments, the audio data may be generated in response to a computer device interpretation of the text and/or numerical data, for example, by a text-to-speech application or program. Interpretation of text and/or numerical data may be performed locally to the client device 125 or on another network-enabled device. The data interpreted may comprise identifying information of the client and/or client device. Such information may be stored in memory accessible to the client device 125, for example, local to the client device, local to the contactless card, or accessible via a network connection. For example, information for a particular client may be found in a database in association with the phone number of the client device from which the message was sent. In some embodiments, the information may comprise dynamic information, such as a counter.
The payload may comprise further information including at least one identifier, in some embodiments. Such an identifier may comprise a counter from the contactless card 305, for example, as described in more detail herein and in the '119 application.
In embodiments, a network 315 may include a system enabled with interactive voice response (IVR). The IVR system may receive and decrypt the encrypted identifying payload sent by the client device 125. Decryption may take place by methods necessary, for example, by methods described in the '119 application or by methods described with respect to
The identifier of the decrypted payload, for example, a counter, may be compared to an expected identifier associated with the client device from which the message was sent. In embodiments, the expected identifier may be associated with the client device by reference of a phone number associated with that client device. In embodiments, the expected identifier may be updated independently of the contents of incoming communications from the associated device. For example, a counter may be increased upon reception of a communication from the client device, but regardless of the contents of the messages received from the client device. In another example, a counter may be increased for each message received from the client device when a message contains a certain type of information. The comparison of the identifier of the decrypted payload to the expected identifier may be made by the IVR system, by another network-enabled device, by an application thereon, or another capable processor. Embodiments are not limited in this manner.
The matching of the identifier of the decrypted payload with the expected identifier may determine a first-factor authentication match. This authentication adds a layer of security farther than symmetric key or asymmetric key authentication alone by requiring not only successful decryption, but also matching of an identifier known only by the client device 125 and the memory in which the expected identifier is stored. For example, a counter value of a number X matched from the decrypted payload to an expected value may indicate not only that the payload had been able to be properly decrypted, but that the sending client device had the same record of the number X past communications with the server as the record of the server.
In embodiments, the IVR system may perform second-factor authentication using the audio data included in the identifying payload. In particular, the IVR system may interpret the audio data included in the identifying payload. In some embodiments, the audio data of the decrypted payload may be interpreted by a speech transcription program, such as a speech-to-text application. In some embodiments, the audio data may be analyzed for characteristics of the audio data itself. In embodiments, attributes such as voice message attributes may be identified from the audio data. Voice message attributes may include recognized words, human speech vs. computer-generated speech, voice characteristics such as tone, language, accent, cadence, background noise, volume, and other characteristics recognizable in audio data by a computer. Such attributes may be identified using methods known in the art of language processing, for example, keyword identification or recognition in accordance with a model trained by one or more machine learning algorithms, neural networks, or another training method. In some embodiments, at least one confidence level may be calculated according to the likelihood that the audio data contains at least one attribute.
The interpreted audio data may, in embodiments, 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 embodiments, aspects of analysis of audio data may take place on the enterprise network 350 as opposed to the public network 315. In cases where analysis is performed as described above on network 315, identified attributes of the audio data may be sent to the enterprise network.
An authentication server 360 may compare identified attributes of the audio data from the decrypted payload to expected attributes of audio data from a particular client and/or client device 125. Such attributes may be stored in association with a client and/or client device in the database 330. For example, a custom voice message from the decrypted payload may be compared to a previously known custom voice message associated with the client device 125 in the database 330. In some embodiments, a binary analysis of the matching of attributes may be used. In other embodiments, attributes may be matched according to a confidence level within a certain range. Such a confidence level may be calculated by one or more machine learning methods, keyword identification methods, and/or other methods known in the art, for example. Based upon the comparison of the identified attributes to the expected attributes of the audio data, the authentication server 360 may or may not be able to establish a second factor authentication match. As such a second-factor authentication match may be based on information and/or audio data that is unique to the expected user of the client device 125, the authentication may provide confidence that the actual user of the client device 125 is the expected user, rather than an imposter.
In some embodiments, the IVR system may selectively establish a connection between the first client device 125 and the second client device 130 based on the results of the first and/or second factor authentication match. In some embodiments, the authentication server 360 may communicate to the IVR system the results of the first and/or second factor authentication match. In some embodiments, the authentication server 360 may further communicate instructions to connect or to not connect the first client device 125 and the second client device 130 based on the result of one or more factor authentication matches. In other embodiments, the PSTN or IVR system on network 315 may receive the results of the first and/or second authentication match and determine whether or not to connect the first client device 125 and the second client device 130 for communication based on the results of the one or more factor authentication matches. In some embodiments, the IVR system may be used to limit access of the first client device 125 to the second client device 130 based upon the first client device 125 being authenticated as one of at least one known validated callers. For example, such validated callers may be known and/or marked in the system as making problematic unsolicited calls.
At step 402, the application 422 communicates with the contactless card 305 (e.g., after being brought near the contactless card 305). Communication between the application 422 and the contactless card 305 may involve the contactless card 305 being sufficiently close to a card reader (not shown) of the client device 410 to enable NFC data transfer between the application 422 and the contactless card 305.
At step 404, after communication has been established between client device 410 and contactless card 305, the contactless card 305 generates a MAC cryptogram. In some examples, this may occur when the contactless card 305 is read by the application 422. In particular, this may occur upon a read, such as an NFC read, of a near field data exchange (NDEF) tag, which may be created in accordance with the NFC Data Exchange Format. For example, a reader, such as application 422, may transmit a message, such as an applet select message, with the applet ID of an NDEF producing applet. Upon confirmation of the selection, a sequence of select file messages followed by read file messages may be transmitted. For example, the sequence may include “Select Capabilities file”, “Read Capabilities file”, and “Select NDEF file”. At this point, a counter value maintained by the contactless card 305 may be updated or incremented, which may be followed by “Read NDEF file.” At this point, the message may be generated which may include a header and a shared secret. Session keys may then be generated. The MAC cryptogram may be created from the message, which may include the header and the shared secret. The MAC cryptogram may then be concatenated with one or more blocks of random data, and the MAC cryptogram and a random number (RND) may be encrypted with the session key. Thereafter, the cryptogram and the header may be concatenated, and encoded as ASCII hex and returned in NDEF message format (responsive to the “Read NDEF file” message).
In some examples, the MAC cryptogram may be transmitted as an NDEF tag, and in other examples the MAC cryptogram may be included with a uniform resource indicator (e.g., as a formatted string).
In some examples, application 422 may be configured to transmit a request to contactless card 305, the request comprising an instruction to generate a MAC cryptogram.
At step 406, the contactless card 305 sends the MAC cryptogram to the application 422. In some examples, the transmission of the MAC cryptogram occurs via NFC, however, the present disclosure is not limited thereto. In other examples, this communication may occur via Bluetooth, Wi-Fi, or other means of wireless data communication.
At step 408, the application 422 communicates the MAC cryptogram to the processor 424.
At step 412, the processor 424 verifies the MAC cryptogram pursuant to an instruction from the application 422. For example, the MAC cryptogram may be verified, as explained below.
In some examples, verifying the MAC cryptogram may be performed by a device other than client device 410, such as a service provider 320 in data communication with the client device 410. For example, processor 424 may output the MAC cryptogram for transmission to service provider 320, which may verify the MAC cryptogram.
In some examples, the MAC cryptogram may function as a digital signature for purposes of verification. Other digital signature algorithms, such as public key asymmetric algorithms, e.g., the Digital Signature Algorithm and the RSA algorithm, or zero knowledge protocols, may be used to perform this verification.
More specifically, according to one aspect, a contactless card 305 may be used in conjunction with first authentication credentials provided to a service provider, such as service provider 320, to authenticate a communication from a client device 410, for example, a call. The use of the contactless card as a second factor of authentication enables the association of a particular device/phone number with a specific individual (i.e., the owner of the card), thereby removing the ability for a malicious third party to spoof, i.e., impersonate, the client. According to another aspect of the invention, authentication communication protocols described herein identify or use specific communication channels for call handling, thereby reducing the opportunity for client impersonation.
The security factor authentication may comprise a plurality of processes. In some embodiments, a first authentication process may comprise logging in and validating a user via one or more applications executing on a device. A second authentication process may operate following successful login and validation to cause a user to engage in one or more behaviors associated with one or more contactless cards. In effect, the security factor authentication process comprises a multi-factor authentication process that may include both securely proving identity of the user and encouraging the user to engage in one or more types of behaviors, including but not limited to one or more tap gestures, associated with the contactless card. In some examples, the one or more tap gestures may comprise a tap of the contactless card by the user to a device. In some examples, the device may comprise a mobile device, a terminal, a tablet, or any other device configured to process a received tap gesture.
For example, to provide a first layer of authentication, a client may access an application operating on the client device. In other examples, the client may access the website of the service provider by linking to a service provider web page using an internet browser application executing on the client device. The browser is a software application such as Google® Chrome®, Internet Explorer °, Safari °, etc., and includes programming code for translating Hypertext Markup Language (HTML) web pages of the service provider application to a format suitable for to a client operating the client device.
As part of accessing the application or the service provider website, the service provider may request first authorization information, including password information, answers to pre-stored queries, biometric information, an image, or other mechanism of verifying that a user of the client device is authorized to access content and services, including accounts, managed by the service provider. Furthermore, this level of authentication provides confidence that the user of the client device 125 is the expected client. In other words, while the methods described above may be particularly helpful for at least authenticating that a communication is coming from an authenticated device, these steps may further authenticate that a communication is coming from an authenticated user of said device.
According to one aspect, the contactless card 305 may be used to provide a second authentication for a user of a 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 may be used to generate a cryptogram that may be used to validate a user of a client device. The counter advantageously reflects previous behaviors of the holder of the card. For example, the counter may reflect the number of times that the user has previously communicated with a particular party, information which is virtually impossible for a malicious third party to garner accurately.
A further level of authentication may be made by using the contactless card 305, for example, by communicatively coupling the card 305 to one of the client devices 410 by tapping or otherwise, as mentioned above. In some embodiments, this constitutes the second authentication. In other embodiments, the second authentication is continued with further analysis of an identifying payload, for example, as described with respect to
Following the second authentication, and as described in more detail herein, data may be returned to the client device. For example, the data may include data allowing the client to initiate a communication link with the second client device or information about the success or failure of the authentication attempt.
It should be noted that although in the above description the first authentication is described as using personal, biometric, questions or other authentication information, it is recognized that in some examples, a client application executing on a device may respond to a tap of a contactless card to initially activate or launch the 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.
In some embodiments, if the client-side application is not installed on a client device, a tap of the contactless card proximate the card reader may initiate a download of the application, (such as navigation to a download page of the application). Subsequent to installation, a tap of the contactless card may activate or launch the application, and then initiate, for example via the application or other back-end communication), activation of the contactless card. In some examples, the one or more applications may be configured to determine that it was launched via one or more tap gestures of the contactless card, such that a launch occurred at 3:51 PM, that a transaction was processed or took place at 3:56 PM, in order to verify the identity of the user.
In some examples, data may be collected on tap behaviors as biometric/gestural authentication. For example, a unique identifier that is cryptographically secure and not susceptible to interception may be transmitted to one or more backend services. The unique identifier may be configured to look up secondary information about the individual. The secondary information may comprise personally identifiable information about the user. In some examples, the secondary information may be stored within the contactless card.
Client device 125 may be associated with a private key 126 and a public key 127. Client device 130 may be associated with a private key 136 and a public key 137. In embodiments in which at least one of client device 125 or client device 130 represents a plurality of client devices, each client device may be associated with a private key and a public key.
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, the private key and the public key for a device may be the same, enabling symmetric key encryption. In other embodiments, the private key and the public key may be different, enabling asymmetric key encryption. Keys may be persistent or dynamic. In some embodiments, a private key may be a session key diversified by use of dynamic information local to the client device or provided by an external object or device, such as a contactless card, as described above.
In various embodiments, client device 125 may initiate a communication with client device 130, for example, a call data stream. A message 505 may be appended to the communication. The message 505 may comprise an encrypted payload, at least one phone number, the at least one phone number comprising 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 sending client device 125, for example, a phrase or greeting. In some embodiments, the message 505 may further include the public key 127 of client device 125.
The encrypted payload may be encrypted using the private key of client device 125. The encrypted payload may comprise at least one identifier. In some cases, the voice memo may be included in the encrypted payload.
The second client device 130 may have access to the public key 127 of the first client device 125 in association with the phone number or other identifying data for the client device 125. For example, the public key 127 of the first client device 125 may be received with the message 505, stored locally to 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. Furthermore, the second client device 130 may have access to an expected identifier in association 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 that client device 125.
The message 505 may be received by the client device 130. The client device 130 may retrieve the public key 127 associated with client device 125 and use the public key 127 to decrypt the encrypted payload of the message 505.
Failure of decryption of the payload with the public key 127 may indicate potential fraudulent behavior. As a result, the communication connection supposedly coming from client device 125 may be denied. In some embodiments, feedback may be provided to the user of client device 130, to a service provider, or to a third party, for example, law enforcement.
In some embodiments, the voice memo of message 505 may be presented to the user of client device 130, for example, via a user interface by playing the voice memo audio data to the user of client device 130 when they answer the incoming call. The user interface may be a part of an application on the client device 130. In some embodiments, the voice memo of message 505 may only be presented to the user based upon a successful first authentication of the identifier of the encrypted payload.
The client device 130 may then receive feedback from its user if they do or do not recognize the voice memo from the user of the first client device 125. For example, feedback may be received via a user interface. This verification of recognition of the voice memo from the first client by the second client provides a further layer of authentication. In some embodiments, the client device 130 may receive instructions from the user via the user interface directing continuation or denial of the communication connection between the client devices 125 and 130.
Based on the feedback concerning voice memo recognition received from the user, 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 local memory or add the client device 125 to a list of recognized and/or trusted devices.
In some embodiments, continued communication between recognized and/or trusted devices may take place with streamlined authentication methods. For example, only a first level of authentication may be required.
In step 610, an incoming call data stream is received from a first mobile phone device. The incoming call stream comprises a phone 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 embodiments, the encrypted payload may be appended to the incoming call data stream. The payload data may comprise information pertaining to the first client and/or client device.
In step 620, the incoming call data stream may be authenticated in response to a match between the information of the encrypted payload and stored information related to the first mobile phone device. In various embodiments, the match between the information of the encrypted payload and stored information related to the first mobile phone device may be judged by successful decryption of the payload. For example, a payload may have been encrypted with a public key diversified using a counter. In this example, successful decryption of the payload with a public key diversified by an independently maintained counter may indicate proper authentication.
In step 630, the system may establish a call connection between the first mobile phone device and the second mobile phone device in response to the step of authenticating.
In some embodiments, a system's failure to properly authenticate a call may prompt denial of the call or other method of dismissal of the call. In some embodiments, a first client device and/or second client device may be notified of the failed attempt and provided details of the attempt, such as the phone number of the caller and/or recipient. In some embodiments, a recipient may be prompted via the user interface of the second client device to add the phone number of the calling first client device to a list of numbers to be blocked. In various embodiments, the system may provide a service provider or third party, for example, law enforcement, with information relating to the unauthenticated call.
In some embodiments, a system's successful authentication of a call 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 and/or by the second mobile device identifying the first mobile device as having been engaged with via an authenticated call. Such registration may be referenced in subsequent communications between the two client devices to efficiently check probable authenticity of the subsequent communications based on the authentication of a prior communication.
In some embodiments, a call connection may be made between a first and second mobile phone device in response to the step of authenticating, and the results of the step of authenticating may be indicated to the recipient, for example, via a user interface of the second client device. For example, a call connection may be made despite authentication failure, but a warning may be communicated to the recipient via the user interface of their mobile phone that the call is unauthenticated. In a further example, a call connection may be made in response to authentication success, with a verification being communicated to the recipient via the user interface of their mobile phone that the call has been authenticated.
Step 710 discloses the retrieval of an incoming call number's public key from a data storage device. In some embodiments, the data storage device may be local to the second client device. In other embodiments, the data storage device may be an external memory, such as that discussed above with reference to authentication router 120 or database 330, for example.
Step 720 discloses the decryption of the encrypted payload using the incoming call number's public key, retrieved in step 710, to produce a decrypted payload comprising an identifier. The encrypted payload may be received with the incoming call number, for example, as in message 140. The identifier may be related to the sending client and/or first client device.
Step 730 discloses comparison of the decrypted payload's identifier to an 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 may be retrieved from memory, which may be the same data storage device referenced in step 710 or a separate data storage device.
Step 740 discloses comparison of the attribute of a voice message to an expected voice message attribute to identify a second factor authentication match. The voice message may be received in association with or as part of the encrypted payload.
Step 750 discloses selective establishment of a connection between the first mobile phone device and the second mobile phone device in response to the first factor authentication and the second factor authentication match.
In some embodiments, a system's failure to properly authenticate a call via the first factor and/or the second factor authentication matches may prompt denial of the call, dropping of the call, or other method of dismissal of the call. In some embodiments, a first client device and/or second client device may be notified of the failed attempt and provided details of the attempt, such as the phone number of the caller and/or recipient. In some embodiments, a recipient may be prompted via the user interface of the second client device to add the phone number of the calling first client device to a list of numbers to be blocked. In various embodiments, the system may provide a service provider or third party, for example, law enforcement, with information relating to the unauthenticated call. Such information may specify which factor of authentication failed and include further details of the attempt.
In some embodiments, a system's successful authentication of a call via the first factor and/or the second factor authentication matches 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 and/or by the second mobile device identifying the first mobile device as having been engaged with via a multifactor authenticated call. Such registration may be referenced in subsequent communications between the two client devices to efficiently check probable authenticity of the subsequent communications based on the multifactor authentication of a prior communication.
In some embodiments, a call connection may be made between a first and second mobile phone device in response to the first factor and/or the second factor authentication matches, and the results of the step of authenticating may be indicated to the recipient, for example, via a user interface of the second client device. For example, a call connection may be made despite multifactor authentication failure, but a warning may be communicated to the recipient via the user interface of their mobile phone that the call is unauthenticated or only partially authenticated. In a further example, a call connection may be made in response to multifactor authentication success, with a verification being communicated to the recipient via the user interface of their mobile phone that the call has been authenticated via multifactor authentication.
Various embodiments may be implemented using hardware elements, software elements, or a combination of both. Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate array (FPGA), logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. Examples of software 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, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints.
One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within the processor, which when read by a machine causes the machine to fabricate logic to perform the techniques described herein. Such representations, known as “IP cores” may be stored on a tangible, machine readable medium and supplied to various users or manufacturing facilities to load into the fabrication machines that actually make the logic or processor. Some embodiments may be implemented, for example, using a machine-readable medium or article which may store an instruction or a set of instructions that, if executed by a machine, may cause the machine to perform a method and/or operations in accordance with the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, or the like, and may be implemented using any suitable combination of hardware and/or software. The machine-readable medium or article 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, for example, memory, removable or non-removable media, erasable or non-erasable media, writeable or re-writeable media, digital or analog media, hard disk, floppy disk, Compact Disk Read Only Memory (CD-ROM), Compact Disk Recordable (CD-R), Compact Disk Rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of Digital Versatile Disk (DVD), a tape, a cassette, or the like. 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, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4683553 | Mollier | Jul 1987 | A |
| 4827113 | Rikuna | May 1989 | A |
| 4910773 | Hazard et al. | Mar 1990 | A |
| 5036461 | Elliott et al. | Jul 1991 | A |
| 5363448 | Koopman, Jr. et al. | Nov 1994 | A |
| 5377270 | Koopman, Jr. et al. | Dec 1994 | A |
| 5533126 | Hazard | Jul 1996 | A |
| 5537314 | Kanter | Jul 1996 | A |
| 5592553 | Guski et al. | Jan 1997 | A |
| 5616901 | Crandall | Apr 1997 | A |
| 5666415 | Kaufman | Sep 1997 | A |
| 5763373 | Robinson et al. | Jun 1998 | A |
| 5764789 | Pare, Jr. et al. | Jun 1998 | A |
| 5768373 | Lohstroh et al. | Jun 1998 | A |
| 5778072 | Samar | Jul 1998 | A |
| 5796827 | Coppersmith et al. | Aug 1998 | A |
| 5832090 | Raspotnik | Nov 1998 | A |
| 5883810 | Franklin et al. | Mar 1999 | A |
| 5901874 | Deters | May 1999 | A |
| 5929413 | Gardner | Jul 1999 | A |
| 5960411 | Hartman et al. | Sep 1999 | A |
| 6021203 | Douceur et al. | Feb 2000 | A |
| 6049328 | Vanderheiden | Apr 2000 | A |
| 6058373 | Blinn et al. | May 2000 | A |
| 6061666 | Do et al. | May 2000 | A |
| 6105013 | Curry et al. | Aug 2000 | A |
| 6199114 | White et al. | Mar 2001 | B1 |
| 6199762 | Hohle | Mar 2001 | B1 |
| 6216227 | Goldstein et al. | Apr 2001 | B1 |
| 6227447 | Campisano | May 2001 | B1 |
| 6282522 | Davis et al. | Aug 2001 | B1 |
| 6324271 | Sawyer et al. | Nov 2001 | B1 |
| 6342844 | Rozin | Jan 2002 | B1 |
| 6367011 | Lee et al. | Apr 2002 | B1 |
| 6402028 | Graham, Jr. et al. | Jun 2002 | B1 |
| 6438550 | Doyle et al. | Aug 2002 | B1 |
| 6501847 | Helot et al. | Dec 2002 | B2 |
| 6631197 | Taenzer | Oct 2003 | B1 |
| 6641050 | Kelley et al. | Nov 2003 | B2 |
| 6655585 | Shinn | Dec 2003 | B2 |
| 6662020 | Aaro et al. | Dec 2003 | B1 |
| 6721706 | Strubbe et al. | Apr 2004 | B1 |
| 6731778 | Oda et al. | May 2004 | B1 |
| 6779115 | Naim | Aug 2004 | B1 |
| 6792533 | Jablon | Sep 2004 | B2 |
| 6829711 | Kwok et al. | Dec 2004 | B1 |
| 6834271 | Hodgson et al. | Dec 2004 | B1 |
| 6834795 | Rasmussen et al. | Dec 2004 | B1 |
| 6852031 | Rowe | Feb 2005 | B1 |
| 6865547 | Brake, Jr. et al. | Mar 2005 | B1 |
| 6873260 | Lancos et al. | Mar 2005 | B2 |
| 6877656 | Jaros et al. | Apr 2005 | B1 |
| 6889198 | Kawan | May 2005 | B2 |
| 6905411 | Nguyen et al. | Jun 2005 | B2 |
| 6910627 | Simpson-Young et al. | Jun 2005 | B1 |
| 6971031 | Haala | Nov 2005 | B2 |
| 6990588 | Yasukura | Jan 2006 | B1 |
| 7006986 | Sines et al. | Feb 2006 | B1 |
| 7085931 | Smith et al. | Aug 2006 | B1 |
| 7127605 | Montgomery et al. | Oct 2006 | B1 |
| 7128274 | Kelley et al. | Oct 2006 | B2 |
| 7140550 | Ramachandran | Nov 2006 | B2 |
| 7152045 | Hoffman | Dec 2006 | B2 |
| 7165727 | de Jong | Jan 2007 | B2 |
| 7175076 | Block et al. | Feb 2007 | B1 |
| 7202773 | Oba et al. | Apr 2007 | B1 |
| 7206806 | Pineau | Apr 2007 | B2 |
| 7232073 | de Jong | Jun 2007 | B1 |
| 7246752 | Brown | Jul 2007 | B2 |
| 7254569 | Goodman et al. | Aug 2007 | B2 |
| 7263507 | Brake, Jr. et al. | Aug 2007 | B1 |
| 7270276 | Vayssiere | Sep 2007 | B2 |
| 7278025 | Saito et al. | Oct 2007 | B2 |
| 7287692 | Patel et al. | Oct 2007 | B1 |
| 7290709 | Tsai et al. | Nov 2007 | B2 |
| 7306143 | Bonneau, Jr. et al. | Dec 2007 | B2 |
| 7319986 | Praisner et al. | Jan 2008 | B2 |
| 7325132 | Takayama et al. | Jan 2008 | B2 |
| 7373515 | Owen et al. | May 2008 | B2 |
| 7374099 | de Jong | May 2008 | B2 |
| 7375616 | Rowse et al. | May 2008 | B2 |
| 7380710 | Brown | Jun 2008 | B2 |
| 7424977 | Smets et al. | Sep 2008 | B2 |
| 7453439 | Kushler et al. | Nov 2008 | B1 |
| 7472829 | Brown | Jan 2009 | B2 |
| 7487357 | Smith et al. | Feb 2009 | B2 |
| 7568631 | Gibbs et al. | Aug 2009 | B2 |
| 7584153 | Brown et al. | Sep 2009 | B2 |
| 7597250 | Finn | Oct 2009 | B2 |
| 7628322 | Holtmanns et al. | Dec 2009 | B2 |
| 7652578 | Braun et al. | Jan 2010 | B2 |
| 7689832 | Talmor et al. | Mar 2010 | B2 |
| 7703142 | Wilson et al. | Apr 2010 | B1 |
| 7748609 | Sachdeva et al. | Jul 2010 | B2 |
| 7748617 | Gray | Jul 2010 | B2 |
| 7748636 | Finn | Jul 2010 | B2 |
| 7762457 | Bonalle et al. | Jul 2010 | B2 |
| 7789302 | Tame | Sep 2010 | B2 |
| 7793851 | Mullen | Sep 2010 | B2 |
| 7796013 | Murakami et al. | Sep 2010 | B2 |
| 7801799 | Brake, Jr. et al. | Sep 2010 | B1 |
| 7801829 | Gray et al. | Sep 2010 | B2 |
| 7805755 | Brown et al. | Sep 2010 | B2 |
| 7809643 | Phillips et al. | Oct 2010 | B2 |
| 7827115 | Weller et al. | Nov 2010 | B2 |
| 7828214 | Narendra et al. | Nov 2010 | B2 |
| 7848746 | Juels | Dec 2010 | B2 |
| 7882553 | Tuliani | Feb 2011 | B2 |
| 7900048 | Andersson | Mar 2011 | B2 |
| 7908216 | Davis et al. | Mar 2011 | B1 |
| 7922082 | Muscato | Apr 2011 | B2 |
| 7933589 | Mamdani et al. | Apr 2011 | B1 |
| 7949559 | Freiberg | May 2011 | B2 |
| 7954716 | Narendra et al. | Jun 2011 | B2 |
| 7954723 | Charrat | Jun 2011 | B2 |
| 7962369 | Rosenberg | Jun 2011 | B2 |
| 7993197 | Kaminkow | Aug 2011 | B2 |
| 8005426 | Huomo et al. | Aug 2011 | B2 |
| 8010405 | Bortolin et al. | Aug 2011 | B1 |
| RE42762 | Shin et al. | Sep 2011 | E |
| 8041954 | Plesman | Oct 2011 | B2 |
| 8060012 | Sklovsky et al. | Nov 2011 | B2 |
| 8074877 | Mullen et al. | Dec 2011 | B2 |
| 8082450 | Frey et al. | Dec 2011 | B2 |
| 8095113 | Kean et al. | Jan 2012 | B2 |
| 8099332 | Lemay et al. | Jan 2012 | B2 |
| 8103249 | Markson | Jan 2012 | B2 |
| 8108687 | Ellis et al. | Jan 2012 | B2 |
| 8127143 | Abdallah et al. | Feb 2012 | B2 |
| 8135648 | Oram et al. | Mar 2012 | B2 |
| 8140010 | Symons et al. | Mar 2012 | B2 |
| 8141136 | Lee et al. | Mar 2012 | B2 |
| 8150321 | Winter et al. | Apr 2012 | B2 |
| 8150767 | Wankmueller | Apr 2012 | B2 |
| 8186602 | Itay et al. | May 2012 | B2 |
| 8196131 | von Behren et al. | Jun 2012 | B1 |
| 8215563 | Levy et al. | Jul 2012 | B2 |
| 8224753 | Atef et al. | Jul 2012 | B2 |
| 8232879 | Davis | Jul 2012 | B2 |
| 8233841 | Griffin et al. | Jul 2012 | B2 |
| 8245292 | Buer | Aug 2012 | B2 |
| 8249654 | Zhu | Aug 2012 | B1 |
| 8266451 | Leydier et al. | Sep 2012 | B2 |
| 8285329 | Zhu | Oct 2012 | B1 |
| 8302872 | Mullen | Nov 2012 | B2 |
| 8312519 | Bailey et al. | Nov 2012 | B1 |
| 8316237 | Felsher et al. | Nov 2012 | B1 |
| 8332272 | Fisher | Dec 2012 | B2 |
| 8365988 | Medina, III et al. | Feb 2013 | B1 |
| 8369960 | Tran et al. | Feb 2013 | B2 |
| 8371501 | Hopkins | Feb 2013 | B1 |
| 8381307 | Cimino | Feb 2013 | B2 |
| 8391719 | Alameh et al. | Mar 2013 | B2 |
| 8417231 | Sanding et al. | Apr 2013 | B2 |
| 8439271 | Smets et al. | May 2013 | B2 |
| 8475367 | Yuen et al. | Jul 2013 | B1 |
| 8489112 | Roeding et al. | Jul 2013 | B2 |
| 8511542 | Pan | Aug 2013 | B2 |
| 8559872 | Butler | Oct 2013 | B2 |
| 8566916 | Bailey et al. | Oct 2013 | B1 |
| 8567670 | Stanfield et al. | Oct 2013 | B2 |
| 8572386 | Takekawa et al. | Oct 2013 | B2 |
| 8577810 | Dalit et al. | Nov 2013 | B1 |
| 8583454 | Beraja et al. | Nov 2013 | B2 |
| 8589335 | Smith et al. | Nov 2013 | B2 |
| 8594730 | Bona et al. | Nov 2013 | B2 |
| 8615468 | Varadarajan | Dec 2013 | B2 |
| 8620218 | Awad | Dec 2013 | B2 |
| 8667285 | Coulier et al. | Mar 2014 | B2 |
| 8723941 | Shirbabadi et al. | May 2014 | B1 |
| 8726405 | Bailey et al. | May 2014 | B1 |
| 8740073 | Vijayshankar et al. | Jun 2014 | B2 |
| 8750514 | Gallo et al. | Jun 2014 | B2 |
| 8752189 | de Jong | Jun 2014 | B2 |
| 8794509 | Bishop et al. | Aug 2014 | B2 |
| 8799668 | Cheng | Aug 2014 | B2 |
| 8806592 | Ganesan | Aug 2014 | B2 |
| 8807440 | von Behren et al. | Aug 2014 | B1 |
| 8811892 | Khan et al. | Aug 2014 | B2 |
| 8814039 | Bishop et al. | Aug 2014 | B2 |
| 8814052 | Bona et al. | Aug 2014 | B2 |
| 8818867 | Baldwin et al. | Aug 2014 | B2 |
| 8850538 | Vernon et al. | Sep 2014 | B1 |
| 8861733 | Benteo et al. | Oct 2014 | B2 |
| 8880027 | Darringer | Nov 2014 | B1 |
| 8888002 | Chesney et al. | Nov 2014 | B2 |
| 8898088 | Springer et al. | Nov 2014 | B2 |
| 8934837 | Zhu et al. | Jan 2015 | B2 |
| 8977569 | Rao | Mar 2015 | B2 |
| 8994498 | Agrafioti et al. | Mar 2015 | B2 |
| 9004365 | Bona et al. | Apr 2015 | B2 |
| 9038894 | Khalid | May 2015 | B2 |
| 9042814 | Royston et al. | May 2015 | B2 |
| 9047531 | Showering et al. | Jun 2015 | B2 |
| 9069976 | Toole et al. | Jun 2015 | B2 |
| 9081948 | Magne | Jul 2015 | B2 |
| 9104853 | Venkataramani et al. | Aug 2015 | B2 |
| 9118663 | Bailey et al. | Aug 2015 | B1 |
| 9122964 | Krawczewicz | Sep 2015 | B2 |
| 9129280 | Bona et al. | Sep 2015 | B2 |
| 9152832 | Royston et al. | Oct 2015 | B2 |
| 9203800 | Izu et al. | Dec 2015 | B2 |
| 9209867 | Royston | Dec 2015 | B2 |
| 9251330 | Boivie et al. | Feb 2016 | B2 |
| 9251518 | Levin et al. | Feb 2016 | B2 |
| 9258715 | Borghei | Feb 2016 | B2 |
| 9270337 | Zhu et al. | Feb 2016 | B2 |
| 9306626 | Hall et al. | Apr 2016 | B2 |
| 9306942 | Bailey et al. | Apr 2016 | B1 |
| 9324066 | Archer et al. | Apr 2016 | B2 |
| 9324067 | Van Os et al. | Apr 2016 | B2 |
| 9332587 | Salahshoor | May 2016 | B2 |
| 9338622 | Bjontegard | May 2016 | B2 |
| 9373141 | Shakkarwar | Jun 2016 | B1 |
| 9379841 | Fine et al. | Jun 2016 | B2 |
| 9413430 | Royston et al. | Aug 2016 | B2 |
| 9413768 | Gregg et al. | Aug 2016 | B1 |
| 9420496 | Indurkar | Aug 2016 | B1 |
| 9426132 | Alikhani | Aug 2016 | B1 |
| 9432339 | Bowness | Aug 2016 | B1 |
| 9455968 | Machani et al. | Sep 2016 | B1 |
| 9473509 | Arsanjani et al. | Oct 2016 | B2 |
| 9491626 | Sharma et al. | Nov 2016 | B2 |
| 9553637 | Yang et al. | Jan 2017 | B2 |
| 9619952 | Zhao et al. | Apr 2017 | B1 |
| 9635000 | Muftic | Apr 2017 | B1 |
| 9665858 | Kumar | May 2017 | B1 |
| 9674705 | Rose et al. | Jun 2017 | B2 |
| 9679286 | Colnot et al. | Jun 2017 | B2 |
| 9680942 | Dimmick | Jun 2017 | B2 |
| 9710804 | Zhou et al. | Jul 2017 | B2 |
| 9740342 | Paulsen et al. | Aug 2017 | B2 |
| 9740988 | Levin et al. | Aug 2017 | B1 |
| 9763097 | Robinson et al. | Sep 2017 | B2 |
| 9767329 | Forster | Sep 2017 | B2 |
| 9769662 | Queru | Sep 2017 | B1 |
| 9773151 | Mil'shtein et al. | Sep 2017 | B2 |
| 9780953 | Gaddam et al. | Oct 2017 | B2 |
| 9891823 | Feng et al. | Feb 2018 | B2 |
| 9940571 | Herrington | Apr 2018 | B1 |
| 9953323 | Candelore et al. | Apr 2018 | B2 |
| 9961194 | Wiechman et al. | May 2018 | B1 |
| 9965756 | Davis et al. | May 2018 | B2 |
| 9965911 | Wishne | May 2018 | B2 |
| 9978058 | Wurmfeld et al. | May 2018 | B2 |
| 10043164 | Dogin et al. | Aug 2018 | B2 |
| 10075437 | Costigan et al. | Sep 2018 | B1 |
| 10129648 | Hernandez et al. | Nov 2018 | B1 |
| 10133979 | Eidam et al. | Nov 2018 | B1 |
| 10217105 | Sangi et al. | Feb 2019 | B1 |
| 20010010723 | Pinkas | Aug 2001 | A1 |
| 20010029485 | Brody et al. | Oct 2001 | A1 |
| 20010034702 | Mockett et al. | Oct 2001 | A1 |
| 20010054003 | Chien et al. | Dec 2001 | A1 |
| 20020078345 | Sandhu et al. | Jun 2002 | A1 |
| 20020093530 | Krothapalli et al. | Jul 2002 | A1 |
| 20020100808 | Norwood et al. | Aug 2002 | A1 |
| 20020120583 | Keresman, III et al. | Aug 2002 | A1 |
| 20020152116 | Yan et al. | Oct 2002 | A1 |
| 20020153424 | Li | Oct 2002 | A1 |
| 20020165827 | Gien et al. | Nov 2002 | A1 |
| 20030023554 | Yap et al. | Jan 2003 | A1 |
| 20030034873 | Chase et al. | Feb 2003 | A1 |
| 20030055727 | Walker et al. | Mar 2003 | A1 |
| 20030078882 | Sukeda et al. | Apr 2003 | A1 |
| 20030167350 | Davis et al. | Sep 2003 | A1 |
| 20030208449 | Diao | Nov 2003 | A1 |
| 20040015958 | Veil et al. | Jan 2004 | A1 |
| 20040039919 | Takayama et al. | Feb 2004 | A1 |
| 20040127256 | Goldthwaite et al. | Jul 2004 | A1 |
| 20040215674 | Odinak et al. | Oct 2004 | A1 |
| 20040230799 | Davis | Nov 2004 | A1 |
| 20050044367 | Gasparini et al. | Feb 2005 | A1 |
| 20050075985 | Cartmell | Apr 2005 | A1 |
| 20050081038 | Arditti Modiano et al. | Apr 2005 | A1 |
| 20050138387 | Lam et al. | Jun 2005 | A1 |
| 20050156026 | Ghosh et al. | Jul 2005 | A1 |
| 20050160049 | Lundholm | Jul 2005 | A1 |
| 20050195975 | Kawakita | Sep 2005 | A1 |
| 20050247797 | Ramachandran | Nov 2005 | A1 |
| 20060006230 | Bear et al. | Jan 2006 | A1 |
| 20060040726 | Szrek et al. | Feb 2006 | A1 |
| 20060041402 | Baker | Feb 2006 | A1 |
| 20060044153 | Dawidowsky | Mar 2006 | A1 |
| 20060047954 | Sachdeva et al. | Mar 2006 | A1 |
| 20060085848 | Aissi et al. | Apr 2006 | A1 |
| 20060136334 | Atkinson et al. | Jun 2006 | A1 |
| 20060173985 | Moore | Aug 2006 | A1 |
| 20060174331 | Schuetz | Aug 2006 | A1 |
| 20060242698 | Inskeep et al. | Oct 2006 | A1 |
| 20060280338 | Rabb | Dec 2006 | A1 |
| 20070033642 | Ganesan et al. | Feb 2007 | A1 |
| 20070055630 | Gauthier et al. | Mar 2007 | A1 |
| 20070061266 | Moore et al. | Mar 2007 | A1 |
| 20070061487 | Moore et al. | Mar 2007 | A1 |
| 20070116292 | Kurita et al. | May 2007 | A1 |
| 20070118745 | Buer | May 2007 | A1 |
| 20070197261 | Humbel | Aug 2007 | A1 |
| 20070224969 | Rao | Sep 2007 | A1 |
| 20070241182 | Buer | Oct 2007 | A1 |
| 20070256134 | Lehtonen et al. | Nov 2007 | A1 |
| 20070258594 | Sandhu et al. | Nov 2007 | A1 |
| 20070278291 | Rans et al. | Dec 2007 | A1 |
| 20080008315 | Fontana et al. | Jan 2008 | A1 |
| 20080011831 | Bonalle et al. | Jan 2008 | A1 |
| 20080014867 | Finn | Jan 2008 | A1 |
| 20080035738 | Mullen | Feb 2008 | A1 |
| 20080071681 | Khalid | Mar 2008 | A1 |
| 20080072303 | Syed | Mar 2008 | A1 |
| 20080086767 | Kulkarni et al. | Apr 2008 | A1 |
| 20080103968 | Bies et al. | May 2008 | A1 |
| 20080109309 | Landau et al. | May 2008 | A1 |
| 20080110983 | Ashfield | May 2008 | A1 |
| 20080120711 | Dispensa | May 2008 | A1 |
| 20080156873 | Wilhelm et al. | Jul 2008 | A1 |
| 20080162312 | Sklovsky et al. | Jul 2008 | A1 |
| 20080164308 | Aaron et al. | Jul 2008 | A1 |
| 20080207307 | Cunningham, II et al. | Aug 2008 | A1 |
| 20080209543 | Aaron | Aug 2008 | A1 |
| 20080223918 | Williams et al. | Sep 2008 | A1 |
| 20080285746 | Landrock et al. | Nov 2008 | A1 |
| 20080308641 | Finn | Dec 2008 | A1 |
| 20090037275 | Pollio | Feb 2009 | A1 |
| 20090048026 | French | Feb 2009 | A1 |
| 20090132417 | Scipioni et al. | May 2009 | A1 |
| 20090143104 | Loh et al. | Jun 2009 | A1 |
| 20090171682 | Dixon et al. | Jul 2009 | A1 |
| 20090210308 | Toomer et al. | Aug 2009 | A1 |
| 20090235339 | Mennes et al. | Sep 2009 | A1 |
| 20090249077 | Gargaro et al. | Oct 2009 | A1 |
| 20090282264 | Ameil et al. | Nov 2009 | A1 |
| 20100023449 | Skowronek et al. | Jan 2010 | A1 |
| 20100023455 | Dispensa et al. | Jan 2010 | A1 |
| 20100029202 | Jolivet et al. | Feb 2010 | A1 |
| 20100033310 | Narendra et al. | Feb 2010 | A1 |
| 20100036769 | Winters et al. | Feb 2010 | A1 |
| 20100078471 | Lin et al. | Apr 2010 | A1 |
| 20100082491 | Rosenblatt et al. | Apr 2010 | A1 |
| 20100094754 | Bertran et al. | Apr 2010 | A1 |
| 20100095130 | Bertran et al. | Apr 2010 | A1 |
| 20100100480 | Altman et al. | Apr 2010 | A1 |
| 20100114731 | Kingston et al. | May 2010 | A1 |
| 20100192230 | Steeves et al. | Jul 2010 | A1 |
| 20100207742 | Buhot et al. | Aug 2010 | A1 |
| 20100211797 | Westerveld et al. | Aug 2010 | A1 |
| 20100240413 | He et al. | Sep 2010 | A1 |
| 20100257357 | McClain | Oct 2010 | A1 |
| 20100312634 | Cervenka | Dec 2010 | A1 |
| 20100312635 | Cervenka | Dec 2010 | A1 |
| 20110028160 | Roeding et al. | Feb 2011 | A1 |
| 20110035604 | Habraken | Feb 2011 | A1 |
| 20110060631 | Grossman et al. | Mar 2011 | A1 |
| 20110068170 | Lehman | Mar 2011 | A1 |
| 20110084132 | Tofighbakhsh | Apr 2011 | A1 |
| 20110101093 | Ehrensvard | May 2011 | A1 |
| 20110113245 | Varadarajan | May 2011 | A1 |
| 20110125638 | Davis et al. | May 2011 | A1 |
| 20110131415 | Schneider | Jun 2011 | A1 |
| 20110153437 | Archer et al. | Jun 2011 | A1 |
| 20110153496 | Royyuru | Jun 2011 | A1 |
| 20110208658 | Makhotin | Aug 2011 | A1 |
| 20110208965 | Machani | Aug 2011 | A1 |
| 20110211219 | Bradley et al. | Sep 2011 | A1 |
| 20110218911 | Spodak | Sep 2011 | A1 |
| 20110238564 | Lim et al. | Sep 2011 | A1 |
| 20110246780 | Yeap et al. | Oct 2011 | A1 |
| 20110258452 | Coulier et al. | Oct 2011 | A1 |
| 20110280406 | Ma et al. | Nov 2011 | A1 |
| 20110282785 | Chin | Nov 2011 | A1 |
| 20110294418 | Chen | Dec 2011 | A1 |
| 20110312271 | Ma et al. | Dec 2011 | A1 |
| 20120024947 | Naelon | Feb 2012 | A1 |
| 20120030047 | Fuentes et al. | Feb 2012 | A1 |
| 20120030121 | Grellier | Feb 2012 | A1 |
| 20120047071 | Mullen et al. | Feb 2012 | A1 |
| 20120079281 | Lowenstein et al. | Mar 2012 | A1 |
| 20120109735 | Krawczewicz | May 2012 | A1 |
| 20120109764 | Martin et al. | May 2012 | A1 |
| 20120143754 | Patel | Jun 2012 | A1 |
| 20120150737 | Rottink et al. | Jun 2012 | A1 |
| 20120178366 | Levy et al. | Jul 2012 | A1 |
| 20120196583 | Kindo | Aug 2012 | A1 |
| 20120207305 | Gallo et al. | Aug 2012 | A1 |
| 20120209773 | Ranganathan | Aug 2012 | A1 |
| 20120238206 | Singh et al. | Sep 2012 | A1 |
| 20120239560 | Pourfallah et al. | Sep 2012 | A1 |
| 20120252350 | Steinmetz et al. | Oct 2012 | A1 |
| 20120254394 | Barras | Oct 2012 | A1 |
| 20120284194 | Liu et al. | Nov 2012 | A1 |
| 20120290472 | Mullen et al. | Nov 2012 | A1 |
| 20120296818 | Nuzzi et al. | Nov 2012 | A1 |
| 20120316992 | Oborne | Dec 2012 | A1 |
| 20120317035 | Royyuru et al. | Dec 2012 | A1 |
| 20120317628 | Yeager | Dec 2012 | A1 |
| 20130005245 | Royston | Jan 2013 | A1 |
| 20130008956 | Ashfield | Jan 2013 | A1 |
| 20130026229 | Jarman et al. | Jan 2013 | A1 |
| 20130048713 | Pan | Feb 2013 | A1 |
| 20130054474 | Yeager | Feb 2013 | A1 |
| 20130065564 | Conner et al. | Mar 2013 | A1 |
| 20130080228 | Fisher | Mar 2013 | A1 |
| 20130080229 | Fisher | Mar 2013 | A1 |
| 20130099587 | Lou et al. | Apr 2013 | A1 |
| 20130104251 | Moore et al. | Apr 2013 | A1 |
| 20130106576 | Hinman et al. | May 2013 | A1 |
| 20130119130 | Braams | May 2013 | A1 |
| 20130130614 | Busch-Sorensen | May 2013 | A1 |
| 20130144793 | Royston | Jun 2013 | A1 |
| 20130171929 | Adams et al. | Jul 2013 | A1 |
| 20130179351 | Wallner | Jul 2013 | A1 |
| 20130185772 | Jaudon et al. | Jul 2013 | A1 |
| 20130191279 | Calman et al. | Jul 2013 | A1 |
| 20130200999 | Spodak et al. | Aug 2013 | A1 |
| 20130216108 | Hwang et al. | Aug 2013 | A1 |
| 20130226791 | Springer et al. | Aug 2013 | A1 |
| 20130226796 | Jiang et al. | Aug 2013 | A1 |
| 20130232082 | Krawczewicz et al. | Sep 2013 | A1 |
| 20130238894 | Ferg et al. | Sep 2013 | A1 |
| 20130282360 | Shimola et al. | Oct 2013 | A1 |
| 20130303085 | Boucher et al. | Nov 2013 | A1 |
| 20130304651 | Smith | Nov 2013 | A1 |
| 20130312082 | Izu et al. | Nov 2013 | A1 |
| 20130314593 | Reznik et al. | Nov 2013 | A1 |
| 20130344857 | Berionne et al. | Dec 2013 | A1 |
| 20140002238 | Taveau et al. | Jan 2014 | A1 |
| 20140019352 | Shrivastava | Jan 2014 | A1 |
| 20140027506 | Heo et al. | Jan 2014 | A1 |
| 20140032409 | Rosano | Jan 2014 | A1 |
| 20140032410 | Georgiev et al. | Jan 2014 | A1 |
| 20140040120 | Cho et al. | Feb 2014 | A1 |
| 20140040139 | Brudnicki et al. | Feb 2014 | A1 |
| 20140040147 | Varadarakan et al. | Feb 2014 | A1 |
| 20140047235 | Lessiak et al. | Feb 2014 | A1 |
| 20140067690 | Pitroda et al. | Mar 2014 | A1 |
| 20140074637 | Hammad | Mar 2014 | A1 |
| 20140074655 | Lim et al. | Mar 2014 | A1 |
| 20140081720 | Wu | Mar 2014 | A1 |
| 20140138435 | Khalid | May 2014 | A1 |
| 20140171034 | Aleksin et al. | Jun 2014 | A1 |
| 20140171039 | Bjontegard | Jun 2014 | A1 |
| 20140172700 | Teuwen et al. | Jun 2014 | A1 |
| 20140180851 | Fisher | Jun 2014 | A1 |
| 20140208112 | McDonald | Jul 2014 | A1 |
| 20140214674 | Narula | Jul 2014 | A1 |
| 20140229375 | Zaytzsev et al. | Aug 2014 | A1 |
| 20140245391 | Adenuga | Aug 2014 | A1 |
| 20140256251 | Caceres et al. | Sep 2014 | A1 |
| 20140258099 | Rosano | Sep 2014 | A1 |
| 20140258113 | Gauthier et al. | Sep 2014 | A1 |
| 20140258125 | Gerber et al. | Sep 2014 | A1 |
| 20140274179 | Zhu et al. | Sep 2014 | A1 |
| 20140279479 | Maniar et al. | Sep 2014 | A1 |
| 20140337235 | Van Heerden et al. | Nov 2014 | A1 |
| 20140339315 | Ko | Nov 2014 | A1 |
| 20140346860 | Aubry et al. | Nov 2014 | A1 |
| 20140365780 | Movassaghi | Dec 2014 | A1 |
| 20140379361 | Mahadkar et al. | Dec 2014 | A1 |
| 20150012444 | Brown et al. | Jan 2015 | A1 |
| 20150032635 | Guise | Jan 2015 | A1 |
| 20150071486 | Rhoads et al. | Mar 2015 | A1 |
| 20150088674 | Flurscheim | Mar 2015 | A1 |
| 20150088757 | Zhou et al. | Mar 2015 | A1 |
| 20150089586 | Ballesteros | Mar 2015 | A1 |
| 20150134452 | Williams | May 2015 | A1 |
| 20150140960 | Powell et al. | May 2015 | A1 |
| 20150154595 | Collinge et al. | Jun 2015 | A1 |
| 20150170138 | Rao | Jun 2015 | A1 |
| 20150178724 | Ngo et al. | Jun 2015 | A1 |
| 20150186871 | Laracey | Jul 2015 | A1 |
| 20150205379 | Mag et al. | Jul 2015 | A1 |
| 20150302409 | Malek et al. | Oct 2015 | A1 |
| 20150317626 | Ran et al. | Nov 2015 | A1 |
| 20150332266 | Friedlander et al. | Nov 2015 | A1 |
| 20150339474 | Paz et al. | Nov 2015 | A1 |
| 20150371234 | Huang et al. | Dec 2015 | A1 |
| 20160012465 | Sharp | Jan 2016 | A1 |
| 20160026997 | Tsui et al. | Jan 2016 | A1 |
| 20160048913 | Rausaria et al. | Feb 2016 | A1 |
| 20160055480 | Shah | Feb 2016 | A1 |
| 20160057619 | Lopez | Feb 2016 | A1 |
| 20160065370 | Le Saint | Mar 2016 | A1 |
| 20160087957 | Shah et al. | Mar 2016 | A1 |
| 20160092696 | Guglani et al. | Mar 2016 | A1 |
| 20160148193 | Kelley et al. | May 2016 | A1 |
| 20160232523 | Venot et al. | Aug 2016 | A1 |
| 20160239672 | Khan et al. | Aug 2016 | A1 |
| 20160253651 | Park et al. | Sep 2016 | A1 |
| 20160255072 | Liu | Sep 2016 | A1 |
| 20160267486 | Mitra et al. | Sep 2016 | A1 |
| 20160277383 | Guyomarc'h et al. | Sep 2016 | A1 |
| 20160277388 | Lowe et al. | Sep 2016 | A1 |
| 20160307187 | Guo et al. | Oct 2016 | A1 |
| 20160307189 | Zarakas et al. | Oct 2016 | A1 |
| 20160314472 | Ashfield | Oct 2016 | A1 |
| 20160330027 | Ebrahimi | Nov 2016 | A1 |
| 20160335531 | Mullen et al. | Nov 2016 | A1 |
| 20160379217 | Hammad | Dec 2016 | A1 |
| 20170004502 | Quentin et al. | Jan 2017 | A1 |
| 20170011395 | Pillai et al. | Jan 2017 | A1 |
| 20170011406 | Tunnell et al. | Jan 2017 | A1 |
| 20170017957 | Radu | Jan 2017 | A1 |
| 20170017964 | Janefalkar et al. | Jan 2017 | A1 |
| 20170024716 | Jiam et al. | Jan 2017 | A1 |
| 20170039566 | Schipperheijn | Feb 2017 | A1 |
| 20170041759 | Gantert et al. | Feb 2017 | A1 |
| 20170068950 | Kwon | Mar 2017 | A1 |
| 20170103388 | Pillai et al. | Apr 2017 | A1 |
| 20170104739 | Lansler et al. | Apr 2017 | A1 |
| 20170109509 | Baghdasaryan | Apr 2017 | A1 |
| 20170109730 | Locke et al. | Apr 2017 | A1 |
| 20170116447 | Cimino et al. | Apr 2017 | A1 |
| 20170124568 | Moghadam | May 2017 | A1 |
| 20170140379 | Deck | May 2017 | A1 |
| 20170154328 | Zarakas | Jun 2017 | A1 |
| 20170154333 | Gleeson et al. | Jun 2017 | A1 |
| 20170180134 | King | Jun 2017 | A1 |
| 20170230189 | Toll et al. | Aug 2017 | A1 |
| 20170237301 | Elad et al. | Aug 2017 | A1 |
| 20170289127 | Hendrick | Oct 2017 | A1 |
| 20170295013 | Claes | Oct 2017 | A1 |
| 20170316696 | Bartel | Nov 2017 | A1 |
| 20170317834 | Smith et al. | Nov 2017 | A1 |
| 20170330173 | Woo et al. | Nov 2017 | A1 |
| 20170374070 | Shah et al. | Dec 2017 | A1 |
| 20180034507 | Wobak et al. | Feb 2018 | A1 |
| 20180039986 | Essebag et al. | Feb 2018 | A1 |
| 20180068316 | Essebag et al. | Mar 2018 | A1 |
| 20180129945 | Saxena et al. | May 2018 | A1 |
| 20180160255 | Park | Jun 2018 | A1 |
| 20180191501 | Lindemann | Jul 2018 | A1 |
| 20180205712 | Versteeg et al. | Jul 2018 | A1 |
| 20180240106 | Garrett et al. | Aug 2018 | A1 |
| 20180254909 | Hancock | Sep 2018 | A1 |
| 20180268132 | Buer et al. | Sep 2018 | A1 |
| 20180270214 | Caterino et al. | Sep 2018 | A1 |
| 20180294959 | Traynor et al. | Oct 2018 | A1 |
| 20180300716 | Carlson | Oct 2018 | A1 |
| 20180302396 | Camenisch et al. | Oct 2018 | A1 |
| 20180315050 | Hammad | Nov 2018 | A1 |
| 20180316666 | Koved et al. | Nov 2018 | A1 |
| 20180322486 | Deliwala et al. | Nov 2018 | A1 |
| 20180359100 | Gaddam et al. | Dec 2018 | A1 |
| 20190014107 | George | Jan 2019 | A1 |
| 20190019375 | Foley | Jan 2019 | A1 |
| 20190036678 | Ahmed | Jan 2019 | A1 |
| 20190238517 | D'Agostino | Aug 2019 | A1 |
| 20190260732 | Narayan | Aug 2019 | A1 |
| Number | Date | Country |
|---|---|---|
| 3010336 | Jul 2017 | CA |
| 101192295 | Jun 2008 | CN |
| 103023643 | Apr 2013 | CN |
| 103417202 | Dec 2013 | CN |
| 1085424 | Mar 2001 | EP |
| 1223565 | Jul 2002 | EP |
| 1265186 | Dec 2002 | EP |
| 1783919 | May 2007 | EP |
| 2139196 | Dec 2009 | EP |
| 1469419 | Aug 2012 | EP |
| 2852070 | Mar 2015 | EP |
| 2457221 | Aug 2009 | GB |
| 2516861 | Feb 2015 | GB |
| 2551907 | Jan 2018 | GB |
| 101508320 | Apr 2015 | KR |
| 0049586 | Aug 2000 | WO |
| 2006070189 | Jul 2006 | WO |
| 2008055170 | May 2008 | WO |
| 2009025605 | Feb 2009 | WO |
| 2010049252 | May 2010 | WO |
| 2011112158 | Sep 2011 | WO |
| 2012001624 | Jan 2012 | WO |
| 2013039395 | Mar 2013 | WO |
| 2013155562 | Oct 2013 | WO |
| 2013192358 | Dec 2013 | WO |
| 2014043278 | Mar 2014 | WO |
| 2014170741 | Oct 2014 | WO |
| 2015179649 | Nov 2015 | WO |
| 2015183818 | Dec 2015 | WO |
| 2016097718 | Jun 2016 | WO |
| 2016160816 | Oct 2016 | WO |
| 2016168394 | Oct 2016 | WO |
| 2017042375 | Mar 2017 | WO |
| 2017042400 | Mar 2017 | WO |
| 2017157859 | Sep 2017 | WO |
| 2017208063 | Dec 2017 | WO |
| 2018063809 | Apr 2018 | WO |
| 2018137888 | Aug 2018 | WO |
| Entry |
|---|
| Haykin, M. and Warnar, R., “Smart Card Technology: New Methods for Computer Access Control”, Computer Science and Technology NIST Special Publication 500-157:1-60 (1988). |
| Lehpamer, H., “Component of the RFID System”, RFID Design Principles, 2nd edition pp. 133-201 (2012). |
| Author Unknown, “CardrefresherSM from American Express®”, [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://merchant-channel.americanexpress.com/merchant/en_US/cardrefresher, 2 pages. |
| Author Unknown, “Add Account Updater to your recurring payment tool”, [online] 2018-19 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.authorize.net/our-features/account-updater/, 5 pages. |
| Author Unknown, “Visa® Account Updater for Merchants”, [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://usa.visa.com/dam/VCOM/download/merchants/visa-account-updater-product-information-fact-sheet-for-merchants.pdf, 2 pages. |
| Author Unknown, “Manage the cards that you use with Apple Pay”, Apple Support [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://support.apple.com/en-us/HT205583, 5 pages. |
| Author Unknown, “Contactless Specifications for Payment Systems”, EMV Book B—Entry Point Specification [online] 2016 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.emvco.com/wp-content/uploads/2017/05/BookB_Entry_Point_Specification_v2_6_20160809023257319.pdf, 52 pages. |
| Author Unknown, “EMV Integrated Circuit Card Specifcations for Payment Systems, Book 2, Security and Key Management,” Version 3.4, [online] 2011 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.emvco.com/wp-content/uploads/2017/05/EMV_v4.3_Book_2_Security_and_Key_Management_20120607061923900.pdf, 174 pages. |
| Author Unknown, “NFC Guide: All You Need to Know About Near Field Communication”, Square Guide [online] 2018 [retrieved on Nov. 13, 2018]. Retrieved from Internet URL: https://squareup.com/guides/nfc, 8 pages. |
| Profis, S., “Everything you need to know about NFC and mobile payments” CNET Directory [online], 2014 [retrieved on Mar. 25, 2019]. Retrieved from the Internet URL: https://www.cnet.com/how-to/how-nfc-works-and-mobile-payments/, 6 pages. |
| Cozma, N., “Copy data from other devices in Android 5.0 Lollipop setup”, CNET Directory [online] 2014 [retrieved on Mar. 25, 2019]. Retrieved from the Internet URL: https://www.cnet.com/how-to/copy-data-from-other-devices-in-android-5-0-lollipop-setup/, 5 pages. |
| Kevin, Android Enthusiast, “How to copy text string from nfc tag”, StackExchange [online] 2013 [retrieved on Mar. 25, 2019]. Retrieved from the Internet URL: https://android.stackexchange.com/questions/55689/how-to-copy-text-string-from-nfc-tag, 11 pages. |
| Author Unknown, “Tap & Go Device Setup”, Samsung [online] date unknown [retrieved on Mar. 25, 2019]. Retrieved from the Internet URL: https://www.samsung.com/us/switch-me/switch-to-the-galaxy-s-5/app/partial/setup-device/tap-go.html, 1 page. |
| Author Unknown, “Multiple encryption”, Wikipedia [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://en.wikipedia.org/wiki/Multiple_encryption, 4 pages. |
| Krawczyk, et al., “HMAC: Keyed-Hashing for Message Authentication”, Network Working Group RFC:2104 memo [online] 1997 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://tools.ietf.org/html/rfc2104, 12 pages. |
| Song, et al., “The AES-CMAC Algorithm”, Network Working Group RFC: 4493 memo [online] 2006 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://tools.ietf.org/html/rfc4493, 21 pages. |
| Katz, J. And Lindell, Y., “Aggregate Message Authentication Codes”, Topics in Cryptology [online] 2008 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.cs.umd.edu/˜jkatz/papers/aggregateMAC.pdf, 11 pages. |
| Adams, D., and Maier, A-K., “Goldbug Big Seven open source crypto-messengers to be compared—or: Comprehensive Confidentiality Review & Audit of GoldBug Encrypting E-Mail-Client & Secure Instant Messenger”, Big Seven Study 2016 [online] [retrieved on Mar. 25, 2018]. Retrieved from Internet URL: https://sf.net/projects/goldbug/files/bigseven-crypto-audit.pdf, 309 pages. |
| Author Unknown, “Triple DES”, Wikipedia [online] 2018 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://simple.wikipedia.org/wiki/Triple_DES, 2 pages. |
| Song F., and Yun, A.I., “Quantum Security of NMAC and Related Constructions—PRF domain extension against quantum attacks”, IACR Cryptology ePrint Archive [online] 2017 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://eprint.iacr.org/2017/509.pdf, 41 pages. |
| Saxena, N., “Lecture 10: NMAC, HMAC and Number Theory”, CS 6903 Modern Cryptography [online] 2008 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: http://isis.poly.edu/courses/cs6903/Lectures/lecture10.pdf, 8 pages. |
| Berg, G., “Fundamentals of EMV”, Smart Card Alliance [online] date unknown [retrieved on Mar. 27, 2019]. Retrieveed from Internet URL: https://www.securetechalliance.org/resources/media/scap13_preconference/02.pdf, 37 pages. |
| Pierce, K., “Is the amazon echo nfc compatible?”, Amazon.com Customer Q&A [online] 2016 [retrieved on Mar. 26, 2019]. Retrieved from Internet URL: https://www.amazon.com/ask/questions/Tx1RJXYSPE6XLJD?_encodi . . . , 2 pages. |
| Author Unknown, “Multi-Factor Authentication”, idaptive [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.centrify.com/products/application-services/adaptive-multi-factor-authentication/risk-based-mfa/, 10 pages. |
| Author Unknown, “Adaptive Authentication”, SecureAuth [online] 2019 [retrieved on Mar. 25, 2019}. Retrieved from Internet URL: https://www.secureauth.com/products/access-management/adaptive-authentication, 7 pages. |
| Van den Breekel, J., et al., “EMV in a nutshell”, Technical Report, 2016 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.cs.ru.nl/E.Poll/papers/EMVtechreport.pdf, 37 pages. |
| Author Unknown, “Autofill”, Computer Hope [online] 2018 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.computerhope.com/jargon/a/autofill.htm, 2 pages. |
| Author Unknown, “Fill out forms automatically”, Google Chrome Help [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://support.google.com/chrome/answer/142893?co=GENIE.Platform%3DDesktop&hl=en, 3 pages. |
| Author Unknown, “Autofill credit cards, contacts, and passwords in Safari on Mac”, Apple Safari User Guide [online] 2019 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://support.apple.com/guide/safari/use-autofill-brw1103/mac, 3 pages. |
| Menghin, M.J., “Power Optimization Techniques for Near Field Communication Systems”, 2014 Dissertation at Technical University of Graz [online]. Retrieved from Internet URL: https://diglib.tugraz.at/download.php?d=576a7b910d2d6&location=browse, 135 pages. |
| Mareli, M., et al., “Experimental evaluation of NFC reliability between an RFID tag and a smartphone”, Conference paper (2013) IEEE AFRICON At Mauritius [online] [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://core.ac.uk/download/pdf/54204839.pdf, 5 pages. |
| Davison, A., et al., “MonoSLAM: Real-Time Single Camera SLAM”, IEEE Transactions on Pattern Analysis and Machine Intelligence 29(6): 1052-1067 (2007). |
| Barba, R., “Sharing your location with your bank sounds creepy, but it's also useful”, Bankrate, LLC [online] 2017 [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.bankrate.com/banking/banking-app-location-sharing/, 6 pages. |
| Author Unknown: “onetappayment™”, [online] Jan. 24, 2019, [retrieved on Mar. 25, 2019]. Retrieved from Internet URL: https://www.payubiz.in/onetap, 4 pages. |
| Vu, et al., “Distinguishing users with capacitive touch communication”, Proceedings of the Annual International Conference on Mobile Computing and Networking, 2012, MOBICOM. 10.1145/2348543.2348569. |
| Pourghomi, P., et al., “A Proposed NFC Payment Application,” International Journal of Advanced Computer Science and Applications, 4(8):173-181 (2013). |
| Author unknown, “EMV Card Personalization Specification”, EMVCo., LLC., specification version 1.0, (2003) 81 pages. |
| Ullmann et al., “On-Card User Authentication for Contactless Smart Cards based on Gesture Recognition”, paper presentation LNI proceedings, (2012) 12 pages. |
| Faraj, S.T., et al., “Investigation of Java Smart Card Technology for Multi-Task Applications”, J of Al-Anbar University for Pure Science, 2(1):23 pages (2008). |
| Dhamdhere, P., “Key Benefits of a Unified Platform for Loyalty, Referral Marketing, and UGC” Annex Cloud [online] May 19, 2017 [retrieved on Jul. 3, 2019]. Retrieved from Internet URL: https://www.annexcloude.com/blog/benefits-unified-platform/, 13 pages. |
