US20150095175A1 - Transaction processing, system, method, and apparatus that utilizes a token credential - Google Patents
Transaction processing, system, method, and apparatus that utilizes a token credentialDownload PDFInfo
- Publication number
- US20150095175A1 US20150095175A1US14/510,822US201414510822AUS2015095175A1US 20150095175 A1US20150095175 A1US 20150095175A1US 201414510822 AUS201414510822 AUS 201414510822AUS 2015095175 A1US2015095175 A1US 2015095175A1
- Authority
- US
- United States
- Prior art keywords
- account
- user
- payment
- credential
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4014—Identity check for transactions
- G06Q20/40145—Biometric identity checks
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10297—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves arrangements for handling protocols designed for non-contact record carriers such as RFIDs NFCs, e.g. ISO/IEC 14443 and 18092
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of M-devices
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3821—Electronic credentials
- G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
- G06Q20/4012—Verifying personal identification numbers [PIN]
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
- H04B5/70—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
- H04B5/77—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for interrogation
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/02—Protecting privacy or anonymity, e.g. protecting personally identifiable information [PII]
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/10—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation
- G06K7/10009—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves
- G06K7/10366—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves the interrogation device being adapted for miscellaneous applications
- G06K7/10415—Methods or arrangements for sensing record carriers, e.g. for reading patterns by electromagnetic radiation, e.g. optical sensing; by corpuscular radiation sensing by radiation using wavelengths larger than 0.1 mm, e.g. radio-waves or microwaves the interrogation device being adapted for miscellaneous applications the interrogation device being fixed in its position, such as an access control device for reading wireless access cards, or a wireless ATM
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
- H04W12/033—Protecting confidentiality, e.g. by encryption of the user plane, e.g. user's traffic
Definitions
- the present inventionrelates generally to systems and methodologies for conducting electronic commerce and more particularly to systems and methodologies for issuing, managing, storing and using credentials authorizing the legitimate holder of such a credential to accomplish a desired result.
- consumertypically carry multiple single-purpose cards, tags, passes, and tokens which allow them to identify themselves to or present account information to retailers, service providers, financial institutions, government agencies, and other organizations.
- These single-purpose devicesmay contain combinations of encoded personal, account, and/or security information in order to identify a user and to authorize the user to conduct a particular transaction.
- Data on these devicesmay be encoded on a variety of media types such as magnetic stripes, bar codes, chips, and/or embossed or printed data.
- the creation of standards for many encoding formatshas contributed to the proliferation of certain card and device types.
- datamay be encoded on magnetic stripe cards using a proprietary methodology or by employing an “open” or “standard” encoding pattern.
- Magnetic stripe cardshave been embraced by financial institutions, merchants, and consumers ever since standards for such cards were adopted by the industry in the 1970s.
- a magnetic stripeis encoded with bit patterns, which correspond to three tracks of ASCII characters. Credit cards and other bank cards typically use only tracks 1 and 2.
- Track 3is a read/write track, but its usage is not standardized among financial institutions and is seldom used.
- ISOInternational Standards Organization
- Magnetic stripe technologyis widely used throughout the world and remains the dominant technology in the United States for transaction processing and access control.
- One drawback associated with magnetic stripe technologyis the limited amount of information that it can hold.
- Other technologiessuch as bar code and smart chip cards are also widely used in large part because they can hold more information than magnetic stripe cards.
- Another drawback of magnetic stripe technologyis that it provides little in the way of card authentication.
- the data on the stripecan be easily read by a card reader and potentially “skimmed” and then copied onto a fraudulent card.
- bank issuersare not able to distinguish card data originating from a genuine card from card data read from a copied (cloned) card during an “online” authorization.
- Smart cardsprovide a distinct advantage in that they offer the ability to provide authentication in connection with a transaction. Card authentication can be performed by the reader terminal and/or the issuer's systems using dynamic techniques that distinguish genuine cards from clones.
- a smart cardgenerally includes an embedded semi-conductor device which is programmed before issue with the account holder's information. This data is protected through secure encryption methods, making it difficult to fraudulently replicate a smart card.
- the integrated circuits within smart cardsin general have continued to improve with miniaturization, low power requirements, the addition of strong encryption capability, and tamper-proof standards for crypto-processor chips
- a contact smart cardrequires that the user insert the smart card into a smart card reader with a direct connection to a conductive micro-module on the surface of the card. It is via these physical contact points, that transmission of commands, data, and card status takes place.
- a contactless smart cardrequires only close proximity to a reader. Both the reader and the card have antennas and it is via this contactless link that the two communicate via radio frequency (RF) when in close proximity.
- RFradio frequency
- Most contactless cardstypically receive power for on-card electronic functions via this electromagnetic signal. The range is typically two to three inches for non-battery powered cards, and this is ideal for applications such as mass transit which requires a very fast card interface.
- the third category of smart cardsis known as hybrid smart cards. These cards typically have a dual interface enabling both contact and contactless communication with the card's chip.
- RFIDRadio Frequency Identification
- Contactless applicationsare particularly attractive to the retail payments segment where speed, convenience, and security are essential.
- Contactless payment systemsare used successfully around the globe and offer a number of advantages to issuers, retailers, and consumers.
- Contactless paymentsallow issuers to penetrate the cash payment market, enjoy increased customer transaction volume, reduce fraud, and utilize the existing transaction processing infrastructure.
- Retailersrealize benefits due to improved operational efficiency and lower operating costs. Consumers enjoy the convenience of faster transaction times and the ability to integrate multiple payment and loyalty accounts on one device.
- smart cardsare slowly replacing the magnetic stripe card as the dominant technology for conducting financial transactions.
- the enhanced ability of smart cards to secure confidential information and the ability of POS systems to authenticate the chip cardsmakes them an attractive alternative to magnetic stripe cards.
- the reduction of fraudulent transactions achieved by smart cardsresults in lower risk, and lower fees for the consumer and the merchant.
- Common short-range communications network standards defined by the International Electrical and Electronic Engineers association (IEEE)include 802.11a, 802.11b, and 802.11g. Many mobile devices employ these IEEE network standards to establish wireless LAN (WLAN) connectivity.
- WLANwireless LAN
- Various other short-range technologies currently in use for device-to-device communicationinclude Bluetooth and infra-red.
- IRinfra-red
- IrDAInfra-red Device Association
- Wireless devices with integrated RFID proximity chips or Near Field Communication (NFC) technologymay also provide users the ability to transfer information to a reader device.
- PTDpersonal trusted device
- One primary hurdle to the broad-based deployment of such a solutionis the difficulty in providing for the convenient, efficient, and secure distribution of credentials into wireless devices such that only those authorized to conduct the transactions may do so and only to the extent of their authorization.
- credential issuersSince there is such a large number of credential issuers, mobile operators, and wireless end-users world-wide, there is also a need for a credential issuance and management system that is readily accessible by such a broad and diverse set of users. There is also a need for a system and method through which credential issuers can securely and rapidly target specific wireless devices for the distribution of the appropriate credentials over public and private networks.
- credentialsmay be selectively issued by issuers such as credit card companies, banks, and merchants to consumers permitting the specific consumer to conduct a transaction according to the authorization given as reflected by the credential or set of credentials.
- issuerssuch as credit card companies, banks, and merchants
- the preferred mechanism for controlling and distributing credentials according to the present inventionis through one or more publicly accessible networks such as the Internet wherein the system design and operating characteristics are in conformance with the standards and other specific requirements of the chosen network or set of networks.
- credentialsare ultimately supplied to a handheld device such as a mobile telephone via a wireless network. The user holding the credential may then use the handheld device to conduct the authorized transaction or set of transactions via, for example, a short range wireless link with a point-of-sale (POS) terminal.
- POSpoint-of-sale
- FIG. 1is a overall view of the components of the present system and their relationship to one another according to a preferred embodiment of the present invention
- FIG. 2is a flowchart illustrating the steps in the process for issuing a credential according to a preferred embodiment of the present invention
- FIG. 3illustrates some of the SIP components, their relationship to one another and the protocols that are employed in a preferred embodiment of the present invention
- FIG. 4is an illustration of a typical SIP message exchange between a credential issuer and a fictitious mobile user
- FIG. 5is a block diagram illustrating the steps in the SIP registration process of a wireless device according to a preferred embodiment of the present invention
- FIGS. 6( a ) and 6 ( b )are graphical representations showing examples of where a “wallet button” might be situated on a wireless device according to a preferred embodiment of the present invention
- FIGS. 7( a ) and 7 ( b )are graphical representations showing examples of where “hot buttons” might be situated on a wireless device according to a preferred embodiment of the present invention.
- FIG. 8is a diagram illustrating the over-the-air PIN verification scheme of the present invention.
- FIG. 9is an example screen shot of a PIN Approval Request displayed by the wallet application according to a preferred embodiment of the present invention.
- FIG. 1is an overall system diagram illustrating some of the key components of the credential distribution system of the present invention in a preferred embodiment thereof.
- the ultimate goal of the present inventionis to securely, accurately and rapidly distribute credentials to the proper wireless devices based upon the actions of credential issuers. It is also important that these credential issuers have the ability to securely, accurately and rapidly update credentials as required.
- wireless credential manager 110 of the present inventionfunctions to manage, distribute and update credentials so that they are contained as desired in a wallet software application running on wireless device 200 .
- a set of components 100collectively comprise a subsystem capable of, among other things, causing the issuance of a credential to wireless device 200 according to the teachings of the present invention.
- FIG. 1shows only a single wireless device 200 it will be readily understood that in deploying the present invention, credential issuers obtain the ability to selectively control credentials held by a practically unlimited number of wireless devices.
- the teachings of the present inventionillustrate techniques for ensuring that the proper credentials are made available only to the proper wireless device or set of wireless devices. Various addressing and other techniques are used in the present invention to ensure secure control over the distribution of credentials to the wireless devices.
- distribution of credentialsis made via a transmission initiated by Issuer Cardholder System 120 to Wireless Credential Manager 110 which causes the credential or set of credentials to be transmitted to wireless device 200 via the Internet and/or one or more alternative public or private networks. Based upon the specific addressing schemes employed herein, the credential may then ultimately make its way to the targeted wireless device via an over-the-air wireless link.
- wireless device 200is preferably a device that is capable of wirelessly connecting to the Internet using network protocols such as GSM/GPRS, CDMA2000, W-CDMA, EDGE, HDR, 1xRTT, UMTS, IMT-2000, 802.11a, 802.11b, 802.11g, or BLUETOOTH or other relevant protocols developed hereinafter.
- wireless device 200has a display screen and a key pad for alphanumeric and special character data input.
- wireless device 200has processing and secure storage capabilities allowing it to host and operate a wallet application capable of receiving, storing, managing and transmitting multiple payment, identification, and other confidential information electronically.
- Wireless device 200also preferably has an integrated short-range communication capability for transmitting confidential information and exchanging other data between the wallet application and an external reader that is in proximity to the wireless device.
- Wireless device 200further preferably is of a type that has an assigned E.164 phone number, Uniform Resource Identifier (URI), or other type of unique address that can be resolved over the Internet.
- wireless device 200also has a Session Initiation Protocol (SIP) Application Programming Interface (API) framework embedded in or running on top of a resident operating system, which allows for multiple SIP-based applications, such as the wallet application discussed herein, to function.
- SIPSession Initiation Protocol
- APIApplication Programming Interface
- the wallet applicationmay also rely on its own SIP architecture, alleviating the need for a SIP API framework that could be used by multiple SIP applications.
- Wireless Credential Manager (WCM) 110maintains, controls and distributes credentials in accordance with the teachings herein.
- WCM 110is able to interface with a payment, identification, and/or other existing user management or card management systems such as issuer cardholder system 120 .
- An issuer representativemay interface with issuer cardholder system 120 through the use of customer care terminal 150 .
- the process for issuing a credential according to the present inventionmay be initiated manually by an issuer representative via terminal 150 .
- the customer himselfmay initiate the process through interactive voice response (IVR) system 160 by calling in through wireline phone 165 via PSTN network 170 .
- IVRinteractive voice response
- Other alternatives for initiating the processinclude the use of computer via the requesting party's ISP 178 , the Internet 180 and through the issuer's web server 182 to issuer cardholder system 120 .
- Still another alternative for initiating the credential issuing processis through wireless device 200 via mobile operator network 155 , SIP proxy 157 , Internet 180 and issuer's web server 182 .
- the wireless device used to initiate the credential issuance processmay be either the device to receive the credential or another wireless device.
- FIG. 1including a credit card personalization machine, a credit card and an envelope indicates that in connection with the delivery of a wireless device credential according to the teachings of the present invention, it is also possible to deliver a conventional credit card or other physical form of the credential for use by the customer.
- WCM 110provides for the secure Internet delivery of electronic credentials to wireless device 200 which is loaded with a wallet application.
- WCM 110provides a secure and robust means of issuing, canceling, and managing electronic credentials on wireless devices via the Internet.
- WCM 110leverages existing Internet protocols and technologies, making it easy for issuers to integrate with their existing systems, and alleviating the need to establish direct links with multiple mobile operators.
- E.164is the name of the international telephone numbering plan administered by the International Telecommunication Union (ITU), which specifies the format, structure, and administrative hierarchy of telephone numbers. “E.164” refers to the ITU document that describes the structure of telephone numbers. The ITU issues country codes to sovereign countries, but administration of telephone numbers within each country is governed by that country's telecommunications regulatory agency. A fully qualified E.164 number is designated by a country code, an area or city code, and a phone number. For example, a fully qualified, E.164 number for the phone number 555-1234 in Washington, D.C. (area code 202) in the United States (country code 1) would be +1-202-555-1234.
- ITUInternational Telecommunication Union
- an E.164 phone numberis used to target a user's wallet application on Internet-enabled wireless device 200 for the delivery of credentials and confidential data, including but not limited to credit card, debit card, ATM card, loyalty card, driver's license, electronic ticket, coupons and other information.
- an E.164 phone numberis used according to the present invention to target a user's wallet application residing on wireless device 200 for the remote cancellation or updating of credentials.
- E.164 phone numbersmay be used as described herein to make person-to-person, person-to-company, or company-to-company electronic payments or fund transfers using wireless device 200 .
- this inventionis not necessarily limited to the use of E.164 phone numbers. Rather, the use of URIs and other address types that are capable of being translated to an Internet address is also possible for the purposes mentioned above.
- WCM 110 of the present inventionuses the Electronic Numbering (ENUM) protocol to resolve a fully qualified E.164 telephone number for the particular wireless device 200 (with a loaded wallet application) to a fully qualified domain name address corresponding to the same device using a DNS-based architecture.
- ENUME.164 Number Mapping, RFC 3761
- DNSDomain Name Service, RFC 1034
- URIsUniform Resource Identifiers, RFC 2396
- ENUMexists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions.
- E.164is the ITU-T standard international numbering plan, under which all globally reachable telephone numbers are organized.
- ENUMpresupposes the collection of these records into a central or hierarchical service.
- the resolved Internet addressis used to establish secure real-time communication between WCM 110 and the wallet application on wireless device 200 using the Session Initiation Protocol (SIP) (for example, according to the RFC 3261 standard) to transfer encrypted credentials.
- SIPSession Initiation Protocol
- the issuer WCM 110may also be used to update credentials or update the status of credentials on wireless device 200 .
- WCM 110may also be used to authenticate a mobile user's identity in real-time during a transaction. While the use of SIP for such purposes is preferred, alternative application protocols may be used in lieu of SIP while still remaining within the spirit and scope of the present invention.
- SIPSecure IP protocol
- wireless device 200The use of SIP for transmitting and managing credentials on wireless device 200 is preferred as mobile operators and fixed line operators are moving towards a SIP-based architecture for voice and other multimedia services. It is envisioned that the use of SIP for communication between a credential issuer and a wallet application resident on wireless device 200 could leverage the same SIP registrar, proxy, and presence servers used to deliver real-time interactive converged communication services within a mobile operator's network.
- ENUMis used as follows.
- the E.164 numberis first converted into a query in the e164.arpa domain.
- the domain “e164.arpa”is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into sub-domains.
- the resultant set of servicesis specified by the returned collection of NAPTR (Naming Authority Pointer) records.
- the agent(the WCM in this case) selects a service that matches the service characteristics of the original request, and takes the corresponding URI for further resolution by DNS.
- the elements of this URIare further decomposed as per any rewrite rules in the NAPTR record.
- DNS queriesare generated as per the sequence of preferred NAPTR rewrite operations. The ultimate result of this sequence of DNS queries is the specification of a protocol, an associated port address, and the IP address for a preferred server for the service.
- the mobile telephone numberIn order to take advantage of ENUM, the mobile telephone number must first be assigned to a user by a telecom operator for services. The number can then be registered for one or more ENUM services. For example, a subscriber might wish to install a wallet application on wireless device 200 and register the telephone number as the identifier for the wallet application. Multiple issuers can in turn deliver payment methods, identification, or other types of electronic credentials to the wallet application on the wireless device 200 via the Internet using the phone number as the destination address. Additionally, that subscriber might wish to register an e-mail address or fax number to be associated with the same phone number. However the user chooses to set up these services, the information for the registered services, including the wallet application, is saved in NAPTR (Naming Authority Pointer) Resource Records.
- NAPTRNaming Authority Pointer
- electronic credentialsmay be issued to a wallet application on a wireless device 200 held (owned, rented or otherwise controlled) by a user that already has a physical card or token-based credential.
- a userthat already has a physical card or token-based credential.
- an existing bank customer that has a magnetic-stripe credit cardmay also request a digital card for use with the wallet application on his or her wireless device 200 .
- the bank customercould request the new credential over the phone by first validating his or her identity with the issuer, by logging into the issuer's secure web site using a valid username and password, or in person at a branch.
- Credentialsmay alternatively be issued to a wireless device held by a user that is applying for a new credential for the first time. For example, a user may be applying for a credit card for the first time, and may wish to only request the credential on his or her mobile phone.
- credential issuersmay request from applicants (e.g. over the telephone) a properly formatted E.164 phone number in order to target the delivery of credential(s) to a wallet application on wireless device 200 .
- the request for a E.164 wireless device number on an application for a credit card, debit card, ATM card, loyalty card, driver's license, security pass, coupons, certificates, or other credential typeis made by the issuer.
- the E.164 phone numbermay be obtained on paper, via a web-based application, via an electronic kiosk, via telephone or it may be captured through other means.
- the credential issuance processbegins with WCM 110 receiving a request from the issuer's card or user management system 120 to issue electronic credentials to an individual user (see step 310 ).
- the requestis forwarded to WCM 110 along with the user's mobile (E.164) number, the credentials to be issued, encryption keys, and other information contained in the Personalization File for the specific request.
- the Personalization Filemay be a batch file that contains numerous records of credentials that are to be issued to individuals on their wireless device 200 , or could be a separate file record for each credential to be issued.
- the Personalization Fileis transmitted to WCM 110 by issuer personalization server 130 which is in communication with issuer cardholder system 120 . Issuer personalization server communicates with personalization bureau server 140 which is typically maintained by the personalization bureau.
- the Personalization Fileis preferably similar to the Personalization File that credit card issuers send to personalization bureaus responsible for manufacturing, personalizing, and fulfilling magnetic-stripe cards for issuance to customers.
- the Personalization File received by personalization bureaus from credit card companiescontains all the necessary account and consumer data required to emboss a card, encode the magnetic stripe, and fulfill the issued card via mail.
- Other informationis sometimes also included in the Personalization File depending on the additional services performed by the Personalization Bureau.
- the filemay contain data indicating a request of the Personalization Bureau to generate a personal identification number (PIN) which may be mailed to the customer. This information or a subset thereof makes up the personalization file record that is transmitted by issuer cardholder system 120 to WCM 110 in connection with a credential issuance request according to the present invention.
- the issuercan provide the user with a digital credential linked to the same magnetic-stripe account, but that bears a different account number.
- the full account number of the electronic credential issued to wireless device 200may not be visible to the user through the wallet application (discussed later), since the credential may have been issued for “device present” transactions only as may be the case with certain credit cards that are issued. Account numbers and other information could also be partially masked for security reasons with other credential types. In all such cases, the issuer may specify in the security characteristics such as the visibility of account numbers or other information in the Personalization File. For example, the issuer may specify that the wallet application should only make the last four digits of the account number visible to the user on wireless device 200 .
- WCM 110will by default be configured to receive the mobile phone number (in the Personalization File Record) in the format specified in section 2.1 of RFC 3761.
- This formatis herein referred to as the Application Unique String (AUS).
- AUSis a fully qualified E.164 number minus any non-digit characters except for the “+” character which appears at the beginning of the number.
- the “+”is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace.
- the E.164 numbercould be stored in issuer's card management system 120 as “+1-202-555-1234”.
- all non-digits except for “+”are removed in the Personalization File sent to WCM 110 , yielding “+12025551234”.
- WCM 110In order for an issuer to send confidential information to an approved user's wireless device 200 , WCM 110 must first validate that the phone number is a syntactically correct E.164 number and then translate the number into an address that can be used by a DNS resolver (see step 320 ).
- ENUMis only applicable for E.164 numbers. As an ENUM compliant application, WCM 110 will only query DNS for what it believes is an E.164 number. WCM 110 could in turn apply validation routines to ensure that the number received from the issuer's card management system 120 (and indirectly received from the user) is a syntactically correct E.164 number. WCM 110 can perform basic formatting on phone numbers received in the Personalization File. While it is preferred that issuer's card management system 120 populate phone numbers in the Personalization File in the AUS format mentioned above, WCM 110 may also have the ability to make edits in order to ensure proper formatting.
- the WCM validation routinemay further be customized by the issuer to be region specific; for example, an issuer in the United States that only wants to issue electronic credentials to domestic users, may set the validation routine to reject all numbers that do not match the US numbering format of +12025551234. While rules like this are preferably enforced in the card issuer's user management system 120 , they can be also enforced by WCM 110 . WCM 110 is preferably flexible to allow other types of validation routines to be programmed. WCM 110 of course cannot ensure that a particular number is valid until it tries it.
- WCM 110After WCM 110 validates the E.164 number, it must translate the mobile phone number into an address that can be used by a DNS resolver integrated into WCM 110 (see step 330 ). Because this address is based on a complete, international telephone number (for example, +12025551234), a unique Internet address exists for every unique phone number (once the ENUM database is completely populated). To determine if the number and address are registered in ENUM, the telephone number is translated in the following manner by WCM 110 :
- This domain-nameis used to request Naming Authority Pointer (NAPTR) resource records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS.
- WCM 110interacts with the domain name space through its built in resolver.
- the resolvermust have knowledge of at least one name server (likely on the issuer's network).
- the WCM resolvercan be configured with multiple name servers.
- the resolverWhen the resolver processes an ENUM query it asks a known name server for the information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, the resolver learns the identities and contents of other name servers. Resolvers in general are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant databases in other servers. Note that the resolver may have to make several queries to several different external name servers to answer a particular user query, and hence the resolution of a ENUM query may involve several network accesses and an arbitrary amount of time.
- the next step in the overall process of the present invention in a preferred embodimentcalls for the retrieval of a NAPTR record (see step 340 ).
- the domain naming systemuses the ENUM query to retrieve a NAPTR record associated with the E.164 number.
- the DNS response to the ENUM querycontains one or more NAPTR records corresponding to the E.164 number, and each NAPTR record contains one or more service-specific Uniform Resource Identifiers (URIs).
- URIsUniform Resource Identifiers
- WCM 110will look for a NAPTR record associated with the “wallet” service.
- the registered ‘E2U+wallet’ enum servicewill function as a selection mechanism for WCM 110 when choosing one NAPTR resource record from another.
- WCM 110can select the corresponding URI and use the resolver a second time to translate the domain name part of the URI to an IP address using the URI-specific DNS resource record as a query term.
- WCM 110can then use the full URI specification to open a session with the selected service port and complete the service transaction with the wallet application on the user's mobile device.
- the packet format of the NAPTR RRis found in section 4 of RFC 4303. Examples of NAPTR records are shown below:
- the Order field in the NAPTR record for the wallet servicecan be set with the highest value since WCM 110 will be selecting a single record that contains the wallet enum service.
- the high value in the Order fieldwill also reduce the likelihood of other SIP applications cycling through the records and incorrectly trying to communicate with the wallet application.
- the flag “u”denotes a terminal lookup that will result in the production of a URI by the regular expression substitution specified.
- the “E2U+wallet”specifies a service to be contacted by SIP through the use of an E.164 to URI (E2U) translation.
- the substitution “!.*$!sips:bob@wallet.mobileco.com!”is then applied to the original phone number (such as +12025551234) to yield the result sips:bob@wallet.mobileco.com, which is used to resolve SIP addresses.
- the replacement stringis the resultant string (“sips:bob@wallet.mobileco.com”), which is to be used to initiate the SIP communication for issuing the credential to the specified wireless device 200 (see step 350 ).
- the NAPTR formatalso specifies a method for various matches in the regular expression to be substituted into the replacement string. This simple example does not require that although in actual operation, this feature may be used.
- Enumservice registrationsmust be made with the IANA.
- a complete registrationwill include the proposed “enumservice” field, the URI schemes, a functional specification, security considerations, intended usage, and any other information intended to allow for the interoperability within ENUM.
- Service Registration requirementsare outlined in RFC 3761.
- the “enumservice” fieldis used to represent an electronic wallet application or service associated with the E.164 phone number.
- the services field of a NAPTR record(as defined in RFC 3403) contains a string that is composed of two subfields: a ‘protocol’ subfield and a ‘resolution service’ subfield.
- ENUMin particular defines an ‘E2U’ (E.164 to URI) resolution service and a service ‘Type’ that is registered with the IANA.
- the token “sip” that is shown as an example aboveis a Type registered with the IANA.
- the Type “wallet”is shown for illustrative purposes. The Types have no implicit connection with the protocols or URI schemes even though they can bear the same name.
- the ‘E2U’ resolution serviceis used in conjunction with a Type that represents an electronic wallet application or service.
- a Typethat represents an electronic wallet application or service.
- an ‘E2U+wallet’ enumservicethat indicates the presence of an electronic wallet application running on a mobile phone or on other systems connected to the Internet may be used. While the example above uses the theoretical “wallet” Type, the actual label that is registered with the IANA for this purpose could be different.
- the service parameters including guidelines for the Type fieldcan be found in section 2.4.2 of RFC 3761.
- the ‘type’must be unique and comply with other naming requirements outlined in section 3.1.2 of RFC 3761.
- the scheme of the URI that will appear in a NAPTR record using the ‘E2U+wallet’ enumservicemay be either ‘SIP’ or ‘SIPS’. While SIPS offers greater security, there may be reasons for using SIP that are not contemplated herein. Furthermore, the use of application protocols other than SIP and SIPs in conjunction with the ‘E2U+wallet’ enumservice in the NAPTR records is also possible. The ability to support another enumservice in addition to the ‘E2U+wallet’ enumservice in the same NAPTR RR is also possible (reference section 8, RFC 3761).
- ENUMuses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic.
- ENUMis deployed on the global Internet, it is expected to be a popular target for various kinds of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself.
- DNSGlobal System for Mobile Communications
- WCM 110preferably includes mechanisms which ameliorate these threats. For example, some of these threats can be solved by verifying the authenticity of the data via mechanisms such as DNSSEC, which will be supported by WCM 110 . WCM 110 will be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, and unknown RRs.
- SIPSession Initiation Protocol, RFC 3261
- RFC 3261Session Initiation Protocol, RFC 3261
- Common applications for SIPinclude Internet telephony, instant messaging, video, Internet gaming, and other forms of real-time communications.
- SIPis a multi-service protocol capable of initiating sessions involving different forms of real-time communications simultaneously.
- SIPis an application-layer control protocol that can establish, modify, and terminate multimedia sessions such as Internet telephony calls. SIP can also invite participants to already existing sessions such as multicast conferences. SIP transparently supports name mapping and redirection services, which supports personal mobility—users can maintain a single externally visible identifier regardless of their network location.
- SIPsupports five facets of establishing and terminating multimedia communications:
- User LocationDetermination of the end system to be used for communication
- Session Setup“Ringing”, Establishment of session parameters at both called and calling party;
- Session ManagementIncluding transfer and termination of sessions, modifying session parameters, and invoking services.
- SIPwas developed by the IETF as part of the Internet Multimedia Conferencing Architecture, and was designed to dovetail with other Internet protocols such as Transmission Control Protocol (TCP), Transmission Layer Security (TLS), User Datagram Protocol (UDP), Internet Protocol (IP), Domain Name System (DNS), and others. SIP works with both IPv4 and IPv6.
- TCPTransmission Control Protocol
- TLSTransmission Layer Security
- UDPUser Datagram Protocol
- IPInternet Protocol
- DNSDomain Name System
- SIPis based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. SIP uses most of the header fields, encoding rules, and status codes of HTTP. This provides a readable text-based format for displaying information. SIP incorporates the use of Session Description Protocol (SDP), which defines session content using a set of types similar to those used in Multipurpose Internet Mail Extensions (MIME). Technically, SIP will function across both IPv4 and IPv6 networks.
- SDPSession Description Protocol
- MIMEMultipurpose Internet Mail Extensions
- SIPcan provide a set of services that is more diverse, compelling and profitable than any of the contemporary wireless protocols including WAP, SMS and MMS.
- SIPallows the development of services that can blend voice, presence, the Web, instant messaging, unified messaging and many others. Carriers who deploy SIP-based infrastructure will be able to offer more differentiated and profitable services than their counterparts, which will correspondingly allow them to realize higher revenues, higher profits and lower chum.
- the present inventionin a preferred embodiment provides for using some of the SIP-network infrastructure that mobile operators will have in place to deliver credentials from SIP-based Wireless Credential Manager (WCM) 110 at an issuer site to a SIP-based wallet application on a wireless device 200 .
- WCMWireless Credential Manager
- the system disclosed hereinis designed to interoperate with mobile 2.5G, 3G, and Wi-Fi networks among others.
- FIG. 1the components shown in FIG. 1 are merely exemplary of one embodiment of the present invention and the invention is not necessarily limited thereto.
- FIG. 3a discussion of the present invention in the context of SIP and related functionality is now provided. As stated above, although the present invention is disclosed in the context of SIP, other protocols and related components may be used while still remaining within the scope and spirit of the present invention.
- FIG. 3illustrates some of the SIP components, their relationship to one another and the protocols that are employed.
- a user agent acting as a client(in this case the issuer WCM 410 which is in communication with issuer card management system 420 ) uses SIP to set up a session with a user agent that acts as a server (in this case a wallet application operating on user's wireless device 400 ).
- the session initiation dialogueuses SIP and involves one or more proxy servers to forward requests and responses between the two user agents.
- the user agentsalso make use of the SDP, which is used to describe the media session.
- the proxy servers 450may also act as redirect servers as needed. If redirection is done, the proxy server 450 needs to consult the location service database 460 , which may or may not be colocated with the proxy server 450 .
- the Domain Name System (DNS) 470is also an important part of SIP operation. Typically, a user agent client (UAC) makes a request using the domain name of the user agent server (UAS), rather than an IP address. Proxy server 450 thus needs to consult DNS server 470 to find a proxy server 450 for the target domain.
- DNSDomain Name System
- SIPoften runs on top of the User Datagram Protocol (UDP) for performance reasons, and provides its own reliability mechanisms, but may also use TCP. If a secure, encrypted transport mechanism is desired, SIP messages may alternatively be carried over the Transport Layer Security (TLS) protocol.
- UDPUser Datagram Protocol
- TLSTransport Layer Security
- SIPAssociated with SIP is the SDP, defined in RFC 2327.
- SIPis used to invite one or more participants to a session, while the SDP-encoded body of the SIP message contains information about what media encodings (for example, voice, video) the parties can and will use. After this information is exchanged and acknowledged, all participants are aware of the participants' IP addresses, available transmission capacity, and media type. Then, data transmission begins, using an appropriate transport protocol. Typically, the RTP is used. Throughout the session, participants can make changes to session parameters, such as new media types or new parties to the session, using SIP messages.
- SDPSession Description Protocol
- a sessioncan include multiple streams of differing content.
- SDPcurrently defines audio, video, data, control, and application as stream types, similar to the MIME types used for Internet mail.
- AddressesSDP indicates the destination addresses, which may be a multicast address, for a media stream.
- PortsFor each stream, the UDP port numbers for sending and receiving are specified.
- Payload typesFor each media stream type in use (for example, telephony), the payload type indicates the media formats that can be used during the session.
- Start and stop timesThese apply to broadcast sessions, for example, a television or radio program. The start, stop, and repeat times of the session are indicated. Originator: For broadcast sessions, the originator is specified, with contact information. This may be useful if a receiver encounters technical difficulties.
- SDPprovides the capability to describe multimedia content, it lacks the mechanisms by which two parties agree on the parameters to be used.
- RFC 3264remedies this lack by defining a simple offer/answer model, by which two parties exchange SDP messages to reach agreement on the nature of the multimedia content to be transmitted.
- a resource within a SIP configurationis identified by a URI.
- Examples of communications resourcesinclude the following:
- SIP URIshave a format based on e-mail address formats, namely user@domain. There are two common schemes.
- An ordinary SIP URIis of the form: sip:bob@biloxi.com.
- the URImay also include a password, port number, and related parameters. If secure transmission is required, “sip:” is replaced by “sips:”. In the latter case, SIP messages are transported over TLS.
- the first exampleshows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established.
- FIG. 4shows a typical example of a SIP message exchange between a credential issuer (named herein Sample Bank) and a fictitious mobile user named Bob.
- a credential issuernamed herein Sample Bank
- Boba credtitious mobile user
- SIP signaling functionality embedded in the Wireless Credential Manager (WCM) 510is used to issue Bob a Sample Bank MasterCard on his SIP-enabled mobile device 500 via the Internet.
- WCMWireless Credential Manager
- two SIP proxy serversthat act on behalf of Sample Bank and Bob's mobile operator (MobileCo) to facilitate session establishment. This typical arrangement is often referred to as the “SIP trapezoid” as shown by the geometric shape of the dotted lines in FIG. 4 .
- WCM 510may initiate communication with a wallet application on Bob's wireless device 500 through a SIP proxy server on MobileCo's network that also handles voice, instant messaging, and other services.
- WCM 510initiates a “call” to Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI.
- URIsare defined in Section 19.1 of RFC 3261.
- the URI corresponding to Bob's wallet applicationwas obtained from the NAPTR record that resulted from the ENUM query performed by WCM 510 on Bob's mobile phone number. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sips:bob@wallet.mobileco.com, where mobileco.com is the domain of Bob's SIP service provider.
- the Sample Bank WCM 510has a SIP URI of sips:wcm.samplebank.com.
- a call made to a ‘SIPS’ URIguarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee.
- SSLsecure, encrypted transport
- SIPis based on an HTTP-like request/response transaction model.
- Each transactionconsists of a request that invokes a particular method, or function, on the server and at least one response.
- the transactionbegins with WCM 510 sending an INVITE request addressed to Bob's SIPS URI.
- the INVITE requestcontains a number of header fields. Header fields are named attributes that provide additional information about a message.
- the ones present in an INVITEinclude a unique identifier for the call, the destination address, the WCM address, and information about the type of session that WCM 510 wishes to establish with Bob.
- the INVITE(message F1 in FIG. 4 ) might look like this:
- the first line of the text-encoded messagecontains the method name (INVITE).
- the lines that followare a list of header fields. This example contains a minimum required set.
- the header fieldsare briefly described below:
- Viacontains the address (wcm.samplebank.com) at which Sample Bank's Wireless Credential Manager is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction.
- Sample Bankcontains a display name (Sample Bank) and a SIP or SIPS URI (sips:wcm.samplebank.com) that indicate the originator of the request.
- This header fieldalso has a tag parameter containing a random string (1928301774) that was added to the URI by the Sample Bank WCM 510 . It is used for identification purposes.
- Call-IDcontains a globally unique identifier for this call, generated by the combination of a random string and the WCM host name or IP address.
- the combination of the To tag, From tag, and Call-IDcompletely defines a peer-to-peer SIP relationship between the WCM 510 and Bob and is referred to as a dialog.
- CSeq or Command Sequencecontains an integer and a method name.
- the CSeq numberis incremented for each new request within a dialog and is a traditional sequence number.
- Contactcontains a SIP or SIPS URI that represents a direct route to contact the WCM 510 , usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests.
- FQDNfully qualified domain name
- Max-Forwardsserves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.
- Content-Typecontains a description of the message body (not shown).
- Content-Lengthcontains an octet (byte) count of the message body.
- SDPSession Description Protocol
- WCM 510Since WCM 510 does not know the location of Bob or the SIP server in the mobileco.com domain, WCM 510 sends the INVITE to the SIP server that serves Sample Bank's domain, samplebank.com.
- the address of the Sample Bank SIP servercould have been configured in WCM 510 , or it could have been discovered by DHCP, for example.
- the SIP proxy functionalitywas shown as a being a separate server from WCM 510 ; in reality the proxy functionality is a part of WCM 510 .
- the proxy component of WCM 510is an important aspect of this system and the overall methodology.
- the Sample Bank SIP server 520(sip.samplebank.com) is a type of SIP server known as a proxy server.
- a proxy serverreceives SIP requests and forwards them on behalf of the requester.
- the proxy server 520receives the INVITE request and sends a 100 (Trying) response back to Sample Bank WCM 510 .
- the 100 (Trying) responseindicates that the INVITE has been received and that the proxy is working on behalf of WCM 510 to route the INVITE to the destination.
- Responses in SIPuse a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows WCM 510 to correlate this response to the sent INVITE.
- the sip.samplebank.com proxy server 520locates the proxy server “wallet.mobileco.com” 530 quite easily as this implementation assumes that the use of a subdomain such as “wallet” is a standard by which WCM 510 can identify a proxy server within the operator's network. In other instances where a subdomain may not be part of the URI that is retrieved from the NAPTR record, the Sample Bank proxy server 520 can identify a proxy server within the operator's network possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the mobileco.com domain. This is described in RFC 3263. Either way, it obtains the IP address of the wallet.mobileco.com proxy server 530 and forwards, or proxies, the INVITE request there.
- DNSDomain Name Service
- the sip.samplebank.com proxy server 520Before forwarding the request, the sip.samplebank.com proxy server 520 adds an additional Via header field value that contains its own address (the INVITE already contains the WCM address in the first Via).
- the wallet.mobileco.com proxy server 530receives the INVITE and responds with a 100 (Trying) response back to the sip.samplebank.com proxy server 520 to indicate that it has received the INVITE and is processing the request.
- the proxy serverconsults a database, generically called a location service, that contains the current IP address of Bob.
- the wallet.mobileco.com proxy server 530adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP enabled mobile phone 500 with the wallet application.
- the wallet application on Bob's SIP phone 500receives the INVITE.
- the INVITE message received by the wallet applicationprompts the application to alert Bob of the incoming communication from Sample Bank.
- the alert mechanism used by the wallet applicationcould use the wireless device's internal capability such as generating a tone or vibrating.
- the device displaymay give Bob additional details of the incoming communication from Sample Bank so that Bob can decide whether to accept connectivity with Sample Bank's server for the purpose of receiving the Sample Bank MasterCard credential.
- Bob's SIP phone 500indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top.
- the 180 (Ringing) responsecan be returned to the caller without lookups or without state being maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE.
- the 180 (Ringing) responseis routed to the Sample Bank WCM 510 .
- Bobdecides to allow connectivity with the Sample Bank server 510 by pressing a key on his phone (as prompted for by the wallet application). After he presses the appropriate key to accept connectivity with Sample Bank's server 510 , his SIP phone 500 sends a 200 (OK) response to indicate that the call has been answered by the wallet application.
- the 200 (OK)contains a message body with the SDP media description of the type of session that the wallet application running on Bob's SIP phone 500 is willing to establish with the Sample Bank WCM 510 .
- the first line of the responsecontains the response code (200) and the reason phrase (OK).
- the remaining linescontain header fields.
- the Via, To, From, Call-ID, and CSeq header fieldsare copied from the INVITE request. (There are three Via header field values—one added by the Sample Bank WCM 510 , one added by the sip.samplebank.com proxy 520 , and one added by the wallet.mobileco.com proxy 520 ).
- Bob's SIP phone 500has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future requests and responses in this communication.
- the Contact header fieldcontains a URI at which Bob can be directly reached at his SIP phone 500 .
- the Content-Type and Content-Lengthrefer to the message body (not shown) that contains Bob's SDP media information.
- proxy serverscan make flexible “routing decisions” to decide where to send a request.
- the 200 (OK)is routed back through the two proxies and is received by the WCM 510 , which then stops the ringback tone and indicates that the “call” has been answered.
- the WCM 510sends an acknowledgement message, ACK, to the wallet application on Bob's SIP phone 500 to confirm the reception of the final response (200 (OK)).
- the ACKis sent directly from the WCM 510 to the wallet application on Bob's SIP phone 500 , bypassing the two proxies.
- SIPSecure IP
- the media session between the Sample Bank WCM 510 and the wallet application on Bob's SIP enabled mobile phone 500has now begun, and they can send data packets using the format to which they agreed in the exchange of SDP.
- the end-to-end data packetstake a different path from the SIP signaling messages.
- the established sessionmay initially be used to exchange encryption keys and/or other security information. Subsequent to that, the issuer's system will authenticate the mobile user's identity in real-time to ensure that the person on the receiving end is in fact the person that requested the digital credential.
- the authentication processcan be accomplished by the issuer system prompting the user for some cardholder or accountholder authentication information contained within its system, that only the rightful accountholder would have. The user would see such a request for information within the wallet application screen on the device display. This could include a request for such information such as an existing card account number, card expiration date, cardholder name, mother's maiden name, billing address, social security number, account balance, transaction history, driver's license number, or business identification.
- the issuercould also request a special code or PIN that was mailed to the user in advance of the issuance as a means to further validate identity and ensure non-repudiation. Some of the input information individually, or a combination of certain input information could be used as a decryption key for a credential that is transmitted to the wireless device. Subsequent to the issuer's system validating the user's identity in real-time, the WCM 510 will transmit the credential to the wallet application.
- either the WCM 510 or the wallet application on Bob's phone 500may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description.
- This re-INVITEreferences the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session.
- the other partysends a 200 (OK) to accept the change.
- the requestorresponds to the 200 (OK) with an ACK.
- the failure of the re-INVITEdoes not cause the existing call to fail—the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14 of RFC 3261.
- Bob's wallet applicationdisconnects (hangs up) first and generates a BYE message.
- This BYEis routed directly to the WCM 510 , again bypassing the proxies.
- the WCM 510confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction.
- No ACKis sent—an ACK is only sent in response to a response to an INVITE request.
- the reasons for this special handling for INVITErelate to the reliability mechanisms in SIP, the length of time it can take for a “ringing” application to be answered, and forking.
- request handling in SIPis often classified as either INVITE or non-INVITE, referring to all other methods besides INVITE.
- Full details on session terminationare in Section 15 of RFC 3261. While the above example shows the wallet application terminating the session first, during actual implementation, the WCM 510 may terminate the session first.
- proxies in the SIP signaling pathmay be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the sip.samplebank.com proxy server 520 wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob's SIP phone 500 and (due to the Record-Route header field being passed back in the 200 (OK)) the WCM 510 and stored for the duration of the dialog.
- Record-Routea required routing header field known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy.
- the sip.samplebank.com proxy serverwould then receive and proxy the ACK, BYE, and 200 (OK) to the BYE.
- Each proxycan independently decide to receive subsequent messages, and those messages will pass through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features. While it is not preferred to use any mid-session features for the purpose of issuing, canceling, or updating credentials, there could be reasons for using it which are not discussed herein.
- SIPoffers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS URI, sips:bob@wallet.mobileco.com, for example, to an associated IP address of the registering wireless device, 192.0.2.4, for example.
- a proxywill consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing.
- a unique URImay be used to represent a wallet application functioning on a wireless device or server, and it may be mapped it to an IP address in a location service.
- Registrationis one way that the wallet.mobileco.com server can learn Bob's current location.
- the wallet application on Bob's SIP phonesends REGISTER messages to a server in the mobileco.com domain known as a SIP registrar.
- the REGISTER messagesassociate Bob's SIP or SIPS URI (sips:bob@wallet.mobileco.com) with the network address currently assigned to his wireless device (conveyed as a SIP or SIPS URI in the Contact header field).
- SIP or SIPS URIuns:bob@wallet.mobileco.com
- a SIP enabled phonemay register itself and all active SIP applications at once with the registration server.
- a unique URIis associated with the wallet application; during actual implementation, the same URI could be used for multiple applications on the same device.
- the registrarwrites this association, also called a binding, to a database, called the location service, where it can be used by the wallet.mobileco.com proxy.
- a registrar server for a domainis co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical.
- the location serviceis just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations are one way to create this information, but not the only way. Arbitrary mapping functions can be configured at the discretion of the administrator.
- SIP message details for this registration exampleis in Section 24.1 of RFC 3261. Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, are addressed in RFC 3261.
- FIG. 5An illustration of the overall registration process is given in FIG. 5 .
- the registrar 610 and proxy server 630are logical roles that can be played by a single device in a network; for purposes of clarity the two are separated in this illustration.
- UAsmay send requests through a proxy server in order to reach a registrar if the two are separate elements.
- SIPdoes not mandate a particular mechanism for implementing the location service 620 .
- the only requirementis that a registrar for some domain MUST be able to read and write data to the location service 620 , and proxy or a redirect server 630 for that domain MUST be capable of reading that same data.
- Registrar 610MAY be co-located with a particular SIP proxy server 630 for the same domain.
- the SIP-enabled wireless devicemay register itself, thus enabling communication with all SIP-based applications operating on the device.
- REGISTER requests add, remove, and query bindingscan add a new binding between an address-of-record and one or more contact addresses.
- a clientcan also remove previous bindings or query to determine which bindings are currently in place for an address-of-record.
- the SIP compliant wallet application running on the wireless deviceis capable of handling such REGISTER requests. If a SIP-based wallet application has a unique URI associated with it, and the application is subsequently deleted by the user from the device, the application will remove its own binding as discussed above prior to the deletion.
- Presence Statushas been extended to include other context information around the status such as disposition (out-to-lunch, away-from the-computer) and activity status (on the phone, idle, etc.).
- SIP presence and availabilitybuild on the SIP event notification mechanism (RFC 3265) and on the registrar and other servers. Scripts can be set up at the server to route calls based on inspection of the INVITE message.
- a presence serveruses SIP SUBSCRIBE/NOTIFY with a presence event package to gather a User Agent's presence status and send responses to a watcher interested in the presence status of a specific entity.
- the next examplemakes use of the SUBSCRIBE method from RFC 3265 that can be used by a user agent to establish a subscription for the purpose of receiving notifications (via the NOTIFY method) about a particular event.
- the Sample Bank WCMwas informed that Bob's device was off-line.
- the Sample Bank WCMcan then issue a SUBSCRIBE message, indicating that it wants to be informed when Bob is available.
- This requestis forwarded through the two proxies in our example to a Presence Server.
- Presence Serverlogic is co-located with the location service.
- the Presence Serverauthorizes subscription by returning an OK message, which is passed back to the WCM.
- the Presence Serverthen immediately sends a NOTIFY message with Bob's current status of not signed in, which the Sample Bank WCM acknowledges.
- Bob's wireless devicesigns on by sending a REGISTER message to the proxy in its domain.
- the proxyupdates the database in the location service to reflect registration.
- the updateis confirmed to the proxy, which confirms the registration back to Bob's wireless device.
- the Presence Servicecould send a NOTIFY message containing Bob's new status to the Sample Bank WCM.
- the Sample Bank WCMacknowledges receipt of the notification and can in turn re-try to initiate communication with the wireless application on Bob's wireless device.
- the present inventionalso contemplates a SUBSCRIBE functionality that is compliant with RFC 3265 as well as support for the SUBSCRIBE functionality in a Presence Server to NOTIFY the WCM of a change in status of a wireless device with a wallet application.
- the SUBSCRIBE functionalityis an important feature of the invention since wireless devices may not always be connected to a network and be reachable. This feature allows the WCM to be notified when a wallet application on an end-user device can be re-contacted in order to initiate a peer-to-peer connection for transferring confidential information.
- Application Statuscould be used for, among other things, to inform a “caller” that the receiving party does not have an application to support the incoming request or media type.
- This Presence Informationcan be used to “push” an application to the receiving party over-the-air so the “caller” can establish communication with the recipient in the future.
- the mobile operator's Presence Servicecould initiate a request to a separate server that sends a message to the wireless end-user's handset, asking him if he would like to download the wallet application in order to receive credentials from different issuers such as the one that tried to communicate with his wireless device.
- the applicationcan be provisioned on the user's device over-the-air. Once installed, the application can inform the Presence Service of its new status to allow it to inform the Sample Bank WCM that it is ready to communicate.
- the use of an Application Status in conjunction with a Presence Service and an over-the-air software provisioning system for wireless and wireline devicesare important aspects of the present invention.
- the WCM, the wallet application, and other SIP systems described hereinmay also support presence as a capability using various SIP extensions such as the SIP Instant Messaging and Presence Leveraging Extensions (SIMPLE).
- the SIP-based wallet application running on the mobile phoneis pre-configured with the appropriate registrar address.
- the mobile operatorwill have the ability to change the registrar address over-the-air.
- the registrar addressmay be configured in there.
- the major security mechanisms suited for the protection of a SIP sessionare summarized here. Some or all of these security mechanisms can be used to securely deliver or manage credentials on a wireless device. Support for these mechanisms may be accomplished in the WCM or the wallet application or both. Implementations may support other security schemes as well.
- the Digest authentication schemeis based on a simple challenge-response paradigm.
- the digest authentication schemechallenges the remote end using a nonce value.
- SIP digest authenticationis based on the digest authentication defined in RFC 2617.
- a valid responsecontains a checksum (by default, the MD5 checksum) of the user name, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear.
- SIP messagescarry MIME bodies.
- MIMEitself defines mechanisms for the integrity protection and the encryption of the MIME contents.
- SIPmay utilize S/MIME to enable mechanisms like public key distribution, authentication and integrity protection, or confidentiality of SIP signaling data.
- S/MIMEmay be considered as a replacement for PGP used in RFC2543 to provide means for integrity protection and encryption of SIP messages.
- tunneling of SIP messages in MIME bodiesis specified.
- S/MIMErequires certificates and private keys to be used, whereas the certificates may be issued by a trusted third party or may be self-generated. The latter case may not provide real user authentication but may be used to provide a limited form of message integrity protection.
- the current document RFC 3261recommends S/MIME to be used for UAs. Moreover, if S/MIME is used to tunnel messages (described below) it is recommend using a TCP connection because of the larger messages. This is to avoid problems that may arise by the fragmentation of UDP packets.
- S/MIMEis used to tunnel messages (described below) it is recommend using a TCP connection because of the larger messages. This is to avoid problems that may arise by the fragmentation of UDP packets.
- TCP connectiona TCP connection because of the larger messages. This is to avoid problems that may arise by the fragmentation of UDP packets.
- the following servicescan be realized:
- TLSSIPS URI
- RFC3261mandates the use of TLS for proxies, redirect servers, and registrars to protect SIP signaling.
- TLSis able to protect SIP signaling messages against loss of integrity, confidentiality and against replay. It provides integrated key-management with mutual authentication and secure key distribution.
- TLSis applicable hop-by-hop between UAs/proxies or between proxies.
- TLScannot be applied to UDP-based SIP signaling.
- IPsecIP Security
- SIPSession Initiation Protocol
- SIPSession Initiation Protocol
- IPsecmay also be used to provide security for SIP signaling at the network layer. This type of security is most suited to securing SIP hosts in a SIP VPN scenario (SIP user agents/proxies) or between administrative SIP domains. IPsec works for all UDP, TCP and SCTP based SIP signaling. IPsec may be used to provide authentication, integrity and confidentiality for the transmitted data and supports end-to-end as well as hop-by-hop scenarios. At this time there is no default cipher suite for IPsec defined in SIP. Note: RFC 3261 does not describe a framework for the use of IPsec. Especially, no information is given as to how the key management is to be realized, or which IPsec header and mode is to be used.
- proxy servers and registrarswill support TLS, and both mutual and one-way authentication. It is also intended that the WCM and the wallet application will be capable initiating TLS. Proxy servers, redirect servers, and registrars may use a site certificate whose subject corresponds to their canonical hostname. UAs may have certificates of their own for mutual authentication with TLS. All SIP elements that support TLS should have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). Further, all SIP elements that support TLS should support the SIPS URI scheme.
- Proxy servers, redirect servers, registrars, and UAsmay implement IPSec or other lower-layer security protocols.
- IPSecIPSec
- the UACshould initiate a TLS connection over which it will send SIP messages.
- UASsmay receive requests over such TLS connections as well.
- Proxy servers, redirect servers, registrars, and UAsshould implement Digest Authorization, encompassing all of the aspects required in Section 22 of RFC 3261. Proxy servers, redirect servers, and registrars should be configured with at least one Digest realm, and at least one “realm” string supported by a given server should correspond to the server's hostname or domain name.
- the WCM and the wallet applicationshould support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23 of RFC 3261. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it should be capable of reusing these to verify S/MIME certificates, as appropriate. A UA may hold root certificates specifically for validating S/MIME certificates.
- SIPsupports the encryption of both message bodies and message headers.
- the encryption of message bodiesmakes it more difficult for an eavesdropper to listen in.
- an uninvited third partyknowing all the Session Description Protocol (SDP) information could guess the real-time transport protocol synchronization source (RTP SSRC) number and send unwanted media to either party, practicing so called “media spamming.”
- RTP SSRCreal-time transport protocol synchronization source
- Encryption of headerscan hide the parties involved in the session.
- actual session streamcan be encrypted as negotiated by SIP.
- SIP messages between the WCM and the wallet application on the wireless devicecan carry any supported content types in its payload (e.g. WML, HTML, XHTML, gif, text and others).
- SIP payload contentcould include encryption keys, encryption algorithms, forms, user authentication information (e.g. usernames, passwords, PINs, and answers to secret questions), software extensions the issuer wants to register with the wallet application, software updates, electronic credentials, updates to existing credentials, graphics that are part of the credentials, and other such information.
- Java appletscan be transported as SIP payload, and Java applets running in a mobile phone can use SIP based services in communications.
- a simple use casewould be distributing the wallet application, checking availability for operator support (if downloaded elsewhere), setting up the application, and communicating with credential issuers using SIP. The credentials in turn can be transported using SIP.
- WCMWireless Credential Manager
- the Wireless Credential Manager (WCM) 110is a carrier-grade platform for real-time electronic credential issuance, management, and authentication. It is ideal for financial institutions, government agencies, and other organizations who wish to securely deliver electronic credentials to a wireless device with an associated E.164 phone number, URI, or other type of Internet-routable address.
- the application engineprovides access to service logic through a CGI, Servlet, or proprietary interface.
- the service logicis free to access business logic and databases using, for example, Corba, SOAP, JDBC, or Socket.
- the application engineis the core of WCM 110 .
- the application engineis responsible for receiving files and commands from the issuer's user management system, interpreting the information, and acting on it through a variety of functions it has in its library and under its control.
- the application enginecan use the ENUM engine (integrated in the WCM 110 ) to query DNS servers in order to map a E.164 phone number to network addresses.
- An integrated DNS resolvercan be used for ENUM queries and also to resolve SIP URIs to network addresses.
- the application enginecan also function as a user agent client (UAC) and a user agent server (UAS) for SIP communication.
- UACuser agent client
- UASuser agent server
- the UACinitiates requests while the UAS generates responses.
- the application enginewill be capable of operating as both a UAC and a UAS during a session with end-user wallet applications. Further more, the application engine is capable of handling multiple simultaneous sessions with different SIP devices.
- the application engineis capable of maintaining state on calls that it initiates or participates in.
- a minimum call state setincludes the local and remote tags, Call-ID, local and remote CSeq header fields, along with the route set and any state information necessary for the media. This information is used to store the dialog information and for reliability.
- the remote CSeq storageis necessary to distinguish between a re-INVITE and a re-transmission.
- the application engine UApreferably supports UDP, TCP, TLS, and SCTP transport.
- the application engine UAalso preferably supports SDP (IETF 2327) for media description. Other types of media description protocols can be used in the body and interpreted by the application engine, but SDP support is required per RFC 3261.
- the application enginealso interfaces with a SIP proxy that is integrated in WCM 110 .
- the SIP proxymay run on the same physical server or separate servers, for load balancing or other reasons. Details of other key components of the WCM under the control of the application engine are outlined below.
- ENUM engine in WCM 110is a standards compliant resolution tool developed based on RFC 3761.
- ENUM(RFC 3761) is the Internet Engineering Task Force (IETF) standard that defines a mechanism for using the Domain Name Service (DNS) as a tool to “discover” services associated with a telephone number (E.164 number).
- IETFInternet Engineering Task Force
- WCM 110automatically processes NAPTR record(s) in DNS wire format into application service, order, preference, and URI fields. WCM 110 correctly parses the NAPTR service fields and dynamically interprets POSIX Extended Regular Expressions. Additionally, WCM 110 provides the DNS message processing and network transport mechanisms required to translate a telephone number into a set of ENUM records. Support is provided for the following feature set:
- Standard ENUM queryreturns all of the ENUM records associated with a given telephone number.
- the WCM's Application Engineis capable of filtering the results based on application protocol and/or service type.
- Server-side Extensionsreturns subset of the ENUM records associated with a given telephone number based on optional query directives that enable the ENUM service to filter results based on both application protocol and/or service type.
- POSIX Extended Regular Expressionsmatches and substitutes any valid POSIX Extended Regular Expression within the NAPTR record regular expression field.
- Recursionprovides DNS recursion from WCM 110 , eliminating the need for a recursive local DNS server when querying multi-tiered DNS systems.
- Thread Safesupports a multi-threaded environment
- UDP/TCP transportsupports both UDP and TCP connections to allow for efficient retrieval of large sets of DNS records.
- Network Latency Based Server Selectiondetermines the best performing ENUM/DNS server based on query response time.
- Cachingrecords for a period of time specified by the Time-To-Live (TTL) field defined for the resource record.
- TTLTime-To-Live
- WCM 110provides DNS resolution and update capabilities for the following resource records: A, NS, SRV, NAPTR, SOA, PTR, MX, CNAME, TXT, and HINFO.
- resource recordsA, NS, SRV, NAPTR, SOA, PTR, MX, CNAME, TXT, and HINFO.
- the following pseudo resource recordsare also supported: TSIG, OPT, SOA.
- RFC 3761highly recommends the use of DNS security.
- the WCM ENUM infrastructuresupports DNSSEC to address a variety of security issues including impersonation, data tampering and unauthorized access/farming.
- the use of TSIGenables transaction level authentication using shared secrets.
- TSIGis lightweight and may be used for authentication on DNS queries. Support for TSIG functionality is built into WCM 110 .
- TSIG DNS resource recordUse of the TSIG DNS resource record is specified in RFC 2845.
- TSIGwas developed as a lightweight alternative to using public key encryption technology for DNS authentication. The main function of using TSIG is to establish a trust relationship between two entities using a shared secret key.
- the TSIG resource recordis dynamically generated per ENUM transaction and is contained in the additional data section of the DNS message. TSIG records are never cached. All of the DNSSEC functionality required to implement TSIG with any ENUM system is implemented in WCM 110 . The process of utilizing TSIG in an ENUM transaction is though the use of a SIP proxy.
- Integrated into WCM 110is a SIP proxy that interfaces directly with the application engine, which is responsible for setting up or terminating sessions with end-user wallet applications.
- the SIP proxysits in the middle of a SIP message exchange, receiving messages and forwarding them. There may be multiple proxies in a signaling path. The proxy server is not really “in the call.”
- the WCM SIP proxyfacilitates the two end-points locating and contacting each other.
- the SIP proxycan be configured to remain in the signaling path or drop out of the signaling path as soon as communication between two end-points is established.
- the SIP proxyis also able to use the DNS resolver within WCM 110 .
- CPLis a standard scripting language defined by the IETF that described how to process inbound and outbound requests.
- the CPL languageis protocol-neutral and has a language binding for SIP. It is designed to be a simple and safe mechanism suitable for executing user-defined scripts.
- the SIP proxyis usually separated from CPL interpreter and application logic. Since CPL is a standard, any application can generate CPL and a compliant proxy should understand it
- WCM 110preferably provides an easy-to-use GUI to manage server clusters and servlet applications. It supports SNMPv2c for ease of integration with external Operations Support Systems (OSS). WCM 110 provides a comprehensive logging service that enables credential issuers to quickly collect fault and performance data.
- OSSOperations Support Systems
- the WCM logging servicealso permits issuers to create, encode, and export communication records (CDRs) with end-user wallet applications for export into user management systems and visibility by issuer customer care departments.
- WCM 110supports flexible configuration of CDR extensions, file transfer options, and file naming.
- WCM 110preferably supports the secure transfer of individual encryption keys (obtained from end-user wallet applications during communication) to other user management databases or LDAP servers within the issuer environment. These encryption keys can be called upon by WCM 110 for future communication with a particular end-user's wallet application.
- WCM 110supports authentication, authorization, and accounting of SIP sessions in accordance to RFC 3702.
- WCM Service Creation Environment(SCE) is comprised of a software developer kit (SDK) coupled with the standards-based, JSR 116-compliant SIP Servlet API.
- SDKsoftware developer kit
- JSRJSR 116-compliant SIP Servlet API.
- the SIP Servlet APIis the interface between the applications and the SIP container, which supports the SIP server roles needed and interfaces with the SIP stack
- Servlet Mapping Rulesare defined in XML and describe criteria to be met by the SIP message.
- the applicationsinteract with the SIP server functionality via the SIP Servlet API.
- the WCM SDKprovides a preloaded set of SIP application building blocks (ABB) that allow issuers/operators to configure WCM 110 to interact with the wallet application for credential management including: i) issuance, cancellation, status change and update; (ii) real-time user authentication during transaction authorization; and (iii) remote wallet
- ABBapplication building blocks
- the WCM SDKalso includes non-SIP application building block connectors (ABB-Cs) that dramatically reduce the effort and knowledge needed to build SIP-based applications within the WCM 110 .
- ABB-Csnon-SIP application building block connectors
- the WCM 110preferably supports MD5 digest authentication to prevent passwords from being sent across the network in clear text.
- WCM 110supports a number of flexible APIs that allows for WCM 110 to communicate with different issuer systems in real-time or batch mode.
- the APIssupport a number of standard command sets recognized by the application engine. Standard APIs and command sets included with the WCM 110 are for:
- APIs and application logiccan be customized using the WCM service creation environment (SCE) discussed earlier.
- API frameworks supported within the WCMutilize: SOAP/XML, .NET and CORBA.
- WCM 110also supports peer-to-peer data integration interfaces to middleware designed for assured delivery, high-volume and secure data exchange.
- middleware interfaces supportedinclude, for example, Sterling Commerce's Connect:Direct.
- Such an interface to Connect:Directcould be used for receiving the Personalization File from an issuer's card management system and sending systems logs, CDRs, and other confidential information to other issuer systems.
- WCM 110supports message authentication (using the ANSI X9.9 and X9.19 standards for authentication of financial transactions) and Secure Sockets Layer (SSL) encryption
- WCM 110is designed with a customized, load-balanced, distributed architecture without single points of failure. Incoming/Outbound SIP-based service requests are load balanced across service hosts by service directors. WCM 110 operates in clustered configurations using off-the-shelf server platforms based on Intel x86 and SUN SPARC architectures. It supports carrier grade Linux (CGL), Sun Solaris, and Microsoft Windows 2000 Advanced Server Operating systems. WCM 110 can also be run on AlphaServer systems running Tru64 Unix and Himalaya High End series running NSK
- WCM 110is preferably compatible with IPv4 and IPv6 networks.
- WCM 110also supports the following transport protocols: UDP/TCP/TLS/SCTP.
- WCM 110also supports multiple domain names. All aspects of WCM 110 are compliant with IETF RFC 3261, 3GPP, and 3GPP2 standards.
- Embedded in WCM 110is a compliant SIP application stack that the different components of WCM 110 are built upon. Cryptographic functions supported include:
- a SIP-capable firewallis also included. Some issuers may choose to use the built in firewall capability, while others may have a stand-alone SIP-capable firewall they are using. There are several possible approaches to SIP-capable firewalls. One of the difficulties is that, unlike for, say, HTTP, connections are originated both by hosts inside and outside the firewall. A likely arrangement is that the SIP proxy sits “on” the firewall and relays SIP requests between the Internet and the intranet. This proxy would also open up the necessary ports in the firewall to let data to flow through, for example, using Socks V5.
- NATnetwork address translator
- the ENUM Provisioneris an application for mobile operators (or other entities) to update ENUM address information in any compatible DNS server that supports dynamic DNS update.
- the ENUM Provisioner applicationcan be interfaced with a mobile operator's user management system or LDAP server to accept qualified updates to the ENUM database.
- the ENUM Update interfacesupports the following functionality:
- Add Recordsadd 1 or more resource records.
- Delete Recordsdelete 1 or more resource records.
- Thread Safecan be used in a multi-threaded environment.
- the ENUM Provisioner interfaceuses Dynamic DNS (DDNS) protocol [RFC2163] to request updates to an ENUM/DNS service. Update requests typically use TCP connections to communicate with the ENUM service.
- DDNSDynamic DNS
- the ENUM Provisionercan be used to add NAPTR records to the ENUM database for user's that have enrolled in the mobile wallet service and activated their wallet on the phone.
- the Provisionercan also be used to add NAPTR records in the ENUM database corresponding to other services associated with E.164 phone number (e.g. voice, instant messenger, etc).
- the mobile operator's existing user management systemcan enforce rules for validating users, activating services, billing, and other functions.
- Other components of a Mobile Operator's SIP Infrastructuremay also include
- Wallet Software Download or Over-the-Air Provisioning Server(Allows wireless device to download the wallet application OTA
- the wallet applicationis a platform capable of securely holding a myriad of different electronic credentials and making them available in a controlled way through specific functions.
- an icon for the wallet applicationis designed to appear on the main navigation screen. The icon can be used to launch the application.
- Extensionsliterally “extend” the capability of the wallet platform by enabling a new set of features defined by the credential issuer.
- Different credentialsserve many unique purposes and are not all used in the same way.
- the cardIn the case of a magnetic-stripe credit card, the card is swiped in a POS terminal and magnetically encoded information on tracks 1 and 2 are read and captured by the reader. The data in turn is used to authorize the transaction with the card issuer.
- a final exampleis a grocery store loyalty card with a bar coded account number.
- a cashierscans the bar code and the decoded account number is validated against a loyalty database and then used to apply discounts against the patron's purchase.
- extensionsare embodied in mini-programs that operate within the wallet application called “extensions” since they “extend” the capability of the wallet application in order to handle new features and capabilities that are specific to an issuer's credential.
- extensionsallow credentials to be used in a controlled way through specific issuer-defined functions.
- SDKsoftware development kit
- APIcan be made available to credential issuers and other organizations that want to develop extensions for the wallet platform. Extensions can utilize all the features that the wallet platform makes available to it, including such features as access to the device's secure storage, standard display parameters, standard messaging, data format conversions, SIP communication capability, access to device and operating system functions, and other attributes.
- a wireless device loaded with the wallet applicationmay come with some pre-loaded extensions. Extensions may reside on the device memory, in an embedded smart card, in a removable storage media, or on a remote server, securely accessible through the wallet application protocols. An extension may communicate with the user, may exchange information with remote servers or it may use other elements of the device hardware or software.
- Credit card associations/networksmay develop a software extension for the wallet application that governs the interaction between the RFID chip embedded in a wireless device and a reader terminal.
- a modified version of the “MasterCard Proximity Chip Payment—Online Profile” and the “Visa Specification for Financial Messaging for Contactless Payment”could be embodied in a software extension for the wallet application.
- the use of such an extension for facilitating credit card transactions using the wallet applicationis an important part of the present invention.
- the provisioning of such an extension to a wireless device using a valid E.164 number of URIis also possible.
- the same extensionscould be used by multiple issuing banks.
- the actual account information or personal information that is transmitted by the issuer to the wallet applicationis referred to as the “credential”.
- the actual credential record that is transmitted to the wallet application by the issuermay contain some of the following information:
- credentiale.g. United Airlines Mileage Plus Card
- the wallet shellis the core of the wallet platform.
- the wallet applicationhandles processing of incoming credentials and extensions, the execution of extensions within the wallet framework, controlling access to secure storage, enabling communication with an embedded RF interface or smart card, and facilitating the use of operating system and hardware features such as display and sound.
- the wallet shellalso provides extensions with a standard menu-driven user interface from which to operate.
- the wallet shellalso enables secure communication with external servers via SIP and TCP/IP.
- the wallet shellalso has an embedded ENUM resolver for being able to do DNS queries on valid E.164 phone numbers.
- This embedded ENUM clientis useful for facilitating secure person-to-person, person-to-company, or company-to-company transfers of digital money over-the-air using a wallet extension designed for this purpose.
- Such an extensioncould use the ENUM resolver built into the wallet shell to locate the URI for a recipient's electronic wallet to where funds are being transferred.
- the client ENUM resolverwill be designed to submit DNS queries on the mobile operator's network; the IP addresses of the DNS server(s) could be pre-programmed in the wallet shell or could be discovered dynamically.
- a mechanism by which a user could transfer funds to another user by using a valid E.164 number, and establishing a peer-to-peer SIP connectionis available through the present invention.
- Mobile transactionscan be performed in three environments: local, remote, and personal. Each environment has its own mobile commerce services and characteristics that may require specific technologies.
- a wallet application on a wireless device that enables transactions in all three environmentswill provide the greatest utility to users. Electronic credentials issued to a user and stored in the wallet application can be used in all three environments.
- POSpoint-of-sale
- Most day-to-day proximity transactions todayuse a card or token with information encoded in a variety of media types including magnetic stripe, bar code, chip, and embossed or printed data.
- a mobile device with a wallet applicationcan serve as a replacement for single-purpose cards and tokens.
- the wireless devicecan transmit payment, identification, or other confidential information to a reader using the short-range transmission capability of the wireless device (e.g. RF).
- a wireless device loaded with a wallet applicationthat also has an integrated RFID chip can simply be waved slowly in close proximity to a reader device to facilitate a transaction.
- a wireless device that uses infra-red to transact with a readerrequires that the user point the infra-red beam to a reader device.
- mobile transactionsare conducted on the user interface of another device and augmented by security, connectivity, information, and other functionality provided by the user's wireless device.
- a point-of-sale devicemay establish secure connectivity with the user's wireless device and poll it for a list of user-defined payment methods that the user can select from using the user-interface of the POS system.
- the implicationis that the user's wireless device can act as a repository of information that can be securely accessed by another device during a transaction.
- the wallet applicationwill support peer-to-peer connectivity to a device in close proximity.
- Connectivity between the wireless device and the reader/POS terminalcould be made via 802.11a/b/g, Bluetooth, or other RF protocols.
- Connectivitycould initially be established by exchanging encryption keys via RFID that allow the devices to establish connectivity via an alternate channel securely so no other device can listen in to the communication. Keys could also initially be exchanged via infra-red technology.
- One advantage of establishing peer-to-peer connectivity with a POS terminalis that it allows for a bi-directional exchange of data where a user may be prompted on his wireless device for various types of preferences, questions, or other data input in sequence. Transactions where there is a stream of data that goes in both directions can benefit from this type of peer-to-peer session using any number of protocols.
- Another advantage of establishing peer-to-peer connectivity with a POS terminal for exampleis that the user can use the terminal's display and input mechanism instead of on the wireless device to interact with his electronic wallet.
- the larger display and input mechanism of the external devicemay make it easier for the user to make selections.
- credential datais transmitted from the wireless device to a merchant/organization using the short-range communication protocols mentioned.
- the personal environment capability of the wallet applicationcould also be used to issue credentials to the device while the user is present in an issuer's site. For example, if a user is present in a bank branch and is requesting a digital credential for his mobile wallet, the credential could be issued in the manner described above. For example, if a user wants a digital debit card, the user may be prompted by a bank employee to bring his wireless device in proximity of an RFID reader, which will send a command to the wallet application signifying that it is going to receive a new credential via Bluetooth.
- the bank system and the wireless devicemay exchange encryption keys via RF in order to establish a secure Bluetooth connection with the bank network (the process for establishing Bluetooth connectivity is similar to what is outlined later in the Wallet Transfer section).
- a remote transaction using a wireless devicecan be conducted over the Internet with a browser on the wireless device.
- the wireless device's user interfaceis of paramount importance.
- the UImust relay all relevant information to maintain the user's trust and ensure usability of the services.
- Remote transactionsrange from online purchases and banking to more impulsive activities like downloading digital content.
- the main menu of the wallet applicationcontains 6 primary modules in a preferred embodiment:
- a wireless device running a wallet application as described hereinwill serve as a replacement for single-purpose cards and tokens that typically fill people's wallets and purses.
- the wallet applicationis designed to facilitate transactions in a proximity, personal, and remote environment using the device's short-range or long-range transmission capability.
- the wallet applicationis specifically designed to store several types of electronic credentials. Electronic credentials are organized in the wallet application using a hierarchical categorization scheme that makes finding credentials visually easy for the end-user.
- the top level of the hierarchyincludes primary categories.
- the primary categoriesare broad descriptors of the different types of information that the wallet application can store.
- Under the primary categoriesare sub-categories, which provide additional specificity for the types of credentials that can be found there. Sub-categories may not always be present. Credentials can be mapped directly under a primary category or to a sub-category. Sub-categories are particularly useful when a large number of credentials are present under a primary category and need to be organized based on some further classification.
- the wallet applicationhas several primary credential categories that are pre-programmed in the wallet application. These pre-programmed primary headings are listed below with examples of the types of credentials that one might find in each:
- Loyalty CardsGlobally store discount cards, airline frequent flier programs, hotel loyalty programs, and other loyalty programs are included in this category
- Membership CardsPersonal memberships to video rental stores, libraries, and other organizations
- Access CardsElectronic keys for offices, apartments, parking garages, cars, and other secure facilities
- E-Tickets & PassesElectronic tickets for sporting events, concerts, shows, transportation, and other purposes may be issued to the wallet application.
- Coupons & CertificatesElectronic coupons and certificates that can be used at specific locations, that typically have a fixed value, and expiration date for usage
- Identification CardsDriver's license, government identification, school or university ID, and other pieces of identification
- Personal InformationName, billing address, shipping address, home phone number, business phone number, fax number, social security number, and date of birth. Electronic business cards could also be stored.
- Sample sub-categoriesare represented in the example credential tree below.
- the credential treemay be used to visually present information in the wallet application.
- An issuer of credentialsmay specify the primary category and secondary category (if applicable) that a particular credential should be linked to in the wallet application's credential tree; this information can be specified in the credential issuance record that is sent by the issuer to the wallet application on the wireless device. Standardized codes or category names may be used in the credential record that allows the wallet application to link newly received credentials to pre-existing categories contained in the credential tree.
- the wallet applicationwill add the primary and/or secondary category automatically before linking the credential to it.
- Primary categories in the credential treecan be automatically organized in alphabetic order or based on frequency of usage, with the most used primary categories at the top of the list for easy access.
- These organization schemesmay be user defined options in the wallet application, or may be set a certain way by the application itself. The same organization schemes would also apply to secondary categories and the credentials themselves.
- All primary and secondary categoriesshould appear in the credential tree, regardless of whether there are credentials contained within them.
- primary and secondary categories that have credentials contained within themmay be visually distinguished in the device display using any number of methods such as bold text, the use of icons, color coding, or some other visual means.
- Primary and secondary categories that do not have credentialsmay in turn be represented using different distinguishing features such as muted text (lightened), the use of icons, separate color coding, or other visual means.
- the usermay be allowed to create their own credential tree by naming all primary and secondary categories and linking newly received credentials to the categories. Users may have a repository of recommended category names within the wallet application that they can opt to use. Further, under this embodiment, users will also have the ability to rename categories, delete categories, and move credentials from one category to another.
- the credential treeis the primary basis by which credential information is organized in the wallet application.
- the credential treerepresents the entire embodiment of all primary categories, secondary categories, and credentials registered in the wallet application. Certain screens in the wallet application may display the entire credential tree, or only certain components of it as necessary.
- the credential treeprovides a visual hierarchy which is useful for (a) allowing users to make quick selections of specific credentials for use in a transaction (via the “Credential Selector” feature described later), and (b) for managing their credentials and wallet settings in the application.
- a credential-specific “reader key”The key is sent with an electronic credential record to a wireless device during the issuance process.
- the same reader keyis programmed in all reader devices employed by an organization.
- the keyis transmitted from the reader to the wireless device's RFID chip during a proximity transaction.
- the receipt of the key by the RFID chip in the wireless devicemay initiate the automatic launch of the wallet application resident on the device, and the transfer of the key to the application.
- the keyis subsequently received by the wallet application and is used as a search string by the application to locate a specific credential for transmission back to the reader via the device's RF capability.
- the “reader key”is especially useful to organizations that are both issuers of electronic credentials and also acceptors of those credentials.
- An examplewould be a grocery chain that has a WCM for issuing electronic loyalty cards to mobile devices, and is also setup to accept those credentials via RFID readers installed at POS terminals in its stores.
- the grocery chainwould program the reader key into all its RF readers so that the key is transmitted during a proximity transaction to the RFID chip embedded in a wireless device.
- the grocery chainsends the reader key along with the loyalty credential to an end-user's wireless device.
- the wallet applicationstores the “reader key” with the electronic credential to which it is linked. When transmitted to the wireless device from the reader, the key is used by the wallet application as a search string for locating the linked credential. If a matching key is found within the wallet application, the corresponding loyalty information will be transmitted to the reader from the wireless device via RF.
- Employing a reader key in the manner describedallows a reader device to automatically capture specific credential information from a wireless device without the end-user having to scroll through different screens within the wallet application and pressing multiple buttons on his device.
- the sequence of events outlined aboveshould occur in less than a second, in order to minimize the amount of time a user has to hold his wireless device in proximity to the RF reader.
- the key that is injected into the readermay be encrypted prior to injection.
- an encrypted keycould be transmitted from the reader to the wireless device, and decrypted by the wallet application on the wireless device using a decryption key that was previously sent by the credential issuer during issuance or through some other process.
- the reader keycan be any length, be in any format (e.g. plain-text, ASCII, binary, etc.), and employ any type of encryption algorithm.
- the keymay also be included as part of a “handshake” message and/or “challenge” message (associated with challenge/response technology that is frequently used with RFID) transmitted from the reader to the wireless device. They key could also be transmitted before or immediately after a “handshake” and/or “challenge” message.
- readerswill be capable of storing and transmitting multiple “reader keys” that can be used to poll wireless devices for different credentials during a single transaction.
- the wallet applicationin turn will be capable of receiving and processing multiple incoming reader keys.
- communication between the POS reader and the wireless devicemight involve sending two separate keys; one key that requests a loyalty card, and a second key that requests valid coupons or certificates stored on the wireless device.
- multiple keysmay be used to poll for separate credentials in a wallet application.
- the loyalty credential and the couponscan be retrieved automatically (without requiring the user to pre-select these credentials for transmission) since the key for each of these items would be mapped to the credentials in the wallet application. It should be noted that if the wallet application receives two keys from the reader, but only one of the corresponding credentials exists in the wallet, only that credential would be transmitted to the reader.
- the readermay transmit multiple keys as part of the same message to the wireless device, or each key could be sent in separate messages sequentially. The same applies for transmission of multiple credentials from the wireless device to the reader. While a large number of keys could in theory be transmitted from the reader to the wireless device, a very large number of keys will likely increase the amount of time it takes to make the initial transmission, for the wallet application to search for multiple credentials, and for the credentials to be transmitted to the reader. The use of a large number of keys may simply require the user to hold the wireless device in front of the reader for a longer period of time while the processing that was described above takes place.
- An organization that is issuing multiple types of credentialsmay also choose to use the same “reader key” for each credential type it issues.
- an issuercan simply send the same reader key with different credentials it is issuing via the WCM.
- the wallet applicationin turn will map the same key to multiple credential records stored within. If that particular key is received by a wireless device during a transaction, the wallet application will identify all the credentials linked to it, and will proceed to send them all to the reader as separate consecutive records or one message containing all records.
- Reader keysalso need not be organization-specific. The same key could be embedded in readers used by multiple organizations to poll for the specific credentials. In such cases, the “reader key” may be securely shared amongst organizations to facilitate the injection of the key into reader devices.
- a credential being transmitted from the wireless device to the readercould be sent along with the same key that was initially transmitted by the reader to the device; this could be done as a way for the reader and related computer systems (e.g. POS equipment) to identify the type of credential (e.g. loyalty card versus coupons).
- the credentials transmitted from the wireless device to the readermay be encrypted using the issuer's encryption key (that may have been provided during the issuance process or through other means).
- the encrypted credentialscould in turn be decrypted by the reader itself, within a central host system, or by other systems employed by the acceptor of the credentials.
- Certain payment methodssuch as subway stored value cards may be organization specific and be the only payment method accepted; as such, a subway operator may employ reader keys to facilitate a rapid payment system with wireless devices.
- a successful transmission of credentials from the wireless device to a readerwould result in a tone being sounded by the device.
- a separate, but distinguishable tonemay also be used to signal an unsuccessful transmission of credential data from the wireless device to the reader that may require the user to again place the device in front of the reader for a re-transmission attempt of the same credential.
- the wallet applicationwill use the wireless device's integrated hardware and software capability to generate such tones.
- a successful transmission of credentials from the wireless device to a readermay also result in a visual acknowledgement on the device display.
- the wallet application messagewill confirm the successful transfer of specific credentials to a reader device; the actual credentials that were transferred will be listed in the message to inform the user of what confidential information was transmitted.
- the usercan close the acknowledgement message by pressing a wallet application designated button such as “OK”, or doing nothing while the message times-out and is automatically closed.
- a set time-out periodwill be programmed into the application. If the message times-out, the device will return to its normal state.
- Data in the wallet applicationis encrypted and protected with a special wallet PIN code which is set by the wireless device owner during the setup of the application.
- the PINis used to authenticate the user to the application.
- PIN-entryis required to access stored credentials and change any application settings or preferences.
- PINscan be any length, and be comprised of any combination of upper or lower case letters, numbers, and special characters as provided for by the wireless device itself. While this document references the use of PIN codes throughout, wireless device's with embedded biometric technologies could use a fingerprint in lieu of a PIN code to authenticate a user to the wallet application.
- the default security setting in the wallet applicationis that PIN-entry is required before the wallet application can be “opened” and any credentials transmitted to an external device.
- a usercan at their own discretion, choose to designate certain credentials within the wallet application to be used without requiring entry of the wallet application PIN.
- Registered credentials that can be designated by the user as not requiring entry of a wallet PINare those that have a “reader key” associated with them. Credentials with a “reader key” associated with them will be flagged as such in the wallet application to help a user identify them.
- a usermay be willing to assume a slight risk by designating certain credentials for PIN-less use since the benefits of speed and convenience are important to them. Rapid payment at the subway turnstile is an example of where the benefits of speed and convenience may outweigh the risks associated with designating a stored value credential on a wireless device for PIN-less use, leaving open the possibility that a fraudster could steal the device and use the stored value purse.
- Each individualwill have their own risk tolerance and as such will want the flexibility to designate specific credentials in their wallet as requiring advance PIN-entry and others to function without the prior input of the wallet PIN.
- Credentials that are marked by users as not requiring PIN-entrywill be automatically selected within the wallet application based on the “reader key” that is received, and transmitted to the reader during a proximity transaction (the process is described above). Successful transmission of credentials to a reader in a PIN-less mode are confirmed by the device sounding a tone and displaying a message on its display as previously described.
- the PIN-less option for certain credentials that have a “reader key” associated with themallows users to complete time-sensitive transactions by simply passing their wireless device in front of a reader without any further key entry. As such, a simple “wave” of the device in front of a reader can result in a completed transaction in about a second or less.
- reader keysby issuers and acceptors
- the user of the wireless devicewill be required to pre-select all the credentials he wants to transmit to a reader prior to placing his device in proximity of the reader during a transaction.
- a “Credential Selector” in the wallet applicationallows for one credential or multiple credentials to be selected from the credential tree (described earlier) for transmission to a reader device. Users can scroll through the credential tree and select credentials by using the visual navigation system of the wallet application and designated buttons on the wireless device for making selections.
- the credential tree as it appears in the “Credential Selector” screenmay provide visual information about the credentials to aid a user in the selection of specific credentials.
- Individual credential recordsmay display information such as:
- credentiale.g. United Airline Mileage Plus Card
- Name(s) and/or logo(s) of association or network(s)e.g. in the case of bank cards
- Account number(e.g. could be full account number, partially masked account number, or fully masked account number)
- the credential information represented in the “Credential Selector” screenis information that is received from each issuer during the issuance process.
- a standard record layout for credentials issued via the WCMwill allow issuers to customize what information is reflected in the credential tree, and in turn how it is represented in the “credential selector”.
- the wallet applicationAfter confirming a successful transmission involving multiple credentials selected via the Credential Selector tool, the wallet application will ask the user (via a display message) if he wants to create a profile with links to the credentials that were recently used for future use. Creating a profile with the credentials that were used will save the user time during future transactions with the same organization; in the future, the user only has to select the saved profile (in the “Profile Selector”) instead of selecting multiple credentials manually prior to a transaction. Profile names can be customized by the user to help with identification during future transactions. The use of profiles is discussed further in the next section. Under one embodiment, only primary and secondary credential categories that contain credentials will appear in the credential tree that appears in the Credential Selector.
- the wallet applicationalso has a feature whereby a user can create and store different profiles in advance, instead of after a transaction (as described above).
- the Profile Creatorallows a user to link multiple credentials (stored in the wallet application) to a single profile for use at specific organizations that may be frequented. This way a user only needs to select one profile prior to initiating a transaction, and not multiple credentials via the “Credential Selector” tool described earlier. Once a user has selected a profile, the user can place the wireless device in proximity to a reader, and the RF chip in the device will automatically transmit all credentials linked to that profile.
- a profile list within the wallet applicationwill automatically be organized in alphabetic order or based on frequency of usage, with the most used profile at the top of the list for easy access.
- These organization schemesmay be user defined options in the wallet application, or may be set a certain way by the application itself.
- an individual profile for a grocery chainmay contain links to a payment method such as a Visa card, a loyalty card, and electronic coupons.
- the number of credentials that can be linked to a profileis not limited in any way (other than by storage and other hardware constraints imposed by the device).
- the wallet applicationmay enforce certain rules for profiles, such as only allowing one payment method to be linked per profile; other rules could include, only allowing one retailer's coupons/certificates to be linked to a single profile, or not allowing any other primary credential type to be linked to a profile that contains an access card. These are only examples of possible rules that may be enforced by the wallet application.
- One embodiment of this inventioninvolves the incorporation of a single button embedded on the wireless device that can be used to activate the wallet application and to control the transmission of information to an external device via RFID (or some other short-range communication mechanism).
- a credential with a “reader key” and the PIN-option turned offcould be read from a wireless device in someone's pocket by a fraudster carrying a reader that comes in close proximity to the device.
- the existence of a button in an RFID-enabled wireless device that controls activation of the wallet application and transmission of credentials via RFcould eliminate a similar fraud risk.
- the wallet applicationlaunches the wallet application and enables communication via the RFID interface in the device; RF communication might be enabled for a period of 30 seconds during which time the device should be placed in proximity of the reader to allow for transmission of a credential that has a “reader key” and is approved for PIN-less transactions.
- the applicationwill disable RF communication and the application may shutdown or go into its normal dormant state. (The actual time that the RF communication is enabled by pressing the “wallet button” may be shorter or longer than 30 seconds.)
- the “wallet button”may have two functions. In addition to being pressed & released prior to a quick PIN-less transaction as described, the button could also be used as a short-cut for the user to launch the wallet application without using the wireless device's operating system functions used to launch resident applications. To summarize, pressing the “wallet button” and releasing it could enable RF communication for 30 seconds, and also launch the application so the user can interact with it if needed. As such the application is ready to communicate with a reader, and simultaneously prompts the user for his Wallet PIN. If a PIN-less transaction takes place during the 30 second window, the device alerts the user as described earlier through sound/vibration and messaging. Separately, if the user wants to open the wallet application to select credentials or make changes to settings, the user can simply enter his wallet PIN when prompted.
- the wallet buttonmay also need to be pressed/released in order to effectuate a transaction that was initiated through the Credential Selector or Profile Selector options previously described. In these cases, the appropriate credential or profile is selected, but the user is prompted to press and release the “wallet button” in order to enable RF communication on the device.
- the “wallet button”is pressed and released in order to open a 30 second window whereby RF communication is enabled.
- RF communicationmay only be enabled during the period while the button is pressed down; as such, the user would be required to hold the button down while bringing the device in proximity to the reader in order to effectuate the transfer of his credential from the device to the reader via RF.
- FIGS. 6( a ) and 6( b )are graphical representations showing examples of where a “wallet button” might be situated and how it might appear on the device.
- FIG. 6( a )shows the “wallet button” on the front side of the device
- FIG. 6( b )shows the “wallet button” on the side of the wireless device.
- buttonsare labeled as follows:
- a usercould use the “Wallet Settings” functionality in the wallet application to link his favorite/preferred credit card to button 1, and his favorite/preferred debit/ATM card to button 2.
- Button 3, labeled above as “QuickWave”,allows a user to transmit any PIN-less designated credential that has a “reader key” associated with it to a reader during a transaction.
- buttons 1 or 2could in addition to transmitting a payment method, also transfer a PIN-less credential that has a “reader key” associated with it—provided that the reader sent the key in its initial communication with the wireless device.
- buttons 7( a ) and 7( b )are shown in FIGS. 7( a ) and 7( b ).
- Pressing buttons 1 or 2may prompt the user to input a PIN before RF communication can be enabled.
- a usermay be required to input a PIN and click “OK” to enable RF communication for a 30 second window.
- the usermay be required to input his PIN, click “OK” to initiate PIN verification, and upon positive confirmation be prompted to hold down either button 1 or 2 while placing the device in close proximity to a reader.
- the press/release or hold down scenarioswould also apply to button 3.
- the wallet application-specific buttons as described abovecan be any size, shape, or color on the front of the mobile device, on the back of the device, or on any side of the device. (The front of the device is typically the side with the display and keypad.)
- the button or buttonsmay also have iconic or text representations either on them or next to them in order to signal their function. In cases where there are multiple buttons associated with the wallet application, the buttons may appear on the device close together or be in different parts of the device.
- Certain credential issuerssuch as financial institutions may require that users validate their identity during a transaction by providing a PIN that was established with or set by the financial institution.
- PINsare verified either online with a bank host computer system, or verified offline against security data onboard the card as in EMV “chip & PIN” transactions.
- the present inventionsupports both of these PIN-verification schemes.
- an issuermay issue a credential to a wireless device and send a PIN code for that credential to the user via an alternative channel such as e-mail or regular mail in order to ensure non-repudiation.
- the PINmay serve as a decryption key for the credential itself and may also be required for every transaction with that credential. Since the credential is designated as using an offline PIN, the wallet application will prompt the user for an issuer PIN each time the credential is selected for use. The entered PIN would in turn be verified against security information that was transmitted during the credential issuance process.
- the wallet applicationwill only prompt for the issuer PIN when that credential is linked to a “hot button” (as described earlier).
- the “hot button” functionalitycan alleviate the need to enter both a “wallet PIN” and an “issuer PIN”, as the issuer PIN is sufficient to validate the user's identity.
- a financial institutionmay have specified via settings in the credential issuance record that a temporary PIN assigned by the financial institution be changed to a user designated PIN when it is first received. PIN changes for credentials that have issuer PINs will be handled securely through the wallet application.
- Other financial institutionsmay send a PIN to the user via an alternative channel in order to allow the user to decrypt and “activate” the credential, but may not require the PIN for use with every transaction; these financial institutions may specify in the credential issuance settings that the wallet PIN must always be prompted for.
- credential issuersmay issue a credential to a wireless device, require the wallet PIN with every transaction, but also prompt the user for an issuer PIN (or PIN set with the issuer) on the POS terminal during each transaction.
- the POS terminalmay know to prompt for a PIN based on a card BIN number for example.
- issuersmay not require the wallet PIN to be prompted for, since the user will be prompted to enter an issuer PIN on the POS terminal that will be authorized on-line.
- the userwill not be prompted for a PIN on the device, but will be prompted for an issuer PIN on the POS terminal.
- Another type of PIN verification scheme for credentials stored in the wallet applicationis unique to the system of the present invention.
- This on-line verification techniqueutilizes the over-the-air (OTA) PIN handling and processing capability of the wallet application and the WCM (at the issuer location).
- OTA PIN verification schemeis useful for credentials that are authorized online, and require a PIN in order to validate the user's identity.
- FIG. 8A discussion of this unique aspect of the present invention now follows in connection with FIG. 8 .
- the unique aspect of this inventionis that the credential information that is transmitted from the wireless device to an RF reader 820 reaches the issuer for an online authorization via one network path (comprised of one or more networks), while the PIN request and response traverse a completely different network path (comprised of one or more networks).
- the separation of credential data from the actual PIN data over separate networksprovides a more secure way to authorize transactions.
- a first transmission path of an electronic credit card authorization request 870includes, for example, a merchant store controller and merchant host system, an acquirer/processor network, a private network such as VisaNet, and a issuer gateway.
- point of sale terminal 860via RF reader 820 can be used to capture and transmit an electronic credential from a wireless device for online authorization.
- the second transmission path as shown in FIG. 8is via WCM 810 using the Internet and wireless link 880 and issuer DNS server 890 and is used to deliver a PIN request to wireless device 800 and to receive a user-input response from wireless device 800 .
- WCM 810can be used to handle over-the-air PIN verification for electronic credentials issued using WCM 810 and also physical card/token based credentials such as magnetic-stripe cards that require enhanced PIN protection using this method. Either way, the issuer must generally make some modifications to its existing card management system. Specifically, accounts in the card management system 830 that have OTA PIN verification turned on, are flagged as such. The issuer's card management system 830 is preferably modified to allow incoming authorization requests associated with a flagged account to undergo additional processing after the underlying account status and other information (e.g. credit limits, velocity rules, etc) have been checked. These checks are performed in connection with various processes 850 running in connection with the issuer cardholder system.
- account status and other informatione.g. credit limits, velocity rules, etc
- Authorization requests associated with accounts that are in good status and are qualified for an “approval” based on issuer defined criteria,will be held until a PIN request is sent to wireless device 800 and the entered PIN is validated by the issuer's host.
- a PIN requestis generated by the system and sent to WCM 810 via a real-time interface along with information relating to the transaction and certain account information. (If the account is not in good status or does not qualify for an “approval”, a denial message would be sent through the network(s) to the origination point.)
- the PIN request message sent to WCM 810should include fields such as the name of the organization that originated the authorization request, location ID from where the request originated (e.g.
- WCM 810receives the PIN request message containing the above information.
- WCM 810uses the E.164 number to perform an ENUM query.
- WCM 810then retrieves and parses NAPTR records received from the query as previously described herein.
- the NAPTR record associated with a wallet application or serviceis selected and used to initiate peer-to-peer SIP communication between WCM 810 and the wallet application on wireless device 800 via the Internet and mobile operator's wireless network 880 .
- the incoming messagemay automatically launch the wallet application or under another embodiment, it may always be running on the device.
- WCM 810After exchanging session information, encryption keys, and other pre-requisite messaging required to establish secure, real-time connectivity—WCM 810 will send a standard formatted PIN request to the wallet application that contains information such as the name of the organization that originated the authorization request, location ID from where the request originated (e.g. a store address), date/time of authorization request, transaction amount being authorized (or purpose of transaction if a non-financial transaction), transaction ID, last four digits of account number, credential type (e.g. Visa Credit Card), and issuer name.
- credential typee.g. Visa Credit Card
- the wallet applicationreceives the properly formatted PIN request, and launches a PIN verification screen that displays the information received in the request.
- the useris prompted on screen to enter his PIN in order to authorize the transaction described.
- the usercan input his PIN as requested using the key input capability of the wireless device 800 .
- WCM 810transmits the received information in real-time with the transaction ID to the issuer's card management system 830 for verification (the transaction ID is sent as a way to match the response with the original authorization request that is pending in the card management system 830 ).
- the card management system 830validates the PIN or PIN offset and if it matches the information in the account record, a positive authorization response (approval message) is sent back to the point-of-sale through the same path the authorization request was received 870 .
- the card management system 830may also send an approval confirmation back to WCM 810 using the transaction ID as the only identifier.
- WCM 810which is still maintaining its peer-to-peer session with the wallet application will send the approval to the device 800 , which will result in an approval message and/or tone being generated by the wallet application on the device 800 (see FIG. 9 ).
- the wallet applicationcan terminate the SIP session (under another embodiment, the WCS could instead terminate the SIP session).
- the issuer's card management system 830In the event that the user initially entered and submitted the wrong PIN, the issuer's card management system 830 would in turn have sent back an “invalid PIN” message to WCM 810 in order to notify the wallet application on wireless device 800 and request a second PIN entry by the user. The number of allowed PIN attempts would be controlled by the issuer card management system 830 . PINs submitted for online verification as described above, are not retained or stored in the memory of wireless device 800 . Credential issuers may allow PINs to be comprised of any combination of upper or lower case letters, numbers, or special characters.
- a credential issued to the wireless device 800could be labeled by an issuer as using over-the-air, real-time PIN verification so the wallet application is aware of this information. Such a code would allow the wallet application to recognize that such credentials do not require a wallet PIN to be input by the user when linked to a “hot button” and accessed from there.
- PINscan be entered directly into the user's wireless device 800 , alleviating the need for an external terminal that has a PIN-pad.
- online PIN verificationalso gives certain credential issuers a stronger means by which to validate a person's identity during a transaction. For example, card-based credentials that are validated today based on a signature match with the signature on the back of the card are open to fraud. PINs offer a better identity validation alternative to signatures, and are in many international jurisdictions considered to be legal electronic signatures.
- biometricscould also be used in lieu of PINs, while still falling within the scope of the present invention.
- a usermay be prompted to scan his fingerprint using an integrated scanner in the wireless device 800 instead of inputting a PIN as described earlier.
- over-the-air PIN verificationis with credit cards. Credit card transactions in North America and many other parts of the world require nothing more than the signature of the card account holder to complete a “card present” transaction. Implementing online PIN verification for credit cards at the POS would be a daunting task today, as it would involve the reprogramming or retrofitting of millions of terminals with PIN pads, costly software development to retailer transaction processing systems, and changes to the way credit card transactions are processed by card acquirers/networks/associations/issuing banks.
- the over-the-air PIN verification systemoffers an alternative to the costly retrofitting and reprogramming that would be required to implement PIN verification at the POS, similar to the way online debit cards work today.
- the over-the-air PIN verification systemcould be implemented with only the issuer having to make changes to its own systems.
- Sample Bankdeploys a WCM on its network and interfaces it to its credit card management system.
- Sample Bankcould begin offering an innovative credit card product that provides consumers with enhanced protection against fraudulent credit card transactions.
- the MasterCard credit card product offered by Sample Bankcould provide online PIN validation via a registered wireless device on every transaction.
- Sample Bankcould offer the over-the-air PIN verification feature for electronic cards issued to wireless devices, and also for traditional magnetic-stripe cards that typically require a signature. In both cases, the retailer POS would process the credit card transaction as it normally would.
- the differenceis that changes within Sample Bank's card management system will allow the incoming authorization request to perform a PIN validation through the WCM before it sends an approval/denial back through the card network. Credit card issuers like Sample Bank could decide to allow users to opt-in to this feature or the feature can be standard with specific card products.
- a wireless userhas an electronic Sample Bank MasterCard credit card stored in the wallet application that is setup for OTA PIN validation.
- the userselects the electronic card for use in a proximity transaction at a grocery store, and the credential information is transmitted to a reader via RF as described earlier.
- the POS at the grocery storewill switch the transaction to its central host, which in turn will recognize that this is a MasterCard credit card and switch it to the MasterCard network (either directly or through an acquirer/processor depending on configuration).
- MasterCardin turn switches the authorization request to Sample Bank which is the card issuer.
- Sample Bank's gatewayreceives the authorization request, and passes the transaction to its card management system for approval.
- the card management systemchecks the account status using the normal validation process it follows for credit card authorizations.
- Sample Bankhas implemented a new credit card product with OTA PIN verification.
- a flag in the credit card customer account recordsignals to the credit card management system that an authorization approval can not be sent back to the retailer POS until an Over-the-Air PIN verification is completed.
- the card management systemlooks up the card member's registered E.164 phone number for his mobile device.
- the card management systemsubmits a real-time OTA PIN validation request to the WCM to which it is interfaced.
- the requestcontains information such as the name of the grocery store that originated the authorization request, location ID from where the request originated (e.g. a store address), date/time of authorization request, transaction amount being authorized, transaction ID, last four digits of account number, credential type (e.g. MasterCard Credit Card), and issuer name/logo (e.g. Sample Bank MasterCard).
- the WCMinitiates an ENUM query on the E.164 phone number, retrieves and parses the appropriate NAPTR record, and attempts to establish a peer-to-peer session with the wallet application on the wireless device using the URI.
- the wallet application on the wireless devicereceives the PIN Approval Request and uses the device's internal capability to generate a tone which signals to the user that he should look at the device display.
- the wallet applicationdisplays the PIN Approval Request received from Sample Bank, and prompts the user to enter his PIN in order to approve the transaction.
- FIG. 9is a sample of what a PIN Approval Request that is displayed in the wallet application might look like.
- the encrypted PIN or some transformed PIN information(derived from the PIN) is transmitted to the WCM, which forwards it to Sample Bank's card management system for validation. If the PIN is valid, the card management system sends an authorization response back to the retailer POS using established processes. The card management system may in turn send an approval message to the WCM for transmission to the user's wallet application (the peer-to-peer session with the user may still be opened for this to take place). Once the user receives the approval message on his wireless device, the WCM may terminate the SIP session.
- OTA PIN validationrequires that the wireless device and the wallet application running on it to be in good working order. It also requires that the wireless device have signal coverage to be able to send and receive information via the Internet. In the event that the WCM can not reach the wallet application on the wireless device, and establish communication for PIN validation, the WCM will send a “not available” code back to the issuer card management system in order for it to send a “decline” response back to the retailer's POS system (there are a number of different decline codes an issuer could use here that are standardized by the card associations and payment networks).
- the dual network processing path utilized for transactions involving OTA PIN verification as described abovecould be used to prompt a user for certain preference information on his wireless device 800 during a transaction.
- Sample Bankmay create an innovative payment product (herein called the “Wallet Account”) that links together multiple payment accounts such as a credit account, a debit account, and a stored value account under a single account number.
- the Wallet Account numbercould utilize a Visa, MasterCard, American Express, Discover, Diners, or other network/association Bank Identification Number (BIN) range that allows Wallet Account transactions to be authorized by a retailer's POS systems the way credit/debit card transactions are 870 .
- BINBank Identification Number
- Sample Bank's Card Management System 830When a Wallet Account transaction reaches Sample Bank's Card Management System 830 for authorization, Sample Bank's system 830 will discern that the account number corresponds to a valid Wallet Account which has a credit, debit, and stored value account linked. Using the user's E.164 number stored in Sample Bank's Card Management System 830 , the Card Management System will send a message to the user's wireless device 800 to request a PIN (as described earlier) and to ask the user to specify his choice of using one of the linked credit, debit, or stored value accounts for completing the transaction. This request for payment preference traverses the same network path as the OTA PIN verification request described earlier, and traverses the Internet and mobile operator network 880 .
- Sample Bank's Card Management System 830can authorize and apply the transaction to the appropriate account.
- This exampleillustrates that requests for user preferences or other information during a transaction can traverse a completely different network path (comprised of one or more networks) than the original online authorization via one network path (comprised of one or more networks). Also illustrated is the fact that OTA PIN requests can be coupled with requests for user preferences or other information.
- the wallet applicationis also equipped to be used for remote transactions with servers connected to the Internet. It is envisioned that payment credentials sent by issuers to the wallet application will have data stored in ECML format to facilitate Internet payments via the wallet application. While the same data may be transmitted via RFID in one format, Internet payments may be made in ECML format.
- ECMLElectronic Commerce Modeling Language. It is a specification, developed and maintained by the Internet Engineering Task Force (IETF), that provides a standard set of hierarchically organized, payment-related information fields in an XML syntax that will enable automated software, such as the mobile wallet discussed herein, to supply and query for needed data in a uniform manner.
- IETFInternet Engineering Task Force
- ECMLElectronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction. With ECML, this task can be more easily automated.
- the wallet application, employing ECMLcan assist in conducting online transactions by storing billing, shipping, payment, preference, and similar information, and by using this information to automatically complete the data sets required by interactions.
- ECMLis an existing Internet standard, already commonly used in online shopping. Thus, Internet merchants can easily adapt their e-business to the mobile context.
- ECMLis a structure, not a protocol. It is security-mechanism independent and can be integrated to other transaction protocols and security elements when available.
- the wallet applicationmay be used for remote payments as follows. First the consumer browses a merchant's online service on the wireless device and selects the items to buy. To pay for the purchases, he selects “wallet payment” and receives a payment request, i.e., a payment data form that must be filled in. When the cursor is in an empty field of the payment request, the consumer can simply press the “wallet button” on the device to launch the wallet application, or the user can launch the application through the operating system. When launched, the user will be prompted to enter his wallet PIN code. The user can then choose the “credential selector” option from the wallet menu.
- the wallet applicationwill detect the ECML fields in the open browser and will automatically populate the fields with data from the wallet application. The user is directed back to the browser and can check the information that has been entered into the form before accepting the order.
- the wallet applicationmay require the user to provide a credential specific PIN to complete the transaction.
- the usermay be prompted for a PIN during the authorization process with his issuing bank (see OTA PIN verification process above).
- a merchantmay require the consumer to digitally sign the payment; after accepting the order, the consumer may receive a signing request and can sign the payment with his/her personal digital signature PIN. This last option requires a security module (SIM/WIM) in the terminal. The merchant may then send the consumer an acknowledgement and a digital receipt of the successful payment via methods that will be described later.
- SIM/WIMsecurity module
- the wallet applicationcan also be used to complete web-based transactions made through a personal computer.
- the data stored inside the wireless deviceis encrypted and protected with the wallet PIN code (or other biometric security information), which is used to allow the user access to the application.
- Security for remote transactionsis provided by the browser on the wireless device itself.
- a number of server authentication and data encryption protocolsmay be employed to secure credentials and other confidential information such as Wireless Transport Layer Security (WTLS), Transport Layer Security (TLS), and Secure Socket Layer (SSL).
- WTLSWireless Transport Layer Security
- TLSTransport Layer Security
- SSLSecure Socket Layer
- WIMWireless Identity Module
- server authentication and digital signaturesmobile transactions are even more secure than transactions on the fixed-line Internet.
- the wallet applicationis capable of receiving digital receipts from merchants.
- Digital receiptsare electronic equivalents of paper receipts. They work as the payer's record of a payment transaction that has taken place during a proximity, personal, or remote transaction using the wallet application. Similar to a paper receipt, they contain information such as the transaction amount, date/time of the transaction, merchant name, payment method used, and sometimes details of what was purchased.
- the receipt functionalitymakes it possible to have a record of the payment before a physical receipt can be delivered, or in cases where a physical receipt is not used at all.
- the receipt support in the wallet applicationwill follow the MeT receipts specification.
- the MeT specificationis a mobile optimized strict subset of the Association for Retail Technology Standards (ARTS).
- the MeT receipts specificationcan be found at: http://www.mobiletransaction.org/
- the wallet receipt functionalitymakes it possible for the merchant in a mobile electronic transaction to send a receipt to the wallet application via a number of methods.
- the wallet applicationsupports receipts by listing “application/vnd.met.receipt” as a supported MIME type.
- the MIME typeis used both in identifying an incoming receipt data object and in publicizing the support for receipt data type in certain message headers (e.g. HTTP, SIP, SMTP, etc).
- the received receiptsare stored, if the user selects to store them, in the wallet application.
- the wallet applicationprotects the user's privacy by requiring a PIN code to be entered before the receipts can be accessed through the wallet application's main menu.
- the Receipt menu optionprovides a central point for the user to access the receipt data.
- Receipts from a merchantcan be sent to the user's wallet application on the wireless device via several methods as discussed herein.
- the user's E.164 phone number for the wireless deviceis transmitted to the merchant with the credential information during an RF transaction.
- the wallet applicationwould have the ability to learn the E.164 phone number of the device on which it operates through the device's operating system, or directly from the SIM card which may contain certain device settings and attributes like the E.164 number.
- a phone number fieldwould be specified in the credential transmission record that is transmitted from the wireless device to the POS reader (or to a server in the case of a remote transaction).
- the merchant's systemreceives the E.164 phone number of the device that initiated the transaction.
- the merchantcould use the number in conjunction with a WCM deployed at the merchant's site to issue digital receipts to the wallet application.
- the merchantwould have a WCM setup to interface with its central transaction processing system.
- the retailer's transaction processing systemwould temporarily hold the E.164 number received with the credential during an authorization request that originated at the POS.
- the retailer transaction processing systemwould switch the transaction out to MasterCard (directly or through a merchant acquirer) and onto the issuing bank for approval. Assuming an approval comes back from the issuing bank to the retailer transaction processing system, the retailer transaction processing system can issue a receipt request for the transaction to the WCM to which it is interfaced.
- the receipt request sent to the WCM from the transaction processing systemmight be sent concurrent to an approval message being sent from the transaction processing system to the POS.
- the receipt request that the transaction processing system sends to the WCMwould include the E.164 number that was temporarily retained, along with specific information about the transaction that would appear on the digital receipt in the display of the wireless device running the wallet application. Once the transaction processing system sends the receipt request to the WCM, the E.164 number that was retained, is purged.
- the WCMwill use the E.164 number contained in the receipt request to perform an ENUM query, retrieve the NAPTR record for the user's wallet application/service, and use the appropriate URI to establish peer-to-peer SIP connectivity with the wireless device to deliver the receipt.
- the use of the “application/vnd.met.receipt” MIME type in the messagewould allow the SIP stack on the wireless device to know that the message relates to the wallet application.
- the wallet applicationin turn will recognize the MIME type and know that the message is a digital receipt.
- the wallet applicationwill alert the user to the arrival of the message containing the digital receipt by displaying a message on the device display and possibly sounding a tone (or some other sound) using the device's internal functions.
- the wallet applicationwill register the digital receipt with the Digital Receipts folder.
- the actual receipt recordwill be stored in the secure storage memory in the device and can be accessed via the Digital Receipts viewer in the wallet application.
- the reason for using peer-to-peer SIP delivery for transmitting receipts to the wallet applicationis for the merchant to be able to guarantee and confirm delivery of the receipt. Merchants may be required to ensure that consumers receive a digital receipt in order to comply with laws, payment association regulations, or other types of mandated rules. SIP provides a means by which to ensure that a message was received by the wallet application. Further, the use of a SIP peer-to-peer session provides a higher degree of privacy and security than other messaging protocols that could be used instead.
- the WCMUpon successful delivery of a digital receipt to the wallet application, the WCM is notified by the wallet application during the peer-to-peer session that it has received a properly formatted receipt.
- the WCMcan log all receipts and delivery confirmations to a separate server for archiving.
- the archived datamay be used by the retailer to satisfy audit requirements related to its compliance with any laws or rules around receipts.
- the WCMcan use the SUBSCRIBE feature of the SIP protocol to be notified when the wireless device is available for communication.
- the WCMcan attempt to deliver the message when it receives notification that the end-user device is available again.
- E.164 phone number fieldthere is a standard E.164 phone number field in the transmission record layout.
- An alternate approachwould be to embed the phone number within certain fields part of the credential itself.
- certain implementations of contactless credit cards todaye.g. MasterCard PayPass
- the track 1 and track 2 data captured from the chipis analogous to data encoded on magnetic-stripe credit cards.
- What is being proposed hereis the incorporation of a E.164 number into one of the track 1 or 2 fields.
- the retailer systemwould need to know the location of the E.164 number within the data format in order to be able to extract it for use by its own systems and the WCM.
- An alternative approach to delivering receiptswould be for the retailer to send them using their standard SMTP server.
- the WCM or another systemcould be used to do an ENUM query on the E.164 number, receive the appropriate NAPTR record, and use the wallet application/service URI (in an e-mail format such as bob@wallet.mobileco.com) to send an SMTP message to the wallet application which would be configured to receive SMTP messages.
- the wallet applicationwould allow for incoming SMTP messages, and would recognize the “application/vnd.met.receipt” MIME type in the message as being a digital receipt. The body of the message would be encoded with the contents of the receipt.
- the SMTP messagewould comply with the MeT Receipt XML Schema.
- the wallet application under this embodimentwould also comply with the MeT Receipt specifications.
- the receiptcould be sent as part of the same peer-to-peer session that was used to initiate and complete the transaction.
- Electronic receiptscould also be sent to wireless devices by the credential issuer instead of the merchant as described as above.
- the wallet applicationwill not function for a period of 10 minutes. If the user forgets his PIN, the wallet can be reset by the user with a general reset code, which will be available in the wallet application user guide or from the mobile operator. The wallet reset function will result in the user losing all credential information, confidential information, and user preferences stored in the wallet application's secure storage area. The user would in turn have to go through a re-issuance process with each credential issuer in order to restore the lost credentials.
- the wallet applicationwill require the user to establish a secret question and answer before the application is used for the first time. This will allow the user to reset his wallet PIN, by being given the secret question, and being prompted for the answer to the secret question. Upon successfully answering the secret question, the user will be given the chance to select a new PIN to replace the one that was forgotten.
- the walletis permanently locked, but the information within the wallet is retained.
- the useris presented with two options after the ninth failed PIN attempt. The first option allows the user to completely wipe out the contents of the wallet and select a new PIN code. Under the second option, the user is given the ability to go through an online authentication process with each issuer in order to validate his identity and account information. Once the user has successfully re-validated his identity with each issuer, the wallet application will prompt the user for a new wallet PIN.
- the wallet applicationopens up a SIP connection to the issuer's WCM and sends a standard handshake/key exchange message in order to establish secure communication (An Internet address for each issuer's WCM and encryption key may be registered in the wallet application as part of each credential record).
- the wallet applicationsends a message alerting the issuer's WCM that the user needs to re-authenticate his identity due to a PIN lockout.
- the WCMcontacts the appropriate issuer system with the information, and the issuer system responds back with a message that requires the user to re-assert his identity by providing some information that only he would know.
- This requestis relayed by the WCM to the wallet application, and may include a request for such information as the user's account number with the issuer, his social security number, date of birth, mother's maiden name, driver's license number, or a variety of other information.
- the userenters the information into the form, and the information is relayed by the wallet application to the issuer's system through the WCM.
- the issuersends a code to wallet application to confirm that the user has re-asserted his identity and that it is ok to re-activate the credential on the device.
- the wallet applicationin turn terminates the session with the issuer's WCM.
- the wallet applicationcontacts the next issuer whose credential is stored in the user's wallet. The same process is repeated to re-assert the user's identity.
- the information that is requested by one issuer to re-assert an identitywill likely be different than others as each issuer has different security measures in place, and different methods by which to validate a person's identity.
- the wallet applicationwill prompt him for a new PIN code.
- the walletwill prompt for dual entry to ensure proper input.
- the userwill see all the credentials for which he re-asserted his identity online directly with each issuer. Any credentials where the user was not able to re-assert his identity with the issuer will be deleted from the wallet storage.
- certain wallet settingswill also be unlocked and restored to their former position.
- the wallet applicationmay have a feature whereby it automatically polls a server managed by a mobile operator, software developer, or other party for upgrades to the wallet application.
- the applicationmay need to be upgraded from time-to-time to support new features or implement new security measures.
- the wallet applicationwill in turn poll a server connected to the Internet at an interval that may be pre-defined in the application. If the software finds an upgrade, the wallet application will notify the user, and ask the user if he wants to complete the upgrade. If the user says “OK”, the application will proceed to download the software and initiate the upgrade on the wireless device. All credentials, confidential information, and settings will be saved and be available in the upgraded version.
- the upgrade processmay use digital certificates to authenticate servers from where software is being downloaded, and also to verify the authenticity of the software itself.
- Credential issuerswill have the ability to remotely cancel credentials, re-issue credentials, or manage credentials in other ways on a wireless device.
- credential issuerswill send a unique “credential issuer key” along with the credential they are issuing to the wallet application. This key is unique to every credential that the issuer sends out.
- the keyis stored in the wallet application's secure storage area with the credential itself. The key must be contained in the first message of any communication with the wallet application. In another embodiment, the key is contained in every message from the issuer to the wallet application. The presence of the credential issuer key in the initial message sent from the issuer to the wallet application allows the wallet application to recognize that the message is authentic and from one particular issuer.
- the credential issuercan use the key to connect to a wallet application and make certain changes to the credential it previously issued.
- the “credential issuer key”only gives the issuer access to managing the credential that it issued and no other organization's credential and no other settings on the wireless device. Any initial message from an issuer that does not contain a credential issuer key that matches a key stored in the wallet application, will not result in communication being established between the two end-points.
- the issuercan use the key to make changes to a credential in the wallet application.
- changescould include, a change to the credential's expiration date, a change in the credentials account number, or a change in the account holder name associated with the credential.
- the issuercan connect to the wallet application with a valid key, make the appropriate changes to the stored credential, and then prompt the wallet application to display a notification message on the device display of the change that was made (a tone may also sound from the device to alert the user of the change).
- the issuermay connect to the wallet application with a valid key, a notification message will appear stating what change the issuer will perform to a credential, the user will be prompted to approve the change, and the change will only be made once the user provides his consent; after the change has been completed, a confirmation message will be displayed in the wallet application.
- the credential issuercan also use the key to initiate communication with the wallet application and make changes without the user's knowledge (no display messages or tones being generated). This feature is especially useful if a wireless device is lost/stolen and the owner of the device wants to have a credential deleted. Under such a scenario, the user might call the issuer or go on the issuer's web site to report his wallet device as being lost/stolen. Upon receiving the request, the issuer would send a message with the credential issuer key to its WCM in order to establish communication with the wallet application for the purpose of deleting the credential.
- the issuercould connect to it through the WCM and issue a lost/stolen command to have the credential deleted.
- the wallet application on the user's devicecould delete the credential without alerting a fraudster through display messages or tones being generated.
- the wallet applicationmay also have a feature whereby a mobile operator will be able to connect to the wallet application and issue a command to purge all its contents.
- a mobile operatorwill issue a unique “mobile operator key” to each wallet application device.
- the keyis stored in the wallet application, and is used by the operator to reset the wallet application remotely in the event that the device is lost/stolen, and to manage other wallet settings like (SIP proxy server addresses, DNS server addresses, etc).
- a user who has recently lost his wallet devicecould contact the operator via phone or log in to the operator's web site to notify the operator online.
- the operatorwould authenticate the identity of the user by asking him a series of questions on the phone or on the operator's web site. Once the user's identity is confirmed, the user can provide his consent to have the operator delete the contents of the wallet application remotely.
- the operatorusing a WCM would connect to the device using the “mobile operator key”, and issue a command to purge all contents of the wallet application. This can be accomplished without a fraudster knowing that the operator has connected to the device and has issued a command to purge all confidential wallet data and has locked the application.
- the deviceIn order for the operator to connect to the device and issue the purge command, the device needs to be turned on and must have signal to the wireless network.
- the operatorcan use the SUBSCRIBE function in the SIP protocol in order to be notified when the device is network accessible.
- the “mobile operator key”can only be used by the mobile operator to issue a purge command to the wallet application, and manage specific settings in the application that relate to how the application interacts with the operator's network and SIP infrastructure. The key does give the operator access to any credentials or other confidential data stored in the application.
- a userwants to change wireless devices, and requires the ability to transfer his wallet credentials and contents from his current device to a new device.
- the usermay accomplish this using a feature in the wallet application that allows stored credentials and other confidential information to be securely transmitted to another wireless device using the short-range transmission capability of both devices (e.g. Bluetooth, infra-red, etc).
- the userwould first login to his existing wallet application using his PIN or biometric ID. From the settings menu, the user would choose the “secure wallet transfer” option. The user might be given the ability to select which short-range transmission capability to use for communication with the new device (in case the device supports different types). For this example, we will assume that the user selects Bluetooth.
- the wallet application on the existing devicewill display a randomly generated 20 digit key that the user will be required to enter in the wallet application on the new device in order to authenticate the existing device and wallet. The user will be required to perform the following steps before peer-to-peer communication can be established between the two devices:
- the userturns on the new wireless device (which is pre-loaded with the latest version of the wallet application).
- the wallet applicationis launched. As the user has never used the wallet application on the new wireless device, launching the wallet application will ask the user if he is wants to setup a new wallet, or is transferring a wallet from another device.
- the userselects that he is transferring a wallet from another device.
- the useris asked to enter the 20 digit key that is currently displayed on his existing wireless device (from where the credentials will be transferred). The user inputs the 20 digit key exactly the way it appears on the existing device display. Upon submitting the key, the new device displays a message stating that it is ready to connect via Bluetooth.
- Bluetooth securityis implemented by the wallet application using preset security mode 3 with authentication and encryption.
- the existing deviceis now prepared to discover the new Bluetooth enabled device.
- the existing deviceperforms a Bluetooth inquiry and gets a response from the new wireless device.
- LMPLink Manager Protocol
- the new devicedetects that it does not have any previous link key with the new device.
- the existing deviceprompts the new device for the passkey that was input by the user.
- the passkeyis sent from the new device to the existing device and is validated.
- a key exchangeis performed between the new device and the existing device.
- a link keyis derived that is shared between the existing device and the new device.
- the new link key between the existing device and the new deviceis stored in nonvolatile memory in both devices.
- the existing deviceauthenticates the new device.
- the new deviceauthenticates the existing device.
- the existing device and the new deviceperform an encryption key exchange.
- the wallet application on the devicesautomatically switch the devices out of pairing mode so they no longer accept any new inquiries or pairing requests.
- the userwill be prompted on the new device for the wallet PIN associated with the existing device. Once the correct PIN has been entered, the contents of the wallet on the existing device will begin transferring to the new device.
- the wallet application on both deviceswill show a visual representation of the data transfer occurring from the existing device to the new device.
- the picturewill show the existing device on the left and the new device on the right of the screen, and a repeating animation of an arrow moving from the existing device to the new device.
- the arrowrepresents the data movement.
- a dynamic bar at the bottom of the screenwill show the percentage completion of the data transfer.
- the new deviceUpon completion of the data transfer, the new device will acknowledge with the existing device that all data has been transferred.
- the existing devicewill purge all credentials and data stored in the wallet application, will notify the new device of the purge, and will reset the application.
- the new devicewill be notified on screen that data on the old device was purged.
- the transferred credentialscan not be used until the wallet application sends a transfer notification to each credential issuer and receives an acknowledgment back. After the transfer of information between the devices is completed, a notification is automatically sent to each credential issuer with specific information related to the new device to which the credentials were transferred. These notifications must be sent before the credentials can be used.
- the notification to the credential issuercould contain, for example, the new device's Media Access Control (MAC) address, a unique code assigned to most forms of networking hardware. The address is permanently assigned to the hardware, so credential issuers may use the MAC address as a way to confirm that future communication from a specific user's wallet application is originating from a registered device.
- MACMedia Access Control
- Credential issuersin this case would retain the MAC address for the wallet device in its user database, and validate the MAC address contained in future communications from the wallet application against the address stored in its database for that user. Communications with incorrect MAC addresses will be rejected by the issuer's system.
- Other information that could be sent as part of a notification message from the wallet application to the credential issuerincludes a new E.164 phone number (if the new device has a newly assigned number) and a new randomly generated encryption key for each credential issuer (used by credential issuers to encrypt information being sent to the wallet application—could be one key for all issuers or unique keys for each issuer depending on the design).
- Credential issuersmay also want to re-authenticate the user's identity in order to allow a credential to be activated on the new device; this may involve the issuer's system establishing a peer-to-peer SIP session (via the WCM) to prompt the user for specific information that only he knows. The user in turn would be required to input the requested information into the wallet application interface in order to authenticate themselves and have the credentials re-activated.
- the credential issuermay also use the peer-to-peer session to re-issue any encryption keys that were issued to the last device.
- the wallet applicationhas two logging features that can be accessed through the wallet main menu “Log Viewer” option.
- the wallet applicationwill log all transactions made in proximity, personal, or remote mode.
- the logwill display information such as date/time, name of retailer/organization, location ID, list of credentials used in the transaction, and purchase price (if transaction had a financial component).
- the purpose of this logis to allow a user to see what credential and personal information was shared with a third-party. User's need to be able to verify sometimes what personal information may have been shared during a specific transaction. This viewer allows the user to go back and view up to 6 months of transactions.
- the log entrieswill also have links to digital receipts (which are stored separately in the wallet application).
- Digital Receiptswill be linked to log entries based on date/time stamp and credential matches (other criteria could also be used—for example, under one embodiment, the device generates a unique transaction ID which is transmitted with the credential to the merchant during each transaction. This ID could be contained in the digital receipt, and used by the wallet application to link the digital receipt with the log entries).
- the second logging featureregisters all credential changes in the wallet application.
- This featurelogs all new credentials, changes to credentials, and credential cancellations. Up to 1 year of data could be retained.
- the purpose of this logis to give users the ability to go back and see when credentials were first issued and when issuers made other changes.
- This logcaptures, date/time, credential, and description of activity/change made by issuer. The log viewer will allow the user to sort log entries based on any of the column headers.
- the secure storage of the wallet applicationresides on a remote network-connected storage device managed by the mobile operator or a “wallet service provider”. Based on this design, the wallet application registers an external wallet storage service as an “extension” within the wallet application on the wireless device.
- the external storagemay be a standard application extension that is automatically registered when the application is first launched and setup by the user.
- the external storageis used to store credentials, personal information, and some wallet settings.
- the external storageperforms two basic functions: storage and retrieval of information registered in the user's wallet application.
- the wallet applicationmay have a pre-programmed address of a secure and trusted storage server.
- the applicationmay contact the storage server to create a profile.
- the mobile operator or service providermay request some personal information to authenticate the identity of the user in order to create a storage profile for the user's wallet.
- the storage serverwill establish a valid username/password for the wallet application to automatically access the storage area; the username and password may be system generated or could be user defined during the storage profile setup.
- the wallet application and storage servicewill exchange encryption keys for secure communication.
- the communication keysare used to encrypt all messages between the wallet application and the storage server.
- New communication keyscan be dynamically generated for each communication session, or the same keys can be used for a set period of time before they are automatically changed.
- Credentialswill be issued to the wireless device in the manner previously described in this document with only a slight modification to where the credentials actually get stored.
- the wallet applicationWhen an issuer's WCM opens a peer-to-peer SIP connection with the wallet application on the wireless device, the wallet application will have an open connection maintained to the secure storage service. Any credentials that are issued to the wireless device will be transparently transmitted to the storage service where they will reside.
- the connection between the wallet application and the storage servicecould utilize an application protocol such as HTTP, SIP, or others.
- Any data transmitted to the storage servicewill be registered with the wallet application first; the registration of credentials, personal information, and other confidential data within the wallet application allows the wallet application to display headers for information in storage without having to retrieve it online; the registration process also allows the wallet application to call specific data from storage based on the assigned registration ID for the data object in storage.
- the wallet applicationwhenever the wallet application is launched on the device and a user logs in with his valid PIN, a real-time connection is initiated between the wallet application and the storage service.
- the wallet applicationautomatically authenticates itself and gains access to the stored credentials. The user is then free to use the wallet menu to select stored credentials or profiles to facilitate a transaction.
- the Credential Selector and Profile Selector screenswill show credentials and profiles in storage; if a user selects an appropriate credential for use, the credential information is securely transmitted to the wireless device and temporarily made available for use by the device's RFID interface. No credential data or settings are retained in memory of the wireless device after a transaction is completed. Under this embodiment, even electronic receipts, logs, and other information registered with the wallet application are stored in the external storage service, and made available for use by the wireless device.
- information stored in the external storage serviceis not registered with the wallet application.
- This type of developmentis made possible by opening some of the APIs on the terminal. Opening these API functionalities on the JAVA side for example has the advantage that applications can be run in a secure environment. Furthermore, applications can be provisioned to the terminal using an over-the-air mechanism in a secure and controlled way. One additional advantage is that the APIs will be available regardless of the underlying operating system.
- a SIP Client APIprovides access to the basic services of a SIP stack. The most essential services are sending and receiving SIP messages, creating registrations, and forming and tearing dialogs initiated by INVITE and SUBSCRIBE.
- a SIP Client APIis appropriate for applications like the wallet application disclosed herein, that intend to use SIP for managing communication sessions, subscribing to events, and sending stand-alone SIP messages.
- JSR180the SIP Application Programming Interface (API) for Java 2 Micro Edition (J2ME) which completed its final release in October 2003 as part of the Java specification process.
- the Java platformis seen as a base for many new innovative SIP applications.
- JSR180can also be deployed on a MIDP 2.0 platform.
- the Mobile Information Device Profile (MIDP)is a key element of the Java 2 Platform, Mobile Edition (J2ME).
- MIDPprovides a standard Java runtime environment for today's most popular mobile information devices, such as cell phones and mainstream personal digital assistants (PDAs).
- SIP Client APIis the SIP Client API Specification (Version 1.0; Jul. 5, 2004) that is valid for all platforms running Symbian OS v7.0s.
- the SIP Client APIrequires the SIP Codec API (v1.0) that provides services for encoding/decoding SIP headers and their fields.
- SIP Codec APIv1.0
- Java and Symbian APIs mentioned aboveallow multiple applications on the same device to use the SIP stack simultaneously.
- the function calls of the APIare synchronous.
- An applicationmust implement a set of callback functions, which the SIP Client API can use to pass events to the application.
- the SIP-based wallet application described hereinis intended to be developed for both of the environments described, and could also be built for other environments such as BREW, Palm, PocketPC, and Linux.
- the wallet applicationwill utilize a SIP API framework operating on the device.
- SIP APIsother than those mentioned above
- other operating systems or programming environmentsis also possible according to the teachings of the present invention.
- SIP identityis a logical identity (address-of-record), a type of Uniform Resource Identifier (URI) called a SIP URI. SIP identity is frequently thought of as the “public address” of the user (see RFC 3261, 6 definitions, p. 20).
- a wireless terminal that supports SIPis typically configured for one user at a time (SIP provider settings). This means that the SIP system uses that address-of-record (URI) as the identity when communicating to other identities. Now, it is very likely that there will be several applications that want to share the same SIP identity. For example, audio/video, instant message/presence, game applications, and a wallet application as disclosed herein. On the other hand, some applications can use their own SIP identity (for that particular service), which does not share the same SIP properties.
- URIaddress-of-record
- the terminalWhen sharing the same identity (address-of-record) the terminal has to know where the incoming request is routed. To do this it can use the MIME type tag carried in a special header (e.g. Accept-Contact).
- MIME type tagcarried in a special header (e.g. Accept-Contact).
- Each applicationis mapped to a certain MIME type.
- Java SIP APIprovides a way to utilize this functionality as is specified below.
- RFC 2046defines a top-level MIME “application” media type to be used for discrete data to be processed by some type of application program. This information must be processed by an application before it is viewable or usable by a user.
- applicationsmay be defined as subtypes of the “application” media type. Examples of two subtypes are: “octet-stream” and “PostScript”.
- the top-level media typeis used to declare the general type of data, while the subtype specifies a specific format for that type of data.
- a media type of “application/wallet”is enough to tell a user agent that the data relates to an application on the wireless device, and further to the Wallet Application which will be mapped to the specific MIME type.
- the subtype of “application”will often be either the name or include part of the name of the application for which the data are intended. While the above example uses the “wallet” subtype for the Wallet Application, another subtype that conforms with the requirements for MIME application sub-types can be used.
- RFC 2048defines registration procedures which use the Internet Assigned Numbers Authority (IANA) as a central registry for such values. Provided that the media type meets the requirements for media types and has obtained approval that is necessary, the author may submit the registration request to the IANA, which will register the media type and make the media type registration available to the community.
- IANAInternet Assigned Numbers Authority
- Profilesmay be shared with other applications.
- a profileis a collection of data necessary for providing required SIP registration behavior.
- a profilestores the following main parameters:
- the type of the profilefor example, 3GPP R5 IMS, IETF, or a proprietary profile type
- the access provider identifier of the used Internet Access Point (IAP)is the access provider identifier of the used Internet Access Point (IAP).
- the address of the SIP proxy serverwith optional connection and security parameters
- the SIP-based Wallet applicationcan share the same profile as other applications, and thus the same registration. This functionality may be built into the Wallet Application or could rely on an API.
- the SIP Profile API Specification(Version 1.0; Jul. 5, 2004) provides a SIP registration service for applications.
- the SIP Client API for the Symbian OS v7.0sis needed as well.
- the behavior of the registration servicedepends on the profile type used. There are different profile types for different standards, for example, 3GPP R5 IP Multimedia System, Internet Engineering Task Force (IETF), and proprietary standard types. At any given time, zero or more profiles of any profile type may exist. Each profile has a one-to-one correspondence with one SIP registration. The user of the API can be unaware of the details of the registration process and can ignore state changes of the access point connection during SIP registration.
- the SIP Profile Agent subsystemstores the SIP profiles in the persistent storage. As mentioned before, these profiles hold information necessary for providing required registration behavior.
- the SIP profilescan be managed with the SIP Settings UI (Application for end the user to add/update/remove SIP profiles), or they can be managed with over the air (OTA) configuration (by the SIP service provider).
- OTAover the air
- EMV-CompliantThe wallet application should meet standards defined by card organizations.
- the wallet applicationshould comply with ISO standards for Personal Identification Number (PIN) management and security in open networks (ISO/TR 9564-4:2004)
- Cryptographic functions supportedinclude:
- the usersets up a “wallet account” with a mobile operator or “wallet service provider”.
- the server-based wallet accountallows a user to store credentials, personal information, and other confidential information in the electronic wallet, which the user can access through a number of channels using a minimum of two registered tokens.
- the server-based wallet system described at this pointhas all the same functionality of the wallet application described above (operating on a wireless device), but allows a user to access the entire “electronic wallet” from virtually any Internet-based channel such as a wireless device, a PC, or point-of-sale terminal.
- the userwould be required to provide a E.164 number for a wireless device in order to establish the wallet account on a server hosted and managed by the wallet service provider.
- the wallet serveruses the E.164 number as an access token and may also use it as a master account number.
- the userwould also be required to establish a username and password/PIN for web access to the account (the username and password/PIN are also tokens).
- the server-based wallet applicationallows a user to register other tokens that can be used to gain access to the account through various means. For example, biometric information such as fingerprints, iris, voiceprints, facial recognition, and hand geometry can be registered through a trusted service provider of the wallet service.
- a magnetic-stripe card, an RFID-based device, a bar-coded card, or other similar devicescould also be registered as valid tokens that can be used for accessing the server-based wallet.
- the number of tokens and the types of tokens required to access the walletare dependent on the access methods available to access the wallet. For example, a POS terminal equipped with a fingerprint scanner and a numeric key input device, would only require a user to provide a valid E.164 phone number and a fingerprint in order to access his electronic wallet as disclosed herein. This example of two-factor authentication is sufficient to securely access a person's wallet at the point-of-sale. Similarly, a POS system that has an RFID reader and a numeric key input device, may require the user to wave a registered RFID token, provide a E.164 number (which could be transmitted by the RFID token or entered by the user manually), and enter his wallet PIN. This example would be considered three-factor authentication if the E.164 number is not encoded in the RFID device and must be entered manually by the user.
- the encoding of a E.164 number in an RFID-based device, magnetic-stripe card, bar coded device, or other similar device—that is used as an access token for an electronic walletis disclosed herein.
- the E.164 number encoded in the access tokenmay be transmitted to a reader along with other information such as a wallet account number, a unique device ID, and a variety of encryption information (that could be validated with the reader and/or with the wallet server).
- the mobile operator or wallet service providerwill populate the ENUM address information differently; under the previous design, the URI in the NAPTR record associated with the wallet service pointed to the wireless device (with the E.164 number). Based on this design, there are two URIs for the E.164 number that are associated with the wallet service. One URI points to a wallet server (managed by the operator or a wallet service provider). The other URI points to the wallet application that resides on a wireless device.
- NAPTR recordsmight be received for an ENUM name query on a particular E.164 mobile number (+1-202-555-1234) that was used to setup a wallet account:
- E2U+walletserverand “E2U+walletapp” enumservices would be registered as described before.
- the use of the “E2U+walletserver” enumservice as a selection mechanism for a wallet-based server, and the “E2U+walletapp” enumservice as a selection mechanism for a wallet-based application on a wireless deviceis provided. While the examples above uses the theoretical “walletserver” and “walletapp” Types, the actual label that is registered with the LANA for the purposes described could be different.
- a user that requests an electronic credentialwill provide the issuer with a valid E.164 number for his wireless device.
- the issuer's WCMwill perform an ENUM query on the E.164 number based on the steps outlined before.
- the difference in this embodimentis that the issuer WCM will look for a NAPTR record associated with the “walletserver”.
- the registered ‘E2U+walletserver’ enumservicewill function as a selection mechanism for the WCM when choosing one NAPTR resource record from another.
- the WCMwill use the corresponding URI to establish a secure peer-to-peer connection with the wallet server using any number of protocols including SIP. After exchanging encryption keys, initial communication from the WCM to the wallet server will contain the E.164 number.
- the wallet serverwill check to see if the E.164 number is associated with a valid account on file. If it is, the wallet server will send back an acknowledgement to the WCM while performing an ENUM query on the E.164 number to obtain a NAPTR record for the “E2U+walletapp” service. The wallet server will use the resulting URI to initiate a peer-to-peer SIP session with the wireless device (while still maintaining the connection with the issuer WCM).
- the wireless deviceloaded with “wallet client software”, allows a user to utilize the remote wallet functionality and access the credentials stored on the wallet server.
- the wallet applicationtogether with the wireless device on which it operates, allows the user to communicate in real-time with the credential issuer during the issuance process.
- the use of the wireless deviceallows the user to be located and contacted in real-time by the issuer in order to authenticate the user's identity before completing the issuance.
- the issuer's WCMis communicating with the wireless end-user through the wallet server using the SIP protocol.
- the wallet serverwould have an integrated WCM of its own to facilitate communication with end-user wireless devices and issuers.
- the issuerwill send the digital credential to the wallet server, where it will be stored. All new credentials or credential changes may be registered in the wallet client software on the wireless device; this way the wireless device doesn't need to access the server every time the user wants to scroll through lists of credentials, profiles, or other information. Alternatively, the wireless device could read all credential header information from the server as described earlier.
- This server-based designmakes it easier for users to change wireless devices, as the user only needs to change the E.164 number that is linked to the wallet account on the server.
- the usercan simply log into his wallet profile through the wallet service provider's secure site, and temporarily restrict the use of credentials stored in the wallet.
- This designalso offers a flexible solution for user's to gain access to their credentials in their digital wallet without the use of a wireless device. For example, in one scenario, a user making a purchase at a grocery store may be prompted at the point-of-sale for his E.164 phone number and his fingerprint.
- the grocery chain's IP-enabled POS systemwill capture the E.164 number and biometric information, and forward them to a WCM connected to the grocery chain's network.
- the grocery chain's WCMwill be used in this case to facilitate a transaction with the wallet server where the user is registered.
- the WCMwill perform an ENUM query on the E.164 number using a DNS server on the grocery chain's network, retrieve a NAPTR record that corresponds to the appropriate wallet service (e.g.
- E2U+walletserveruses the URI in the NAPTR record to establish a secure peer-to-peer session via the Internet to the wallet server.
- the WCM and the wallet servermay exchange encryption keys using established methods for doing so over the Internet prior to exchanging any confidential information.
- the WCMwill send the wallet server the E.164 number and the biometric information (fingerprint data) that was captured at the POS.
- the wallet serverwill validate that the E.164 number is associated with an account on record that is in good standing. If the account is valid and in good standing, the wallet server will validate the biometric information against information stored in the account. If the biometric information matches, the wallet server will transmit a menu showing all the credential types that are in the customer's wallet.
- This menucorresponds to the primary credential categories in the hierarchy that was previously discussed in this document.
- the customercould for example select “payment methods” and then see the secondary hierarchy (credit cards, debit cards, stored value cards, etc). Credentials will be displayed under the secondary categories. Credential listings will be displayed with some of the follow information:
- Name/logo of associatione.g. Visa, MasterCard
- the usercan select the appropriate payment method to complete the transaction.
- the userwill be able to select multiple credentials stored on the wallet server for the transaction. For example, a payment method, loyalty card, and electronic coupons could all be selected.
- a payment method, loyalty card, and electronic couponscould all be selected.
- the credentialsare then securely transmitted from the wallet server to the grocery chain's WCM which routes them to the POS system for processing.
- the POSor a related system in the chain's network
- the WCMtransmits the digital receipt to the wallet server and then drops the connection to the wallet server.
- the digital receiptsare made available to the user by logging into the wallet service provider's secure site using the username and password/PIN that was created.
- a usermay choose to also receive receipt notices from the wallet server via e-mail or on his wireless device using the methods and protocols previously described, Short Message Service (SMS), or some other type of messaging protocol.
- SMSShort Message Service
- the wallet serverwill have an integrated WCM.
- the wallet serverwill also have access to a secure storage apparatus, high-performing database infrastructure, and front-end web architecture that allows users to manage/maintain their accounts online through a standard web browser.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Toxicology (AREA)
- Health & Medical Sciences (AREA)
- Electromagnetism (AREA)
- General Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Mobile Radio Communication Systems (AREA)
- Telephonic Communication Services (AREA)
Abstract
Description
- The present invention is a continuation of and claims benefit of priority to co-pending U.S. patent application Ser. No. 14/187,693, filed on Feb. 24, 2014, which is a continuation of and claims benefit of priority of U.S. patent application Ser. No. 11/040,847, filed on Jan. 21, 2005, now allowed, the entire disclosure of which is hereby incorporated by reference herein.
- 1. Field of the Invention
- The present invention relates generally to systems and methodologies for conducting electronic commerce and more particularly to systems and methodologies for issuing, managing, storing and using credentials authorizing the legitimate holder of such a credential to accomplish a desired result.
- 2. Description of the Related Art
- According to current practices, consumers typically carry multiple single-purpose cards, tags, passes, and tokens which allow them to identify themselves to or present account information to retailers, service providers, financial institutions, government agencies, and other organizations. These single-purpose devices may contain combinations of encoded personal, account, and/or security information in order to identify a user and to authorize the user to conduct a particular transaction. Data on these devices may be encoded on a variety of media types such as magnetic stripes, bar codes, chips, and/or embossed or printed data. The creation of standards for many encoding formats has contributed to the proliferation of certain card and device types.
- For example, data may be encoded on magnetic stripe cards using a proprietary methodology or by employing an “open” or “standard” encoding pattern. Magnetic stripe cards have been embraced by financial institutions, merchants, and consumers ever since standards for such cards were adopted by the industry in the 1970s. A magnetic stripe is encoded with bit patterns, which correspond to three tracks of ASCII characters. Credit cards and other bank cards typically use only
tracks Track 3 is a read/write track, but its usage is not standardized among financial institutions and is seldom used. The majority of magnetic cards in circulation conform to International Standards Organization (ISO) standards for magnetic cards. - Magnetic stripe technology is widely used throughout the world and remains the dominant technology in the United States for transaction processing and access control. One drawback associated with magnetic stripe technology is the limited amount of information that it can hold. Other technologies such as bar code and smart chip cards are also widely used in large part because they can hold more information than magnetic stripe cards.
- Another drawback of magnetic stripe technology is that it provides little in the way of card authentication. The data on the stripe can be easily read by a card reader and potentially “skimmed” and then copied onto a fraudulent card. Because of the static nature of the magnetic stripe, bank issuers are not able to distinguish card data originating from a genuine card from card data read from a copied (cloned) card during an “online” authorization.
- Smart cards provide a distinct advantage in that they offer the ability to provide authentication in connection with a transaction. Card authentication can be performed by the reader terminal and/or the issuer's systems using dynamic techniques that distinguish genuine cards from clones. A smart card generally includes an embedded semi-conductor device which is programmed before issue with the account holder's information. This data is protected through secure encryption methods, making it difficult to fraudulently replicate a smart card. The integrated circuits within smart cards in general have continued to improve with miniaturization, low power requirements, the addition of strong encryption capability, and tamper-proof standards for crypto-processor chips
- There are three general categories of smart cards: contact, contactless, and hybrid smart cards. A contact smart card requires that the user insert the smart card into a smart card reader with a direct connection to a conductive micro-module on the surface of the card. It is via these physical contact points, that transmission of commands, data, and card status takes place.
- A contactless smart card requires only close proximity to a reader. Both the reader and the card have antennas and it is via this contactless link that the two communicate via radio frequency (RF) when in close proximity. Most contactless cards typically receive power for on-card electronic functions via this electromagnetic signal. The range is typically two to three inches for non-battery powered cards, and this is ideal for applications such as mass transit which requires a very fast card interface.
- The third category of smart cards is known as hybrid smart cards. These cards typically have a dual interface enabling both contact and contactless communication with the card's chip.
- As stated, RF communication is used in connection with both contactless and hybrid smart cards. RF and Radio Frequency Identification (RFID) technologies come in a variety of forms, each of which may be tailored for use in different types of environments. These technologies differ in, for example, the frequency bands they employ, which in turn influences the rate of data transfer between the tag and reader. Consequently, different data transfer rate requirements influence the types of solutions that RFID services can and should be expected to provide. RFID technology is typically used for POS payments, electronic toll collection, access control, and numerous other applications.
- Contactless applications are particularly attractive to the retail payments segment where speed, convenience, and security are essential. Contactless payment systems are used successfully around the globe and offer a number of advantages to issuers, retailers, and consumers. Contactless payments allow issuers to penetrate the cash payment market, enjoy increased customer transaction volume, reduce fraud, and utilize the existing transaction processing infrastructure. Retailers realize benefits due to improved operational efficiency and lower operating costs. Consumers enjoy the convenience of faster transaction times and the ability to integrate multiple payment and loyalty accounts on one device.
- American Express, MasterCard, and Visa have agreed on a single contactless payment standard in the United States, ISO/IEC 14443, and are implementing a contactless payment approach that leverages the existing payments infrastructure. As a result, merchants can easily add a contactless RF reader to their existing POS systems and immediately begin accepting contactless payment. MasterCard and Visa have also been working jointly over the last few years to develop specifications that define a set of requirements for security and interoperability between chip cards and terminals on a global basis, regardless of the manufacturer, the financial institution, or where the card is used.
- As a result of the increased move towards standardization, improving technology and more demanding security and authorization requirements, smart cards are slowly replacing the magnetic stripe card as the dominant technology for conducting financial transactions. The enhanced ability of smart cards to secure confidential information and the ability of POS systems to authenticate the chip cards makes them an attractive alternative to magnetic stripe cards. Also, the reduction of fraudulent transactions achieved by smart cards results in lower risk, and lower fees for the consumer and the merchant.
- Another important trend in consumer-related electronics is the increased speed and the reduced size of available electronic components which has contributed to the proliferation of powerful wireless devices. Mobile devices including personal digital assistants (PDAs) and cellular phones now number over one billion worldwide. The capability of wireless devices has been augmented by their ability to connect to the Internet and also to exchange data over short ranges with other wireless devices or readers.
- Common short-range communications network standards defined by the International Electrical and Electronic Engineers association (IEEE) include 802.11a, 802.11b, and 802.11g. Many mobile devices employ these IEEE network standards to establish wireless LAN (WLAN) connectivity. Various other short-range technologies currently in use for device-to-device communication include Bluetooth and infra-red. One major short-range infra-red (IR) communications network protocol is defined by the Infra-red Device Association (IrDA), and is known as the IrDA standard. Wireless devices with integrated RFID proximity chips or Near Field Communication (NFC) technology may also provide users the ability to transfer information to a reader device.
- With reference to the aforementioned fraud concerns as well as the general inconvenience of having to carry a large number of cards, tags and tokens, it would be beneficial to be able to conduct consumer and other financial transactions in a different manner. Although a completely cashless society is unlikely at least for the foreseeable future, it would be desirable to provide consumers with the ability to conduct more transactions without the need for cash.
- The short-range data transmission capability of wireless devices, coupled with electronic wallet software operating on the devices, could allow users to carry out various transactions using a personal trusted device (PTD) that is loaded with the user's payment, identification, and/or other credentials. Unfortunately, there remain various obstacles to solutions using PTDs or other portable devices for conducting financial transactions. One primary hurdle to the broad-based deployment of such a solution is the difficulty in providing for the convenient, efficient, and secure distribution of credentials into wireless devices such that only those authorized to conduct the transactions may do so and only to the extent of their authorization.
- Various possible solutions present a variety of drawbacks. Allowing the user to manually enter his or her personal information or account data that was previously stored on magnetic stripe, bar code, or chip cards directly into the wireless device leaves open the possibility that the data could be lost or used by an unauthorized party to make fraudulent transactions. Banks and other organizations in turn are reluctant to allow manual importation of sensitive information into wireless devices, owing primarily to security risks. Accordingly, there is a need for a solution which provides for the secure importation of financial and other personal information into wireless devices.
- Since there is such a large number of credential issuers, mobile operators, and wireless end-users world-wide, there is also a need for a credential issuance and management system that is readily accessible by such a broad and diverse set of users. There is also a need for a system and method through which credential issuers can securely and rapidly target specific wireless devices for the distribution of the appropriate credentials over public and private networks.
- It is therefore a primary object of the present invention to provide a system and methodology which improves upon prior art systems and methodologies and their related drawbacks as described above.
- It is another object of the present invention to provide for the convenient, efficient, and secure distribution of credentials into wireless devices such that only those authorized to conduct the transactions may do so and only to the extent of their authorization.
- It is a still further object of the present invention to provide for the secure importation of financial and other personal information into wireless devices.
- It is a yet further object of the present invention to provide a system and method through which credential issuers can securely and rapidly target specific wireless devices for the distribution of the appropriate credentials.
- It is an even further object of the present invention to provide an overall system and processing methodology through which financial transactions can be conducted in a secure context without the need for credit cards, tags, tokens or other physical embodiments of currency or the authority to conduct a transaction.
- These and other objects of the present invention are obtained through the use of a novel system and methodology for conducting financial and other transactions requiring authorization. According to the methodology of the present invention, credentials may be selectively issued by issuers such as credit card companies, banks, and merchants to consumers permitting the specific consumer to conduct a transaction according to the authorization given as reflected by the credential or set of credentials. The preferred mechanism for controlling and distributing credentials according to the present invention is through one or more publicly accessible networks such as the Internet wherein the system design and operating characteristics are in conformance with the standards and other specific requirements of the chosen network or set of networks. According to a preferred embodiment of the invention, credentials are ultimately supplied to a handheld device such as a mobile telephone via a wireless network. The user holding the credential may then use the handheld device to conduct the authorized transaction or set of transactions via, for example, a short range wireless link with a point-of-sale (POS) terminal.
- These and other advantages and features of the present invention are described herein with specificity so as to make the present invention understandable to one of ordinary skill in the art.
FIG. 1 is a overall view of the components of the present system and their relationship to one another according to a preferred embodiment of the present invention;FIG. 2 is a flowchart illustrating the steps in the process for issuing a credential according to a preferred embodiment of the present invention;FIG. 3 illustrates some of the SIP components, their relationship to one another and the protocols that are employed in a preferred embodiment of the present invention;FIG. 4 is an illustration of a typical SIP message exchange between a credential issuer and a fictitious mobile user;FIG. 5 is a block diagram illustrating the steps in the SIP registration process of a wireless device according to a preferred embodiment of the present invention;FIGS. 6( a) and6(b) are graphical representations showing examples of where a “wallet button” might be situated on a wireless device according to a preferred embodiment of the present invention;FIGS. 7( a) and7(b) are graphical representations showing examples of where “hot buttons” might be situated on a wireless device according to a preferred embodiment of the present invention;FIG. 8 is a diagram illustrating the over-the-air PIN verification scheme of the present invention; andFIG. 9 is an example screen shot of a PIN Approval Request displayed by the wallet application according to a preferred embodiment of the present invention.- The present invention for transaction processing and related credential management and distribution is now described in specific terms sufficient to teach one of skill in the practice the invention herein. In the description that follows, numerous specific details are set forth by way of example for the purposes of explanation and in furtherance of teaching one of skill in the art to practice the invention. It will, however, be understood that the invention is not limited to the specific embodiments disclosed and discussed herein and that the invention can be practiced without such specific details and/or substitutes therefor. The present invention is limited only by the appended claims and may include various other embodiments which are not particularly described herein but which remain within the scope and spirit of the present invention.
- A general discussion of the present invention is now provided and is thereafter followed by a detailed description of each of the components and functions of the invention according to specific preferred embodiments.
FIG. 1 is an overall system diagram illustrating some of the key components of the credential distribution system of the present invention in a preferred embodiment thereof. The ultimate goal of the present invention is to securely, accurately and rapidly distribute credentials to the proper wireless devices based upon the actions of credential issuers. It is also important that these credential issuers have the ability to securely, accurately and rapidly update credentials as required. In furtherance of this,wireless credential manager 110 of the present invention functions to manage, distribute and update credentials so that they are contained as desired in a wallet software application running onwireless device 200. A set ofcomponents 100 collectively comprise a subsystem capable of, among other things, causing the issuance of a credential towireless device 200 according to the teachings of the present invention. - Although
FIG. 1 shows only asingle wireless device 200 it will be readily understood that in deploying the present invention, credential issuers obtain the ability to selectively control credentials held by a practically unlimited number of wireless devices. The teachings of the present invention illustrate techniques for ensuring that the proper credentials are made available only to the proper wireless device or set of wireless devices. Various addressing and other techniques are used in the present invention to ensure secure control over the distribution of credentials to the wireless devices. - In a preferred embodiment of the present invention, distribution of credentials is made via a transmission initiated by
Issuer Cardholder System 120 toWireless Credential Manager 110 which causes the credential or set of credentials to be transmitted towireless device 200 via the Internet and/or one or more alternative public or private networks. Based upon the specific addressing schemes employed herein, the credential may then ultimately make its way to the targeted wireless device via an over-the-air wireless link. - As stated above, the present invention preferably involves the distribution of credentials to a “wireless device”. As used herein,
wireless device 200 is preferably a device that is capable of wirelessly connecting to the Internet using network protocols such as GSM/GPRS, CDMA2000, W-CDMA, EDGE, HDR, 1xRTT, UMTS, IMT-2000, 802.11a, 802.11b, 802.11g, or BLUETOOTH or other relevant protocols developed hereinafter. Preferably,wireless device 200 has a display screen and a key pad for alphanumeric and special character data input. It is further preferred thatwireless device 200 has processing and secure storage capabilities allowing it to host and operate a wallet application capable of receiving, storing, managing and transmitting multiple payment, identification, and other confidential information electronically.Wireless device 200 also preferably has an integrated short-range communication capability for transmitting confidential information and exchanging other data between the wallet application and an external reader that is in proximity to the wireless device. Wireless device 200 further preferably is of a type that has an assigned E.164 phone number, Uniform Resource Identifier (URI), or other type of unique address that can be resolved over the Internet. In a preferred embodiment,wireless device 200 also has a Session Initiation Protocol (SIP) Application Programming Interface (API) framework embedded in or running on top of a resident operating system, which allows for multiple SIP-based applications, such as the wallet application discussed herein, to function. The wallet application may also rely on its own SIP architecture, alleviating the need for a SIP API framework that could be used by multiple SIP applications.- Wireless Credential Manager (WCM)110 maintains, controls and distributes credentials in accordance with the teachings herein. In a preferred embodiment,
WCM 110 is able to interface with a payment, identification, and/or other existing user management or card management systems such asissuer cardholder system 120. An issuer representative may interface withissuer cardholder system 120 through the use ofcustomer care terminal 150. The process for issuing a credential according to the present invention may be initiated manually by an issuer representative viaterminal 150. Alternatively, the customer himself may initiate the process through interactive voice response (IVR)system 160 by calling in throughwireline phone 165 viaPSTN network 170. - Other alternatives for initiating the process include the use of computer via the requesting party's
ISP 178, theInternet 180 and through the issuer'sweb server 182 toissuer cardholder system 120. Still another alternative for initiating the credential issuing process is throughwireless device 200 viamobile operator network 155,SIP proxy 157,Internet 180 and issuer'sweb server 182. The wireless device used to initiate the credential issuance process may be either the device to receive the credential or another wireless device. - The bottom of
FIG. 1 including a credit card personalization machine, a credit card and an envelope indicates that in connection with the delivery of a wireless device credential according to the teachings of the present invention, it is also possible to deliver a conventional credit card or other physical form of the credential for use by the customer. WCM 110 provides for the secure Internet delivery of electronic credentials towireless device 200 which is loaded with a wallet application.WCM 110 provides a secure and robust means of issuing, canceling, and managing electronic credentials on wireless devices via the Internet.WCM 110 leverages existing Internet protocols and technologies, making it easy for issuers to integrate with their existing systems, and alleviating the need to establish direct links with multiple mobile operators.- E.164 is the name of the international telephone numbering plan administered by the International Telecommunication Union (ITU), which specifies the format, structure, and administrative hierarchy of telephone numbers. “E.164” refers to the ITU document that describes the structure of telephone numbers. The ITU issues country codes to sovereign nations, but administration of telephone numbers within each country is governed by that country's telecommunications regulatory agency. A fully qualified E.164 number is designated by a country code, an area or city code, and a phone number. For example, a fully qualified, E.164 number for the phone number 555-1234 in Washington, D.C. (area code 202) in the United States (country code 1) would be +1-202-555-1234.
- According to the teachings of the present invention, an E.164 phone number is used to target a user's wallet application on Internet-enabled
wireless device 200 for the delivery of credentials and confidential data, including but not limited to credit card, debit card, ATM card, loyalty card, driver's license, electronic ticket, coupons and other information. In addition, an E.164 phone number is used according to the present invention to target a user's wallet application residing onwireless device 200 for the remote cancellation or updating of credentials. Also, E.164 phone numbers may be used as described herein to make person-to-person, person-to-company, or company-to-company electronic payments or fund transfers usingwireless device 200. Although a preferred embodiment, this invention is not necessarily limited to the use of E.164 phone numbers. Rather, the use of URIs and other address types that are capable of being translated to an Internet address is also possible for the purposes mentioned above. - In a preferred embodiment,
WCM 110 of the present invention uses the Electronic Numbering (ENUM) protocol to resolve a fully qualified E.164 telephone number for the particular wireless device200 (with a loaded wallet application) to a fully qualified domain name address corresponding to the same device using a DNS-based architecture. ENUM (E.164 Number Mapping, RFC 3761) is a system that uses DNS (Domain Name Service, RFC 1034) in order to translate certain telephone numbers, like ‘+12025551234’, into URIs (Uniform Resource Identifiers, RFC 2396) like ‘sip:user@sipcarrier.com’. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions. E.164 is the ITU-T standard international numbering plan, under which all globally reachable telephone numbers are organized. - The use of ENUM presupposes the collection of these records into a central or hierarchical service. According to a preferred embodiment, the resolved Internet address is used to establish secure real-time communication between
WCM 110 and the wallet application onwireless device 200 using the Session Initiation Protocol (SIP) (for example, according to the RFC 3261 standard) to transfer encrypted credentials. Theissuer WCM 110 may also be used to update credentials or update the status of credentials onwireless device 200.WCM 110 may also be used to authenticate a mobile user's identity in real-time during a transaction. While the use of SIP for such purposes is preferred, alternative application protocols may be used in lieu of SIP while still remaining within the spirit and scope of the present invention. - The use of SIP for transmitting and managing credentials on
wireless device 200 is preferred as mobile operators and fixed line operators are moving towards a SIP-based architecture for voice and other multimedia services. It is envisioned that the use of SIP for communication between a credential issuer and a wallet application resident onwireless device 200 could leverage the same SIP registrar, proxy, and presence servers used to deliver real-time interactive converged communication services within a mobile operator's network. - According to a preferred embodiment, ENUM is used as follows. The E.164 number is first converted into a query in the e164.arpa domain. The domain “e164.arpa” is being populated in order to provide the infrastructure in DNS for storage of E.164 numbers. In order to facilitate distributed operations, this domain is divided into sub-domains. The resultant set of services is specified by the returned collection of NAPTR (Naming Authority Pointer) records. The agent (the WCM in this case) selects a service that matches the service characteristics of the original request, and takes the corresponding URI for further resolution by DNS. The elements of this URI are further decomposed as per any rewrite rules in the NAPTR record. DNS queries are generated as per the sequence of preferred NAPTR rewrite operations. The ultimate result of this sequence of DNS queries is the specification of a protocol, an associated port address, and the IP address for a preferred server for the service.
- In order to take advantage of ENUM, the mobile telephone number must first be assigned to a user by a telecom operator for services. The number can then be registered for one or more ENUM services. For example, a subscriber might wish to install a wallet application on
wireless device 200 and register the telephone number as the identifier for the wallet application. Multiple issuers can in turn deliver payment methods, identification, or other types of electronic credentials to the wallet application on thewireless device 200 via the Internet using the phone number as the destination address. Additionally, that subscriber might wish to register an e-mail address or fax number to be associated with the same phone number. However the user chooses to set up these services, the information for the registered services, including the wallet application, is saved in NAPTR (Naming Authority Pointer) Resource Records. - Today, there exists an issue as to ownership of these ENUM DNS zones. In other words, it has not yet been decided which entity or entities will have the right to populate the e164.arpa domain with the URIs. For purposes of illustration, the discussion herein assumes that mobile operators will have the right to populate a collection of resource records associated with a DNS name. Furthermore, while e164.arpa appears to have been selected as the common international DNS root for ENUM DNS entries, there is a chance that once ENUM moves beyond the trial phase in many countries, a different domain could become the new standard. As such, references to e164.arpa throughout this document are not limiting and could be replaced with another root while still remaining within the scope of the present invention.
- According to the present invention, electronic credentials may be issued to a wallet application on a
wireless device 200 held (owned, rented or otherwise controlled) by a user that already has a physical card or token-based credential. For example, an existing bank customer that has a magnetic-stripe credit card may also request a digital card for use with the wallet application on his or herwireless device 200. The bank customer could request the new credential over the phone by first validating his or her identity with the issuer, by logging into the issuer's secure web site using a valid username and password, or in person at a branch. - Credentials may alternatively be issued to a wireless device held by a user that is applying for a new credential for the first time. For example, a user may be applying for a credit card for the first time, and may wish to only request the credential on his or her mobile phone. According to the teachings of this invention, credential issuers may request from applicants (e.g. over the telephone) a properly formatted E.164 phone number in order to target the delivery of credential(s) to a wallet application on
wireless device 200. The request for a E.164 wireless device number on an application for a credit card, debit card, ATM card, loyalty card, driver's license, security pass, coupons, certificates, or other credential type is made by the issuer. The E.164 phone number may be obtained on paper, via a web-based application, via an electronic kiosk, via telephone or it may be captured through other means. - Turning now to
FIG. 2 , an overview of the credential issuance process of the present invention, in a preferred embodiment thereof, is now described. The credential issuance process begins withWCM 110 receiving a request from the issuer's card oruser management system 120 to issue electronic credentials to an individual user (see step310). The request is forwarded toWCM 110 along with the user's mobile (E.164) number, the credentials to be issued, encryption keys, and other information contained in the Personalization File for the specific request. The Personalization File may be a batch file that contains numerous records of credentials that are to be issued to individuals on theirwireless device 200, or could be a separate file record for each credential to be issued. In another embodiment, the Personalization File is transmitted toWCM 110 byissuer personalization server 130 which is in communication withissuer cardholder system 120. Issuer personalization server communicates withpersonalization bureau server 140 which is typically maintained by the personalization bureau. - The Personalization File is preferably similar to the Personalization File that credit card issuers send to personalization bureaus responsible for manufacturing, personalizing, and fulfilling magnetic-stripe cards for issuance to customers. The Personalization File received by personalization bureaus from credit card companies contains all the necessary account and consumer data required to emboss a card, encode the magnetic stripe, and fulfill the issued card via mail. Other information is sometimes also included in the Personalization File depending on the additional services performed by the Personalization Bureau. For example, the file may contain data indicating a request of the Personalization Bureau to generate a personal identification number (PIN) which may be mailed to the customer. This information or a subset thereof makes up the personalization file record that is transmitted by
issuer cardholder system 120 toWCM 110 in connection with a credential issuance request according to the present invention. - In the case where a user already has one or more credentials from the issuer, such as a magnetic-stripe credit card, and wishes to supplement the card with a digital version of the credential on his or her
wireless device 200, the issuer can provide the user with a digital credential linked to the same magnetic-stripe account, but that bears a different account number. - The full account number of the electronic credential issued to
wireless device 200 may not be visible to the user through the wallet application (discussed later), since the credential may have been issued for “device present” transactions only as may be the case with certain credit cards that are issued. Account numbers and other information could also be partially masked for security reasons with other credential types. In all such cases, the issuer may specify in the security characteristics such as the visibility of account numbers or other information in the Personalization File. For example, the issuer may specify that the wallet application should only make the last four digits of the account number visible to the user onwireless device 200. - According to a preferred embodiment,
WCM 110 will by default be configured to receive the mobile phone number (in the Personalization File Record) in the format specified in section 2.1 of RFC 3761. This format is herein referred to as the Application Unique String (AUS). The AUS is a fully qualified E.164 number minus any non-digit characters except for the “+” character which appears at the beginning of the number. The “+” is kept to provide a well understood anchor for the AUS in order to distinguish it from other telephone numbers that are not part of the E.164 namespace. For example, the E.164 number could be stored in issuer'scard management system 120 as “+1-202-555-1234”. To ensure consistent syntactic form, all non-digits except for “+” are removed in the Personalization File sent toWCM 110, yielding “+12025551234”. - In order for an issuer to send confidential information to an approved user's
wireless device 200,WCM 110 must first validate that the phone number is a syntactically correct E.164 number and then translate the number into an address that can be used by a DNS resolver (see step320). - ENUM is only applicable for E.164 numbers. As an ENUM compliant application,
WCM 110 will only query DNS for what it believes is an E.164 number.WCM 110 could in turn apply validation routines to ensure that the number received from the issuer's card management system120 (and indirectly received from the user) is a syntactically correct E.164 number.WCM 110 can perform basic formatting on phone numbers received in the Personalization File. While it is preferred that issuer'scard management system 120 populate phone numbers in the Personalization File in the AUS format mentioned above,WCM 110 may also have the ability to make edits in order to ensure proper formatting. - The WCM validation routine may further be customized by the issuer to be region specific; for example, an issuer in the United States that only wants to issue electronic credentials to domestic users, may set the validation routine to reject all numbers that do not match the US numbering format of +12025551234. While rules like this are preferably enforced in the card issuer's
user management system 120, they can be also enforced byWCM 110.WCM 110 is preferably flexible to allow other types of validation routines to be programmed.WCM 110 of course cannot ensure that a particular number is valid until it tries it. - After
WCM 110 validates the E.164 number, it must translate the mobile phone number into an address that can be used by a DNS resolver integrated into WCM110 (see step330). Because this address is based on a complete, international telephone number (for example, +12025551234), a unique Internet address exists for every unique phone number (once the ENUM database is completely populated). To determine if the number and address are registered in ENUM, the telephone number is translated in the following manner by WCM110: - 1) All characters with the exception of the digits are removed. For example,
WCM 110 starts with the Application Unique String “+12025551234”. This step would simply remove the leading “+”, producing “12025551234”. - 2) Dots (“.”) are added between each digit. Example: 1.2.0.2.5.5.5.1.2.3.4
- 3) The order of the digits are reversed. Example: 4.3.2.1.5.5.5.2.0.2.1
- 4) The string “.e164.arpa” is appended to the end. Example: 4.3.2.1.5.5.5.2.0.2.1.e164.arpa
- This domain-name is used to request Naming Authority Pointer (NAPTR) resource records which may contain the end result or, if the flags field is blank, produces new keys in the form of domain-names from the DNS.
WCM 110 interacts with the domain name space through its built in resolver. The resolver must have knowledge of at least one name server (likely on the issuer's network). The WCM resolver can be configured with multiple name servers. - When the resolver processes an ENUM query it asks a known name server for the information; in return, the resolver either receives the desired information or a referral to another name server. Using these referrals, the resolver learns the identities and contents of other name servers. Resolvers in general are responsible for dealing with the distribution of the domain space and dealing with the effects of name server failure by consulting redundant databases in other servers. Note that the resolver may have to make several queries to several different external name servers to answer a particular user query, and hence the resolution of a ENUM query may involve several network accesses and an arbitrary amount of time.
- The next step in the overall process of the present invention in a preferred embodiment calls for the retrieval of a NAPTR record (see step340). According to RFC 3761, the domain naming system uses the ENUM query to retrieve a NAPTR record associated with the E.164 number. The DNS response to the ENUM query contains one or more NAPTR records corresponding to the E.164 number, and each NAPTR record contains one or more service-specific Uniform Resource Identifiers (URIs).
- Thus, for the example ENUM name query given above, the following NAPTR records might be received:
$ORIGIN 4.3.2.1.5.5.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 ″u″ ″E2U+sip″ ″!{circumflex over ( )} {circumflex over ( )}.*$!sip:bob@MobileCo.com!″ .IN NAPTR 103 10 ″u″ ″E2U+wallet″ ″!{circumflex over ( )} {circumflex over ( )}.*$!sips:bob@wallet.MobileCo.com!″ . WCM 110 will look for a NAPTR record associated with the “wallet” service. The registered ‘E2U+wallet’ enum service will function as a selection mechanism forWCM 110 when choosing one NAPTR resource record from another.WCM 110 can select the corresponding URI and use the resolver a second time to translate the domain name part of the URI to an IP address using the URI-specific DNS resource record as a query term.WCM 110 can then use the full URI specification to open a session with the selected service port and complete the service transaction with the wallet application on the user's mobile device.- The packet format of the NAPTR RR is found in
section 4 of RFC 4303. Examples of NAPTR records are shown below: Order Pref. Flags Services Regexp Replacement IN NAPTR 100 10 ″u″ ″E2U + sip″ !{circumflex over ( )}{circumflex over ( )}.*$!sip:bob@mobileco.com!″ . IN NAPTR103 10 ″u″ ″E2U + wallet″ !{circumflex over ( )}{circumflex over ( )}.*$!sips:bob@wallet.mobileco.com!″ . - NAPTR fields contain numerous components:
- An Order field to specify the order in which multiple NAPTR records must be processed
- A Preference field to determine the processing order when multiple records have the same order value
- A Service field to specify the resolution protocol and service
- Flags to modify the actions of further DNS lookups
- A Regular Expression to allow the query client to rephrase the original request in a DNS format
- A Replacement field to define the next DNS query object
- The Order field in the NAPTR record for the wallet service can be set with the highest value since
WCM 110 will be selecting a single record that contains the wallet enum service. The high value in the Order field will also reduce the likelihood of other SIP applications cycling through the records and incorrectly trying to communicate with the wallet application. - The flag “u” denotes a terminal lookup that will result in the production of a URI by the regular expression substitution specified. The “E2U+wallet” specifies a service to be contacted by SIP through the use of an E.164 to URI (E2U) translation. The substitution “!.*$!sips:bob@wallet.mobileco.com!” is then applied to the original phone number (such as +12025551234) to yield the result sips:bob@wallet.mobileco.com, which is used to resolve SIP addresses.
- The replacement string is the resultant string (“sips:bob@wallet.mobileco.com”), which is to be used to initiate the SIP communication for issuing the credential to the specified wireless device200 (see step350). The NAPTR format also specifies a method for various matches in the regular expression to be substituted into the replacement string. This simple example does not require that although in actual operation, this feature may be used.
- Enumservice registrations must be made with the IANA. A complete registration will include the proposed “enumservice” field, the URI schemes, a functional specification, security considerations, intended usage, and any other information intended to allow for the interoperability within ENUM. Service Registration requirements are outlined in RFC 3761.
- According to the teachings of the present invention, the “enumservice” field is used to represent an electronic wallet application or service associated with the E.164 phone number. Traditionally, the services field of a NAPTR record (as defined in RFC 3403) contains a string that is composed of two subfields: a ‘protocol’ subfield and a ‘resolution service’ subfield. ENUM in particular defines an ‘E2U’ (E.164 to URI) resolution service and a service ‘Type’ that is registered with the IANA. Note that the token “sip” that is shown as an example above is a Type registered with the IANA. The Type “wallet” however, is shown for illustrative purposes. The Types have no implicit connection with the protocols or URI schemes even though they can bear the same name.
- According to the teachings of the present invention the ‘E2U’ resolution service is used in conjunction with a Type that represents an electronic wallet application or service. For example, an ‘E2U+wallet’ enumservice that indicates the presence of an electronic wallet application running on a mobile phone or on other systems connected to the Internet may be used. While the example above uses the theoretical “wallet” Type, the actual label that is registered with the IANA for this purpose could be different. The service parameters including guidelines for the Type field can be found in section 2.4.2 of RFC 3761. The ‘type’ must be unique and comply with other naming requirements outlined in section 3.1.2 of RFC 3761.
- The scheme of the URI that will appear in a NAPTR record using the ‘E2U+wallet’ enumservice may be either ‘SIP’ or ‘SIPS’. While SIPS offers greater security, there may be reasons for using SIP that are not contemplated herein. Furthermore, the use of application protocols other than SIP and SIPs in conjunction with the ‘E2U+wallet’ enumservice in the NAPTR records is also possible. The ability to support another enumservice in addition to the ‘E2U+wallet’ enumservice in the same NAPTR RR is also possible (
reference section 8, RFC 3761). - As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the data one gets back is authentic. As ENUM is deployed on the global Internet, it is expected to be a popular target for various kinds of attacks, and attacking the underlying DNS infrastructure is one way of attacking the ENUM service itself. There are multiple types of attacks that can happen against DNS that ENUM implementations should be aware of. Section 6.1 of RFC 3761 lists threats that are taken from Threat Analysis of the Domain Name System.
- Because of those threats,
WCM 110 preferably includes mechanisms which ameliorate these threats. For example, some of these threats can be solved by verifying the authenticity of the data via mechanisms such as DNSSEC, which will be supported byWCM 110.WCM 110 will be prepared to receive DNSSEC and other standardized DNS security responses, including large responses, EDNS0 signaling, and unknown RRs. - SIP (Session Initiation Protocol, RFC 3261) is a text-based application protocol that allows two endpoints in the Internet to discover one another in order to exchange context information about a session they would like to share. Common applications for SIP include Internet telephony, instant messaging, video, Internet gaming, and other forms of real-time communications. SIP is a multi-service protocol capable of initiating sessions involving different forms of real-time communications simultaneously.
- SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions such as Internet telephony calls. SIP can also invite participants to already existing sessions such as multicast conferences. SIP transparently supports name mapping and redirection services, which supports personal mobility—users can maintain a single externally visible identifier regardless of their network location.
- SIP supports five facets of establishing and terminating multimedia communications:
- 1. User Location: Determination of the end system to be used for communication;
- 2. User Availability: Determination of the willingness of the called party to engage in communications;
- 3. User capabilities: Determination of the media and media parameters to be used;
- 4. Session Setup: “Ringing”, Establishment of session parameters at both called and calling party;
- 5. Session Management: Including transfer and termination of sessions, modifying session parameters, and invoking services.
- SIP was developed by the IETF as part of the Internet Multimedia Conferencing Architecture, and was designed to dovetail with other Internet protocols such as Transmission Control Protocol (TCP), Transmission Layer Security (TLS), User Datagram Protocol (UDP), Internet Protocol (IP), Domain Name System (DNS), and others. SIP works with both IPv4 and IPv6.
- SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. SIP uses most of the header fields, encoding rules, and status codes of HTTP. This provides a readable text-based format for displaying information. SIP incorporates the use of Session Description Protocol (SDP), which defines session content using a set of types similar to those used in Multipurpose Internet Mail Extensions (MIME). Technically, SIP will function across both IPv4 and IPv6 networks.
- SIP can provide a set of services that is more diverse, compelling and profitable than any of the contemporary wireless protocols including WAP, SMS and MMS. SIP allows the development of services that can blend voice, presence, the Web, instant messaging, unified messaging and many others. Carriers who deploy SIP-based infrastructure will be able to offer more differentiated and profitable services than their counterparts, which will correspondingly allow them to realize higher revenues, higher profits and lower chum.
- The present invention, in a preferred embodiment provides for using some of the SIP-network infrastructure that mobile operators will have in place to deliver credentials from SIP-based Wireless Credential Manager (WCM)110 at an issuer site to a SIP-based wallet application on a
wireless device 200. The system disclosed herein is designed to interoperate with mobile 2.5G, 3G, and Wi-Fi networks among others. - It will be understood that the components shown in
FIG. 1 are merely exemplary of one embodiment of the present invention and the invention is not necessarily limited thereto. - Turning now to
FIG. 3 , a discussion of the present invention in the context of SIP and related functionality is now provided. As stated above, although the present invention is disclosed in the context of SIP, other protocols and related components may be used while still remaining within the scope and spirit of the present invention. FIG. 3 illustrates some of the SIP components, their relationship to one another and the protocols that are employed. A user agent acting as a client (in this case theissuer WCM 410 which is in communication with issuer card management system420) uses SIP to set up a session with a user agent that acts as a server (in this case a wallet application operating on user's wireless device400). The session initiation dialogue uses SIP and involves one or more proxy servers to forward requests and responses between the two user agents. The user agents also make use of the SDP, which is used to describe the media session.- The
proxy servers 450 may also act as redirect servers as needed. If redirection is done, theproxy server 450 needs to consult thelocation service database 460, which may or may not be colocated with theproxy server 450. The Domain Name System (DNS)470 is also an important part of SIP operation. Typically, a user agent client (UAC) makes a request using the domain name of the user agent server (UAS), rather than an IP address.Proxy server 450 thus needs to consultDNS server 470 to find aproxy server 450 for the target domain. - SIP often runs on top of the User Datagram Protocol (UDP) for performance reasons, and provides its own reliability mechanisms, but may also use TCP. If a secure, encrypted transport mechanism is desired, SIP messages may alternatively be carried over the Transport Layer Security (TLS) protocol.
- Associated with SIP is the SDP, defined in RFC 2327. SIP is used to invite one or more participants to a session, while the SDP-encoded body of the SIP message contains information about what media encodings (for example, voice, video) the parties can and will use. After this information is exchanged and acknowledged, all participants are aware of the participants' IP addresses, available transmission capacity, and media type. Then, data transmission begins, using an appropriate transport protocol. Typically, the RTP is used. Throughout the session, participants can make changes to session parameters, such as new media types or new parties to the session, using SIP messages.
- The Session Description Protocol (SDP), defined in RFC 2327, describes the content of sessions, including telephony, Internet radio, and multimedia applications. SDP includes information about:
- Media streams: A session can include multiple streams of differing content. SDP currently defines audio, video, data, control, and application as stream types, similar to the MIME types used for Internet mail.
Addresses: SDP indicates the destination addresses, which may be a multicast address, for a media stream.
Ports: For each stream, the UDP port numbers for sending and receiving are specified.
Payload types: For each media stream type in use (for example, telephony), the payload type indicates the media formats that can be used during the session.
Start and stop times: These apply to broadcast sessions, for example, a television or radio program. The start, stop, and repeat times of the session are indicated.
Originator: For broadcast sessions, the originator is specified, with contact information. This may be useful if a receiver encounters technical difficulties. - Although SDP provides the capability to describe multimedia content, it lacks the mechanisms by which two parties agree on the parameters to be used. RFC 3264 remedies this lack by defining a simple offer/answer model, by which two parties exchange SDP messages to reach agreement on the nature of the multimedia content to be transmitted.
- A resource within a SIP configuration is identified by a URI. Examples of communications resources include the following:
- A user of an online service
- An appearance on a multiline phone
- A mailbox on a messaging system
- A telephone number at a gateway service
- A group (such as “sales” or “help desk”) in an organization
- SIP URIs have a format based on e-mail address formats, namely user@domain. There are two common schemes. An ordinary SIP URI is of the form: sip:bob@biloxi.com. The URI may also include a password, port number, and related parameters. If secure transmission is required, “sip:” is replaced by “sips:”. In the latter case, SIP messages are transported over TLS.
- Now that a general description of the methodology and components of the present invention has been provided, the following discussion provides examples of the use of the SIP protocol for issuing, canceling and updating credentials on a wireless device according to the teachings of the present invention.
- The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established.
FIG. 4 shows a typical example of a SIP message exchange between a credential issuer (named herein Sample Bank) and a fictitious mobile user named Bob. (Each message is labeled with the letter “F” and a number for reference by the text.) In this example, SIP signaling functionality embedded in the Wireless Credential Manager (WCM)510 is used to issue Bob a Sample Bank MasterCard on his SIP-enabledmobile device 500 via the Internet. Also shown are two SIP proxy servers that act on behalf of Sample Bank and Bob's mobile operator (MobileCo) to facilitate session establishment. This typical arrangement is often referred to as the “SIP trapezoid” as shown by the geometric shape of the dotted lines inFIG. 4 .WCM 510 may initiate communication with a wallet application on Bob'swireless device 500 through a SIP proxy server on MobileCo's network that also handles voice, instant messaging, and other services.WCM 510 initiates a “call” to Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. URIs are defined in Section 19.1 of RFC 3261. The URI corresponding to Bob's wallet application was obtained from the NAPTR record that resulted from the ENUM query performed byWCM 510 on Bob's mobile phone number. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sips:bob@wallet.mobileco.com, where mobileco.com is the domain of Bob's SIP service provider. TheSample Bank WCM 510 has a SIP URI of sips:wcm.samplebank.com.- A call made to a ‘SIPS’ URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee.
- As previously mentioned, SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. In this example, the transaction begins with
WCM 510 sending an INVITE request addressed to Bob's SIPS URI. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, the WCM address, and information about the type of session thatWCM 510 wishes to establish with Bob. The INVITE (message F1 inFIG. 4 ) might look like this: INVITE sips:bob@wallet.mobileco.com SIP/2.0 Via: SIP/2.0/TLS wcm.samplebank.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob Smith <sips:bob@wallet.mobileco.com> From: Samplebank <sips:WCM.samplebank.com>;tag=1928301774 Call-ID: a84b4c76e66710@WCM.samplebank.com CSeq: 314159 INVITE Contact: <sips:wcm.samplebank.com> Content-Type: application/sdp Content-Length: 142 [0143] (Sample Bank's SDP not shown) - The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below:
- Via contains the address (wcm.samplebank.com) at which Sample Bank's Wireless Credential Manager is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction.
- To contains a display name (Bob Smith) and a SIP or SIPS URI (sips:bob@wallet.mobileco.com) towards which the request was originally directed. Display names are described in RFC 2822.
- From also contains a display name (Sample Bank) and a SIP or SIPS URI (sips:wcm.samplebank.com) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the
Sample Bank WCM 510. It is used for identification purposes. - Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the WCM host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between the
WCM 510 and Bob and is referred to as a dialog. - CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.
- Contact contains a SIP or SIPS URI that represents a direct route to contact the
WCM 510, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests. - Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.
- Content-Type contains a description of the message body (not shown).
- Content-Length contains an octet (byte) count of the message body.
- The complete set of SIP header fields is defined in Section 20 of RFC 3261. The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327. This SDP message (not shown in the example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message.
- Since
WCM 510 does not know the location of Bob or the SIP server in the mobileco.com domain,WCM 510 sends the INVITE to the SIP server that serves Sample Bank's domain, samplebank.com. The address of the Sample Bank SIP server (sip.samplebank.com) could have been configured inWCM 510, or it could have been discovered by DHCP, for example. It should be noted that for illustrative purposes the SIP proxy functionality was shown as a being a separate server fromWCM 510; in reality the proxy functionality is a part ofWCM 510. The proxy component ofWCM 510 is an important aspect of this system and the overall methodology. - The Sample Bank SIP server520 (sip.samplebank.com) is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requester. In this example, the
proxy server 520 receives the INVITE request and sends a100 (Trying) response back toSample Bank WCM 510. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on behalf ofWCM 510 to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allowsWCM 510 to correlate this response to the sent INVITE. - The
sip.samplebank.com proxy server 520 locates the proxy server “wallet.mobileco.com”530 quite easily as this implementation assumes that the use of a subdomain such as “wallet” is a standard by whichWCM 510 can identify a proxy server within the operator's network. In other instances where a subdomain may not be part of the URI that is retrieved from the NAPTR record, the SampleBank proxy server 520 can identify a proxy server within the operator's network possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the mobileco.com domain. This is described in RFC 3263. Either way, it obtains the IP address of thewallet.mobileco.com proxy server 530 and forwards, or proxies, the INVITE request there. - Before forwarding the request, the
sip.samplebank.com proxy server 520 adds an additional Via header field value that contains its own address (the INVITE already contains the WCM address in the first Via). Thewallet.mobileco.com proxy server 530 receives the INVITE and responds with a 100 (Trying) response back to thesip.samplebank.com proxy server 520 to indicate that it has received the INVITE and is processing the request. The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. Thewallet.mobileco.com proxy server 530 adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP enabledmobile phone 500 with the wallet application. - The wallet application on Bob's
SIP phone 500 receives the INVITE. The INVITE message received by the wallet application prompts the application to alert Bob of the incoming communication from Sample Bank. The alert mechanism used by the wallet application could use the wireless device's internal capability such as generating a tone or vibrating. In addition to the tone or vibration, the device display may give Bob additional details of the incoming communication from Sample Bank so that Bob can decide whether to accept connectivity with Sample Bank's server for the purpose of receiving the Sample Bank MasterCard credential. Bob'sSIP phone 500 indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE. - In the next example, the 180 (Ringing) response is routed to the
Sample Bank WCM 510. In this example, Bob decides to allow connectivity with theSample Bank server 510 by pressing a key on his phone (as prompted for by the wallet application). After he presses the appropriate key to accept connectivity with Sample Bank'sserver 510, hisSIP phone 500 sends a 200 (OK) response to indicate that the call has been answered by the wallet application. The 200 (OK) contains a message body with the SDP media description of the type of session that the wallet application running on Bob'sSIP phone 500 is willing to establish with theSample Bank WCM 510. As a result, there is a two-phase exchange of SDP messages: theWCM 510 sent one to Bob's wallet application, and the wallet application sent one back to theWCM 510. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If Bob did not wish to answer the communication from Sample Bank or was busy on a phone call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established between the wallet application on Bob'sphone 500 and theSample Bank WCM 510. The complete list of SIP response codes is in Section 21 of RFC 3261. The 200 (OK) (message F9 inFIG. 4 ) might look like this as Bob's wallet application sends it out: SIP/2.0 200 OK Via: SIP/2.0/TLS wallet.mobileco.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/TLS sip.samplebank.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/TLS wcm.samplebank.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob Smith <sips:bob@wallet.mobileco.com>;tag=a6c85cf From: Samplebank <sips:wcm.samplebank.com>;tag=1928301774 Call-ID: a84b4c76e66710@wcm.samplebank.com CSeq: 314159 INVITE Contact: <sips:bob@ 192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) - The first line of the response contains the response code (200) and the reason phrase (OK). The remaining lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. (There are three Via header field values—one added by the
Sample Bank WCM 510, one added by thesip.samplebank.com proxy 520, and one added by the wallet.mobileco.com proxy520). Bob'sSIP phone 500 has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future requests and responses in this communication. The Contact header field contains a URI at which Bob can be directly reached at hisSIP phone 500. The Content-Type and Content-Length refer to the message body (not shown) that contains Bob's SDP media information. - In addition to DNS and location service lookups shown in this example, proxy servers can make flexible “routing decisions” to decide where to send a request. In this case, the 200 (OK) is routed back through the two proxies and is received by the
WCM 510, which then stops the ringback tone and indicates that the “call” has been answered. Finally, theWCM 510 sends an acknowledgement message, ACK, to the wallet application on Bob'sSIP phone 500 to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from theWCM 510 to the wallet application on Bob'sSIP phone 500, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details on session setup are in Section 13 of RFC 3261. - The use of a SIP architecture to locate a mobile end-user and to establish direct communication between the end-points (WCM and wallet application) for the purpose of transferring confidential information (e.g. credentials) is an important aspect of the present invention. The direct connection between the end-points using SIP offers a secure method, without intermediary servers, by which to transmit confidential information.
- The media session between the
Sample Bank WCM 510 and the wallet application on Bob's SIP enabledmobile phone 500 has now begun, and they can send data packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end data packets take a different path from the SIP signaling messages. - The established session may initially be used to exchange encryption keys and/or other security information. Subsequent to that, the issuer's system will authenticate the mobile user's identity in real-time to ensure that the person on the receiving end is in fact the person that requested the digital credential. The authentication process can be accomplished by the issuer system prompting the user for some cardholder or accountholder authentication information contained within its system, that only the rightful accountholder would have. The user would see such a request for information within the wallet application screen on the device display. This could include a request for such information such as an existing card account number, card expiration date, cardholder name, mother's maiden name, billing address, social security number, account balance, transaction history, driver's license number, or business identification. The issuer could also request a special code or PIN that was mailed to the user in advance of the issuance as a means to further validate identity and ensure non-repudiation. Some of the input information individually, or a combination of certain input information could be used as a decryption key for a credential that is transmitted to the wireless device. Subsequent to the issuer's system validating the user's identity in real-time, the
WCM 510 will transmit the credential to the wallet application. - During the peer-to-peer session, either the
WCM 510 or the wallet application on Bob'sphone 500 may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re-INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail—the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14 of RFC 3261. - At the end of the communication session (in this example), Bob's wallet application disconnects (hangs up) first and generates a BYE message. This BYE is routed directly to the
WCM 510, again bypassing the proxies. TheWCM 510 confirms receipt of the BYE with a200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent—an ACK is only sent in response to a response to an INVITE request. The reasons for this special handling for INVITE relate to the reliability mechanisms in SIP, the length of time it can take for a “ringing” application to be answered, and forking. For this reason, request handling in SIP is often classified as either INVITE or non-INVITE, referring to all other methods besides INVITE. Full details on session termination are in Section 15 of RFC 3261. While the above example shows the wallet application terminating the session first, during actual implementation, theWCM 510 may terminate the session first. - In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the
sip.samplebank.com proxy server 520 wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record-Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob'sSIP phone 500 and (due to the Record-Route header field being passed back in the 200 (OK)) theWCM 510 and stored for the duration of the dialog. The sip.samplebank.com proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently decide to receive subsequent messages, and those messages will pass through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features. While it is not preferred to use any mid-session features for the purpose of issuing, canceling, or updating credentials, there could be reasons for using it which are not discussed herein. - SIP offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS URI, sips:bob@wallet.mobileco.com, for example, to an associated IP address of the registering wireless device, 192.0.2.4, for example. Ultimately, a proxy will consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing. According to the present invention, a unique URI may be used to represent a wallet application functioning on a wireless device or server, and it may be mapped it to an IP address in a location service.
- Registration is one way that the wallet.mobileco.com server can learn Bob's current location. Upon initialization, and at periodic intervals, the wallet application on Bob's SIP phone sends REGISTER messages to a server in the mobileco.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sips:bob@wallet.mobileco.com) with the network address currently assigned to his wireless device (conveyed as a SIP or SIPS URI in the Contact header field). While it is stated that the wallet application is performing the registration, a SIP enabled phone (with multiple SIP applications running on it) may register itself and all active SIP applications at once with the registration server. In this example, a unique URI is associated with the wallet application; during actual implementation, the same URI could be used for multiple applications on the same device.
- The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the wallet.mobileco.com proxy. Often, a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical.
- The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations are one way to create this information, but not the only way. Arbitrary mapping functions can be configured at the discretion of the administrator.
- Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and has no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either on a request-by-request basis with a challenge/response mechanism, or by using a lower layer scheme as discussed in Section 26 of RFC 3261. The use of authorization and authentication schemes between the wallet application and the mobile operator's SIP proxy is an important part of the present invention.
- The complete set of SIP message details for this registration example is in Section 24.1 of RFC 3261. Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, are addressed in RFC 3261.
- An illustration of the overall registration process is given in
FIG. 5 . Note that theregistrar 610 andproxy server 630 are logical roles that can be played by a single device in a network; for purposes of clarity the two are separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements. - SIP does not mandate a particular mechanism for implementing the
location service 620. The only requirement is that a registrar for some domain MUST be able to read and write data to thelocation service 620, and proxy or aredirect server 630 for that domain MUST be capable of reading that same data.Registrar 610 MAY be co-located with a particularSIP proxy server 630 for the same domain. As noted earlier, in some cases the SIP-enabled wireless device may register itself, thus enabling communication with all SIP-based applications operating on the device. - REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of-record. The SIP compliant wallet application running on the wireless device is capable of handling such REGISTER requests. If a SIP-based wallet application has a unique URI associated with it, and the application is subsequently deleted by the user from the device, the application will remove its own binding as discussed above prior to the deletion.
- Presence is a vital aspect of SIP technology. Presence is the notion that the current state of an entity, particularly its communications state, can be exposed and represented in a standardized, sharable way. Entities so represented need not be human or singular. For example a device status, user status, or application status might be captured as a Presence Status (for example “Device Status=Off-Hook”, “User Status=Online”, or “Application Status=Not Loaded”). Starting with a simple definition of “Online/Offline” status, Presence Status has been extended to include other context information around the status such as disposition (out-to-lunch, away-from the-computer) and activity status (on the phone, idle, etc.).
- SIP presence and availability build on the SIP event notification mechanism (RFC 3265) and on the registrar and other servers. Scripts can be set up at the server to route calls based on inspection of the INVITE message. A presence server uses SIP SUBSCRIBE/NOTIFY with a presence event package to gather a User Agent's presence status and send responses to a watcher interested in the presence status of a specific entity.
- The next example makes use of the SUBSCRIBE method from RFC 3265 that can be used by a user agent to establish a subscription for the purpose of receiving notifications (via the NOTIFY method) about a particular event. Suppose that in the preceding example, the Sample Bank WCM was informed that Bob's device was off-line. The Sample Bank WCM can then issue a SUBSCRIBE message, indicating that it wants to be informed when Bob is available.
- This request is forwarded through the two proxies in our example to a Presence Server. In this example, we assume that the Presence Server logic is co-located with the location service. The Presence Server authorizes subscription by returning an OK message, which is passed back to the WCM. The Presence Server then immediately sends a NOTIFY message with Bob's current status of not signed in, which the Sample Bank WCM acknowledges.
- Continuing with the example, at some point in the future, Bob's wireless device signs on by sending a REGISTER message to the proxy in its domain. The proxy updates the database in the location service to reflect registration. The update is confirmed to the proxy, which confirms the registration back to Bob's wireless device. With Bob's new status recorded in the location service, the Presence Service could send a NOTIFY message containing Bob's new status to the Sample Bank WCM. The Sample Bank WCM acknowledges receipt of the notification and can in turn re-try to initiate communication with the wireless application on Bob's wireless device.
- The present invention also contemplates a SUBSCRIBE functionality that is compliant with RFC 3265 as well as support for the SUBSCRIBE functionality in a Presence Server to NOTIFY the WCM of a change in status of a wireless device with a wallet application. The SUBSCRIBE functionality is an important feature of the invention since wireless devices may not always be connected to a network and be reachable. This feature allows the WCM to be notified when a wallet application on an end-user device can be re-contacted in order to initiate a peer-to-peer connection for transferring confidential information.
- Another unique aspect of the present invention is the use of an Application Status in conjunction with a Presence Service. Application Status could be used for, among other things, to inform a “caller” that the receiving party does not have an application to support the incoming request or media type. This Presence Information can be used to “push” an application to the receiving party over-the-air so the “caller” can establish communication with the recipient in the future. Continuing with the example above, if the Application Status was returned to the Presence Service as “Not Loaded”, the mobile operator's Presence Service could initiate a request to a separate server that sends a message to the wireless end-user's handset, asking him if he would like to download the wallet application in order to receive credentials from different issuers such as the one that tried to communicate with his wireless device. If the user agrees, the application can be provisioned on the user's device over-the-air. Once installed, the application can inform the Presence Service of its new status to allow it to inform the Sample Bank WCM that it is ready to communicate. The use of an Application Status in conjunction with a Presence Service and an over-the-air software provisioning system for wireless and wireline devices are important aspects of the present invention. The WCM, the wallet application, and other SIP systems described herein may also support presence as a capability using various SIP extensions such as the SIP Instant Messaging and Presence Leveraging Extensions (SIMPLE).
- In order to discover a Registrar, the SIP-based wallet application running on the mobile phone is pre-configured with the appropriate registrar address. The mobile operator will have the ability to change the registrar address over-the-air. In cases where there is a SIP application stack installed on the wireless device, the registrar address may be configured in there.
- The following discussion covers security mechanisms and procedures which may be used in a preferred embodiment of the system of the present invention. Since the SIP message structure is a straight derivation from the HTTP request/response model, all security mechanisms available for HTTP (RFC 2617) can also be applied to SIP sessions. The use of MIME containers within SIP messages supports the use of email security mechanisms S/MIME (RFC 2633). And of course similar to a https: URI, a corresponding sips: URI will try to build up a secure transport layer tunnel using TLS (RFC 2246). And last but not least IP security (IPsec) (RFC 2315) can be used as a general purpose mechanism to encrypt all IP based communication right on the network layer.
- The major security mechanisms suited for the protection of a SIP session are summarized here. Some or all of these security mechanisms can be used to securely deliver or manage credentials on a wireless device. Support for these mechanisms may be accomplished in the WCM or the wallet application or both. Implementations may support other security schemes as well.
- One possible mechanism is HTTP Digest Authentication. The Digest authentication scheme is based on a simple challenge-response paradigm. The digest authentication scheme challenges the remote end using a nonce value. SIP digest authentication is based on the digest authentication defined in RFC 2617. Here, a valid response contains a checksum (by default, the MD5 checksum) of the user name, the password, the given nonce value, the HTTP method, and the requested URI. In this way, the password is never sent in the clear.
- Another possible security mechanism is Secure MIME (S/MIME). SIP messages carry MIME bodies. MIME itself defines mechanisms for the integrity protection and the encryption of the MIME contents. SIP may utilize S/MIME to enable mechanisms like public key distribution, authentication and integrity protection, or confidentiality of SIP signaling data. S/MIME may be considered as a replacement for PGP used in RFC2543 to provide means for integrity protection and encryption of SIP messages. To be able to protect SIP header fields as well, tunneling of SIP messages in MIME bodies is specified. Generally the proposed SIP tunneling for SIP header protection will create additional overhead. S/MIME requires certificates and private keys to be used, whereas the certificates may be issued by a trusted third party or may be self-generated. The latter case may not provide real user authentication but may be used to provide a limited form of message integrity protection.
- The current document RFC 3261 recommends S/MIME to be used for UAs. Moreover, if S/MIME is used to tunnel messages (described below) it is recommend using a TCP connection because of the larger messages. This is to avoid problems that may arise by the fragmentation of UDP packets. The following services can be realized:
- Authentication and Integrity Protection of Signaling Data
- Confidentiality of Signaling Data
- Yet another security mechanism which may be used in accordance with the present invention is based upon SIPS URI (TLS). RFC3261 mandates the use of TLS for proxies, redirect servers, and registrars to protect SIP signaling. Using TLS for UAs is recommended. TLS is able to protect SIP signaling messages against loss of integrity, confidentiality and against replay. It provides integrated key-management with mutual authentication and secure key distribution. TLS is applicable hop-by-hop between UAs/proxies or between proxies. The drawback of TLS in SIP scenarios is the requirement of a reliable transport stack (TCP-based SIP signaling). TLS cannot be applied to UDP-based SIP signaling.
- Another security mechanism which may be used in connection with the present invention is IP Security (IPsec). IPsec may also be used to provide security for SIP signaling at the network layer. This type of security is most suited to securing SIP hosts in a SIP VPN scenario (SIP user agents/proxies) or between administrative SIP domains. IPsec works for all UDP, TCP and SCTP based SIP signaling. IPsec may be used to provide authentication, integrity and confidentiality for the transmitted data and supports end-to-end as well as hop-by-hop scenarios. At this time there is no default cipher suite for IPsec defined in SIP. Note: RFC 3261 does not describe a framework for the use of IPsec. Especially, no information is given as to how the key management is to be realized, or which IPsec header and mode is to be used.
- In order to provide security implementation (see RFC 3261), various requirements exist. It is intended that the proxy servers and registrars will support TLS, and both mutual and one-way authentication. It is also intended that the WCM and the wallet application will be capable initiating TLS. Proxy servers, redirect servers, and registrars may use a site certificate whose subject corresponds to their canonical hostname. UAs may have certificates of their own for mutual authentication with TLS. All SIP elements that support TLS should have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). Further, all SIP elements that support TLS should support the SIPS URI scheme.
- Proxy servers, redirect servers, registrars, and UAs may implement IPSec or other lower-layer security protocols. When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC should initiate a TLS connection over which it will send SIP messages. In some architectures, UASs may receive requests over such TLS connections as well.
- Proxy servers, redirect servers, registrars, and UAs should implement Digest Authorization, encompassing all of the aspects required in Section 22 of RFC 3261. Proxy servers, redirect servers, and registrars should be configured with at least one Digest realm, and at least one “realm” string supported by a given server should correspond to the server's hostname or domain name.
- The WCM and the wallet application should support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23 of RFC 3261. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it should be capable of reusing these to verify S/MIME certificates, as appropriate. A UA may hold root certificates specifically for validating S/MIME certificates.
- Note that is it anticipated that future security extensions may upgrade the normative strength associated with S/MIME as S/MIME implementations appear and the problem space becomes better understood.
- SIP supports the encryption of both message bodies and message headers. The encryption of message bodies makes it more difficult for an eavesdropper to listen in. Also, an uninvited third party, knowing all the Session Description Protocol (SDP) information could guess the real-time transport protocol synchronization source (RTP SSRC) number and send unwanted media to either party, practicing so called “media spamming.” Encryption of headers can hide the parties involved in the session. In addition to that, actual session stream can be encrypted as negotiated by SIP.
- Depending on the situation, SIP messages between the WCM and the wallet application on the wireless device can carry any supported content types in its payload (e.g. WML, HTML, XHTML, gif, text and others). SIP payload content could include encryption keys, encryption algorithms, forms, user authentication information (e.g. usernames, passwords, PINs, and answers to secret questions), software extensions the issuer wants to register with the wallet application, software updates, electronic credentials, updates to existing credentials, graphics that are part of the credentials, and other such information.
- Java applets can be transported as SIP payload, and Java applets running in a mobile phone can use SIP based services in communications. A simple use case would be distributing the wallet application, checking availability for operator support (if downloaded elsewhere), setting up the application, and communicating with credential issuers using SIP. The credentials in turn can be transported using SIP.
- Wireless Credential Manager (WCM)
- Various details of the
WCM 110 of the present invention, in a preferred embodiment thereof, are now presented. The Wireless Credential Manager (WCM)110 is a carrier-grade platform for real-time electronic credential issuance, management, and authentication. It is ideal for financial institutions, government agencies, and other organizations who wish to securely deliver electronic credentials to a wireless device with an associated E.164 phone number, URI, or other type of Internet-routable address. - Application Engine
- The application engine provides access to service logic through a CGI, Servlet, or proprietary interface. The service logic is free to access business logic and databases using, for example, Corba, SOAP, JDBC, or Socket.
- The application engine is the core of
WCM 110. The application engine is responsible for receiving files and commands from the issuer's user management system, interpreting the information, and acting on it through a variety of functions it has in its library and under its control. For example, the application engine can use the ENUM engine (integrated in the WCM110) to query DNS servers in order to map a E.164 phone number to network addresses. An integrated DNS resolver can be used for ENUM queries and also to resolve SIP URIs to network addresses. - The application engine can also function as a user agent client (UAC) and a user agent server (UAS) for SIP communication. The UAC initiates requests while the UAS generates responses. As such, the application engine will be capable of operating as both a UAC and a UAS during a session with end-user wallet applications. Further more, the application engine is capable of handling multiple simultaneous sessions with different SIP devices.
- The application engine is capable of maintaining state on calls that it initiates or participates in. A minimum call state set includes the local and remote tags, Call-ID, local and remote CSeq header fields, along with the route set and any state information necessary for the media. This information is used to store the dialog information and for reliability. The remote CSeq storage is necessary to distinguish between a re-INVITE and a re-transmission. The application engine UA preferably supports UDP, TCP, TLS, and SCTP transport. The application engine UA also preferably supports SDP (IETF 2327) for media description. Other types of media description protocols can be used in the body and interpreted by the application engine, but SDP support is required per RFC 3261.
- The application engine also interfaces with a SIP proxy that is integrated in
WCM 110. The SIP proxy may run on the same physical server or separate servers, for load balancing or other reasons. Details of other key components of the WCM under the control of the application engine are outlined below. - ENUM Engine
- The ENUM engine in
WCM 110 is a standards compliant resolution tool developed based on RFC 3761. ENUM (RFC 3761) is the Internet Engineering Task Force (IETF) standard that defines a mechanism for using the Domain Name Service (DNS) as a tool to “discover” services associated with a telephone number (E.164 number). WCM 110 automatically processes NAPTR record(s) in DNS wire format into application service, order, preference, and URI fields.WCM 110 correctly parses the NAPTR service fields and dynamically interprets POSIX Extended Regular Expressions. Additionally,WCM 110 provides the DNS message processing and network transport mechanisms required to translate a telephone number into a set of ENUM records. Support is provided for the following feature set:- 1. Standard ENUM query—returns all of the ENUM records associated with a given telephone number. The WCM's Application Engine is capable of filtering the results based on application protocol and/or service type.
- 2. Server-side Extensions—returns subset of the ENUM records associated with a given telephone number based on optional query directives that enable the ENUM service to filter results based on both application protocol and/or service type.
- 3. POSIX Extended Regular Expressions—matches and substitutes any valid POSIX Extended Regular Expression within the NAPTR record regular expression field.
- 4. Public/Private Dialing Plans—supports both public and private dialing plans by selectively querying alternate root ENUM domains.
- 5. Multiple Attempts—retries a query N times.
- 6. Recursion—provides DNS recursion from
WCM 110, eliminating the need for a recursive local DNS server when querying multi-tiered DNS systems. - 7. Security—supports Secret Key Transaction Authentication (TSIG).
- 8. Thread Safe—supports a multi-threaded environment
- 9. UDP/TCP transport—supports both UDP and TCP connections to allow for efficient retrieval of large sets of DNS records.
- 10. Larger UDP payload—support for large UDP response payload beyond the default 512 bytes. [RFC 2671]
- 11. Network Latency Based Server Selection—determines the best performing ENUM/DNS server based on query response time.
- 12. Caching—caches records for a period of time specified by the Time-To-Live (TTL) field defined for the resource record.
- Preferably,
WCM 110 provides DNS resolution and update capabilities for the following resource records: A, NS, SRV, NAPTR, SOA, PTR, MX, CNAME, TXT, and HINFO. The following pseudo resource records are also supported: TSIG, OPT, SOA. - RFC 3761 highly recommends the use of DNS security. The WCM ENUM infrastructure supports DNSSEC to address a variety of security issues including impersonation, data tampering and unauthorized access/farming. The use of TSIG enables transaction level authentication using shared secrets. TSIG is lightweight and may be used for authentication on DNS queries. Support for TSIG functionality is built into
WCM 110. - Use of the TSIG DNS resource record is specified in RFC 2845. TSIG was developed as a lightweight alternative to using public key encryption technology for DNS authentication. The main function of using TSIG is to establish a trust relationship between two entities using a shared secret key. The TSIG resource record is dynamically generated per ENUM transaction and is contained in the additional data section of the DNS message. TSIG records are never cached. All of the DNSSEC functionality required to implement TSIG with any ENUM system is implemented in
WCM 110. The process of utilizing TSIG in an ENUM transaction is though the use of a SIP proxy. - Integrated into
WCM 110 is a SIP proxy that interfaces directly with the application engine, which is responsible for setting up or terminating sessions with end-user wallet applications. The SIP proxy sits in the middle of a SIP message exchange, receiving messages and forwarding them. There may be multiple proxies in a signaling path. The proxy server is not really “in the call.” The WCM SIP proxy facilitates the two end-points locating and contacting each other. The SIP proxy can be configured to remain in the signaling path or drop out of the signaling path as soon as communication between two end-points is established. The SIP proxy is also able to use the DNS resolver withinWCM 110. - Support for Call Processing Language is supported within
WCM 110. CPL is a standard scripting language defined by the IETF that described how to process inbound and outbound requests. The CPL language is protocol-neutral and has a language binding for SIP. It is designed to be a simple and safe mechanism suitable for executing user-defined scripts. The SIP proxy is usually separated from CPL interpreter and application logic. Since CPL is a standard, any application can generate CPL and a compliant proxy should understand it WCM 110 preferably provides an easy-to-use GUI to manage server clusters and servlet applications. It supports SNMPv2c for ease of integration with external Operations Support Systems (OSS).WCM 110 provides a comprehensive logging service that enables credential issuers to quickly collect fault and performance data.- The WCM logging service also permits issuers to create, encode, and export communication records (CDRs) with end-user wallet applications for export into user management systems and visibility by issuer customer care departments.
WCM 110 supports flexible configuration of CDR extensions, file transfer options, and file naming. WCM 110 preferably supports the secure transfer of individual encryption keys (obtained from end-user wallet applications during communication) to other user management databases or LDAP servers within the issuer environment. These encryption keys can be called upon byWCM 110 for future communication with a particular end-user's wallet application.WCM 110 supports authentication, authorization, and accounting of SIP sessions in accordance to RFC 3702. WCM Service Creation Environment (SCE) is comprised of a software developer kit (SDK) coupled with the standards-based, JSR 116-compliant SIP Servlet API. The SIP Servlet API is the interface between the applications and the SIP container, which supports the SIP server roles needed and interfaces with the SIP stack- When an incoming SIP message arrives in the SIP container, it uses so-called Servlet Mapping Rules to decide which application(s) need to be invoked. These Servlet Mapping Rules are defined in XML and describe criteria to be met by the SIP message. The applications interact with the SIP server functionality via the SIP Servlet API.
- The WCM SDK provides a preloaded set of SIP application building blocks (ABB) that allow issuers/operators to configure
WCM 110 to interact with the wallet application for credential management including: i) issuance, cancellation, status change and update; (ii) real-time user authentication during transaction authorization; and (iii) remote wallet - The WCM SDK also includes non-SIP application building block connectors (ABB-Cs) that dramatically reduce the effort and knowledge needed to build SIP-based applications within the
WCM 110. - In addition to the security protocols supported above, the
WCM 110 preferably supports MD5 digest authentication to prevent passwords from being sent across the network in clear text. WCM 110 supports a number of flexible APIs that allows forWCM 110 to communicate with different issuer systems in real-time or batch mode. The APIs support a number of standard command sets recognized by the application engine. Standard APIs and command sets included with theWCM 110 are for:- Interface to credit card management systems
- Interface to debit card management systems
- Interface to ATM card management system
- Interface to retailer loyalty card
- Interface to retailer membership systems
- Interface to corporate security access control systems
- APIs and application logic can be customized using the WCM service creation environment (SCE) discussed earlier. API frameworks supported within the WCM utilize: SOAP/XML, .NET and CORBA.
WCM 110 also supports peer-to-peer data integration interfaces to middleware designed for assured delivery, high-volume and secure data exchange. Such middleware interfaces supported include, for example, Sterling Commerce's Connect:Direct. Such an interface to Connect:Direct could be used for receiving the Personalization File from an issuer's card management system and sending systems logs, CDRs, and other confidential information to other issuer systems. - To ensure that a message sent to the system is from a valid source and has not been tampered with,
WCM 110 supports message authentication (using the ANSI X9.9 and X9.19 standards for authentication of financial transactions) and Secure Sockets Layer (SSL) encryption - A discussion of the architecture of
WCM 110 in a preferred embodiment now follows.WCM 110 is designed with a customized, load-balanced, distributed architecture without single points of failure. Incoming/Outbound SIP-based service requests are load balanced across service hosts by service directors.WCM 110 operates in clustered configurations using off-the-shelf server platforms based on Intel x86 and SUN SPARC architectures. It supports carrier grade Linux (CGL), Sun Solaris, and Microsoft Windows 2000 Advanced Server Operating systems.WCM 110 can also be run on AlphaServer systems running Tru64 Unix and Himalaya High End series running NSK - Technically, SIP will function across both IPv4 and IPv6 networks. As such,
WCM 110 is preferably compatible with IPv4 and IPv6 networks.WCM 110 also supports the following transport protocols: UDP/TCP/TLS/SCTP.WCM 110 also supports multiple domain names. All aspects ofWCM 110 are compliant with IETF RFC 3261, 3GPP, and 3GPP2 standards. Embedded inWCM 110 is a compliant SIP application stack that the different components ofWCM 110 are built upon. Cryptographic functions supported include: - PIN, MAC and Data encryption keys
- Multiple index for all cryptographic keys
- Single, double or triple length of all encryption
- Single or Triple DES encryption/decryption
- Dynamic key exchange
- Key thresholds and threshold limits
- In a preferred embodiment of the present invention a SIP-capable firewall is also included. Some issuers may choose to use the built in firewall capability, while others may have a stand-alone SIP-capable firewall they are using. There are several possible approaches to SIP-capable firewalls. One of the difficulties is that, unlike for, say, HTTP, connections are originated both by hosts inside and outside the firewall. A likely arrangement is that the SIP proxy sits “on” the firewall and relays SIP requests between the Internet and the intranet. This proxy would also open up the necessary ports in the firewall to let data to flow through, for example, using Socks V5.
- As an alternative, if a firewall or network address translator (NAT) allows outgoing TCP connections, the inside client can open up a TCP connection to an outside proxy. All outgoing and incoming calls would then be handled by that TCP connection. (The client would still have to use SOCKS or a similar mechanism to convince the firewall to let packets through.)
- The following discussion provides information about the Mobile Operator Architecture according to a preferred embodiment of the present invention. The ENUM Provisioner is an application for mobile operators (or other entities) to update ENUM address information in any compatible DNS server that supports dynamic DNS update. The ENUM Provisioner application can be interfaced with a mobile operator's user management system or LDAP server to accept qualified updates to the ENUM database.
- The ENUM Update interface supports the following functionality:
- Add Records—add 1 or more resource records.
- Delete Records—delete 1 or more resource records.
- Multiple Operations—perform multiple add and/or delete operations in a single request.
- Security—Optional TSIG authentication.
- Thread Safe—can be used in a multi-threaded environment.
- The ENUM Provisioner interface uses Dynamic DNS (DDNS) protocol [RFC2163] to request updates to an ENUM/DNS service. Update requests typically use TCP connections to communicate with the ENUM service.
- The ENUM Provisioner can be used to add NAPTR records to the ENUM database for user's that have enrolled in the mobile wallet service and activated their wallet on the phone. The Provisioner can also be used to add NAPTR records in the ENUM database corresponding to other services associated with E.164 phone number (e.g. voice, instant messenger, etc). The mobile operator's existing user management system can enforce rules for validating users, activating services, billing, and other functions. Other components of a Mobile Operator's SIP Infrastructure may also include
- Proxy Servers
- Registration Server
- Location Server
- Presence Server
- Wallet Software Download or Over-the-Air Provisioning Server (Allows wireless device to download the wallet application OTA
- LDAP server/user management system
- Wallet Application
- The following discussion provides additional details concerning the wallet application of the present invention in a preferred embodiment thereof. The wallet application is a platform capable of securely holding a myriad of different electronic credentials and making them available in a controlled way through specific functions. When loaded on a wireless device, an icon for the wallet application is designed to appear on the main navigation screen. The icon can be used to launch the application.
- The open-architecture of the wallet platform allows credential issuers to deploy their own commerce-specific applications called “extensions”. Extensions literally “extend” the capability of the wallet platform by enabling a new set of features defined by the credential issuer. Different credentials serve many unique purposes and are not all used in the same way.
- For example, when a subway contactless stored value card is waved in front of a reader at the turnstile, the electronic balance is automatically debited from the onboard chip. The rules that govern the functioning of that stored value program and the card's interaction with an external RF reader, are all programmed into the onboard chip.
- In the case of a magnetic-stripe credit card, the card is swiped in a POS terminal and magnetically encoded information on
tracks - A final example is a grocery store loyalty card with a bar coded account number. At the POS, a cashier scans the bar code and the decoded account number is validated against a loyalty database and then used to apply discounts against the patron's purchase.
- These are just a few examples of the types of credentials that can be issued to and stored within the wallet application. Implementing electronic versions of these credentials in the wallet application creates different operating and processing requirements for each credential. Consider the requirements associated with implementing the subway stored value credential through the wallet platform. The logic required to operate the subway stored value credential, the unique message format for communication between the wireless device and a RF reader at the turnstile, unique display messages, an over-the-air reload tool, and other features associated with the stored value credential that a user might see on the wireless device—all need to be programmed into the wallet application. These types of requirements are embodied in mini-programs that operate within the wallet application called “extensions” since they “extend” the capability of the wallet application in order to handle new features and capabilities that are specific to an issuer's credential. These extensions allow credentials to be used in a controlled way through specific issuer-defined functions.
- A software development kit (SDK) and API can be made available to credential issuers and other organizations that want to develop extensions for the wallet platform. Extensions can utilize all the features that the wallet platform makes available to it, including such features as access to the device's secure storage, standard display parameters, standard messaging, data format conversions, SIP communication capability, access to device and operating system functions, and other attributes.
- A wireless device loaded with the wallet application may come with some pre-loaded extensions. Extensions may reside on the device memory, in an embedded smart card, in a removable storage media, or on a remote server, securely accessible through the wallet application protocols. An extension may communicate with the user, may exchange information with remote servers or it may use other elements of the device hardware or software.
- Credit card associations/networks may develop a software extension for the wallet application that governs the interaction between the RFID chip embedded in a wireless device and a reader terminal. A modified version of the “MasterCard Proximity Chip Payment—Online Profile” and the “Visa Specification for Financial Messaging for Contactless Payment” could be embodied in a software extension for the wallet application. The use of such an extension for facilitating credit card transactions using the wallet application is an important part of the present invention. The provisioning of such an extension to a wireless device using a valid E.164 number of URI is also possible. The same extensions could be used by multiple issuing banks.
- The actual account information or personal information that is transmitted by the issuer to the wallet application is referred to as the “credential”. The actual credential record that is transmitted to the wallet application by the issuer may contain some of the following information:
- Name of credential (e.g. United Airlines Mileage Plus Card)
- Name and logo of credential issuer
- Name(s) and logo(s) of association or network(s) (e.g. Visa, MasterCard)
- Account specific information
- Account number
- Expiration date of credential
- Special security information related to credential (e.g. CVV/CVC, CVV2/CVC2, etc)
- “Reader Key” for credential (discussed later in the document)
- Identifier for extension to which the credential is associated (When a credential is selected by a user, this identifier is used to launch an extension in the wallet application)
- Primary and secondary credential categories
- Wallet Shell
- The wallet shell is the core of the wallet platform. The wallet application handles processing of incoming credentials and extensions, the execution of extensions within the wallet framework, controlling access to secure storage, enabling communication with an embedded RF interface or smart card, and facilitating the use of operating system and hardware features such as display and sound.
- All user settings are also controlled by the wallet shell. Features that allow users to delete extensions/credentials, change/reset PINs, and change certain preferences are controlled through the shell.
- The wallet shell also provides extensions with a standard menu-driven user interface from which to operate. The wallet shell also enables secure communication with external servers via SIP and TCP/IP. The wallet shell also has an embedded ENUM resolver for being able to do DNS queries on valid E.164 phone numbers. This embedded ENUM client is useful for facilitating secure person-to-person, person-to-company, or company-to-company transfers of digital money over-the-air using a wallet extension designed for this purpose. Such an extension could use the ENUM resolver built into the wallet shell to locate the URI for a recipient's electronic wallet to where funds are being transferred. The client ENUM resolver will be designed to submit DNS queries on the mobile operator's network; the IP addresses of the DNS server(s) could be pre-programmed in the wallet shell or could be discovered dynamically. A mechanism by which a user could transfer funds to another user by using a valid E.164 number, and establishing a peer-to-peer SIP connection is available through the present invention.
- Wallet Application
- Mobile transactions can be performed in three environments: local, remote, and personal. Each environment has its own mobile commerce services and characteristics that may require specific technologies. A wallet application on a wireless device that enables transactions in all three environments will provide the greatest utility to users. Electronic credentials issued to a user and stored in the wallet application can be used in all three environments.
- Local Environment
- In a local—or proximity—environment, the consumer is in the vicinity of a reader device that is connected to a point-of-sale (POS) terminal or some other type of computer system. Most day-to-day proximity transactions today use a card or token with information encoded in a variety of media types including magnetic stripe, bar code, chip, and embossed or printed data. A mobile device with a wallet application can serve as a replacement for single-purpose cards and tokens. During a proximity transaction, the wireless device can transmit payment, identification, or other confidential information to a reader using the short-range transmission capability of the wireless device (e.g. RF). For example, a wireless device loaded with a wallet application, that also has an integrated RFID chip can simply be waved slowly in close proximity to a reader device to facilitate a transaction. Similarly, a wireless device that uses infra-red to transact with a reader requires that the user point the infra-red beam to a reader device.
- Personal Environment
- In a personal environment, mobile transactions are conducted on the user interface of another device and augmented by security, connectivity, information, and other functionality provided by the user's wireless device. For example, during a transaction—a point-of-sale device may establish secure connectivity with the user's wireless device and poll it for a list of user-defined payment methods that the user can select from using the user-interface of the POS system. The implication is that the user's wireless device can act as a repository of information that can be securely accessed by another device during a transaction.
- The wallet application will support peer-to-peer connectivity to a device in close proximity. Connectivity between the wireless device and the reader/POS terminal could be made via 802.11a/b/g, Bluetooth, or other RF protocols. Connectivity could initially be established by exchanging encryption keys via RFID that allow the devices to establish connectivity via an alternate channel securely so no other device can listen in to the communication. Keys could also initially be exchanged via infra-red technology.
- One advantage of establishing peer-to-peer connectivity with a POS terminal is that it allows for a bi-directional exchange of data where a user may be prompted on his wireless device for various types of preferences, questions, or other data input in sequence. Transactions where there is a stream of data that goes in both directions can benefit from this type of peer-to-peer session using any number of protocols.
- Another advantage of establishing peer-to-peer connectivity with a POS terminal for example is that the user can use the terminal's display and input mechanism instead of on the wireless device to interact with his electronic wallet. The larger display and input mechanism of the external device may make it easier for the user to make selections. In personal environment transactions, credential data is transmitted from the wireless device to a merchant/organization using the short-range communication protocols mentioned.
- The personal environment capability of the wallet application could also be used to issue credentials to the device while the user is present in an issuer's site. For example, if a user is present in a bank branch and is requesting a digital credential for his mobile wallet, the credential could be issued in the manner described above. For example, if a user wants a digital debit card, the user may be prompted by a bank employee to bring his wireless device in proximity of an RFID reader, which will send a command to the wallet application signifying that it is going to receive a new credential via Bluetooth. The bank system and the wireless device may exchange encryption keys via RF in order to establish a secure Bluetooth connection with the bank network (the process for establishing Bluetooth connectivity is similar to what is outlined later in the Wallet Transfer section).
- Remote Environment
- In a remote—or online—environment, transactions are conducted with a remote server over a wireless network. For example, a remote transaction using a wireless device can be conducted over the Internet with a browser on the wireless device. In such transactions, the wireless device's user interface (UI) is of paramount importance. The UI must relay all relevant information to maintain the user's trust and ensure usability of the services. Remote transactions range from online purchases and banking to more impulsive activities like downloading digital content.
- Wallet Main Menu
- The main menu of the wallet application contains 6 primary modules in a preferred embodiment:
- Credential Selector
- Profile Selector
- Profile Creator
- Digital Receipts
- Log Viewer
- Wallet Settings
- Application Background
- A wireless device running a wallet application as described herein will serve as a replacement for single-purpose cards and tokens that typically fill people's wallets and purses. The wallet application is designed to facilitate transactions in a proximity, personal, and remote environment using the device's short-range or long-range transmission capability.
- The wallet application is specifically designed to store several types of electronic credentials. Electronic credentials are organized in the wallet application using a hierarchical categorization scheme that makes finding credentials visually easy for the end-user. The top level of the hierarchy includes primary categories. The primary categories are broad descriptors of the different types of information that the wallet application can store. Under the primary categories are sub-categories, which provide additional specificity for the types of credentials that can be found there. Sub-categories may not always be present. Credentials can be mapped directly under a primary category or to a sub-category. Sub-categories are particularly useful when a large number of credentials are present under a primary category and need to be organized based on some further classification.
- The wallet application has several primary credential categories that are pre-programmed in the wallet application. These pre-programmed primary headings are listed below with examples of the types of credentials that one might find in each:
- Payment Methods—Credit, debit/ATM, stored value, electronic check, and RFID payment methods may be registered with the wallet application
- Loyalty Cards—Grocery store discount cards, airline frequent flier programs, hotel loyalty programs, and other loyalty programs are included in this category
- Membership Cards—Personal memberships to video rental stores, libraries, and other organizations
- Access Cards—Electronic keys for offices, apartments, parking garages, cars, and other secure facilities
- E-Tickets & Passes—Electronic tickets for sporting events, concerts, shows, transportation, and other purposes may be issued to the wallet application.
- Coupons & Certificates—Electronic coupons and certificates that can be used at specific locations, that typically have a fixed value, and expiration date for usage
- Identification Cards—Driver's license, government identification, school or university ID, and other pieces of identification
- Personal Information—Name, billing address, shipping address, home phone number, business phone number, fax number, social security number, and date of birth. Electronic business cards could also be stored.
- The presence of all the above primary categories to classify different credentials within the wallet application is possible according to the teachings of the present invention. The use of sub-categories under the primary categories is also possible as is the presence of credentials directly under a primary category or under a secondary category.
- Sample sub-categories are represented in the example credential tree below. The credential tree may be used to visually present information in the wallet application.
- Sample Bank MasterCard XXX4321
- CapitalOne Visa XXX1234
- Home Depot Card XXX9865
- Gap Card XXX5432
- Exxon Mobil Card XXX4564
- Sample Bank XXX5432
- Starbucks S-Value XXX9876
- Sample Bank Checking XXX7654
- Speedpass XXX3456
- An issuer of credentials may specify the primary category and secondary category (if applicable) that a particular credential should be linked to in the wallet application's credential tree; this information can be specified in the credential issuance record that is sent by the issuer to the wallet application on the wireless device. Standardized codes or category names may be used in the credential record that allows the wallet application to link newly received credentials to pre-existing categories contained in the credential tree.
- If a credential is received by the wallet application containing a primary and/or secondary category that does not yet exist in the credential tree, the wallet application will add the primary and/or secondary category automatically before linking the credential to it.
- Primary categories in the credential tree can be automatically organized in alphabetic order or based on frequency of usage, with the most used primary categories at the top of the list for easy access. These organization schemes may be user defined options in the wallet application, or may be set a certain way by the application itself. The same organization schemes would also apply to secondary categories and the credentials themselves.
- All primary and secondary categories should appear in the credential tree, regardless of whether there are credentials contained within them. Under this embodiment, primary and secondary categories that have credentials contained within them may be visually distinguished in the device display using any number of methods such as bold text, the use of icons, color coding, or some other visual means. Primary and secondary categories that do not have credentials may in turn be represented using different distinguishing features such as muted text (lightened), the use of icons, separate color coding, or other visual means.
- Under another embodiment of the wallet application, the user may be allowed to create their own credential tree by naming all primary and secondary categories and linking newly received credentials to the categories. Users may have a repository of recommended category names within the wallet application that they can opt to use. Further, under this embodiment, users will also have the ability to rename categories, delete categories, and move credentials from one category to another.
- The credential tree is the primary basis by which credential information is organized in the wallet application. The credential tree represents the entire embodiment of all primary categories, secondary categories, and credentials registered in the wallet application. Certain screens in the wallet application may display the entire credential tree, or only certain components of it as necessary. The credential tree provides a visual hierarchy which is useful for (a) allowing users to make quick selections of specific credentials for use in a transaction (via the “Credential Selector” feature described later), and (b) for managing their credentials and wallet settings in the application.
- The following discussion provides further information regarding the interaction between a wireless device and a reader. If the wallet application UI, and the wireless device itself are overly complex and difficult to use, people will not want to give up their traditional wallet or purse filled with a variety of single-purpose cards and tokens. Completing a time-sensitive transaction such as a grocery store POS purchase or a ticket purchase at the subway turnstile requires a wallet application and device that minimizes the key strokes a user has to make, but at the same time provides for a high degree of user control and security over confidential account information.
- Several features of this invention serve to minimize the key strokes a user has to make in searching for, selecting, and transmitting a credential to a reader. One such feature of this invention is the use of a credential-specific “reader key”. The key is sent with an electronic credential record to a wireless device during the issuance process. The same reader key is programmed in all reader devices employed by an organization. In the case of an RFID reader, the key is transmitted from the reader to the wireless device's RFID chip during a proximity transaction. The receipt of the key by the RFID chip in the wireless device may initiate the automatic launch of the wallet application resident on the device, and the transfer of the key to the application. The key is subsequently received by the wallet application and is used as a search string by the application to locate a specific credential for transmission back to the reader via the device's RF capability.
- The “reader key” is especially useful to organizations that are both issuers of electronic credentials and also acceptors of those credentials. An example would be a grocery chain that has a WCM for issuing electronic loyalty cards to mobile devices, and is also setup to accept those credentials via RFID readers installed at POS terminals in its stores. The grocery chain would program the reader key into all its RF readers so that the key is transmitted during a proximity transaction to the RFID chip embedded in a wireless device. During the issuance process of a digital loyalty card, the grocery chain sends the reader key along with the loyalty credential to an end-user's wireless device. The wallet application stores the “reader key” with the electronic credential to which it is linked. When transmitted to the wireless device from the reader, the key is used by the wallet application as a search string for locating the linked credential. If a matching key is found within the wallet application, the corresponding loyalty information will be transmitted to the reader from the wireless device via RF.
- Employing a reader key in the manner described allows a reader device to automatically capture specific credential information from a wireless device without the end-user having to scroll through different screens within the wallet application and pressing multiple buttons on his device. The sequence of events outlined above should occur in less than a second, in order to minimize the amount of time a user has to hold his wireless device in proximity to the RF reader.
- The key that is injected into the reader may be encrypted prior to injection. As such, an encrypted key could be transmitted from the reader to the wireless device, and decrypted by the wallet application on the wireless device using a decryption key that was previously sent by the credential issuer during issuance or through some other process. The reader key can be any length, be in any format (e.g. plain-text, ASCII, binary, etc.), and employ any type of encryption algorithm. The key may also be included as part of a “handshake” message and/or “challenge” message (associated with challenge/response technology that is frequently used with RFID) transmitted from the reader to the wireless device. They key could also be transmitted before or immediately after a “handshake” and/or “challenge” message.
- It should be noted, that readers will be capable of storing and transmitting multiple “reader keys” that can be used to poll wireless devices for different credentials during a single transaction. The wallet application in turn will be capable of receiving and processing multiple incoming reader keys. Keeping with the grocery chain example above, communication between the POS reader and the wireless device might involve sending two separate keys; one key that requests a loyalty card, and a second key that requests valid coupons or certificates stored on the wireless device. As discussed, multiple keys may be used to poll for separate credentials in a wallet application.
- The loyalty credential and the coupons can be retrieved automatically (without requiring the user to pre-select these credentials for transmission) since the key for each of these items would be mapped to the credentials in the wallet application. It should be noted that if the wallet application receives two keys from the reader, but only one of the corresponding credentials exists in the wallet, only that credential would be transmitted to the reader.
- The reader may transmit multiple keys as part of the same message to the wireless device, or each key could be sent in separate messages sequentially. The same applies for transmission of multiple credentials from the wireless device to the reader. While a large number of keys could in theory be transmitted from the reader to the wireless device, a very large number of keys will likely increase the amount of time it takes to make the initial transmission, for the wallet application to search for multiple credentials, and for the credentials to be transmitted to the reader. The use of a large number of keys may simply require the user to hold the wireless device in front of the reader for a longer period of time while the processing that was described above takes place.
- An organization that is issuing multiple types of credentials, may also choose to use the same “reader key” for each credential type it issues. During the issuance process, an issuer can simply send the same reader key with different credentials it is issuing via the WCM. The wallet application in turn will map the same key to multiple credential records stored within. If that particular key is received by a wireless device during a transaction, the wallet application will identify all the credentials linked to it, and will proceed to send them all to the reader as separate consecutive records or one message containing all records.
- “Reader keys” also need not be organization-specific. The same key could be embedded in readers used by multiple organizations to poll for the specific credentials. In such cases, the “reader key” may be securely shared amongst organizations to facilitate the injection of the key into reader devices. During a transaction, a credential being transmitted from the wireless device to the reader could be sent along with the same key that was initially transmitted by the reader to the device; this could be done as a way for the reader and related computer systems (e.g. POS equipment) to identify the type of credential (e.g. loyalty card versus coupons).
- The credentials transmitted from the wireless device to the reader may be encrypted using the issuer's encryption key (that may have been provided during the issuance process or through other means). The encrypted credentials could in turn be decrypted by the reader itself, within a central host system, or by other systems employed by the acceptor of the credentials.
- Certain payment methods such as subway stored value cards may be organization specific and be the only payment method accepted; as such, a subway operator may employ reader keys to facilitate a rapid payment system with wireless devices.
- In a preferred embodiment, a successful transmission of credentials from the wireless device to a reader would result in a tone being sounded by the device. A separate, but distinguishable tone may also be used to signal an unsuccessful transmission of credential data from the wireless device to the reader that may require the user to again place the device in front of the reader for a re-transmission attempt of the same credential. The wallet application will use the wireless device's integrated hardware and software capability to generate such tones.
- A successful transmission of credentials from the wireless device to a reader may also result in a visual acknowledgement on the device display. The wallet application message will confirm the successful transfer of specific credentials to a reader device; the actual credentials that were transferred will be listed in the message to inform the user of what confidential information was transmitted. The user can close the acknowledgement message by pressing a wallet application designated button such as “OK”, or doing nothing while the message times-out and is automatically closed. A set time-out period will be programmed into the application. If the message times-out, the device will return to its normal state.
- Data in the wallet application is encrypted and protected with a special wallet PIN code which is set by the wireless device owner during the setup of the application. The PIN is used to authenticate the user to the application. PIN-entry is required to access stored credentials and change any application settings or preferences. PINs can be any length, and be comprised of any combination of upper or lower case letters, numbers, and special characters as provided for by the wireless device itself. While this document references the use of PIN codes throughout, wireless device's with embedded biometric technologies could use a fingerprint in lieu of a PIN code to authenticate a user to the wallet application. The default security setting in the wallet application is that PIN-entry is required before the wallet application can be “opened” and any credentials transmitted to an external device.
- A user can at their own discretion, choose to designate certain credentials within the wallet application to be used without requiring entry of the wallet application PIN. Registered credentials that can be designated by the user as not requiring entry of a wallet PIN are those that have a “reader key” associated with them. Credentials with a “reader key” associated with them will be flagged as such in the wallet application to help a user identify them.
- A user may be willing to assume a slight risk by designating certain credentials for PIN-less use since the benefits of speed and convenience are important to them. Rapid payment at the subway turnstile is an example of where the benefits of speed and convenience may outweigh the risks associated with designating a stored value credential on a wireless device for PIN-less use, leaving open the possibility that a fraudster could steal the device and use the stored value purse. Each individual will have their own risk tolerance and as such will want the flexibility to designate specific credentials in their wallet as requiring advance PIN-entry and others to function without the prior input of the wallet PIN.
- Credentials that are marked by users as not requiring PIN-entry will be automatically selected within the wallet application based on the “reader key” that is received, and transmitted to the reader during a proximity transaction (the process is described above). Successful transmission of credentials to a reader in a PIN-less mode are confirmed by the device sounding a tone and displaying a message on its display as previously described.
- The PIN-less option for certain credentials that have a “reader key” associated with them allows users to complete time-sensitive transactions by simply passing their wireless device in front of a reader without any further key entry. As such, a simple “wave” of the device in front of a reader can result in a completed transaction in about a second or less.
- The use of “reader keys” by issuers and acceptors is optional. In the event that reader keys are not employed, the user of the wireless device will be required to pre-select all the credentials he wants to transmit to a reader prior to placing his device in proximity of the reader during a transaction. A “Credential Selector” in the wallet application allows for one credential or multiple credentials to be selected from the credential tree (described earlier) for transmission to a reader device. Users can scroll through the credential tree and select credentials by using the visual navigation system of the wallet application and designated buttons on the wireless device for making selections. The credential tree as it appears in the “Credential Selector” screen may provide visual information about the credentials to aid a user in the selection of specific credentials. Individual credential records may display information such as:
- Name of credential (e.g. United Airline Mileage Plus Card)
- Name and/or logo of credential issuer
- Name(s) and/or logo(s) of association or network(s) (e.g. in the case of bank cards)
- Account number (e.g. could be full account number, partially masked account number, or fully masked account number)
- Indicator showing if the credential has a “reader key” associated with it
- Indicator showing if the credential has been flagged for use without the wallet PIN
- The credential information represented in the “Credential Selector” screen is information that is received from each issuer during the issuance process. A standard record layout for credentials issued via the WCM will allow issuers to customize what information is reflected in the credential tree, and in turn how it is represented in the “credential selector”. Once the user completes making his selection(s) in the “Credential Selector”, the wallet application is ready to transmit the credential(s) via its RFID interface. When the wireless device is placed in proximity to the reader, the selected credential(s) are automatically transmitted by the RFID chip in the wireless device to the reader.
- After confirming a successful transmission involving multiple credentials selected via the Credential Selector tool, the wallet application will ask the user (via a display message) if he wants to create a profile with links to the credentials that were recently used for future use. Creating a profile with the credentials that were used will save the user time during future transactions with the same organization; in the future, the user only has to select the saved profile (in the “Profile Selector”) instead of selecting multiple credentials manually prior to a transaction. Profile names can be customized by the user to help with identification during future transactions. The use of profiles is discussed further in the next section. Under one embodiment, only primary and secondary credential categories that contain credentials will appear in the credential tree that appears in the Credential Selector.
- The wallet application also has a feature whereby a user can create and store different profiles in advance, instead of after a transaction (as described above). The Profile Creator allows a user to link multiple credentials (stored in the wallet application) to a single profile for use at specific organizations that may be frequented. This way a user only needs to select one profile prior to initiating a transaction, and not multiple credentials via the “Credential Selector” tool described earlier. Once a user has selected a profile, the user can place the wireless device in proximity to a reader, and the RF chip in the device will automatically transmit all credentials linked to that profile.
- A profile list within the wallet application will automatically be organized in alphabetic order or based on frequency of usage, with the most used profile at the top of the list for easy access. These organization schemes may be user defined options in the wallet application, or may be set a certain way by the application itself. As example, an individual profile for a grocery chain may contain links to a payment method such as a Visa card, a loyalty card, and electronic coupons. The number of credentials that can be linked to a profile is not limited in any way (other than by storage and other hardware constraints imposed by the device). The wallet application may enforce certain rules for profiles, such as only allowing one payment method to be linked per profile; other rules could include, only allowing one retailer's coupons/certificates to be linked to a single profile, or not allowing any other primary credential type to be linked to a profile that contains an access card. These are only examples of possible rules that may be enforced by the wallet application.
- Because of the sensitive nature of information stored in the wallet application, user's want to ensure that they have complete control over the transmission of information to an external reader such as at a retail point-of-sale. This is especially important for wireless devices that have an embedded RFID chip for short-range transmission. While RFID cards automatically exchange information with a reader when held in close proximity, users require a greater sense of control when using an RFID-enabled wireless device that contains multiple pieces of confidential information.
- One embodiment of this invention involves the incorporation of a single button embedded on the wireless device that can be used to activate the wallet application and to control the transmission of information to an external device via RFID (or some other short-range communication mechanism). A credential with a “reader key” and the PIN-option turned off could be read from a wireless device in someone's pocket by a fraudster carrying a reader that comes in close proximity to the device. As such, the existence of a button in an RFID-enabled wireless device that controls activation of the wallet application and transmission of credentials via RF could eliminate a similar fraud risk. Under one design, when the “wallet button” is pressed and released, the wallet application launches the wallet application and enables communication via the RFID interface in the device; RF communication might be enabled for a period of 30 seconds during which time the device should be placed in proximity of the reader to allow for transmission of a credential that has a “reader key” and is approved for PIN-less transactions. In the event that the device is not placed in proximity of the reader during the 30 seconds, the application will disable RF communication and the application may shutdown or go into its normal dormant state. (The actual time that the RF communication is enabled by pressing the “wallet button” may be shorter or longer than 30 seconds.)
- The “wallet button” may have two functions. In addition to being pressed & released prior to a quick PIN-less transaction as described, the button could also be used as a short-cut for the user to launch the wallet application without using the wireless device's operating system functions used to launch resident applications. To summarize, pressing the “wallet button” and releasing it could enable RF communication for 30 seconds, and also launch the application so the user can interact with it if needed. As such the application is ready to communicate with a reader, and simultaneously prompts the user for his Wallet PIN. If a PIN-less transaction takes place during the 30 second window, the device alerts the user as described earlier through sound/vibration and messaging. Separately, if the user wants to open the wallet application to select credentials or make changes to settings, the user can simply enter his wallet PIN when prompted.
- Under this embodiment, the wallet button may also need to be pressed/released in order to effectuate a transaction that was initiated through the Credential Selector or Profile Selector options previously described. In these cases, the appropriate credential or profile is selected, but the user is prompted to press and release the “wallet button” in order to enable RF communication on the device.
- In the discussion herein, the “wallet button” is pressed and released in order to open a 30 second window whereby RF communication is enabled. As an alternative, RF communication may only be enabled during the period while the button is pressed down; as such, the user would be required to hold the button down while bringing the device in proximity to the reader in order to effectuate the transfer of his credential from the device to the reader via RF.
FIGS. 6( a) and 6(b) are graphical representations showing examples of where a “wallet button” might be situated and how it might appear on the device.FIG. 6( a) shows the “wallet button” on the front side of the device, whileFIG. 6( b) shows the “wallet button” on the side of the wireless device.- In another embodiment of this invention as illustrated in
FIGS. 7( a) and 7(b), three “hot buttons” will appear on the wireless device. The buttons are labeled as follows: - Credit
- Debit/ATM
- QuickWave
- According to this embodiment, a user could use the “Wallet Settings” functionality in the wallet application to link his favorite/preferred credit card to
button 1, and his favorite/preferred debit/ATM card tobutton 2.Button 3, labeled above as “QuickWave”, allows a user to transmit any PIN-less designated credential that has a “reader key” associated with it to a reader during a transaction. - Pressing
buttons - The use of the three “hot buttons” above is intended as a way for a user to quickly transfer certain frequently used credentials to a reader during a transaction. Graphical representations of how the three “hot buttons” may be situated on the wireless device are shown in
FIGS. 7( a) and 7(b). - Pressing
buttons button button 3. - The wallet application-specific buttons as described above can be any size, shape, or color on the front of the mobile device, on the back of the device, or on any side of the device. (The front of the device is typically the side with the display and keypad.) The button or buttons may also have iconic or text representations either on them or next to them in order to signal their function. In cases where there are multiple buttons associated with the wallet application, the buttons may appear on the device close together or be in different parts of the device.
- A discussion of issuer PINs and related security techniques according to various preferred embodiments of the present invention now follows. Certain credential issuers such as financial institutions may require that users validate their identity during a transaction by providing a PIN that was established with or set by the financial institution.
- Presently, with various bank card transactions, PINs are verified either online with a bank host computer system, or verified offline against security data onboard the card as in EMV “chip & PIN” transactions. The present invention supports both of these PIN-verification schemes.
- In the case of offline PINs, an issuer may issue a credential to a wireless device and send a PIN code for that credential to the user via an alternative channel such as e-mail or regular mail in order to ensure non-repudiation. The PIN may serve as a decryption key for the credential itself and may also be required for every transaction with that credential. Since the credential is designated as using an offline PIN, the wallet application will prompt the user for an issuer PIN each time the credential is selected for use. The entered PIN would in turn be verified against security information that was transmitted during the credential issuance process.
- For credentials where an issuer PIN needs to be prompted for on the wireless device for each transaction, the wallet application will only prompt for the issuer PIN when that credential is linked to a “hot button” (as described earlier). As such, the “hot button” functionality can alleviate the need to enter both a “wallet PIN” and an “issuer PIN”, as the issuer PIN is sufficient to validate the user's identity. A financial institution may have specified via settings in the credential issuance record that a temporary PIN assigned by the financial institution be changed to a user designated PIN when it is first received. PIN changes for credentials that have issuer PINs will be handled securely through the wallet application.
- Other financial institutions may send a PIN to the user via an alternative channel in order to allow the user to decrypt and “activate” the credential, but may not require the PIN for use with every transaction; these financial institutions may specify in the credential issuance settings that the wallet PIN must always be prompted for.
- Other credential issuers may issue a credential to a wireless device, require the wallet PIN with every transaction, but also prompt the user for an issuer PIN (or PIN set with the issuer) on the POS terminal during each transaction. The POS terminal may know to prompt for a PIN based on a card BIN number for example.
- As such, some issuers may not require the wallet PIN to be prompted for, since the user will be prompted to enter an issuer PIN on the POS terminal that will be authorized on-line. In cases where such credentials are linked to a “hot button”, the user will not be prompted for a PIN on the device, but will be prompted for an issuer PIN on the POS terminal.
- Another type of PIN verification scheme for credentials stored in the wallet application is unique to the system of the present invention. This on-line verification technique utilizes the over-the-air (OTA) PIN handling and processing capability of the wallet application and the WCM (at the issuer location). The OTA PIN verification scheme is useful for credentials that are authorized online, and require a PIN in order to validate the user's identity. A discussion of this unique aspect of the present invention now follows in connection with
FIG. 8 . The unique aspect of this invention is that the credential information that is transmitted from the wireless device to anRF reader 820 reaches the issuer for an online authorization via one network path (comprised of one or more networks), while the PIN request and response traverse a completely different network path (comprised of one or more networks). The separation of credential data from the actual PIN data over separate networks provides a more secure way to authorize transactions. - As can be seen in
FIG. 8 , a first transmission path of an electronic creditcard authorization request 870 includes, for example, a merchant store controller and merchant host system, an acquirer/processor network, a private network such as VisaNet, and a issuer gateway. Using these components, point ofsale terminal 860, viaRF reader 820 can be used to capture and transmit an electronic credential from a wireless device for online authorization. The second transmission path as shown inFIG. 8 is viaWCM 810 using the Internet andwireless link 880 andissuer DNS server 890 and is used to deliver a PIN request towireless device 800 and to receive a user-input response fromwireless device 800. - An issuer that has deployed
WCM 810 for issuing credentials to wireless devices can also use it for implementing over-the-air PIN verification.WCM 810 can be used to handle over-the-air PIN verification for electronic credentials issued usingWCM 810 and also physical card/token based credentials such as magnetic-stripe cards that require enhanced PIN protection using this method. Either way, the issuer must generally make some modifications to its existing card management system. Specifically, accounts in thecard management system 830 that have OTA PIN verification turned on, are flagged as such. The issuer'scard management system 830 is preferably modified to allow incoming authorization requests associated with a flagged account to undergo additional processing after the underlying account status and other information (e.g. credit limits, velocity rules, etc) have been checked. These checks are performed in connection withvarious processes 850 running in connection with the issuer cardholder system. - Authorization requests associated with accounts that are in good status and are qualified for an “approval” based on issuer defined criteria, will be held until a PIN request is sent to
wireless device 800 and the entered PIN is validated by the issuer's host. - After the issuer's
card management system 830 has validated that the account is in good status and is qualified for “approval”, a PIN request is generated by the system and sent toWCM 810 via a real-time interface along with information relating to the transaction and certain account information. (If the account is not in good status or does not qualify for an “approval”, a denial message would be sent through the network(s) to the origination point.) The PIN request message sent toWCM 810 should include fields such as the name of the organization that originated the authorization request, location ID from where the request originated (e.g. a store address), date/time of authorization request, transaction amount being authorized (or purpose of transaction if a non-financial transaction), transaction ID, last four digits of account number, credential type (e.g. Visa Credit Card), issuer name, and the E.164 mobile phone number retrieved from the credential holder's account (in Application Unique String format as defined earlier). There must be a valid E.164 mobile phone number in the account record in order to enable OTA PIN verification with a credential. WCM 810 receives the PIN request message containing the above information.WCM 810 uses the E.164 number to perform an ENUM query.WCM 810 then retrieves and parses NAPTR records received from the query as previously described herein. The NAPTR record associated with a wallet application or service is selected and used to initiate peer-to-peer SIP communication betweenWCM 810 and the wallet application onwireless device 800 via the Internet and mobile operator'swireless network 880. The incoming message may automatically launch the wallet application or under another embodiment, it may always be running on the device. After exchanging session information, encryption keys, and other pre-requisite messaging required to establish secure, real-time connectivity—WCM 810 will send a standard formatted PIN request to the wallet application that contains information such as the name of the organization that originated the authorization request, location ID from where the request originated (e.g. a store address), date/time of authorization request, transaction amount being authorized (or purpose of transaction if a non-financial transaction), transaction ID, last four digits of account number, credential type (e.g. Visa Credit Card), and issuer name.- The wallet application in turn receives the properly formatted PIN request, and launches a PIN verification screen that displays the information received in the request. The user is prompted on screen to enter his PIN in order to authorize the transaction described. The user can input his PIN as requested using the key input capability of the
wireless device 800. After the user enters his PIN and presses an application-designated button to submit the PIN, the actual PIN or a PIN Offset is transmitted in an encrypted manner toWCM 810.WCM 810 in turn transmits the received information in real-time with the transaction ID to the issuer'scard management system 830 for verification (the transaction ID is sent as a way to match the response with the original authorization request that is pending in the card management system830). Thecard management system 830 validates the PIN or PIN offset and if it matches the information in the account record, a positive authorization response (approval message) is sent back to the point-of-sale through the same path the authorization request was received870. - Upon validating the PIN or PIN Offset, the
card management system 830 may also send an approval confirmation back toWCM 810 using the transaction ID as the only identifier.WCM 810 which is still maintaining its peer-to-peer session with the wallet application will send the approval to thedevice 800, which will result in an approval message and/or tone being generated by the wallet application on the device800 (seeFIG. 9 ). Once the wallet application receives a PIN approval message, the wallet application can terminate the SIP session (under another embodiment, the WCS could instead terminate the SIP session). - In the event that the user initially entered and submitted the wrong PIN, the issuer's
card management system 830 would in turn have sent back an “invalid PIN” message toWCM 810 in order to notify the wallet application onwireless device 800 and request a second PIN entry by the user. The number of allowed PIN attempts would be controlled by the issuercard management system 830. PINs submitted for online verification as described above, are not retained or stored in the memory ofwireless device 800. Credential issuers may allow PINs to be comprised of any combination of upper or lower case letters, numbers, or special characters. - A credential issued to the
wireless device 800 could be labeled by an issuer as using over-the-air, real-time PIN verification so the wallet application is aware of this information. Such a code would allow the wallet application to recognize that such credentials do not require a wallet PIN to be input by the user when linked to a “hot button” and accessed from there. - The use of a real-time PIN-verification system as described has several advantages. One advantage is that PINs can be entered directly into the user's
wireless device 800, alleviating the need for an external terminal that has a PIN-pad. Further, online PIN verification also gives certain credential issuers a stronger means by which to validate a person's identity during a transaction. For example, card-based credentials that are validated today based on a signature match with the signature on the back of the card are open to fraud. PINs offer a better identity validation alternative to signatures, and are in many international jurisdictions considered to be legal electronic signatures. While the above description calls for the use of over-the-air PIN verification, it should be noted that biometrics could also be used in lieu of PINs, while still falling within the scope of the present invention. For example, a user may be prompted to scan his fingerprint using an integrated scanner in thewireless device 800 instead of inputting a PIN as described earlier. - One use of the over-the-air PIN verification is with credit cards. Credit card transactions in North America and many other parts of the world require nothing more than the signature of the card account holder to complete a “card present” transaction. Implementing online PIN verification for credit cards at the POS would be a monumental task today, as it would involve the reprogramming or retrofitting of millions of terminals with PIN pads, costly software development to retailer transaction processing systems, and changes to the way credit card transactions are processed by card acquirers/networks/associations/issuing banks. The over-the-air PIN verification system offers an alternative to the costly retrofitting and reprogramming that would be required to implement PIN verification at the POS, similar to the way online debit cards work today. The over-the-air PIN verification system could be implemented with only the issuer having to make changes to its own systems.
- As an example, assume that Sample Bank deploys a WCM on its network and interfaces it to its credit card management system. Sample Bank could begin offering an innovative credit card product that provides consumers with enhanced protection against fraudulent credit card transactions. The MasterCard credit card product offered by Sample Bank could provide online PIN validation via a registered wireless device on every transaction. Sample Bank could offer the over-the-air PIN verification feature for electronic cards issued to wireless devices, and also for traditional magnetic-stripe cards that typically require a signature. In both cases, the retailer POS would process the credit card transaction as it normally would. The difference is that changes within Sample Bank's card management system will allow the incoming authorization request to perform a PIN validation through the WCM before it sends an approval/denial back through the card network. Credit card issuers like Sample Bank could decide to allow users to opt-in to this feature or the feature can be standard with specific card products.
- Assume that a wireless user has an electronic Sample Bank MasterCard credit card stored in the wallet application that is setup for OTA PIN validation. The user selects the electronic card for use in a proximity transaction at a grocery store, and the credential information is transmitted to a reader via RF as described earlier. The POS at the grocery store will switch the transaction to its central host, which in turn will recognize that this is a MasterCard credit card and switch it to the MasterCard network (either directly or through an acquirer/processor depending on configuration). MasterCard in turn switches the authorization request to Sample Bank which is the card issuer. Sample Bank's gateway receives the authorization request, and passes the transaction to its card management system for approval. The card management system checks the account status using the normal validation process it follows for credit card authorizations. One of the novel aspects of the present invention is that Sample Bank has implemented a new credit card product with OTA PIN verification. As such, a flag in the credit card customer account record signals to the credit card management system that an authorization approval can not be sent back to the retailer POS until an Over-the-Air PIN verification is completed.
- As such, the card management system looks up the card member's registered E.164 phone number for his mobile device. The card management system in turn submits a real-time OTA PIN validation request to the WCM to which it is interfaced. The request contains information such as the name of the grocery store that originated the authorization request, location ID from where the request originated (e.g. a store address), date/time of authorization request, transaction amount being authorized, transaction ID, last four digits of account number, credential type (e.g. MasterCard Credit Card), and issuer name/logo (e.g. Sample Bank MasterCard). The WCM initiates an ENUM query on the E.164 phone number, retrieves and parses the appropriate NAPTR record, and attempts to establish a peer-to-peer session with the wallet application on the wireless device using the URI.
- The wallet application on the wireless device receives the PIN Approval Request and uses the device's internal capability to generate a tone which signals to the user that he should look at the device display. The wallet application displays the PIN Approval Request received from Sample Bank, and prompts the user to enter his PIN in order to approve the transaction.
FIG. 9 is a sample of what a PIN Approval Request that is displayed in the wallet application might look like. - Once the user enters his PIN and presses a button to submit it, the encrypted PIN or some transformed PIN information (derived from the PIN) is transmitted to the WCM, which forwards it to Sample Bank's card management system for validation. If the PIN is valid, the card management system sends an authorization response back to the retailer POS using established processes. The card management system may in turn send an approval message to the WCM for transmission to the user's wallet application (the peer-to-peer session with the user may still be opened for this to take place). Once the user receives the approval message on his wireless device, the WCM may terminate the SIP session.
- One important aspect of OTA PIN validation is that is requires that the wireless device and the wallet application running on it to be in good working order. It also requires that the wireless device have signal coverage to be able to send and receive information via the Internet. In the event that the WCM can not reach the wallet application on the wireless device, and establish communication for PIN validation, the WCM will send a “not available” code back to the issuer card management system in order for it to send a “decline” response back to the retailer's POS system (there are a number of different decline codes an issuer could use here that are standardized by the card associations and payment networks).
- Under another embodiment of this invention, the dual network processing path utilized for transactions involving OTA PIN verification as described above, could be used to prompt a user for certain preference information on his
wireless device 800 during a transaction. For example, Sample Bank may create an innovative payment product (herein called the “Wallet Account”) that links together multiple payment accounts such as a credit account, a debit account, and a stored value account under a single account number. The Wallet Account number could utilize a Visa, MasterCard, American Express, Discover, Diners, or other network/association Bank Identification Number (BIN) range that allows Wallet Account transactions to be authorized by a retailer's POS systems the way credit/debit card transactions are870. When a Wallet Account transaction reaches Sample Bank'sCard Management System 830 for authorization, Sample Bank'ssystem 830 will discern that the account number corresponds to a valid Wallet Account which has a credit, debit, and stored value account linked. Using the user's E.164 number stored in Sample Bank'sCard Management System 830, the Card Management System will send a message to the user'swireless device 800 to request a PIN (as described earlier) and to ask the user to specify his choice of using one of the linked credit, debit, or stored value accounts for completing the transaction. This request for payment preference traverses the same network path as the OTA PIN verification request described earlier, and traverses the Internet andmobile operator network 880. Based on the user's payment preference input intowireless device 800, Sample Bank'sCard Management System 830 can authorize and apply the transaction to the appropriate account. This example illustrates that requests for user preferences or other information during a transaction can traverse a completely different network path (comprised of one or more networks) than the original online authorization via one network path (comprised of one or more networks). Also illustrated is the fact that OTA PIN requests can be coupled with requests for user preferences or other information. - Up to this point, only proximity transactions using a short-range interface such as RFID have been discussed. The wallet application is also equipped to be used for remote transactions with servers connected to the Internet. It is envisioned that payment credentials sent by issuers to the wallet application will have data stored in ECML format to facilitate Internet payments via the wallet application. While the same data may be transmitted via RFID in one format, Internet payments may be made in ECML format.
- ECML stands for Electronic Commerce Modeling Language. It is a specification, developed and maintained by the Internet Engineering Task Force (IETF), that provides a standard set of hierarchically organized, payment-related information fields in an XML syntax that will enable automated software, such as the mobile wallet discussed herein, to supply and query for needed data in a uniform manner.
- Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction. With ECML, this task can be more easily automated. The wallet application, employing ECML can assist in conducting online transactions by storing billing, shipping, payment, preference, and similar information, and by using this information to automatically complete the data sets required by interactions. ECML is an existing Internet standard, already commonly used in online shopping. Thus, Internet merchants can easily adapt their e-business to the mobile context. ECML is a structure, not a protocol. It is security-mechanism independent and can be integrated to other transaction protocols and security elements when available.
- The wallet application may be used for remote payments as follows. First the consumer browses a merchant's online service on the wireless device and selects the items to buy. To pay for the purchases, he selects “wallet payment” and receives a payment request, i.e., a payment data form that must be filled in. When the cursor is in an empty field of the payment request, the consumer can simply press the “wallet button” on the device to launch the wallet application, or the user can launch the application through the operating system. When launched, the user will be prompted to enter his wallet PIN code. The user can then choose the “credential selector” option from the wallet menu. Once the user has selected the payment method he wants to use and clicks “OK”, the wallet application will detect the ECML fields in the open browser and will automatically populate the fields with data from the wallet application. The user is directed back to the browser and can check the information that has been entered into the form before accepting the order.
- In some circumstances the wallet application may require the user to provide a credential specific PIN to complete the transaction. In other cases, the user may be prompted for a PIN during the authorization process with his issuing bank (see OTA PIN verification process above). In yet another case, a merchant may require the consumer to digitally sign the payment; after accepting the order, the consumer may receive a signing request and can sign the payment with his/her personal digital signature PIN. This last option requires a security module (SIM/WIM) in the terminal. The merchant may then send the consumer an acknowledgement and a digital receipt of the successful payment via methods that will be described later.
- The wallet application can also be used to complete web-based transactions made through a personal computer. A computer that has an RFID reader embedded or attached to it through a USB, serial, or some other type of port, could be used to capture payment and other personal information from the wireless device in ECML or other formats in order to populate fields in a form. The process would be similar to what is described above.
- The data stored inside the wireless device is encrypted and protected with the wallet PIN code (or other biometric security information), which is used to allow the user access to the application. Security for remote transactions is provided by the browser on the wireless device itself. A number of server authentication and data encryption protocols may be employed to secure credentials and other confidential information such as Wireless Transport Layer Security (WTLS), Transport Layer Security (TLS), and Secure Socket Layer (SSL). Wireless Identity Module (WIM) could be used for digital signatures enabling authenticated payments. With server authentication and digital signatures, mobile transactions are even more secure than transactions on the fixed-line Internet.
- The wallet application is capable of receiving digital receipts from merchants. Digital receipts are electronic equivalents of paper receipts. They work as the payer's record of a payment transaction that has taken place during a proximity, personal, or remote transaction using the wallet application. Similar to a paper receipt, they contain information such as the transaction amount, date/time of the transaction, merchant name, payment method used, and sometimes details of what was purchased. The receipt functionality makes it possible to have a record of the payment before a physical receipt can be delivered, or in cases where a physical receipt is not used at all.
- The receipt support in the wallet application will follow the MeT receipts specification. The MeT specification is a mobile optimized strict subset of the Association for Retail Technology Standards (ARTS). The MeT receipts specification can be found at: http://www.mobiletransaction.org/
- The wallet receipt functionality makes it possible for the merchant in a mobile electronic transaction to send a receipt to the wallet application via a number of methods. The wallet application supports receipts by listing “application/vnd.met.receipt” as a supported MIME type. The MIME type is used both in identifying an incoming receipt data object and in publicizing the support for receipt data type in certain message headers (e.g. HTTP, SIP, SMTP, etc). The received receipts are stored, if the user selects to store them, in the wallet application. The wallet application protects the user's privacy by requiring a PIN code to be entered before the receipts can be accessed through the wallet application's main menu. The Receipt menu option provides a central point for the user to access the receipt data.
- Receipts from a merchant can be sent to the user's wallet application on the wireless device via several methods as discussed herein. Under one design, the user's E.164 phone number for the wireless device is transmitted to the merchant with the credential information during an RF transaction. The wallet application would have the ability to learn the E.164 phone number of the device on which it operates through the device's operating system, or directly from the SIM card which may contain certain device settings and attributes like the E.164 number. A phone number field would be specified in the credential transmission record that is transmitted from the wireless device to the POS reader (or to a server in the case of a remote transaction). Under this embodiment, the merchant's system receives the E.164 phone number of the device that initiated the transaction. The merchant could use the number in conjunction with a WCM deployed at the merchant's site to issue digital receipts to the wallet application. The merchant would have a WCM setup to interface with its central transaction processing system. The retailer's transaction processing system would temporarily hold the E.164 number received with the credential during an authorization request that originated at the POS.
- Assuming the credential in this example is a MasterCard credit card, the retailer transaction processing system would switch the transaction out to MasterCard (directly or through a merchant acquirer) and onto the issuing bank for approval. Assuming an approval comes back from the issuing bank to the retailer transaction processing system, the retailer transaction processing system can issue a receipt request for the transaction to the WCM to which it is interfaced. The receipt request sent to the WCM from the transaction processing system might be sent concurrent to an approval message being sent from the transaction processing system to the POS. The receipt request that the transaction processing system sends to the WCM would include the E.164 number that was temporarily retained, along with specific information about the transaction that would appear on the digital receipt in the display of the wireless device running the wallet application. Once the transaction processing system sends the receipt request to the WCM, the E.164 number that was retained, is purged.
- The WCM will use the E.164 number contained in the receipt request to perform an ENUM query, retrieve the NAPTR record for the user's wallet application/service, and use the appropriate URI to establish peer-to-peer SIP connectivity with the wireless device to deliver the receipt. The use of the “application/vnd.met.receipt” MIME type in the message would allow the SIP stack on the wireless device to know that the message relates to the wallet application. The wallet application in turn will recognize the MIME type and know that the message is a digital receipt. The wallet application will alert the user to the arrival of the message containing the digital receipt by displaying a message on the device display and possibly sounding a tone (or some other sound) using the device's internal functions. The wallet application will register the digital receipt with the Digital Receipts folder. The actual receipt record will be stored in the secure storage memory in the device and can be accessed via the Digital Receipts viewer in the wallet application.
- The reason for using peer-to-peer SIP delivery for transmitting receipts to the wallet application is for the merchant to be able to guarantee and confirm delivery of the receipt. Merchants may be required to ensure that consumers receive a digital receipt in order to comply with laws, payment association regulations, or other types of mandated rules. SIP provides a means by which to ensure that a message was received by the wallet application. Further, the use of a SIP peer-to-peer session provides a higher degree of privacy and security than other messaging protocols that could be used instead.
- Upon successful delivery of a digital receipt to the wallet application, the WCM is notified by the wallet application during the peer-to-peer session that it has received a properly formatted receipt. The WCM can log all receipts and delivery confirmations to a separate server for archiving. The archived data may be used by the retailer to satisfy audit requirements related to its compliance with any laws or rules around receipts.
- In the event that the wireless device is turned off or does not have network coverage at the time the WCM attempts to deliver a digital receipt, the WCM can use the SUBSCRIBE feature of the SIP protocol to be notified when the wireless device is available for communication. The WCM can attempt to deliver the message when it receives notification that the end-user device is available again.
- The description above assumes that there is a standard E.164 phone number field in the transmission record layout. An alternate approach would be to embed the phone number within certain fields part of the credential itself. For example, certain implementations of contactless credit cards today (e.g. MasterCard PayPass) involve the transmission of
track 1 andtrack 2 data from the card chip to the RF reader. Thetrack 1 andtrack 2 data captured from the chip is analogous to data encoded on magnetic-stripe credit cards. What is being proposed here is the incorporation of a E.164 number into one of thetrack - An alternative approach to delivering receipts would be for the retailer to send them using their standard SMTP server. Under this embodiment, the WCM or another system could be used to do an ENUM query on the E.164 number, receive the appropriate NAPTR record, and use the wallet application/service URI (in an e-mail format such as bob@wallet.mobileco.com) to send an SMTP message to the wallet application which would be configured to receive SMTP messages. Under this embodiment, the wallet application would allow for incoming SMTP messages, and would recognize the “application/vnd.met.receipt” MIME type in the message as being a digital receipt. The body of the message would be encoded with the contents of the receipt. The SMTP message would comply with the MeT Receipt XML Schema. The wallet application under this embodiment would also comply with the MeT Receipt specifications. In a personal transaction as discussed before, the receipt could be sent as part of the same peer-to-peer session that was used to initiate and complete the transaction. Electronic receipts could also be sent to wireless devices by the credential issuer instead of the merchant as described as above.
- If a user keys in the wrong wallet PIN code (or incorrect biometric identification if used in lieu of PIN codes) three consecutive times, the wallet application will not function for a period of 10 minutes. If the user forgets his PIN, the wallet can be reset by the user with a general reset code, which will be available in the wallet application user guide or from the mobile operator. The wallet reset function will result in the user losing all credential information, confidential information, and user preferences stored in the wallet application's secure storage area. The user would in turn have to go through a re-issuance process with each credential issuer in order to restore the lost credentials.
- Under one embodiment, the wallet application will require the user to establish a secret question and answer before the application is used for the first time. This will allow the user to reset his wallet PIN, by being given the secret question, and being prompted for the answer to the secret question. Upon successfully answering the secret question, the user will be given the chance to select a new PIN to replace the one that was forgotten.
- Under another embodiment of the invention, after some number incorrect PIN attempts, the wallet is permanently locked, but the information within the wallet is retained. Under this design, the user is presented with two options after the ninth failed PIN attempt. The first option allows the user to completely wipe out the contents of the wallet and select a new PIN code. Under the second option, the user is given the ability to go through an online authentication process with each issuer in order to validate his identity and account information. Once the user has successfully re-validated his identity with each issuer, the wallet application will prompt the user for a new wallet PIN.
- Entering the new wallet PIN will provide the user with access to all the wallet's functionality and credentials that were successfully validated with the issuer. The online access to the issuer's systems for this re-validation process are provided through capability within the wallet application. The wallet application opens up a SIP connection to the issuer's WCM and sends a standard handshake/key exchange message in order to establish secure communication (An Internet address for each issuer's WCM and encryption key may be registered in the wallet application as part of each credential record). The wallet application sends a message alerting the issuer's WCM that the user needs to re-authenticate his identity due to a PIN lockout. The WCM contacts the appropriate issuer system with the information, and the issuer system responds back with a message that requires the user to re-assert his identity by providing some information that only he would know. This request is relayed by the WCM to the wallet application, and may include a request for such information as the user's account number with the issuer, his social security number, date of birth, mother's maiden name, driver's license number, or a variety of other information.
- The user enters the information into the form, and the information is relayed by the wallet application to the issuer's system through the WCM. Once the user's identity has been established with the issuer, the issuer sends a code to wallet application to confirm that the user has re-asserted his identity and that it is ok to re-activate the credential on the device. The wallet application in turn terminates the session with the issuer's WCM. Upon completion of the first validation, the wallet application contacts the next issuer whose credential is stored in the user's wallet. The same process is repeated to re-assert the user's identity. The information that is requested by one issuer to re-assert an identity will likely be different than others as each issuer has different security measures in place, and different methods by which to validate a person's identity.
- Once the user has re-asserted his identity with the final issuer, the wallet application will prompt him for a new PIN code. The wallet will prompt for dual entry to ensure proper input. Once the user logs in with the newly selected PIN, the user will see all the credentials for which he re-asserted his identity online directly with each issuer. Any credentials where the user was not able to re-assert his identity with the issuer will be deleted from the wallet storage. Once the user logs in with his new PIN, certain wallet settings will also be unlocked and restored to their former position.
- The wallet application may have a feature whereby it automatically polls a server managed by a mobile operator, software developer, or other party for upgrades to the wallet application. The application may need to be upgraded from time-to-time to support new features or implement new security measures. The wallet application will in turn poll a server connected to the Internet at an interval that may be pre-defined in the application. If the software finds an upgrade, the wallet application will notify the user, and ask the user if he wants to complete the upgrade. If the user says “OK”, the application will proceed to download the software and initiate the upgrade on the wireless device. All credentials, confidential information, and settings will be saved and be available in the upgraded version. The upgrade process, may use digital certificates to authenticate servers from where software is being downloaded, and also to verify the authenticity of the software itself.
- Credential issuers will have the ability to remotely cancel credentials, re-issue credentials, or manage credentials in other ways on a wireless device. During the initial issuance process, credential issuers will send a unique “credential issuer key” along with the credential they are issuing to the wallet application. This key is unique to every credential that the issuer sends out. During the issuance process, the key is stored in the wallet application's secure storage area with the credential itself. The key must be contained in the first message of any communication with the wallet application. In another embodiment, the key is contained in every message from the issuer to the wallet application. The presence of the credential issuer key in the initial message sent from the issuer to the wallet application allows the wallet application to recognize that the message is authentic and from one particular issuer.
- As such, the credential issuer can use the key to connect to a wallet application and make certain changes to the credential it previously issued. It should be noted that the “credential issuer key” only gives the issuer access to managing the credential that it issued and no other organization's credential and no other settings on the wireless device. Any initial message from an issuer that does not contain a credential issuer key that matches a key stored in the wallet application, will not result in communication being established between the two end-points.
- The issuer can use the key to make changes to a credential in the wallet application. Examples of changes could include, a change to the credential's expiration date, a change in the credentials account number, or a change in the account holder name associated with the credential. In such cases, the issuer can connect to the wallet application with a valid key, make the appropriate changes to the stored credential, and then prompt the wallet application to display a notification message on the device display of the change that was made (a tone may also sound from the device to alert the user of the change). Under another embodiment, the issuer may connect to the wallet application with a valid key, a notification message will appear stating what change the issuer will perform to a credential, the user will be prompted to approve the change, and the change will only be made once the user provides his consent; after the change has been completed, a confirmation message will be displayed in the wallet application.
- Under certain circumstances, the credential issuer can also use the key to initiate communication with the wallet application and make changes without the user's knowledge (no display messages or tones being generated). This feature is especially useful if a wireless device is lost/stolen and the owner of the device wants to have a credential deleted. Under such a scenario, the user might call the issuer or go on the issuer's web site to report his wallet device as being lost/stolen. Upon receiving the request, the issuer would send a message with the credential issuer key to its WCM in order to establish communication with the wallet application for the purpose of deleting the credential. If the wireless device is turned on and has network coverage, the issuer could connect to it through the WCM and issue a lost/stolen command to have the credential deleted. The wallet application on the user's device could delete the credential without alerting a fraudster through display messages or tones being generated.
- If a user's wallet device is lost/stolen, notifying each credential issuer individually may be a long and tedious process for the user. As such, the wallet application may also have a feature whereby a mobile operator will be able to connect to the wallet application and issue a command to purge all its contents.
- During the setup process of the wallet application, a mobile operator will issue a unique “mobile operator key” to each wallet application device. The key is stored in the wallet application, and is used by the operator to reset the wallet application remotely in the event that the device is lost/stolen, and to manage other wallet settings like (SIP proxy server addresses, DNS server addresses, etc).
- A user who has recently lost his wallet device could contact the operator via phone or log in to the operator's web site to notify the operator online. The operator would authenticate the identity of the user by asking him a series of questions on the phone or on the operator's web site. Once the user's identity is confirmed, the user can provide his consent to have the operator delete the contents of the wallet application remotely.
- The operator, using a WCM would connect to the device using the “mobile operator key”, and issue a command to purge all contents of the wallet application. This can be accomplished without a fraudster knowing that the operator has connected to the device and has issued a command to purge all confidential wallet data and has locked the application. In order for the operator to connect to the device and issue the purge command, the device needs to be turned on and must have signal to the wireless network. In the event that the device is not reachable by the mobile operator's WCM, the operator can use the SUBSCRIBE function in the SIP protocol in order to be notified when the device is network accessible.
- The “mobile operator key” can only be used by the mobile operator to issue a purge command to the wallet application, and manage specific settings in the application that relate to how the application interacts with the operator's network and SIP infrastructure. The key does give the operator access to any credentials or other confidential data stored in the application.
- There may be instances where a user wants to change wireless devices, and requires the ability to transfer his wallet credentials and contents from his current device to a new device. The user may accomplish this using a feature in the wallet application that allows stored credentials and other confidential information to be securely transmitted to another wireless device using the short-range transmission capability of both devices (e.g. Bluetooth, infra-red, etc).
- The user would first login to his existing wallet application using his PIN or biometric ID. From the settings menu, the user would choose the “secure wallet transfer” option. The user might be given the ability to select which short-range transmission capability to use for communication with the new device (in case the device supports different types). For this example, we will assume that the user selects Bluetooth. The wallet application on the existing device will display a randomly generated 20 digit key that the user will be required to enter in the wallet application on the new device in order to authenticate the existing device and wallet. The user will be required to perform the following steps before peer-to-peer communication can be established between the two devices:
- 1. The user turns on the new wireless device (which is pre-loaded with the latest version of the wallet application).
- 2. The wallet application is launched. As the user has never used the wallet application on the new wireless device, launching the wallet application will ask the user if he is wants to setup a new wallet, or is transferring a wallet from another device.
- 3. The user selects that he is transferring a wallet from another device.
- 4. The user is asked to enter the 20 digit key that is currently displayed on his existing wireless device (from where the credentials will be transferred). The user inputs the 20 digit key exactly the way it appears on the existing device display. Upon submitting the key, the new device displays a message stating that it is ready to connect via Bluetooth.
- 5. On the existing wireless device, the user is asked to press a designated key as soon as the new device is ready for communication. The user presses the designated key, which enables its Bluetooth interface. It is assumed that Bluetooth security is implemented by the wallet application using
preset security mode 3 with authentication and encryption. - 6. The existing device is now prepared to discover the new Bluetooth enabled device.
- 7. The existing device performs a Bluetooth inquiry and gets a response from the new wireless device.
- 8. As part of the Link Manager Protocol (LMP) channel set-up, the existing device demands authentication of the new device.
- 9. The new device detects that it does not have any previous link key with the new device.
- 10. The Bluetooth pairing is requested.
- 11. The existing device prompts the new device for the passkey that was input by the user.
- 12. The passkey is sent from the new device to the existing device and is validated.
- 13. A key exchange is performed between the new device and the existing device. A link key is derived that is shared between the existing device and the new device.
- 14. The new link key between the existing device and the new device is stored in nonvolatile memory in both devices.
- 15. The existing device authenticates the new device.
- 16. The new device authenticates the existing device.
- 17. The existing device and the new device perform an encryption key exchange.
- 18. The LMP set-up is now complete. The existing device and the new device encrypt all data they exchange from now on.
- 19. The wallet application on the devices automatically switch the devices out of pairing mode so they no longer accept any new inquiries or pairing requests.
- 20. At this point, both wallet applications will not allow any external connections while the two devices are communicating.
- 21. The user will be prompted on the new device for the wallet PIN associated with the existing device. Once the correct PIN has been entered, the contents of the wallet on the existing device will begin transferring to the new device.
- 22. The wallet application on both devices will show a visual representation of the data transfer occurring from the existing device to the new device. The picture will show the existing device on the left and the new device on the right of the screen, and a repeating animation of an arrow moving from the existing device to the new device. The arrow represents the data movement. A dynamic bar at the bottom of the screen will show the percentage completion of the data transfer.
- 23. In the event that the transfer is interrupted for any reason, the process must be started from the beginning (no data will be retained on the new device in the event of an interruption).
- 24. Upon completion of the data transfer, the new device will acknowledge with the existing device that all data has been transferred.
- 25. The existing device will purge all credentials and data stored in the wallet application, will notify the new device of the purge, and will reset the application.
- 26. The new device will be notified on screen that data on the old device was purged.
- 27. The reset of the wallet application on the old device will terminate the bluetooth session. All encryption keys related to the bluetooth session will be discarded.
- 28. The user will now be able to log into the wallet on the new device with his existing PIN.
- The transferred credentials can not be used until the wallet application sends a transfer notification to each credential issuer and receives an acknowledgment back. After the transfer of information between the devices is completed, a notification is automatically sent to each credential issuer with specific information related to the new device to which the credentials were transferred. These notifications must be sent before the credentials can be used. The notification to the credential issuer could contain, for example, the new device's Media Access Control (MAC) address, a unique code assigned to most forms of networking hardware. The address is permanently assigned to the hardware, so credential issuers may use the MAC address as a way to confirm that future communication from a specific user's wallet application is originating from a registered device. Credential issuers in this case would retain the MAC address for the wallet device in its user database, and validate the MAC address contained in future communications from the wallet application against the address stored in its database for that user. Communications with incorrect MAC addresses will be rejected by the issuer's system. Other information that could be sent as part of a notification message from the wallet application to the credential issuer includes a new E.164 phone number (if the new device has a newly assigned number) and a new randomly generated encryption key for each credential issuer (used by credential issuers to encrypt information being sent to the wallet application—could be one key for all issuers or unique keys for each issuer depending on the design).
- Credential issuers may also want to re-authenticate the user's identity in order to allow a credential to be activated on the new device; this may involve the issuer's system establishing a peer-to-peer SIP session (via the WCM) to prompt the user for specific information that only he knows. The user in turn would be required to input the requested information into the wallet application interface in order to authenticate themselves and have the credentials re-activated. The credential issuer may also use the peer-to-peer session to re-issue any encryption keys that were issued to the last device.
- The wallet application has two logging features that can be accessed through the wallet main menu “Log Viewer” option. First, the wallet application will log all transactions made in proximity, personal, or remote mode. The log will display information such as date/time, name of retailer/organization, location ID, list of credentials used in the transaction, and purchase price (if transaction had a financial component). The purpose of this log is to allow a user to see what credential and personal information was shared with a third-party. User's need to be able to verify sometimes what personal information may have been shared during a specific transaction. This viewer allows the user to go back and view up to 6 months of transactions. In the case of financial transactions, the log entries will also have links to digital receipts (which are stored separately in the wallet application). Digital Receipts will be linked to log entries based on date/time stamp and credential matches (other criteria could also be used—for example, under one embodiment, the device generates a unique transaction ID which is transmitted with the credential to the merchant during each transaction. This ID could be contained in the digital receipt, and used by the wallet application to link the digital receipt with the log entries).
- The second logging feature registers all credential changes in the wallet application. This feature logs all new credentials, changes to credentials, and credential cancellations. Up to 1 year of data could be retained. The purpose of this log is to give users the ability to go back and see when credentials were first issued and when issuers made other changes. This log captures, date/time, credential, and description of activity/change made by issuer. The log viewer will allow the user to sort log entries based on any of the column headers.
- Under one embodiment of the present invention, the secure storage of the wallet application resides on a remote network-connected storage device managed by the mobile operator or a “wallet service provider”. Based on this design, the wallet application registers an external wallet storage service as an “extension” within the wallet application on the wireless device. The external storage may be a standard application extension that is automatically registered when the application is first launched and setup by the user. The external storage is used to store credentials, personal information, and some wallet settings. The external storage performs two basic functions: storage and retrieval of information registered in the user's wallet application.
- The wallet application may have a pre-programmed address of a secure and trusted storage server. During the wallet application setup process, the application may contact the storage server to create a profile. The mobile operator or service provider may request some personal information to authenticate the identity of the user in order to create a storage profile for the user's wallet. During the storage setup process, the storage server will establish a valid username/password for the wallet application to automatically access the storage area; the username and password may be system generated or could be user defined during the storage profile setup.
- The wallet application and storage service will exchange encryption keys for secure communication. The communication keys are used to encrypt all messages between the wallet application and the storage server. New communication keys can be dynamically generated for each communication session, or the same keys can be used for a set period of time before they are automatically changed.
- Credentials will be issued to the wireless device in the manner previously described in this document with only a slight modification to where the credentials actually get stored. When an issuer's WCM opens a peer-to-peer SIP connection with the wallet application on the wireless device, the wallet application will have an open connection maintained to the secure storage service. Any credentials that are issued to the wireless device will be transparently transmitted to the storage service where they will reside. The connection between the wallet application and the storage service could utilize an application protocol such as HTTP, SIP, or others. Any data transmitted to the storage service will be registered with the wallet application first; the registration of credentials, personal information, and other confidential data within the wallet application allows the wallet application to display headers for information in storage without having to retrieve it online; the registration process also allows the wallet application to call specific data from storage based on the assigned registration ID for the data object in storage.
- Under this embodiment, whenever the wallet application is launched on the device and a user logs in with his valid PIN, a real-time connection is initiated between the wallet application and the storage service. The wallet application automatically authenticates itself and gains access to the stored credentials. The user is then free to use the wallet menu to select stored credentials or profiles to facilitate a transaction. The Credential Selector and Profile Selector screens will show credentials and profiles in storage; if a user selects an appropriate credential for use, the credential information is securely transmitted to the wireless device and temporarily made available for use by the device's RFID interface. No credential data or settings are retained in memory of the wireless device after a transaction is completed. Under this embodiment, even electronic receipts, logs, and other information registered with the wallet application are stored in the external storage service, and made available for use by the wireless device.
- Under another embodiment of this invention, information stored in the external storage service is not registered with the wallet application. Under this design, headers describing the stored information, and the information itself—are retrieved in real-time from the storage device.
- The following discussion provides details concerning the architecture of the IETF, 3GPP, and 3GPP2-compliant SIP wallet application that is intended to function on a wireless device. As opposed to the situation in 2G networks, in 3G and in traditional IP networks it will be very unlikely that wireless terminal vendors will invent and implement all key applications. Operators and third-party developers are keener than ever to provide their own customized applications.
- This type of development is made possible by opening some of the APIs on the terminal. Opening these API functionalities on the JAVA side for example has the advantage that applications can be run in a secure environment. Furthermore, applications can be provisioned to the terminal using an over-the-air mechanism in a secure and controlled way. One additional advantage is that the APIs will be available regardless of the underlying operating system.
- A SIP Client API provides access to the basic services of a SIP stack. The most essential services are sending and receiving SIP messages, creating registrations, and forming and tearing dialogs initiated by INVITE and SUBSCRIBE. A SIP Client API is appropriate for applications like the wallet application disclosed herein, that intend to use SIP for managing communication sessions, subscribing to events, and sending stand-alone SIP messages.
- One such API is known as JSR180, the SIP Application Programming Interface (API) for
Java 2 Micro Edition (J2ME) which completed its final release in October 2003 as part of the Java specification process. The Java platform is seen as a base for many new innovative SIP applications. JSR180 can also be deployed on a MIDP 2.0 platform. The Mobile Information Device Profile (MIDP) is a key element of theJava 2 Platform, Mobile Edition (J2ME). When combined with the Connected Limited Device Configuration (CLDC), MIDP provides a standard Java runtime environment for today's most popular mobile information devices, such as cell phones and mainstream personal digital assistants (PDAs). - Another SIP API is the SIP Client API Specification (Version 1.0; Jul. 5, 2004) that is valid for all platforms running Symbian OS v7.0s. The SIP Client API requires the SIP Codec API (v1.0) that provides services for encoding/decoding SIP headers and their fields. Both the Java and Symbian APIs mentioned above allow multiple applications on the same device to use the SIP stack simultaneously. The function calls of the API are synchronous. An application must implement a set of callback functions, which the SIP Client API can use to pass events to the application.
- The SIP-based wallet application described herein is intended to be developed for both of the environments described, and could also be built for other environments such as BREW, Palm, PocketPC, and Linux. The wallet application will utilize a SIP API framework operating on the device. The use of other SIP APIs (other than those mentioned above) with other operating systems or programming environments is also possible according to the teachings of the present invention.
- SIP identity is a logical identity (address-of-record), a type of Uniform Resource Identifier (URI) called a SIP URI. SIP identity is frequently thought of as the “public address” of the user (see
RFC 3261, 6 definitions, p. 20). - A wireless terminal that supports SIP is typically configured for one user at a time (SIP provider settings). This means that the SIP system uses that address-of-record (URI) as the identity when communicating to other identities. Now, it is very likely that there will be several applications that want to share the same SIP identity. For example, audio/video, instant message/presence, game applications, and a wallet application as disclosed herein. On the other hand, some applications can use their own SIP identity (for that particular service), which does not share the same SIP properties.
- When sharing the same identity, the issue falls to the decisions on how the SIP requests are routed to the User Agents (applications). This functionality is specified in SIP Working Group (http://www.ietf.org/html.charters/sip-charter.html) as callee's capabilities and caller's preferences. The implementation should follow the framework and parameters specified in the final specification of the SIP working group.
- When sharing the same identity (address-of-record) the terminal has to know where the incoming request is routed. To do this it can use the MIME type tag carried in a special header (e.g. Accept-Contact). Each application is mapped to a certain MIME type. For example, Java SIP API provides a way to utilize this functionality as is specified below.
- To allow the Java SIP API to share the system SIP identity or use the application's own identity, the following rules are defined when the SIP server connection is opened with Connector.open( ):
Connector SIP URI SIP Identity Request Routing 1 sip:5080[type=″application/wallet″] Use route only the requests with the matching dedicated port 5080 Route all incoming SIP tag. 2 sip:;type=″application/wallet″ Share Use identity set by the requests on port system SIP port Route incoming SIP 5080 to this application requests Share system SIP identity with SipConnectionNotifier. If the optional MIME MIME type feature tag ″application/wallet″ type feature tag ″application/wallet″ is set to this SipConnectionNotifier 3 sip: Usededicated port Route all incoming SIP selected by the system requests to the selected port Use identity set by the to this SipConnectionNotifier application - RFC 2046 defines a top-level MIME “application” media type to be used for discrete data to be processed by some type of application program. This information must be processed by an application before it is viewable or usable by a user. Such applications may be defined as subtypes of the “application” media type. Examples of two subtypes are: “octet-stream” and “PostScript”.
- In general, the top-level media type is used to declare the general type of data, while the subtype specifies a specific format for that type of data. Thus, a media type of “application/wallet” is enough to tell a user agent that the data relates to an application on the wireless device, and further to the Wallet Application which will be mapped to the specific MIME type.
- According to RFC 2046, the subtype of “application” will often be either the name or include part of the name of the application for which the data are intended. While the above example uses the “wallet” subtype for the Wallet Application, another subtype that conforms with the requirements for MIME application sub-types can be used.
- Any application program name can not be used freely as a subtype of “application”. RFC 2048 defines registration procedures which use the Internet Assigned Numbers Authority (IANA) as a central registry for such values. Provided that the media type meets the requirements for media types and has obtained approval that is necessary, the author may submit the registration request to the IANA, which will register the media type and make the media type registration available to the community.
- Profiles may be shared with other applications. A profile is a collection of data necessary for providing required SIP registration behavior. A profile stores the following main parameters:
- The user-friendly name of the service provider
- The type of the profile, for example, 3GPP R5 IMS, IETF, or a proprietary profile type
- The user's registered public name (SIP Address Of Record, AOR)
- The access provider identifier of the used Internet Access Point (IAP)
- The address of the SIP registrar server, with optional connection and security parameters
- The address of the SIP proxy server, with optional connection and security parameters
- Compression and security preferences
- An indication of whether the profile is to be always automatically registered or only when it is used by an application
- Any number of extension parameters stored as key/value pairs
- The SIP-based Wallet application can share the same profile as other applications, and thus the same registration. This functionality may be built into the Wallet Application or could rely on an API. For example, the SIP Profile API Specification (Version 1.0; Jul. 5, 2004) provides a SIP registration service for applications. In order for the Wallet Application to use this API, the SIP Client API for the Symbian OS v7.0s is needed as well.
- The behavior of the registration service depends on the profile type used. There are different profile types for different standards, for example, 3GPP R5 IP Multimedia System, Internet Engineering Task Force (IETF), and proprietary standard types. At any given time, zero or more profiles of any profile type may exist. Each profile has a one-to-one correspondence with one SIP registration. The user of the API can be unaware of the details of the registration process and can ignore state changes of the access point connection during SIP registration.
- The SIP Profile Agent subsystem stores the SIP profiles in the persistent storage. As mentioned before, these profiles hold information necessary for providing required registration behavior. The SIP profiles can be managed with the SIP Settings UI (Application for end the user to add/update/remove SIP profiles), or they can be managed with over the air (OTA) configuration (by the SIP service provider).
- All aspects of the WCM are preferably compliant with IETF RFC 3261, 3GPP, and 3GPP2 standards. EMV-Compliant—The wallet application should meet standards defined by card organizations. The wallet application should comply with ISO standards for Personal Identification Number (PIN) management and security in open networks (ISO/TR 9564-4:2004)
- Cryptographic functions supported include:
- PIN, MAC and Data encryption keys
- Multiple index for all cryptographic keys
- Single, double or triple length of all encryption keys
- Single or Triple DES encryption/decryption
- Dynamic key exchange
- Key thresholds and threshold limits
- Under another embodiment of this invention, the user sets up a “wallet account” with a mobile operator or “wallet service provider”. The server-based wallet account allows a user to store credentials, personal information, and other confidential information in the electronic wallet, which the user can access through a number of channels using a minimum of two registered tokens. The server-based wallet system described at this point has all the same functionality of the wallet application described above (operating on a wireless device), but allows a user to access the entire “electronic wallet” from virtually any Internet-based channel such as a wireless device, a PC, or point-of-sale terminal.
- Based on the design disclosed herein, the user would be required to provide a E.164 number for a wireless device in order to establish the wallet account on a server hosted and managed by the wallet service provider. The wallet server uses the E.164 number as an access token and may also use it as a master account number. The user would also be required to establish a username and password/PIN for web access to the account (the username and password/PIN are also tokens). The server-based wallet application allows a user to register other tokens that can be used to gain access to the account through various means. For example, biometric information such as fingerprints, iris, voiceprints, facial recognition, and hand geometry can be registered through a trusted service provider of the wallet service. A magnetic-stripe card, an RFID-based device, a bar-coded card, or other similar devices could also be registered as valid tokens that can be used for accessing the server-based wallet.
- The number of tokens and the types of tokens required to access the wallet are dependent on the access methods available to access the wallet. For example, a POS terminal equipped with a fingerprint scanner and a numeric key input device, would only require a user to provide a valid E.164 phone number and a fingerprint in order to access his electronic wallet as disclosed herein. This example of two-factor authentication is sufficient to securely access a person's wallet at the point-of-sale. Similarly, a POS system that has an RFID reader and a numeric key input device, may require the user to wave a registered RFID token, provide a E.164 number (which could be transmitted by the RFID token or entered by the user manually), and enter his wallet PIN. This example would be considered three-factor authentication if the E.164 number is not encoded in the RFID device and must be entered manually by the user.
- The encoding of a E.164 number in an RFID-based device, magnetic-stripe card, bar coded device, or other similar device—that is used as an access token for an electronic wallet is disclosed herein. The E.164 number encoded in the access token may be transmitted to a reader along with other information such as a wallet account number, a unique device ID, and a variety of encryption information (that could be validated with the reader and/or with the wallet server).
- In contrast to the design detailed earlier in this document, the mobile operator or wallet service provider will populate the ENUM address information differently; under the previous design, the URI in the NAPTR record associated with the wallet service pointed to the wireless device (with the E.164 number). Based on this design, there are two URIs for the E.164 number that are associated with the wallet service. One URI points to a wallet server (managed by the operator or a wallet service provider). The other URI points to the wallet application that resides on a wireless device.
- As an example, the following NAPTR records might be received for an ENUM name query on a particular E.164 mobile number (+1-202-555-1234) that was used to setup a wallet account:
$ORIGIN 4.3.2.1.5.5.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 ″u″ ″E2U + sip″ ″!{circumflex over ( )}.*$!sip:bob@mobileco.com!″ .IN NAPTR 103 10 ″u″ ″E2U + walletserver″ {circumflex over ( )}.*$!sips:12025551234@walletserver.com!″ . IN NAPTR 104 10 ″u″ ″E2U + walletapp″ ″!{circumflex over ( )}$!sips:bob@wallet.mobileco.com!″ . - The “E2U+walletserver” and “E2U+walletapp” enumservices would be registered as described before. The use of the “E2U+walletserver” enumservice as a selection mechanism for a wallet-based server, and the “E2U+walletapp” enumservice as a selection mechanism for a wallet-based application on a wireless device is provided. While the examples above uses the theoretical “walletserver” and “walletapp” Types, the actual label that is registered with the LANA for the purposes described could be different.
- As before, a user that requests an electronic credential will provide the issuer with a valid E.164 number for his wireless device. The issuer's WCM will perform an ENUM query on the E.164 number based on the steps outlined before. The difference in this embodiment is that the issuer WCM will look for a NAPTR record associated with the “walletserver”. The registered ‘E2U+walletserver’ enumservice will function as a selection mechanism for the WCM when choosing one NAPTR resource record from another. The WCM will use the corresponding URI to establish a secure peer-to-peer connection with the wallet server using any number of protocols including SIP. After exchanging encryption keys, initial communication from the WCM to the wallet server will contain the E.164 number. The wallet server will check to see if the E.164 number is associated with a valid account on file. If it is, the wallet server will send back an acknowledgement to the WCM while performing an ENUM query on the E.164 number to obtain a NAPTR record for the “E2U+walletapp” service. The wallet server will use the resulting URI to initiate a peer-to-peer SIP session with the wireless device (while still maintaining the connection with the issuer WCM).
- The wireless device, loaded with “wallet client software”, allows a user to utilize the remote wallet functionality and access the credentials stored on the wallet server. The wallet application together with the wireless device on which it operates, allows the user to communicate in real-time with the credential issuer during the issuance process. As the credential is ultimately being issued to a remote server, the use of the wireless device allows the user to be located and contacted in real-time by the issuer in order to authenticate the user's identity before completing the issuance. In essence the issuer's WCM is communicating with the wireless end-user through the wallet server using the SIP protocol. The wallet server would have an integrated WCM of its own to facilitate communication with end-user wireless devices and issuers. Provided that the wireless user validates his identity for the issuer, the issuer will send the digital credential to the wallet server, where it will be stored. All new credentials or credential changes may be registered in the wallet client software on the wireless device; this way the wireless device doesn't need to access the server every time the user wants to scroll through lists of credentials, profiles, or other information. Alternatively, the wireless device could read all credential header information from the server as described earlier.
- This server-based design makes it easier for users to change wireless devices, as the user only needs to change the E.164 number that is linked to the wallet account on the server. In the event that the user's wireless device is lost/stolen, the user can simply log into his wallet profile through the wallet service provider's secure site, and temporarily restrict the use of credentials stored in the wallet.
- This design also offers a flexible solution for user's to gain access to their credentials in their digital wallet without the use of a wireless device. For example, in one scenario, a user making a purchase at a grocery store may be prompted at the point-of-sale for his E.164 phone number and his fingerprint. The grocery chain's IP-enabled POS system will capture the E.164 number and biometric information, and forward them to a WCM connected to the grocery chain's network. The grocery chain's WCM will be used in this case to facilitate a transaction with the wallet server where the user is registered. The WCM will perform an ENUM query on the E.164 number using a DNS server on the grocery chain's network, retrieve a NAPTR record that corresponds to the appropriate wallet service (e.g. “E2U+walletserver”), and use the URI in the NAPTR record to establish a secure peer-to-peer session via the Internet to the wallet server. The WCM and the wallet server may exchange encryption keys using established methods for doing so over the Internet prior to exchanging any confidential information. After the key exchange, the WCM will send the wallet server the E.164 number and the biometric information (fingerprint data) that was captured at the POS. The wallet server will validate that the E.164 number is associated with an account on record that is in good standing. If the account is valid and in good standing, the wallet server will validate the biometric information against information stored in the account. If the biometric information matches, the wallet server will transmit a menu showing all the credential types that are in the customer's wallet. This menu corresponds to the primary credential categories in the hierarchy that was previously discussed in this document. The customer could for example select “payment methods” and then see the secondary hierarchy (credit cards, debit cards, stored value cards, etc). Credentials will be displayed under the secondary categories. Credential listings will be displayed with some of the follow information:
- Name/logo of issuer
- Name/logo of association (e.g. Visa, MasterCard)
- Last 4 digits of account number
- Indicator showing whether the payment method is for business/personal use
- Using the POS display and input device (could be a touch screen interface), the user can select the appropriate payment method to complete the transaction. The user will be able to select multiple credentials stored on the wallet server for the transaction. For example, a payment method, loyalty card, and electronic coupons could all be selected. Once the user completes his selections, he will be prompted to signal his intention to complete the transaction. The credentials are then securely transmitted from the wallet server to the grocery chain's WCM which routes them to the POS system for processing. Once the POS system processes payment and completes the transaction, the POS (or a related system in the chain's network) sends a confirmation with a digital receipt to the grocery chain's WCM. The WCM transmits the digital receipt to the wallet server and then drops the connection to the wallet server. The digital receipts are made available to the user by logging into the wallet service provider's secure site using the username and password/PIN that was created. A user may choose to also receive receipt notices from the wallet server via e-mail or on his wireless device using the methods and protocols previously described, Short Message Service (SMS), or some other type of messaging protocol.
- As mentioned earlier, the wallet server will have an integrated WCM. The wallet server will also have access to a secure storage apparatus, high-performing database infrastructure, and front-end web architecture that allows users to manage/maintain their accounts online through a standard web browser.
- The foregoing disclosure of the preferred embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be apparent to one of ordinary skill in the art in light of the above disclosure. The scope of the invention is to be defined only by the claims, and by their equivalents.
Claims (63)
1. A system to process requests to authorize a payment transaction using a token credential, the system comprising:
a communications interface coupled to a payment network that is configured to receive transaction authorization requests originating from a merchant point-of-sale (POS) system, and to transmit an applicable transaction approval or decline response to the merchant POS system through the same path;
at least one storage device to store a database including user accounts, wherein each user account contains at least one linked payment account number and at least one token account number that is used to authorize a payment transaction between the merchant POS system and the system;
a transaction authorization interface to authorize the payment transaction against a selected payment account that is linked to a user account containing the at least one token account number; and
a processor configured to receive transaction authorization requests originating from the merchant POS system via the communications interface, select a user account from the user accounts stored in the database using the token account number contained in the received transaction authorization request, select the payment account number linked to the user account, transmit an authorization request against the selected linked payment account via the transaction authorization interface, receive and identify an approval or decline authorization response based on at least the state of the user account and the received authorization response associated with the linked payment account that is selected for authorization, and transmit a transaction approval or decline authorization response to the payment network and merchant point-of-sale system via the communications interface.
2. The system ofclaim 1 , wherein the at least one account number is one of a plurality of information included in the token credential.
3. The system ofclaim 1 , where the at least one token account number is within a Bank Identification Number (BIN) range associated with at least one of a payment card issuer and a payment network.
4. The system ofclaim 3 , wherein the at least one token account number within the designated BIN range enables transaction authorizations to be routed from the merchant POS system, to an acquirer, to the applicable payment network, and to an applicable token credential issuer system for approval.
5. The system ofclaim 1 , wherein the user accounts within the database have at least one linked payment account from one of a credit account, a debit account, or a stored value account type.
6. The system ofclaim 1 , wherein a token account number is mapped to a single linked payment account or a plurality of linked payment accounts.
7. The system ofclaim 6 , wherein the linked payment accounts have an associated account number that is within a designated Bank Identification Number (BIN) range associated with at least one of a specific payment network and a payment card issuer.
8. The system ofclaim 1 , wherein the linked payment accounts are administered by their respective issuer credential management systems.
9. The system ofclaim 1 , wherein any linked payment account within the user account is changeable according to input received from a user.
10. The system ofclaim 9 , wherein the linked payment account is removable by linking a new payment account to replace an existing one, or deleting an existing linked payment account.
11. The system ofclaim 9 , wherein changes to the linked payment accounts are made via at least one of a software application on a mobile device or via a computer connected to the Internet that is communicating with the system.
12. The system ofclaim 1 , wherein the system is coupled to a credential issuance system that is connected to the Internet.
13. The system ofclaim 12 , wherein the credential issuance system issues the token account number to a mobile device via a wireless network and the Internet.
14. The system ofclaim 13 , wherein the token account number, upon issuance, is stored in a memory of the mobile device.
15. The system ofclaim 14 , wherein the token account number is transmitted to a reader device when the mobile device's short-range radio-frequency (RF) interface comes in proximity to the reader's RF interface.
16. The system ofclaim 15 , wherein the reader device and the mobile device communicate via a short-range RF standard such as near field communication (NFC), Bluetooth, or another wireless communication standard that is mutually supported by both devices.
17. The system ofclaim 15 , wherein the transmission of the token account number to the reader device initiates a transaction authorization request from the merchant POS system to the system via the applicable payment network associated with the account number credential.
18. The system ofclaim 1 , wherein a token credential account number assigned to the user account within the database is updated by an issuer.
19. The system ofclaim 18 , wherein the issuer correspondingly updates a token account number stored in a mobile device's memory via a wireless network and the Internet.
20. The system ofclaim 18 , wherein a token credential account number is stored in a magnetic-stripe card, a chip card, a mobile device, or a computer system.
21. The system ofclaim 18 , wherein the token credential account number is transmitted to the merchant POS system by at least one of an encoded magnetic-stripe card, an encoded chip, via a radio frequency (RF) interface in a mobile device, and a computer system to initiate a payment authorization.
22. The system ofclaim 1 , wherein the processor selects a linked payment account upon receiving a transaction authorization request containing a token account number via the communications interface.
23. The system ofclaim 22 , wherein when a user had previously selected a default payment account to be used, the processor selects the linked payment account that had been pre-selected by the user.
24. The system ofclaim 22 , wherein the selection of a linked payment account is automatic when there is only one payment account linked to the user account.
25. The system ofclaim 22 , wherein when there is no pre-selection made of a linked payment account by the user and there is more than one linked payment account, the system initiates a message to the mobile device or computer system to prompt the user to make a selection from one of the linked payment accounts when a transaction authorization request containing the token account number is received by the processor via the communications interface.
26. The system ofclaim 25 , wherein upon receipt of the selection and the transaction approval or decline of the linked payment account, the processor responds to the initial authorization request from the merchant POS with an approval or decline message.
27. An apparatus to process requests to authorize a payment transaction using a token credential, the apparatus comprising:
a communications interface coupled to a payment network that is configured to receive transaction authorization requests originating from a merchant point-of-sale (POS) system, and to transmit an applicable transaction approval or decline response to the merchant POS system through the same path;
at least one storage device to store a database including user accounts, wherein each user account contains at least one linked payment account number and at least one token account number that is used to authorize a payment transaction between the merchant POS system and the apparatus; and
a processor configured to receive transaction authorization requests originating from the merchant POS system via the communications interface, select a user account from the user accounts stored in the database using the token account number contained in the received transaction authorization request, select a payment account number linked to the user account, transmit an authorization request against the selected linked payment account via the transaction authorization interface, receive and identify an approval or decline authorization response based on at least the state of the user account and the received authorization response associated with the linked payment account that is selected for authorization, and transmit a transaction approval or decline authorization response to the payment network and merchant point-of-sale system via the communications interface.
28. The apparatus ofclaim 27 , wherein the at least one account number is one of a plurality of information included in the token credential.
29. The apparatus ofclaim 27 , where the at least one token account number is within a Bank Identification Number (BIN) range associated with at least one of a payment card issuer and a payment network.
30. The apparatus ofclaim 29 , wherein the at least one token account number within the designated BIN range enables transaction authorizations to be routed from the merchant POS system, to an acquirer, to the applicable payment network, and to an applicable token credential issuer system for approval.
31. The apparatus ofclaim 27 , wherein the user accounts within the database have at least one linked payment account from one of a credit account, debit account, or stored value account payment type.
32. The apparatus ofclaim 27 , wherein a token account number is mapped to a single linked payment account or a plurality of linked payment accounts.
33. The apparatus ofclaim 32 , wherein the linked payment accounts have an associated account number that is within a designated Bank Identification Number (BIN) range associated with at least one of a specific payment network and a designated issuer.
34. The apparatus ofclaim 27 , wherein any linked payment account within the user account is changeable according to input received from a user.
35. The apparatus ofclaim 34 , wherein the linked payment account is changeable by linking a new account to replace an existing one, or deleting an existing linked account.
36. The apparatus ofclaim 27 , wherein a token credential account number assigned to the user account is updated within the database by an issuer.
37. The apparatus ofclaim 27 , wherein the processor selects a linked payment account upon receiving a transaction authorization request containing a token account number via the communications interface.
38. The apparatus ofclaim 37 , wherein when a user had previously selected a default payment account to be used, the processor selects the linked payment account that had been pre-selected by the user.
39. The apparatus ofclaim 37 , wherein the selection of a linked payment account is automatic when there is only one payment account linked to the user account.
40. A method of conducting a financial transaction over a payment network using a token credential, the method comprising:
transmitting a transaction authorization request containing an amount of the transaction and a token account number, from a merchant point-of-sale (POS) system to an applicable payment network and issuer transaction processing system;
receiving the transaction authorization request at the issuer transaction processing system;
selecting, by the issuer transaction processing system, a user account based on the token account number contained in the received transaction authorization request;
selecting, by the issuer transaction processing system, a payment account from one or more linked payment accounts contained within the user account to which a transaction amount is to be applied;
transmitting an authorization request against the selected payment account, and receiving an approval or decline authorization response at the issuer transaction processing system;
identifying an approval or decline authorization response based on at least the received transaction authorization response associated with the linked payment account that is authorized; and
transmitting a transaction approval or decline authorization response from the issuer transaction processing system to the payment network and the merchant POS system.
41. The method ofclaim 40 , wherein the token account number is within a Bank Identification Number (BIN) range associated with at least one of a payment card issuer and a payment network.
42. The method ofclaim 41 , further comprising:
routing transaction authorizations having the token account number within the designated BIN range from the merchant POS system, to an acquirer, to the applicable payment network, and to an applicable token credential issuer system for approval.
43. The method ofclaim 40 , wherein the user account has at least one linked payment account from one of a credit account, debit account, or stored value account payment type.
44. The method ofclaim 40 , further comprising:
linking the token account number to the payment account.
45. The method ofclaim 44 , further comprising:
associating the linked payment account with an account number that is within a designated Bank Identification Number (BIN) range associated with a specific payment network and a designated issuer.
46. The method ofclaim 40 , further comprising:
administering, with an issuer credential management system, the linked payment account.
47. The method ofclaim 40 , further comprising:
changing the linked payment account in the user account according to input received from a user.
48. The method ofclaim 47 , wherein the changing of the linked payment account comprises:
removing the linked payment account by linking a new account to replace an existing one, or deleting an existing linked account.
49. The method ofclaim 47 , wherein the changing the linked payment account comprises:
changing the linked payment account via a software application on a mobile device or via a computer connected to the Internet.
50. The method ofclaim 40 , further comprising:
issuing, with a credential issuance system, a token credential to a mobile device via a wireless network and the Internet.
51. The method ofclaim 50 , further comprising:
storing the token credential, upon issuance, in a memory of the mobile device.
52. The method ofclaim 51 , further comprising:
transmitting the token credential to a reader device when the mobile device's short-range radio-frequency (RF) interface comes in proximity to the reader's RF interface.
53. The method ofclaim 52 , wherein the reader device and the mobile device communicate via a short-range RF standard such as near field communication (NFC), Bluetooth, or another wireless communication standard that is mutually supported by both devices.
54. The method ofclaim 52 , wherein the transmission of the token credential to the reader device further comprises:
initiating a transaction authorization request from the merchant POS system to the system via the applicable payment network associated with the token credential.
55. The method ofclaim 40 , further comprising:
updating, by an issuer, a token credential account number assigned to the user account within the database.
56. The method ofclaim 55 , further comprising:
correspondingly updating, by an issuer, a token account number stored in a mobile device's memory via a wireless network and the Internet.
57. The method ofclaim 55 , further comprising:
storing a token credential account number in a magnetic-stripe card, a chip card, a mobile device, or a computer system.
58. The method ofclaim 55 , further comprising:
transmitting the token credential account number to the merchant POS system by at least one of an encoded magnetic-stripe card, an encoded chip, via a radio frequency (RF) interface in a mobile device, and a computer system to initiate a payment authorization.
59. The method ofclaim 40 , further comprising:
selecting a linked payment account upon receiving a transaction authorization request containing a token account number via the system.
60. The method ofclaim 59 , further comprising:
when a user has previously selected a default payment account to be used, selecting the linked payment account that had been pre-selected by the user.
61. The method ofclaim 59 , wherein the selection of a linked payment account is automatic when there is only one payment account linked to the user account.
62. The method ofclaim 59 , further comprising:
when there is no pre-selection made of the linked payment account by the user and there is more than one linked payment account, initiating a message to a mobile device or a computer system to prompt the user to make a selection from one of the linked payment accounts when a transaction authorization request containing the token account number is received by the system.
63. The method ofclaim 62 , further comprising:
in response to the user's selection and the transaction approval or decline of the linked payment account, responding to the initial authorization request from the merchant POS with an approval or decline message.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US14/510,822US20150095175A1 (en) | 2005-01-21 | 2014-10-09 | Transaction processing, system, method, and apparatus that utilizes a token credential |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US11/040,847US8700729B2 (en) | 2005-01-21 | 2005-01-21 | Method and apparatus for managing credentials through a wireless network |
| US14/187,693US20140172724A1 (en) | 2005-01-21 | 2014-02-24 | Conducting transactions with electronic credentials |
| US14/510,822US20150095175A1 (en) | 2005-01-21 | 2014-10-09 | Transaction processing, system, method, and apparatus that utilizes a token credential |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US14/187,693ContinuationUS20140172724A1 (en) | 2005-01-21 | 2014-02-24 | Conducting transactions with electronic credentials |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| US20150095175A1true US20150095175A1 (en) | 2015-04-02 |
Family
ID=36696675
Family Applications (16)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US11/040,847Active2029-10-22US8700729B2 (en) | 2005-01-21 | 2005-01-21 | Method and apparatus for managing credentials through a wireless network |
| US14/187,693AbandonedUS20140172724A1 (en) | 2005-01-21 | 2014-02-24 | Conducting transactions with electronic credentials |
| US14/228,514AbandonedUS20140222682A1 (en) | 2005-01-21 | 2014-03-28 | Provisioning a mobile communication device with electronic credentials |
| US14/302,511Expired - LifetimeUS9235839B2 (en) | 2005-01-21 | 2014-06-12 | Method, apparatus, and system for processing payments using a proxy credential |
| US14/337,584AbandonedUS20140337227A1 (en) | 2005-01-21 | 2014-07-22 | System and method of selecting a virtual card application |
| US14/505,890AbandonedUS20150095174A1 (en) | 2005-01-21 | 2014-10-03 | Apparatus, system, and method of securing financial transactions using a mobile device |
| US14/510,822AbandonedUS20150095175A1 (en) | 2005-01-21 | 2014-10-09 | Transaction processing, system, method, and apparatus that utilizes a token credential |
| US14/533,722AbandonedUS20150058227A1 (en) | 2005-01-21 | 2014-11-05 | System, method, and apparatus to authorize a payment transaction using a token credential |
| US14/549,087AbandonedUS20150077228A1 (en) | 2005-01-21 | 2014-11-20 | System, device, and method of transmitting a plurality of credentials via near-field communication |
| US14/551,827AbandonedUS20150081559A1 (en) | 2005-01-21 | 2014-11-24 | Near-field communication (nfc) method, apparatus, and system with biometric authentication |
| US14/557,938Active2027-01-04US11468438B2 (en) | 2005-01-21 | 2014-12-02 | Method, apparatus, and system for performing online transactions with biometric authentication |
| US14/564,034Active2027-03-15US11403630B2 (en) | 2005-01-21 | 2014-12-08 | Method, apparatus, and system for performing wireless transactions with biometric authentication |
| US14/572,313Active2027-08-26US10769633B2 (en) | 2005-01-21 | 2014-12-16 | Method, apparatus, and system for performing wireless transactions with near-field communication (NFC) set up |
| US14/572,287Active2027-08-15US10872333B2 (en) | 2005-01-21 | 2014-12-16 | System, devices, and method to automatically launch an application on a mobile computing device based on a near-field communication data exchange |
| US14/791,739Expired - LifetimeUS11222330B2 (en) | 2005-01-21 | 2015-07-06 | Apparatus and method to perform point of sale transactions using near-field communication (NFC) and biometric authentication |
| US14/818,974AbandonedUS20150339667A1 (en) | 2005-01-21 | 2015-08-05 | Apparatus, system, and method to process transaction requests |
Family Applications Before (6)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US11/040,847Active2029-10-22US8700729B2 (en) | 2005-01-21 | 2005-01-21 | Method and apparatus for managing credentials through a wireless network |
| US14/187,693AbandonedUS20140172724A1 (en) | 2005-01-21 | 2014-02-24 | Conducting transactions with electronic credentials |
| US14/228,514AbandonedUS20140222682A1 (en) | 2005-01-21 | 2014-03-28 | Provisioning a mobile communication device with electronic credentials |
| US14/302,511Expired - LifetimeUS9235839B2 (en) | 2005-01-21 | 2014-06-12 | Method, apparatus, and system for processing payments using a proxy credential |
| US14/337,584AbandonedUS20140337227A1 (en) | 2005-01-21 | 2014-07-22 | System and method of selecting a virtual card application |
| US14/505,890AbandonedUS20150095174A1 (en) | 2005-01-21 | 2014-10-03 | Apparatus, system, and method of securing financial transactions using a mobile device |
Family Applications After (9)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| US14/533,722AbandonedUS20150058227A1 (en) | 2005-01-21 | 2014-11-05 | System, method, and apparatus to authorize a payment transaction using a token credential |
| US14/549,087AbandonedUS20150077228A1 (en) | 2005-01-21 | 2014-11-20 | System, device, and method of transmitting a plurality of credentials via near-field communication |
| US14/551,827AbandonedUS20150081559A1 (en) | 2005-01-21 | 2014-11-24 | Near-field communication (nfc) method, apparatus, and system with biometric authentication |
| US14/557,938Active2027-01-04US11468438B2 (en) | 2005-01-21 | 2014-12-02 | Method, apparatus, and system for performing online transactions with biometric authentication |
| US14/564,034Active2027-03-15US11403630B2 (en) | 2005-01-21 | 2014-12-08 | Method, apparatus, and system for performing wireless transactions with biometric authentication |
| US14/572,313Active2027-08-26US10769633B2 (en) | 2005-01-21 | 2014-12-16 | Method, apparatus, and system for performing wireless transactions with near-field communication (NFC) set up |
| US14/572,287Active2027-08-15US10872333B2 (en) | 2005-01-21 | 2014-12-16 | System, devices, and method to automatically launch an application on a mobile computing device based on a near-field communication data exchange |
| US14/791,739Expired - LifetimeUS11222330B2 (en) | 2005-01-21 | 2015-07-06 | Apparatus and method to perform point of sale transactions using near-field communication (NFC) and biometric authentication |
| US14/818,974AbandonedUS20150339667A1 (en) | 2005-01-21 | 2015-08-05 | Apparatus, system, and method to process transaction requests |
Country Status (1)
| Country | Link |
|---|---|
| US (16) | US8700729B2 (en) |
Cited By (48)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150161592A1 (en)* | 2013-12-05 | 2015-06-11 | Samsung Electronics Co., Ltd. | Method for payment using membership card and electronic device thereof |
| US20170262849A1 (en)* | 2016-03-14 | 2017-09-14 | Jpmorgan Chase Bank, N.A. | Systems and methods for device authentication |
| DK201670628A1 (en)* | 2016-05-19 | 2017-11-27 | Apple Inc | Remote authorization to proceed with an action |
| US9842330B1 (en) | 2016-09-06 | 2017-12-12 | Apple Inc. | User interfaces for stored-value accounts |
| US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| WO2018075630A1 (en)* | 2016-10-19 | 2018-04-26 | Visa International Service Association | Digital wallet merchant-specific virtual payment accounts |
| US10013684B2 (en) | 2015-06-02 | 2018-07-03 | Bank Of America Corporation | Processing cardless transactions at automated teller devices |
| US10142835B2 (en) | 2011-09-29 | 2018-11-27 | Apple Inc. | Authentication with secondary approver |
| US10178234B2 (en) | 2014-05-30 | 2019-01-08 | Apple, Inc. | User interface for phone call routing among devices |
| US10395128B2 (en) | 2017-09-09 | 2019-08-27 | Apple Inc. | Implementation of biometric authentication |
| US10438205B2 (en) | 2014-05-29 | 2019-10-08 | Apple Inc. | User interface for payments |
| US10484384B2 (en) | 2011-09-29 | 2019-11-19 | Apple Inc. | Indirect authentication |
| US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
| US10521579B2 (en) | 2017-09-09 | 2019-12-31 | Apple Inc. | Implementation of biometric authentication |
| US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
| US10956550B2 (en) | 2007-09-24 | 2021-03-23 | Apple Inc. | Embedded authentication systems in an electronic device |
| US10992795B2 (en) | 2017-05-16 | 2021-04-27 | Apple Inc. | Methods and interfaces for home media control |
| US10996917B2 (en) | 2019-05-31 | 2021-05-04 | Apple Inc. | User interfaces for audio media control |
| US11037150B2 (en) | 2016-06-12 | 2021-06-15 | Apple Inc. | User interfaces for transactions |
| US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
| US11126704B2 (en) | 2014-08-15 | 2021-09-21 | Apple Inc. | Authenticated device used to unlock another device |
| US11129018B2 (en) | 2015-02-27 | 2021-09-21 | Samsung Electronics Co., Ltd. | Payment means operation supporting method and electronic device for supporting the same |
| US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
| US11182769B2 (en) | 2015-02-12 | 2021-11-23 | Samsung Electronics Co., Ltd. | Payment processing method and electronic device supporting the same |
| US11283916B2 (en) | 2017-05-16 | 2022-03-22 | Apple Inc. | Methods and interfaces for configuring a device in accordance with an audio tone signal |
| US11392291B2 (en) | 2020-09-25 | 2022-07-19 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
| US11431836B2 (en) | 2017-05-02 | 2022-08-30 | Apple Inc. | Methods and interfaces for initiating media playback |
| US11481769B2 (en) | 2016-06-11 | 2022-10-25 | Apple Inc. | User interface for transactions |
| US11539831B2 (en) | 2013-03-15 | 2022-12-27 | Apple Inc. | Providing remote interactions with host device using a wireless device |
| US20230007484A1 (en)* | 2018-09-21 | 2023-01-05 | Schlage Lock Company Llc | Wireless access credential system |
| WO2023043589A1 (en)* | 2021-09-15 | 2023-03-23 | Visa International Service Association | Multiple interaction processing |
| US11620103B2 (en) | 2019-05-31 | 2023-04-04 | Apple Inc. | User interfaces for audio media control |
| US11676373B2 (en) | 2008-01-03 | 2023-06-13 | Apple Inc. | Personal computing device control using face detection and recognition |
| US11683408B2 (en) | 2017-05-16 | 2023-06-20 | Apple Inc. | Methods and interfaces for home media control |
| US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
| US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
| US11847378B2 (en) | 2021-06-06 | 2023-12-19 | Apple Inc. | User interfaces for audio routing |
| US11861700B1 (en)* | 2015-07-13 | 2024-01-02 | Wells Fargo Bank, N.A. | Systems and methods for real time credit extension and bill pay configuration |
| US11907013B2 (en) | 2014-05-30 | 2024-02-20 | Apple Inc. | Continuity of applications across devices |
| US12002042B2 (en) | 2016-06-11 | 2024-06-04 | Apple, Inc | User interface for transactions |
| US12079458B2 (en) | 2016-09-23 | 2024-09-03 | Apple Inc. | Image data for enhanced user interactions |
| US12099586B2 (en) | 2021-01-25 | 2024-09-24 | Apple Inc. | Implementation of biometric authentication |
| US20240320651A1 (en)* | 2023-03-20 | 2024-09-26 | Kakao Corp. | Method and apparatus for payment service |
| US12210603B2 (en) | 2021-03-04 | 2025-01-28 | Apple Inc. | User interface for enrolling a biometric feature |
| US12216754B2 (en) | 2021-05-10 | 2025-02-04 | Apple Inc. | User interfaces for authenticating to perform secure operations |
| US12262111B2 (en) | 2011-06-05 | 2025-03-25 | Apple Inc. | Device, method, and graphical user interface for accessing an application in a locked device |
| US12407754B2 (en) | 2015-09-29 | 2025-09-02 | Soracom, Inc | Control apparatus for gateway in mobile communication system |
| US12423052B2 (en) | 2021-06-06 | 2025-09-23 | Apple Inc. | User interfaces for audio routing |
Families Citing this family (1228)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7904468B2 (en)* | 2008-02-27 | 2011-03-08 | Research In Motion Limited | Method and software for facilitating interaction with a personal information manager application at a wireless communication device |
| US7865528B2 (en)* | 2001-01-09 | 2011-01-04 | Nextair Corporation | Software, devices and methods facilitating execution of server-side applications at mobile devices |
| WO2002069608A2 (en)* | 2001-01-16 | 2002-09-06 | Akamai Technologies, Inc. | Using virtual domain name service (dns) zones for enterprise content delivery |
| US7237117B2 (en) | 2001-03-16 | 2007-06-26 | Kenneth P. Weiss | Universal secure registry |
| FI20011498A0 (en)* | 2001-07-09 | 2001-07-09 | Ericsson Telefon Ab L M | Method and system for verification of electronic signatures |
| US7611409B2 (en)* | 2001-09-20 | 2009-11-03 | Igt | Method and apparatus for registering a mobile device with a gaming machine |
| US7699703B2 (en)* | 2001-09-20 | 2010-04-20 | Igt | Method and apparatus for registering a mobile device with a gaming machine |
| US20030167231A1 (en)* | 2002-03-04 | 2003-09-04 | First Data Corporation | Method and system for processing credit card payments |
| AU2003255949A1 (en) | 2002-07-09 | 2004-01-23 | Neology, Inc. | System and method for providing secure identification solutions |
| US10176476B2 (en) | 2005-10-06 | 2019-01-08 | Mastercard Mobile Transactions Solutions, Inc. | Secure ecosystem infrastructure enabling multiple types of electronic wallets in an ecosystem of issuers, service providers, and acquires of instruments |
| FR2847756B1 (en)* | 2002-11-22 | 2005-09-23 | Cegetel Groupe | METHOD FOR ESTABLISHING AND MANAGING A MODEL OF CONFIDENCE BETWEEN A CHIP CARD AND A RADIO TERMINAL |
| JP4680918B2 (en)* | 2003-05-30 | 2011-05-11 | プリヴァリス・インコーポレーテッド | System and method for assignment and use of media content subscription service privileges |
| US7873716B2 (en)* | 2003-06-27 | 2011-01-18 | Oracle International Corporation | Method and apparatus for supporting service enablers via service request composition |
| US7761374B2 (en) | 2003-08-18 | 2010-07-20 | Visa International Service Association | Method and system for generating a dynamic verification value |
| US7740168B2 (en) | 2003-08-18 | 2010-06-22 | Visa U.S.A. Inc. | Method and system for generating a dynamic verification value |
| US7953663B1 (en) | 2003-09-04 | 2011-05-31 | Jpmorgan Chase Bank, N.A. | System and method for financial instrument pre-qualification and offering |
| US7886348B2 (en) | 2003-10-03 | 2011-02-08 | Verizon Services Corp. | Security management system for monitoring firewall operation |
| US8512144B2 (en) | 2003-10-20 | 2013-08-20 | Tipping Point Group, Llc | Method and apparatus for providing secondary gaming machine functionality |
| JP2005202914A (en)* | 2003-12-15 | 2005-07-28 | Matsushita Electric Ind Co Ltd | Secure device and information processing device |
| WO2005086802A2 (en) | 2004-03-08 | 2005-09-22 | Proxense, Llc | Linked account system using personal digital key (pdk-las) |
| US7860490B2 (en)* | 2004-12-01 | 2010-12-28 | Oracle International Corporation | Methods and systems for exposing access network capabilities using an enabler proxy |
| US9245236B2 (en) | 2006-02-16 | 2016-01-26 | Oracle International Corporation | Factorization of concerns to build a SDP (service delivery platform) |
| US9038082B2 (en) | 2004-05-28 | 2015-05-19 | Oracle International Corporation | Resource abstraction via enabler and metadata |
| US8458703B2 (en) | 2008-06-26 | 2013-06-04 | Oracle International Corporation | Application requesting management function based on metadata for managing enabler or dependency |
| US8321498B2 (en) | 2005-03-01 | 2012-11-27 | Oracle International Corporation | Policy interface description framework |
| US9565297B2 (en) | 2004-05-28 | 2017-02-07 | Oracle International Corporation | True convergence with end to end identity management |
| US8073810B2 (en)* | 2007-10-29 | 2011-12-06 | Oracle International Corporation | Shared view of customers across business support systems (BSS) and a service delivery platform (SDP) |
| US8966498B2 (en) | 2008-01-24 | 2015-02-24 | Oracle International Corporation | Integrating operational and business support systems with a service delivery platform |
| US8425323B2 (en) | 2004-06-30 | 2013-04-23 | Wms Gaming Inc. | Wagering game with asset trading |
| US10862994B1 (en)* | 2006-11-15 | 2020-12-08 | Conviva Inc. | Facilitating client decisions |
| US8752125B2 (en)* | 2004-10-20 | 2014-06-10 | Salt Group Pty Ltd | Authentication method |
| US7328839B2 (en)* | 2004-10-21 | 2008-02-12 | International Business Machines Corporation | User configurable alerts for ATM transactions |
| CN102609640B (en) | 2004-10-25 | 2015-07-15 | 安全第一公司 | Secure data parser method and system |
| EP1829283A2 (en) | 2004-12-20 | 2007-09-05 | Proxense, LLC | Biometric personal data key (pdk) authentication |
| US8032920B2 (en)* | 2004-12-27 | 2011-10-04 | Oracle International Corporation | Policies as workflows |
| US8700729B2 (en) | 2005-01-21 | 2014-04-15 | Robin Dua | Method and apparatus for managing credentials through a wireless network |
| US10719859B2 (en)* | 2005-01-28 | 2020-07-21 | Wells Fargo Bank, N.A. | Electronic bill pay and bill presentment account number treatment system and method |
| US8219622B2 (en)* | 2005-02-09 | 2012-07-10 | Verizon Business Global Llc | Systems and methods for providing extended peering |
| US20060182101A1 (en)* | 2005-02-14 | 2006-08-17 | Hoekstra Geert J | Method for distributing transport sessions over multiple network interfaces |
| CN101164356A (en)* | 2005-02-15 | 2008-04-16 | 沃达方集团有限公司 | Improving security of wireless communications |
| US20060252435A1 (en)* | 2005-03-18 | 2006-11-09 | Yahoo! Inc. | Enabling application wakeup on a mobile device with a hybrid client |
| US7908480B2 (en)* | 2005-03-21 | 2011-03-15 | Cisco Technology, Inc. | Authenticating an endpoint using a STUN server |
| US8677125B2 (en)* | 2005-03-31 | 2014-03-18 | Alcatel Lucent | Authenticating a user of a communication device to a wireless network to which the user is not associated with |
| US7706778B2 (en) | 2005-04-05 | 2010-04-27 | Assa Abloy Ab | System and method for remotely assigning and revoking access credentials using a near field communication equipped mobile phone |
| CN101518042B (en)* | 2005-04-12 | 2013-06-12 | 电信系统有限公司 | Temporary enum gateway |
| US7617530B2 (en)* | 2005-04-22 | 2009-11-10 | Microsoft Corporation | Rights elevator |
| US7810143B2 (en)* | 2005-04-22 | 2010-10-05 | Microsoft Corporation | Credential interface |
| US20090323558A1 (en)* | 2005-05-10 | 2009-12-31 | Venkat Stinivas Meenavalli | System and an improved method for controlling multimedia features and services in a sip-based phones |
| JP4571010B2 (en)* | 2005-05-16 | 2010-10-27 | 富士通株式会社 | IP phone system, information processing terminal and mobile phone that can save power |
| US8430300B2 (en)* | 2005-05-26 | 2013-04-30 | Codebroker, Llc | Using validity events to control the use of coupons containing barcodes in mobile devices that display the barcodes for reading by barcode readers |
| WO2007127385A2 (en) | 2006-04-27 | 2007-11-08 | Codebroker Llc | Customizing barcode images for particular displays |
| US7644165B2 (en)* | 2005-05-31 | 2010-01-05 | Alcatel-Lucent Usa Inc. | Method and apparatus for SIP messaging |
| US8045998B2 (en)* | 2005-06-08 | 2011-10-25 | Cisco Technology, Inc. | Method and system for communicating using position information |
| US20070004438A1 (en)* | 2005-07-01 | 2007-01-04 | Alec Brusilovsky | Method and apparatus enabling PTT (push-to-talk) communications between legacy PSTN, cellular and wireless 3G terminals |
| US20070162862A1 (en)* | 2005-07-06 | 2007-07-12 | Gemini Mobile Technologies, Inc. | Selective user monitoring in an online environment |
| US20070016645A1 (en)* | 2005-07-15 | 2007-01-18 | Hong Na | System and method of composing search free mail |
| US20070022289A1 (en)* | 2005-07-20 | 2007-01-25 | Mci, Inc. | Method and system for providing secure credential storage to support interdomain traversal |
| US8184641B2 (en)* | 2005-07-20 | 2012-05-22 | Verizon Business Global Llc | Method and system for providing secure communications between proxy servers in support of interdomain traversal |
| KR100974679B1 (en)* | 2005-07-25 | 2010-08-06 | 도요 잉키 세이조 가부시끼가이샤 | Active energy ray curable ink for inkjet |
| CN100361553C (en)* | 2005-07-29 | 2008-01-09 | 华为技术有限公司 | Method and device for storing wireless terminal user ID |
| JP4687310B2 (en)* | 2005-07-29 | 2011-05-25 | ソニー株式会社 | Remote operation system, remote communication device, remote operation method |
| US7706339B2 (en)* | 2005-08-10 | 2010-04-27 | Cisco Technology, Inc. | Method and system for communicating media based on location of media source |
| US7633914B2 (en)* | 2005-08-10 | 2009-12-15 | Cisco Technology, Inc. | Method and system for providing interoperable communications with location information |
| US7636339B2 (en)* | 2005-08-10 | 2009-12-22 | Cisco Technology, Inc. | Method and system for automatic configuration of virtual talk groups based on location of media sources |
| US7869386B2 (en) | 2005-08-29 | 2011-01-11 | Cisco Technology, Inc. | Method and system for conveying media source location information |
| USRE49187E1 (en) | 2005-09-06 | 2022-08-23 | Samsung Electronics Co., Ltd. | Mobile communication terminal and method of the same for outputting short message |
| US7997476B2 (en) | 2005-09-15 | 2011-08-16 | Capital One Financial Corporation | Wireless devices for storing a financial account card and methods for storing card data in a wireless device |
| US7987251B2 (en)* | 2005-09-16 | 2011-07-26 | Microsoft Corporation | Validation of domain name control |
| DE102005044798B4 (en)* | 2005-09-19 | 2007-10-31 | Siemens Ag | Method for activating at least one further intercepting measure in at least one communication network |
| US8363812B1 (en) | 2005-09-22 | 2013-01-29 | Verizon Patent And Licensing Inc. | Method and system for providing call parking in a SIP-based network |
| US10032160B2 (en) | 2005-10-06 | 2018-07-24 | Mastercard Mobile Transactions Solutions, Inc. | Isolating distinct service provider widgets within a wallet container |
| US8352376B2 (en)* | 2005-10-11 | 2013-01-08 | Amazon Technologies, Inc. | System and method for authorization of transactions |
| US20070094113A1 (en)* | 2005-10-21 | 2007-04-26 | Eduardo Chapeta | Transactional mobile system |
| US7356767B2 (en)* | 2005-10-27 | 2008-04-08 | International Business Machines Corporation | Extensible resource resolution framework |
| US20070099679A1 (en)* | 2005-11-01 | 2007-05-03 | Mikko Saarisalo | Wireless near field communication control using device state or orientation |
| WO2007053225A1 (en)* | 2005-11-04 | 2007-05-10 | Catalina Marketing Corporation | Personal portable devices |
| US9374342B2 (en) | 2005-11-08 | 2016-06-21 | Verizon Patent And Licensing Inc. | System and method for testing network firewall using fine granularity measurements |
| US8027251B2 (en)* | 2005-11-08 | 2011-09-27 | Verizon Services Corp. | Systems and methods for implementing protocol-aware network firewall |
| US8396922B2 (en)* | 2005-11-18 | 2013-03-12 | Aol Inc. | Promoting interoperability of presence-based systems through the use of ubiquitous online identities |
| EP1952575B1 (en) | 2005-11-18 | 2017-12-27 | Security First Corp. | Secure data parser method and system |
| CA2576133C (en)* | 2005-11-21 | 2012-01-24 | Bce Inc. | Method, system and apparatus for announcing caller information over a television link |
| EP1802155A1 (en)* | 2005-12-21 | 2007-06-27 | Cronto Limited | System and method for dynamic multifactor authentication |
| US7600675B2 (en)* | 2005-12-28 | 2009-10-13 | Compucredit Intellectual Property Holdings Corp. Ii | Method for providing financial instruments to customers of a service provider |
| US20070162366A1 (en)* | 2005-12-30 | 2007-07-12 | Ebay Inc. | Anti-phishing communication system |
| US8391165B2 (en)* | 2005-12-30 | 2013-03-05 | Motorola Mobility Llc | Method and apparatus for identifying caller preferences matched to callee capabilities for IMS communications |
| US8352323B2 (en)* | 2007-11-30 | 2013-01-08 | Blaze Mobile, Inc. | Conducting an online payment transaction using an NFC enabled mobile communication device |
| US8219129B2 (en) | 2006-01-06 | 2012-07-10 | Proxense, Llc | Dynamic real-time tiered client access |
| US11206664B2 (en) | 2006-01-06 | 2021-12-21 | Proxense, Llc | Wireless network synchronization of cells and client devices on a network |
| EP1978707B2 (en)* | 2006-01-26 | 2017-01-18 | Huawei Technologies Co., Ltd. | A method and system for generating and acquiring the rights object and the rights issuing center |
| US7945951B2 (en)* | 2006-01-30 | 2011-05-17 | Microsoft Corporation | Rights-context elevator |
| US7941848B2 (en) | 2006-01-30 | 2011-05-10 | Microsoft Corporation | Elevating rights |
| US20070198934A1 (en)* | 2006-02-17 | 2007-08-23 | Microsoft Corporation | Performing a Prohibited Task |
| US11227676B2 (en) | 2006-02-21 | 2022-01-18 | Universal Secure Registry, Llc | Universal secure registry |
| EP1987463A1 (en) | 2006-02-21 | 2008-11-05 | WEISS, Kenneth P. | Method and apparatus for secure access payment and identification |
| US8234220B2 (en) | 2007-02-21 | 2012-07-31 | Weiss Kenneth P | Universal secure registry |
| US8117459B2 (en)* | 2006-02-24 | 2012-02-14 | Microsoft Corporation | Personal identification information schemas |
| US8104074B2 (en)* | 2006-02-24 | 2012-01-24 | Microsoft Corporation | Identity providers in digital identity system |
| US20070203852A1 (en)* | 2006-02-24 | 2007-08-30 | Microsoft Corporation | Identity information including reputation information |
| US8085671B2 (en)* | 2006-02-27 | 2011-12-27 | Cisco Technology, Inc. | Method and system for providing interoperable communications with congestion management |
| US8260338B2 (en) | 2006-02-28 | 2012-09-04 | Cisco Technology, Inc. | Method and system for providing interoperable communications with dynamic event area allocation |
| JP4933292B2 (en)* | 2006-02-28 | 2012-05-16 | キヤノン株式会社 | Information processing apparatus, wireless communication method, storage medium, program |
| US20070205275A1 (en)* | 2006-03-06 | 2007-09-06 | First Data Corporation | Portable point of sale systems and methods |
| US8452961B2 (en)* | 2006-03-07 | 2013-05-28 | Samsung Electronics Co., Ltd. | Method and system for authentication between electronic devices with minimal user intervention |
| US7730192B2 (en)* | 2006-03-20 | 2010-06-01 | Microsoft Corporation | Managing parallel requests in a communications environment supporting serial and parallel request handlers |
| US20070228147A1 (en)* | 2006-03-30 | 2007-10-04 | Reporo Limited | Application generation system, method and machine readable medium |
| US7818264B2 (en) | 2006-06-19 | 2010-10-19 | Visa U.S.A. Inc. | Track data encryption |
| US9112746B2 (en)* | 2006-04-05 | 2015-08-18 | Cisco Technology, Inc. | Method and system for managing virtual talk groups |
| US9065643B2 (en) | 2006-04-05 | 2015-06-23 | Visa U.S.A. Inc. | System and method for account identifier obfuscation |
| JP2007286697A (en)* | 2006-04-12 | 2007-11-01 | Mastercard Internatl Japan Inc | Payment processing support device and payment processing support method |
| US8992304B2 (en) | 2006-04-13 | 2015-03-31 | Igt | Methods and systems for tracking an event of an externally controlled interface |
| US9028329B2 (en) | 2006-04-13 | 2015-05-12 | Igt | Integrating remotely-hosted and locally rendered content on a gaming device |
| US8784196B2 (en) | 2006-04-13 | 2014-07-22 | Igt | Remote content management and resource sharing on a gaming machine and method of implementing same |
| US10026255B2 (en) | 2006-04-13 | 2018-07-17 | Igt | Presentation of remotely-hosted and locally rendered content for gaming systems |
| US8437751B2 (en)* | 2006-04-25 | 2013-05-07 | Core Wireless Licensing S.A.R.L. | Method, apparatus and computer program product for providing confirmed over-the-air terminal configuration |
| US7904718B2 (en) | 2006-05-05 | 2011-03-08 | Proxense, Llc | Personal digital key differentiation for secure transactions |
| US7860070B2 (en)* | 2006-05-10 | 2010-12-28 | Cisco Technology, Inc. | Providing multiple virtual talk group communication sessions |
| ATE524909T1 (en)* | 2006-05-17 | 2011-09-15 | Deutsche Telekom Ag | METHOD AND DEVICES FOR ENHANCEMENT OF VOICE CALLS AND SEMANTIC COMBINATION OF SEVERAL SERVICE SESSIONS INTO A VIRTUAL COMBINED SERVICE SESSION |
| US7831270B2 (en)* | 2006-05-18 | 2010-11-09 | Cisco Technology, Inc. | Providing virtual talk group communication sessions in accordance with endpoint resources |
| US7639634B2 (en)* | 2006-06-02 | 2009-12-29 | Cisco Technology, Inc. | Method and System for Joining a virtual talk group |
| US20070280203A1 (en)* | 2006-06-02 | 2007-12-06 | Shmuel Shaffer | Method and System for Managing a Plurality of Virtual Talk Groups |
| CN101090397B (en) | 2006-06-13 | 2010-12-15 | 国际商业机器公司 | Method, device and computer system for performing transactions between a client and a server |
| US8914493B2 (en) | 2008-03-10 | 2014-12-16 | Oracle International Corporation | Presence-based event driven architecture |
| US7881315B2 (en)* | 2006-06-27 | 2011-02-01 | Microsoft Corporation | Local peer-to-peer digital content distribution |
| WO2008005300A2 (en)* | 2006-06-29 | 2008-01-10 | Wms Gaming Inc. | Wagering game funding mechanisms and methods therefor |
| US20080002710A1 (en)* | 2006-06-29 | 2008-01-03 | Motorola, Inc. | System and method for routing communications to mobile stations |
| US8393955B2 (en) | 2006-06-29 | 2013-03-12 | Wms Gaming Inc. | Player wagering account and methods thereof |
| US8437757B2 (en)* | 2006-06-30 | 2013-05-07 | Nokia Corporation | Systems for providing peer-to-peer communications |
| US9008620B2 (en)* | 2006-07-19 | 2015-04-14 | Samsung Electronics Co., Ltd. | Mobile device service authorization system and method |
| US8400947B2 (en)* | 2006-07-20 | 2013-03-19 | Tekelec, Inc. | Methods, systems, and computer program products for specifying a particular ENUM service type in a communications network that utilizes a plurality of different ENUM service types |
| US11062342B2 (en) | 2006-07-27 | 2021-07-13 | Blackhawk Network, Inc. | System and method for targeted marketing and consumer resource management |
| JP2008035250A (en)* | 2006-07-28 | 2008-02-14 | Fujitsu Ltd | Information service control system |
| US8078880B2 (en)* | 2006-07-28 | 2011-12-13 | Microsoft Corporation | Portable personal identity information |
| US8190507B2 (en)* | 2006-07-31 | 2012-05-29 | Wms Gaming Inc. | Cash-out methods and systems yielding enhanced time-deferred value |
| US8036366B2 (en)* | 2006-08-04 | 2011-10-11 | Microsoft Corporation | Intelligent formatting of VoIP telephone numbers |
| US8074271B2 (en) | 2006-08-09 | 2011-12-06 | Assa Abloy Ab | Method and apparatus for making a decision on a card |
| US9985950B2 (en) | 2006-08-09 | 2018-05-29 | Assa Abloy Ab | Method and apparatus for making a decision on a card |
| US20080040262A1 (en)* | 2006-08-10 | 2008-02-14 | Integra Micro Systems (P) Ltd | Voice authenticated financial transaction |
| US7469151B2 (en)* | 2006-09-01 | 2008-12-23 | Vivotech, Inc. | Methods, systems and computer program products for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities |
| US8165635B2 (en)* | 2006-09-01 | 2012-04-24 | Vivotech, Inc. | Methods, systems, and computer readable media for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities |
| US11195163B2 (en)* | 2006-09-01 | 2021-12-07 | Mastercard International Incorporated | Methods, systems and computer readable media for over the air (OTA) provisioning of soft cards on devices with wireless communications capabilities |
| US8909553B2 (en)* | 2006-09-06 | 2014-12-09 | Transaction Wireless, Inc. | Payment card terminal for mobile phones |
| US20080066181A1 (en)* | 2006-09-07 | 2008-03-13 | Microsoft Corporation | DRM aspects of peer-to-peer digital content distribution |
| US20090298514A1 (en)* | 2006-09-14 | 2009-12-03 | Shah Ullah | Real world behavior measurement using identifiers specific to mobile devices |
| US20080109888A1 (en)* | 2006-09-14 | 2008-05-08 | Shah Ullah | Methods and systems for securing content projected to a nearby device |
| US20080220760A1 (en)* | 2006-09-14 | 2008-09-11 | Shah Ullah | Methods and systems for usage profiling associated with device specific identifiers |
| US20080133327A1 (en)* | 2006-09-14 | 2008-06-05 | Shah Ullah | Methods and systems for securing content played on mobile devices |
| US9445353B2 (en) | 2006-09-14 | 2016-09-13 | Omnitrail Technologies Inc. | Presence platform for passive radio access network-to-radio access network device transition |
| US7548203B2 (en)* | 2006-09-15 | 2009-06-16 | Nokia Corporation | Performance and power management in direction of arrival determination by utilizing sensor information |
| US10210516B2 (en)* | 2006-09-24 | 2019-02-19 | Rfcyber Corp. | Mobile devices for commerce over unsecured networks |
| US9015075B2 (en) | 2006-09-29 | 2015-04-21 | Oracle America, Inc. | Method and apparatus for secure information distribution |
| US7958291B2 (en)* | 2006-10-10 | 2011-06-07 | Atmel Rousset S.A.S. | Supplemental communication interface |
| US20080090520A1 (en)* | 2006-10-17 | 2008-04-17 | Camp William O | Apparatus and methods for communication mobility management using near-field communications |
| US8570909B1 (en) | 2006-10-17 | 2013-10-29 | Cisco Technology, Inc. | Method and system for providing an indication of a communication |
| US8090366B2 (en) | 2006-10-19 | 2012-01-03 | At&T Mobility Ii Llc | Systems and methods for file sharing through mobile devices |
| US8335543B1 (en)* | 2006-10-24 | 2012-12-18 | Sprint Spectrum L.P. | Content management in wireless devices with saving of content settings |
| US8966619B2 (en)* | 2006-11-08 | 2015-02-24 | Verizon Patent And Licensing Inc. | Prevention of denial of service (DoS) attacks on session initiation protocol (SIP)-based systems using return routability check filtering |
| US9473529B2 (en) | 2006-11-08 | 2016-10-18 | Verizon Patent And Licensing Inc. | Prevention of denial of service (DoS) attacks on session initiation protocol (SIP)-based systems using method vulnerability filtering |
| US9311774B2 (en) | 2006-11-10 | 2016-04-12 | Igt | Gaming machine with externally controlled content display |
| US20090156303A1 (en) | 2006-11-10 | 2009-06-18 | Igt | Bonusing Architectures in a Gaming Environment |
| US9269221B2 (en) | 2006-11-13 | 2016-02-23 | John J. Gobbi | Configuration of interfaces for a location detection system and application |
| US7942738B2 (en)* | 2006-11-15 | 2011-05-17 | Cfph, Llc | Verifying a gaming device is in communications with a gaming server |
| US7942739B2 (en) | 2006-11-15 | 2011-05-17 | Cfph, Llc | Storing information from a verification device and accessing the information from a gaming device to verify that the gaming device is communicating with a server |
| US7942740B2 (en)* | 2006-11-15 | 2011-05-17 | Cfph, Llc | Verifying a first device is in communications with a server by storing a value from the first device and accessing the value from a second device |
| US10068421B2 (en)* | 2006-11-16 | 2018-09-04 | Cfph, Llc | Using a first device to verify whether a second device is communicating with a server |
| US7942741B2 (en)* | 2006-11-15 | 2011-05-17 | Cfph, Llc | Verifying whether a device is communicating with a server |
| US8012015B2 (en) | 2006-11-15 | 2011-09-06 | Cfph, Llc | Verifying whether a gaming device is communicating with a gaming server |
| US7942742B2 (en)* | 2006-11-15 | 2011-05-17 | Cfph, Llc | Accessing identification information to verify a gaming device is in communications with a server |
| US8874725B1 (en) | 2006-11-15 | 2014-10-28 | Conviva Inc. | Monitoring the performance of a content player |
| TW200835186A (en)* | 2006-11-15 | 2008-08-16 | Nxp Bv | Near field communication (NFC) activation |
| US9047465B2 (en)* | 2006-11-22 | 2015-06-02 | At&T Intellectual Property I, L.P. | Methods and apparatus for automatic security checking in systems that monitor for improper network usage |
| US20080126258A1 (en)* | 2006-11-27 | 2008-05-29 | Qualcomm Incorporated | Authentication of e-commerce transactions using a wireless telecommunications device |
| JP2008141400A (en)* | 2006-11-30 | 2008-06-19 | Sony Ericsson Mobilecommunications Japan Inc | Communication system, communication terminal, and communication method |
| CN101689230A (en) | 2006-12-05 | 2010-03-31 | 安全第一公司 | Improved Tape Backup Method |
| US20080137859A1 (en)* | 2006-12-06 | 2008-06-12 | Ramanathan Jagadeesan | Public key passing |
| US8190885B2 (en)* | 2006-12-21 | 2012-05-29 | Spansion Llc | Non-volatile memory sub-system integrated with security for storing near field transactions |
| WO2008079375A1 (en)* | 2006-12-22 | 2008-07-03 | Telcordia Technologies, Inc. | Flexible mobility framework for heterogeneous roaming in next generation wireless networks |
| US8805743B2 (en)* | 2006-12-27 | 2014-08-12 | International Business Machines Corporation | Tracking, distribution and management of apportionable licenses granted for distributed software products |
| US8189460B2 (en)* | 2006-12-28 | 2012-05-29 | Cisco Technology, Inc. | Method and system for providing congestion management within a virtual talk group |
| US20080165706A1 (en)* | 2007-01-05 | 2008-07-10 | Bruno Bozionek | Destination service selection for a telephone |
| US8019320B2 (en) | 2007-01-05 | 2011-09-13 | Macronix International Co., Ltd. | System and method of managing contactless payment transactions using a mobile communication device as a stored value device |
| JP5301463B2 (en)* | 2007-01-09 | 2013-09-25 | ビザ ユー．エス．エー．インコーポレイテッド | Mobile phone payment process including threshold indicator |
| CN101657836A (en)* | 2007-01-09 | 2010-02-24 | 维萨美国股份有限公司 | Mobile phone payment process including threshold indicator |
| US10045327B2 (en)* | 2007-01-17 | 2018-08-07 | Eagency, Inc. | Mobile communication device monitoring systems and methods |
| US8087072B2 (en)* | 2007-01-18 | 2011-12-27 | Microsoft Corporation | Provisioning of digital identity representations |
| US8407767B2 (en)* | 2007-01-18 | 2013-03-26 | Microsoft Corporation | Provisioning of digital identity representations |
| US8689296B2 (en)* | 2007-01-26 | 2014-04-01 | Microsoft Corporation | Remote access of digital identities |
| US20080189554A1 (en)* | 2007-02-05 | 2008-08-07 | Asad Ali | Method and system for securing communication between a host computer and a secure portable device |
| US20080208762A1 (en)* | 2007-02-22 | 2008-08-28 | First Data Corporation | Payments using a mobile commerce device |
| US20080208688A1 (en)* | 2007-02-22 | 2008-08-28 | First Data Corporation | Methods and systems for handling of mobile discount certificates using mobile devices |
| US8566239B2 (en)* | 2007-02-22 | 2013-10-22 | First Data Corporation | Mobile commerce systems and methods |
| US10102518B2 (en)* | 2007-02-22 | 2018-10-16 | First Data Corporation | Enrollment and registration of a device in a mobile commerce system |
| US20080208741A1 (en)* | 2007-02-22 | 2008-08-28 | First Data Corporation | Account information lookup systems and methods in mobile commerce |
| US20080208742A1 (en)* | 2007-02-22 | 2008-08-28 | First Data Corporation | Provisioning of a device for mobile commerce |
| US20080207234A1 (en)* | 2007-02-22 | 2008-08-28 | First Data Corporation | Marketing messages in mobile commerce |
| US9055150B2 (en)* | 2007-02-28 | 2015-06-09 | International Business Machines Corporation | Skills based routing in a standards based contact center using a presence server and expertise specific watchers |
| WO2008104981A2 (en)* | 2007-03-01 | 2008-09-04 | Sandlinks Systems Ltd. | Array of very light readers for active rfid and location applications |
| US10489794B2 (en)* | 2007-03-05 | 2019-11-26 | Electronic Credit Systems Corporation | Business to business marketing system |
| US20080223469A1 (en)* | 2007-03-13 | 2008-09-18 | Hillel David Renassia | Multiple conduit-repair method |
| US8214503B2 (en) | 2007-03-23 | 2012-07-03 | Oracle International Corporation | Factoring out dialog control and call control |
| JP4834595B2 (en)* | 2007-04-03 | 2011-12-14 | 株式会社東芝 | Telephone system and gateway device |
| US8548908B2 (en)* | 2007-04-11 | 2013-10-01 | First Data Corporation | Mobile commerce infrastructure systems and methods |
| US8064597B2 (en)* | 2007-04-20 | 2011-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and system for mobile device credentialing |
| US20080263389A1 (en)* | 2007-04-20 | 2008-10-23 | At&T Knowledge Ventures, L.P. | System for monitoring enum performance |
| US9462060B2 (en)* | 2007-04-23 | 2016-10-04 | Alcatel Lucent | System and method for sending notification message to a mobile station using session initiation protocol (SIP) |
| EP1986161A1 (en)* | 2007-04-27 | 2008-10-29 | Italdata Ingegneria Dell'Idea S.p.A. | Data survey device, integrated with a communication system, and related method |
| US7706750B2 (en)* | 2007-05-07 | 2010-04-27 | Dell Products L.P. | Enabling bluetooth support within a secondary and/or across multiple operating system partitions |
| US7845568B2 (en)* | 2007-05-09 | 2010-12-07 | Atmel Rousset S.A.S. | Managing power and timing in a smart card device |
| US8874159B2 (en)* | 2007-05-10 | 2014-10-28 | Cisco Technology, Inc. | Method and system for handling dynamic incidents |
| US8725883B2 (en)* | 2007-05-11 | 2014-05-13 | Nokia Corporation | Method for the establishing of peer-to-peer multimedia sessions in a communication system |
| GB2450193A (en)* | 2007-06-12 | 2008-12-17 | Cvon Innovations Ltd | Method and system for managing credits via a mobile device |
| US20080313079A1 (en)* | 2007-06-14 | 2008-12-18 | Motorola, Inc. | System and method for proximity payment transaction between a wireless communication device and a point of sale terminal in conjunction with a trusted party |
| US20080313082A1 (en)* | 2007-06-14 | 2008-12-18 | Motorola, Inc. | Method and apparatus for proximity payment provisioning between a wireless communication device and a trusted party |
| US9342823B2 (en)* | 2007-06-18 | 2016-05-17 | Lemon, Inc. | Payment clearing network for electronic financial transactions and related personal financial transaction device |
| US7945959B2 (en)* | 2007-06-18 | 2011-05-17 | International Business Machines Corporation | Secure physical distribution of a security token through a mobile telephony provider's infrastructure |
| US8746581B2 (en) | 2007-06-19 | 2014-06-10 | Codebroker, Llc | Techniques for providing an electronic representation of a card |
| US20080320566A1 (en)* | 2007-06-25 | 2008-12-25 | Microsoft Corporation | Device provisioning and domain join emulation over non-secured networks |
| US8302186B2 (en) | 2007-06-29 | 2012-10-30 | Verizon Patent And Licensing Inc. | System and method for testing network firewall for denial-of-service (DOS) detection and prevention in signaling channel |
| US7930249B2 (en)* | 2007-07-11 | 2011-04-19 | Qualcomm Incorporated | Mobile wireless financial instrument for automatically selecting a payment instrument |
| US8694787B2 (en)* | 2007-08-07 | 2014-04-08 | Christophe Niglio | Apparatus and method for securing digital data with a security token |
| US20090049087A1 (en)* | 2007-08-17 | 2009-02-19 | Tekelec | Methods, systems, and computer program products for providing a universal uniform resource identifier (UURI) |
| US20140049360A1 (en)* | 2007-08-24 | 2014-02-20 | Assa Abloy Ab | Data collection using a credential |
| US9548973B2 (en) | 2007-08-24 | 2017-01-17 | Assa Abloy Ab | Detecting and responding to an atypical behavior |
| US8109444B2 (en)* | 2007-09-12 | 2012-02-07 | Devicefidelity, Inc. | Selectively switching antennas of transaction cards |
| CA2702803C (en)* | 2007-09-14 | 2016-12-13 | Steven D. Cabouli | Smart wallet |
| US8249935B1 (en) | 2007-09-27 | 2012-08-21 | Sprint Communications Company L.P. | Method and system for blocking confidential information at a point-of-sale reader from eavesdropping |
| US8094812B1 (en)* | 2007-09-28 | 2012-01-10 | Juniper Networks, Inc. | Updating stored passwords |
| US9883381B1 (en) | 2007-10-02 | 2018-01-30 | Sprint Communications Company L.P. | Providing secure access to smart card applications |
| US8774174B2 (en) | 2007-10-11 | 2014-07-08 | At&T Intellectual Property I, Lp | System and method for conveying end-to-end call status |
| US9177313B1 (en)* | 2007-10-18 | 2015-11-03 | Jpmorgan Chase Bank, N.A. | System and method for issuing, circulating and trading financial instruments with smart features |
| WO2009070430A2 (en)* | 2007-11-08 | 2009-06-04 | Suridx, Inc. | Apparatus and methods for providing scalable, dynamic, individualized credential services using mobile telephones |
| US8659427B2 (en) | 2007-11-09 | 2014-02-25 | Proxense, Llc | Proximity-sensor supporting multiple application services |
| US8539097B2 (en) | 2007-11-14 | 2013-09-17 | Oracle International Corporation | Intelligent message processing |
| US20090127334A1 (en)* | 2007-11-19 | 2009-05-21 | Korea Information & Communications Co.,Ltd. | Method for Processing Settlement by VoIP Terminal and Recording Medium |
| US8161171B2 (en)* | 2007-11-20 | 2012-04-17 | Oracle International Corporation | Session initiation protocol-based internet protocol television |
| US9098844B2 (en) | 2007-11-20 | 2015-08-04 | Wells Fargo Bank, N.A. | Mobile electronic wallet |
| US9130963B2 (en)* | 2011-04-06 | 2015-09-08 | Telecommunication Systems, Inc. | Ancillary data support in session initiation protocol (SIP) messaging |
| US9424562B2 (en)* | 2007-11-30 | 2016-08-23 | U.S. Bank National Association | Profile-based arrangements and methods for disparate network systems |
| US8126806B1 (en) | 2007-12-03 | 2012-02-28 | Sprint Communications Company L.P. | Method for launching an electronic wallet |
| US7848982B2 (en)* | 2007-12-04 | 2010-12-07 | Jiafeng Zhu | Method and system of aggregating consideration associated with a request |
| US8346641B2 (en)* | 2007-12-04 | 2013-01-01 | Jiafeng Zhu | Method and system of aggregating consideration associated with a request |
| US8171528B1 (en) | 2007-12-06 | 2012-05-01 | Proxense, Llc | Hybrid device having a personal digital key and receiver-decoder circuit and methods of use |
| US8165116B2 (en)* | 2007-12-12 | 2012-04-24 | At&T Intellectual Property I, L.P. | Method and system to provide contact services in a communication network |
| US9251332B2 (en)* | 2007-12-19 | 2016-02-02 | Proxense, Llc | Security system and method for controlling access to computing resources |
| US20090171773A1 (en)* | 2007-12-26 | 2009-07-02 | Vishwanath Shastry | System and method for administering a value vault for use in facilitating a financial transaction |
| US8794532B2 (en)* | 2008-12-29 | 2014-08-05 | Mastercard International Incorporated | Methods and apparatus for use in association with identification token |
| WO2009083999A1 (en)* | 2007-12-31 | 2009-07-09 | Onmobile Global Limited | Method and system for authenticating commercial transaction in a telecommunication network |
| EP2245832B1 (en) | 2008-01-07 | 2016-01-06 | Unify GmbH & Co. KG | Method for authenticating key information between terminals of a communication link |
| GB2456184A (en)* | 2008-01-07 | 2009-07-08 | Cvon Innovations Ltd | System for selecting an information provider or service provider |
| CN101483613B (en)* | 2008-01-09 | 2012-02-15 | 国际商业机器公司 | Method and device for providing QoS control capability to presenting server, and system thereof |
| US8107921B2 (en) | 2008-01-11 | 2012-01-31 | Seven Networks, Inc. | Mobile virtual network operator |
| US8914901B2 (en)* | 2008-01-11 | 2014-12-16 | Microsoft Corporation | Trusted storage and display |
| EP2250791B1 (en)* | 2008-01-11 | 2016-08-10 | Telefonaktiebolaget LM Ericsson (publ) | Securing contact information |
| US20090198618A1 (en)* | 2008-01-15 | 2009-08-06 | Yuen Wah Eva Chan | Device and method for loading managing and using smartcard authentication token and digital certificates in e-commerce |
| US9654515B2 (en) | 2008-01-23 | 2017-05-16 | Oracle International Corporation | Service oriented architecture-based SCIM platform |
| US8589338B2 (en)* | 2008-01-24 | 2013-11-19 | Oracle International Corporation | Service-oriented architecture (SOA) management of data repository |
| US20090193507A1 (en)* | 2008-01-28 | 2009-07-30 | Wael Ibrahim | Authentication messaging service |
| US8055184B1 (en) | 2008-01-30 | 2011-11-08 | Sprint Communications Company L.P. | System and method for active jamming of confidential information transmitted at a point-of-sale reader |
| US7778992B2 (en)* | 2008-01-31 | 2010-08-17 | International Business Machines Corporation | Computing resource selection method and system |
| US8083140B1 (en) | 2008-02-05 | 2011-12-27 | Sprint Communications Company L.P. | System and method of over-the-air provisioning |
| US8401022B2 (en) | 2008-02-08 | 2013-03-19 | Oracle International Corporation | Pragmatic approaches to IMS |
| WO2009102979A2 (en) | 2008-02-14 | 2009-08-20 | Proxense, Llc | Proximity-based healthcare management system with automatic access to private information |
| US7856448B2 (en)* | 2008-02-14 | 2010-12-21 | International Business Machines Corporation | Access control decision method and system |
| EP2245534B1 (en)* | 2008-02-18 | 2015-09-16 | BlackBerry Limited | System and method for resolving extensions for the sip session policy framework |
| US8214298B2 (en)* | 2008-02-26 | 2012-07-03 | Rfinity Corporation | Systems and methods for performing wireless financial transactions |
| US8204827B1 (en) | 2008-03-27 | 2012-06-19 | Amazon Technologies, Inc. | System and method for personalized commands |
| US8620826B2 (en)* | 2008-03-27 | 2013-12-31 | Amazon Technologies, Inc. | System and method for receiving requests for tasks from unregistered devices |
| US8301500B2 (en)* | 2008-04-02 | 2012-10-30 | Global 1 Enterprises | Ghosting payment account data in a mobile telephone payment transaction system |
| US20090253409A1 (en)* | 2008-04-07 | 2009-10-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of Authenticating Home Operator for Over-the-Air Provisioning of a Wireless Device |
| EP2266293A1 (en)* | 2008-04-07 | 2010-12-29 | Nokia Siemens Networks OY | Apparatus, method, system and program for secure communication |
| WO2009126732A2 (en) | 2008-04-08 | 2009-10-15 | Proxense, Llc | Automated service-based order processing |
| US8655310B1 (en) | 2008-04-08 | 2014-02-18 | Sprint Communications Company L.P. | Control of secure elements through point-of-sale device |
| US8635132B1 (en)* | 2008-04-14 | 2014-01-21 | United Services Automobile Associatiion (USAA) | Self-service real-time financial advice |
| US9002955B2 (en)* | 2008-04-25 | 2015-04-07 | Zte Corporation | Carrier-grade Peer-to-Peer (P2P) network, system and method |
| US8280415B2 (en) | 2008-05-06 | 2012-10-02 | International Business Machines Corporation | Performing caller based routing of a phone call |
| US9049293B2 (en)* | 2008-05-06 | 2015-06-02 | International Business Machines Corporation | Performing proximity based routing of a phone call |
| US8345837B2 (en)* | 2008-05-06 | 2013-01-01 | International Business Machines Corporation | Preventing unintended users from accessing a re-routed communication |
| US8244282B2 (en)* | 2008-05-06 | 2012-08-14 | International Business Machines Corporation | Performing recipient based routing of a phone call |
| US8718042B2 (en)* | 2008-05-08 | 2014-05-06 | Microsoft Corporation | Extensible and secure transmission of multiple conversation contexts |
| US11080678B2 (en) | 2008-05-09 | 2021-08-03 | Verient, Inc. | Payment processing platform |
| US9953313B2 (en) | 2008-05-09 | 2018-04-24 | Verient, Inc. | System and method for distributed payment products |
| US8340634B2 (en) | 2009-01-28 | 2012-12-25 | Headwater Partners I, Llc | Enhanced roaming services and converged carrier networks with device assisted services and a proxy |
| US8626115B2 (en) | 2009-01-28 | 2014-01-07 | Headwater Partners I Llc | Wireless network service interfaces |
| US8548428B2 (en) | 2009-01-28 | 2013-10-01 | Headwater Partners I Llc | Device group partitions and settlement platform |
| US8275830B2 (en) | 2009-01-28 | 2012-09-25 | Headwater Partners I Llc | Device assisted CDR creation, aggregation, mediation and billing |
| US8402111B2 (en) | 2009-01-28 | 2013-03-19 | Headwater Partners I, Llc | Device assisted services install |
| US8589541B2 (en) | 2009-01-28 | 2013-11-19 | Headwater Partners I Llc | Device-assisted services for protecting network capacity |
| US8725123B2 (en) | 2008-06-05 | 2014-05-13 | Headwater Partners I Llc | Communications device with secure data path processing agents |
| US8635335B2 (en) | 2009-01-28 | 2014-01-21 | Headwater Partners I Llc | System and method for wireless network offloading |
| US8406748B2 (en) | 2009-01-28 | 2013-03-26 | Headwater Partners I Llc | Adaptive ambient services |
| US8898293B2 (en) | 2009-01-28 | 2014-11-25 | Headwater Partners I Llc | Service offer set publishing to device agent with on-device service selection |
| US8391834B2 (en) | 2009-01-28 | 2013-03-05 | Headwater Partners I Llc | Security techniques for device assisted services |
| US8832777B2 (en) | 2009-03-02 | 2014-09-09 | Headwater Partners I Llc | Adapting network policies based on device service processor configuration |
| US8346225B2 (en) | 2009-01-28 | 2013-01-01 | Headwater Partners I, Llc | Quality of service for device assisted services |
| US8924543B2 (en) | 2009-01-28 | 2014-12-30 | Headwater Partners I Llc | Service design center for device assisted services |
| US8924469B2 (en) | 2008-06-05 | 2014-12-30 | Headwater Partners I Llc | Enterprise access control and accounting allocation for access networks |
| US8250207B2 (en) | 2009-01-28 | 2012-08-21 | Headwater Partners I, Llc | Network based ambient services |
| US8478692B2 (en) | 2008-06-26 | 2013-07-02 | Visa International Service Association | Systems and methods for geographic location notifications of payment transactions |
| US20090327135A1 (en)* | 2008-06-26 | 2009-12-31 | Loc Duc Nguyen | Credit card paired with location identifiable device for point of service fraud detection |
| US9542687B2 (en) | 2008-06-26 | 2017-01-10 | Visa International Service Association | Systems and methods for visual representation of offers |
| US9824366B2 (en) | 2008-07-08 | 2017-11-21 | First Data Corporation | Customer pre-selected electronic coupons |
| US20100011110A1 (en)* | 2008-07-14 | 2010-01-14 | Nokia Corporation | Mobile terminal to media server connection apparatus, system, and method |
| US20100293374A1 (en)* | 2008-07-30 | 2010-11-18 | Bushby Donald P | Secure Portable Memory Storage Device |
| US8308058B2 (en)* | 2008-07-31 | 2012-11-13 | Sybase, Inc. | Mobile banking architecture |
| CN106407758A (en)* | 2008-07-31 | 2017-02-15 | 高通股份有限公司 | Unlocking of locked user equipment by use of unlocking code generated by computer and provided by user |
| US8740073B2 (en)* | 2008-08-01 | 2014-06-03 | Mastercard International Incorporated | Methods, systems and computer readable media for storing and redeeming electronic certificates using a wireless smart card |
| US8620299B2 (en)* | 2008-08-12 | 2013-12-31 | Mastercard International Incorporated | Methods, systems and computer readable media for electronically delivering a prepaid card to a mobile device |
| US8279851B2 (en)* | 2008-08-15 | 2012-10-02 | Nokia Corporation | Apparatus, system, and method for obtaining local connectivity settings |
| US10819530B2 (en) | 2008-08-21 | 2020-10-27 | Oracle International Corporation | Charging enabler |
| US8751376B1 (en)* | 2008-09-15 | 2014-06-10 | Galileo Processing, Inc. | Financial instrument having credit and pre-paid characteristics |
| US8408454B2 (en)* | 2008-09-16 | 2013-04-02 | Visa U.S.A. Inc. | Multifunctional portable consumer payment device |
| US9639852B2 (en)* | 2008-09-24 | 2017-05-02 | Paypal, Inc. | GUI-based wallet program for online transactions |
| CA2738457A1 (en) | 2008-09-25 | 2010-04-01 | Visa International Service Association | Systems and methods for sorting alert and offer messages on a mobile device |
| WO2010037204A1 (en)* | 2008-10-03 | 2010-04-08 | Consumer Mt Inc. | System and method for providing a universal electronic wallet |
| CN102257524A (en) | 2008-10-06 | 2011-11-23 | 维沃科技公司 | System, method and computer readable medium for payment and non-payment virtual card transfer between mobile devices |
| US8402519B2 (en) | 2008-10-16 | 2013-03-19 | Verisign, Inc. | Transparent client authentication |
| US8706588B1 (en) | 2008-10-20 | 2014-04-22 | Sprint Communications Company L.P. | System and method of provisioning confidential information via a mobile device |
| US8875261B2 (en)* | 2008-10-22 | 2014-10-28 | International Business Machines Corporation | Rules driven multiple passwords |
| KR101619736B1 (en)* | 2008-10-23 | 2016-05-12 | 삼성전자주식회사 | Method, apparatus and system for manageing private network remotely using session initiation protocol |
| US10867298B1 (en) | 2008-10-31 | 2020-12-15 | Wells Fargo Bank, N.A. | Payment vehicle with on and off function |
| US20100114768A1 (en) | 2008-10-31 | 2010-05-06 | Wachovia Corporation | Payment vehicle with on and off function |
| US9462411B2 (en)* | 2008-11-04 | 2016-10-04 | Telcom Ventures, Llc | Mobile device mode enablement responsive to a proximity criterion |
| EP2461297B1 (en)* | 2008-11-12 | 2020-10-07 | Idemia Denmark A/S | Personal identification number distribution device and method |
| US8024777B2 (en)* | 2008-11-20 | 2011-09-20 | Mark Kevin Shull | Domain based authentication scheme |
| US20100131409A1 (en)* | 2008-11-22 | 2010-05-27 | Google Inc. | Identification verification with user challenge |
| US9154942B2 (en)* | 2008-11-26 | 2015-10-06 | Free Stream Media Corp. | Zero configuration communication between a browser and a networked media device |
| US20100145861A1 (en)* | 2008-12-08 | 2010-06-10 | Palm, Inc. | Payment transaction processing for mobile computing devices |
| US8370502B2 (en)* | 2008-12-12 | 2013-02-05 | At&T Intellectual Property I, L.P. | Method and apparatus for completing a circuit switched service call in an internet protocol network |
| EP2197167B1 (en)* | 2008-12-12 | 2017-07-12 | Vodafone Holding GmbH | Device and method for short range communication |
| US9842356B2 (en)* | 2008-12-17 | 2017-12-12 | Iii Holdings 1, Llc | System, method, apparatus and computer program product for interfacing a multi-card radio frequency (RF) device with a mobile communications device |
| US20100161727A1 (en)* | 2008-12-19 | 2010-06-24 | Cisco Technology, Inc. | System and Method for Accelerating a Wide Area Notification |
| US8041378B2 (en) | 2008-12-19 | 2011-10-18 | Cisco Technology, Inc. | System and method for providing channel configurations in a communications environment |
| US8126494B2 (en)* | 2008-12-19 | 2012-02-28 | Cisco Technology, Inc. | System and method for providing a trunked radio and gateway |
| US20100174598A1 (en)* | 2008-12-31 | 2010-07-08 | Mohammad Khan | Methods, systems and computer readable media for redeeming and delivering electronic loyalty reward certificates using a mobile device |
| US8380989B2 (en) | 2009-03-05 | 2013-02-19 | Sybase, Inc. | System and method for second factor authentication |
| US9209994B2 (en)* | 2008-12-31 | 2015-12-08 | Sybase, Inc. | System and method for enhanced application server |
| US8903434B2 (en)* | 2008-12-31 | 2014-12-02 | Sybase, Inc. | System and method for message-based conversations |
| US9100222B2 (en)* | 2008-12-31 | 2015-08-04 | Sybase, Inc. | System and method for mobile user authentication |
| US8060449B1 (en)* | 2009-01-05 | 2011-11-15 | Sprint Communications Company L.P. | Partially delegated over-the-air provisioning of a secure element |
| US8200582B1 (en) | 2009-01-05 | 2012-06-12 | Sprint Communications Company L.P. | Mobile device password system |
| US20120004967A1 (en)* | 2009-01-21 | 2012-01-05 | Billshrink, Inc. | System and method for providing a future reward through a user financial instrument |
| US20120004969A1 (en)* | 2009-01-21 | 2012-01-05 | Billshrink, Inc. | System and method for providing a geo-enhanced savings opportunity in association with a financial account |
| US8600857B2 (en) | 2009-01-21 | 2013-12-03 | Truaxis, Inc. | System and method for providing a savings opportunity in association with a financial account |
| US8566197B2 (en) | 2009-01-21 | 2013-10-22 | Truaxis, Inc. | System and method for providing socially enabled rewards through a user financial instrument |
| US10594870B2 (en) | 2009-01-21 | 2020-03-17 | Truaxis, Llc | System and method for matching a savings opportunity using census data |
| US10504126B2 (en) | 2009-01-21 | 2019-12-10 | Truaxis, Llc | System and method of obtaining merchant sales information for marketing or sales teams |
| US20110137785A1 (en)* | 2009-12-04 | 2011-06-09 | Lutnick Howard W | Multicomputer distributed processing of trading information |
| US10841839B2 (en) | 2009-01-28 | 2020-11-17 | Headwater Research Llc | Security, fraud detection, and fraud mitigation in device-assisted services systems |
| US9392462B2 (en) | 2009-01-28 | 2016-07-12 | Headwater Partners I Llc | Mobile end-user device with agent limiting wireless data communication for specified background applications based on a stored policy |
| US12166596B2 (en) | 2009-01-28 | 2024-12-10 | Disney Enterprises, Inc. | Device-assisted services for protecting network capacity |
| US9572019B2 (en) | 2009-01-28 | 2017-02-14 | Headwater Partners LLC | Service selection set published to device agent with on-device service selection |
| US8351898B2 (en) | 2009-01-28 | 2013-01-08 | Headwater Partners I Llc | Verifiable device assisted service usage billing with integrated accounting, mediation accounting, and multi-account |
| US10798252B2 (en) | 2009-01-28 | 2020-10-06 | Headwater Research Llc | System and method for providing user notifications |
| US10326800B2 (en) | 2009-01-28 | 2019-06-18 | Headwater Research Llc | Wireless network service interfaces |
| US9270559B2 (en) | 2009-01-28 | 2016-02-23 | Headwater Partners I Llc | Service policy implementation for an end-user device having a control application or a proxy agent for routing an application traffic flow |
| US9351193B2 (en) | 2009-01-28 | 2016-05-24 | Headwater Partners I Llc | Intermediate networking devices |
| US9253663B2 (en) | 2009-01-28 | 2016-02-02 | Headwater Partners I Llc | Controlling mobile device communications on a roaming network based on device state |
| US10715342B2 (en) | 2009-01-28 | 2020-07-14 | Headwater Research Llc | Managing service user discovery and service launch object placement on a device |
| US9609510B2 (en) | 2009-01-28 | 2017-03-28 | Headwater Research Llc | Automated credential porting for mobile devices |
| US11218854B2 (en) | 2009-01-28 | 2022-01-04 | Headwater Research Llc | Service plan design, user interfaces, application programming interfaces, and device management |
| US9557889B2 (en) | 2009-01-28 | 2017-01-31 | Headwater Partners I Llc | Service plan design, user interfaces, application programming interfaces, and device management |
| US10200541B2 (en) | 2009-01-28 | 2019-02-05 | Headwater Research Llc | Wireless end-user device with divided user space/kernel space traffic policy system |
| US8793758B2 (en) | 2009-01-28 | 2014-07-29 | Headwater Partners I Llc | Security, fraud detection, and fraud mitigation in device-assisted services systems |
| US10057775B2 (en) | 2009-01-28 | 2018-08-21 | Headwater Research Llc | Virtualized policy and charging system |
| US12388810B2 (en) | 2009-01-28 | 2025-08-12 | Headwater Research Llc | End user device that secures an association of application to service policy with an application certificate check |
| US10783581B2 (en) | 2009-01-28 | 2020-09-22 | Headwater Research Llc | Wireless end-user device providing ambient or sponsored services |
| US9955332B2 (en) | 2009-01-28 | 2018-04-24 | Headwater Research Llc | Method for child wireless device activation to subscriber account of a master wireless device |
| US11973804B2 (en) | 2009-01-28 | 2024-04-30 | Headwater Research Llc | Network service plan design |
| US9578182B2 (en) | 2009-01-28 | 2017-02-21 | Headwater Partners I Llc | Mobile device and service management |
| US9954975B2 (en) | 2009-01-28 | 2018-04-24 | Headwater Research Llc | Enhanced curfew and protection associated with a device group |
| US9980146B2 (en) | 2009-01-28 | 2018-05-22 | Headwater Research Llc | Communications device with secure data path processing agents |
| US10237757B2 (en) | 2009-01-28 | 2019-03-19 | Headwater Research Llc | System and method for wireless network offloading |
| US9565707B2 (en) | 2009-01-28 | 2017-02-07 | Headwater Partners I Llc | Wireless end-user device with wireless data attribution to multiple personas |
| US12432130B2 (en) | 2009-01-28 | 2025-09-30 | Headwater Research Llc | Flow tagging for service policy implementation |
| US10492102B2 (en) | 2009-01-28 | 2019-11-26 | Headwater Research Llc | Intermediate networking devices |
| US11985155B2 (en) | 2009-01-28 | 2024-05-14 | Headwater Research Llc | Communications device with secure data path processing agents |
| US10484858B2 (en) | 2009-01-28 | 2019-11-19 | Headwater Research Llc | Enhanced roaming services and converged carrier networks with device assisted services and a proxy |
| US9755842B2 (en) | 2009-01-28 | 2017-09-05 | Headwater Research Llc | Managing service user discovery and service launch object placement on a device |
| US8745191B2 (en) | 2009-01-28 | 2014-06-03 | Headwater Partners I Llc | System and method for providing user notifications |
| US12389218B2 (en) | 2009-01-28 | 2025-08-12 | Headwater Research Llc | Service selection set publishing to device agent with on-device service selection |
| US10248996B2 (en) | 2009-01-28 | 2019-04-02 | Headwater Research Llc | Method for operating a wireless end-user device mobile payment agent |
| US8606911B2 (en) | 2009-03-02 | 2013-12-10 | Headwater Partners I Llc | Flow tagging for service policy implementation |
| US9706061B2 (en) | 2009-01-28 | 2017-07-11 | Headwater Partners I Llc | Service design center for device assisted services |
| US9647918B2 (en) | 2009-01-28 | 2017-05-09 | Headwater Research Llc | Mobile device and method attributing media services network usage to requesting application |
| US8893009B2 (en) | 2009-01-28 | 2014-11-18 | Headwater Partners I Llc | End user device that secures an association of application to service policy with an application certificate check |
| US9858559B2 (en) | 2009-01-28 | 2018-01-02 | Headwater Research Llc | Network service plan design |
| US10779177B2 (en) | 2009-01-28 | 2020-09-15 | Headwater Research Llc | Device group partitions and settlement platform |
| US8364587B2 (en)* | 2009-01-28 | 2013-01-29 | First Data Corporation | Systems and methods for financial account access for a mobile device via a gateway |
| US10064055B2 (en)* | 2009-01-28 | 2018-08-28 | Headwater Research Llc | Security, fraud detection, and fraud mitigation in device-assisted services systems |
| US10264138B2 (en) | 2009-01-28 | 2019-04-16 | Headwater Research Llc | Mobile device and service management |
| US9092772B2 (en)* | 2009-02-16 | 2015-07-28 | Xius Corp. | Integrated system and method for enabling mobile commerce transactions using “contactless identity modules in mobile handsets” |
| WO2010094014A1 (en)* | 2009-02-16 | 2010-08-19 | Cellular Express Inc Dba Xius-Bcgi | Integrated system and method for enabling mobile commerce transactions using "contactless identity modules in mobile handsets" |
| US8768845B1 (en)* | 2009-02-16 | 2014-07-01 | Sprint Communications Company L.P. | Electronic wallet removal from mobile electronic devices |
| US8706628B2 (en)* | 2009-02-25 | 2014-04-22 | Mastercard International Incorporated | Automated opening of electronic wallet function in mobile device |
| US20100217682A1 (en)* | 2009-02-26 | 2010-08-26 | Research In Motion Limited | System and method for capturing user inputs in electronic forms |
| US7983951B2 (en) | 2009-03-02 | 2011-07-19 | Kabbage, Inc. | Apparatus to provide liquid funds in the online auction and marketplace environment |
| US11257149B2 (en) | 2009-03-02 | 2022-02-22 | American Express Kabbage Inc. | Method and apparatus to evaluate and provide funds in online environments |
| US10430873B2 (en) | 2009-03-02 | 2019-10-01 | Kabbage, Inc. | Method and apparatus to evaluate and provide funds in online environments |
| US9246955B2 (en)* | 2009-03-06 | 2016-01-26 | Telefonaktiebolaget L M Ericsson (Publ) | Capability query handling in a communication network |
| US10992817B2 (en)* | 2009-03-18 | 2021-04-27 | Mastercard International Incorporated | Methods, systems and computer readable media for selecting and delivering electronic value certificates using a mobile device |
| US9230259B1 (en) | 2009-03-20 | 2016-01-05 | Jpmorgan Chase Bank, N.A. | Systems and methods for mobile ordering and payment |
| US8462769B2 (en)* | 2009-03-26 | 2013-06-11 | Andrew Llc | System and method for managing created location contexts in a location server |
| US8391884B2 (en)* | 2009-03-26 | 2013-03-05 | Andrew Llc | System and method for managing created location contexts in a location server |
| US20110225045A1 (en)* | 2009-03-30 | 2011-09-15 | Yuh-Shen Song | Paperless Coupon Transactions System |
| US8201261B2 (en)* | 2009-04-27 | 2012-06-12 | Chase Barfield | Secure data storage system and method |
| WO2010127003A1 (en)* | 2009-04-28 | 2010-11-04 | Mastercard International Incorporated | Apparatus, method, and computer program product for encoding enhanced issuer information in a card |
| US8224375B2 (en)* | 2009-05-01 | 2012-07-17 | Qualcomm Incorporated | Proximity purchase ringtones |
| BRPI1013062A2 (en) | 2009-05-19 | 2016-04-05 | Security First Corp | systems and methods to protect cloud data |
| US20100306531A1 (en) | 2009-05-29 | 2010-12-02 | Ebay Inc. | Hardware-Based Zero-Knowledge Strong Authentication (H0KSA) |
| US20100306076A1 (en)* | 2009-05-29 | 2010-12-02 | Ebay Inc. | Trusted Integrity Manager (TIM) |
| US9489503B2 (en) | 2009-12-21 | 2016-11-08 | Paypal, Inc. | Behavioral stochastic authentication (BSA) |
| US9135424B2 (en) | 2009-05-29 | 2015-09-15 | Paypal, Inc. | Secure identity binding (SIB) |
| US9734496B2 (en) | 2009-05-29 | 2017-08-15 | Paypal, Inc. | Trusted remote attestation agent (TRAA) |
| US8879547B2 (en) | 2009-06-02 | 2014-11-04 | Oracle International Corporation | Telephony application services |
| US20100313244A1 (en)* | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| US8286084B2 (en)* | 2009-06-08 | 2012-10-09 | Swakker Llc | Methods and apparatus for remote interaction using a partitioned display |
| US20100310193A1 (en)* | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for selecting and/or displaying images of perspective views of an object at a communication device |
| US20100313249A1 (en)* | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| US20100312813A1 (en)* | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| WO2010144428A1 (en)* | 2009-06-08 | 2010-12-16 | Swakker Llc | Methods and apparatus for distributing, storing, and replaying directives within a network |
| US20100311393A1 (en)* | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| CN101576989A (en)* | 2009-06-09 | 2009-11-11 | 阿里巴巴集团控股有限公司 | Method for realizing payment in mobile terminal and mobile device |
| US8710953B2 (en)* | 2009-06-12 | 2014-04-29 | Microsoft Corporation | Automatic portable electronic device configuration |
| US20110034149A1 (en)* | 2009-07-14 | 2011-02-10 | Deutsche Telekom Ag | Method for releasing a mobile communication card for the use of a service of a mobile communication network and user equipment for interaction with a mobile communication network |
| US9100288B1 (en)* | 2009-07-20 | 2015-08-04 | Conviva Inc. | Augmenting the functionality of a content player |
| WO2011017099A2 (en)* | 2009-07-27 | 2011-02-10 | Suridx, Inc. | Secure communication using asymmetric cryptography and light-weight certificates |
| US8776214B1 (en) | 2009-08-12 | 2014-07-08 | Amazon Technologies, Inc. | Authentication manager |
| CA2699345C (en) | 2009-08-26 | 2012-01-17 | Mobiroo Inc. | Digital device advertising system and method |
| US20110088090A1 (en)* | 2009-09-08 | 2011-04-14 | Avoco Secure Ltd. | Enhancements to claims based digital identities |
| US8386640B2 (en)* | 2009-10-30 | 2013-02-26 | At&T Intellectual Property I, Lp | Method, computer readable medium, and apparatus for providing different services to different users of an aggregate endpoint in an internet protocol multimedia subsystem (IMS) network |
| US8583830B2 (en) | 2009-11-19 | 2013-11-12 | Oracle International Corporation | Inter-working with a walled garden floor-controlled system |
| US9269060B2 (en) | 2009-11-20 | 2016-02-23 | Oracle International Corporation | Methods and systems for generating metadata describing dependencies for composable elements |
| US8533773B2 (en) | 2009-11-20 | 2013-09-10 | Oracle International Corporation | Methods and systems for implementing service level consolidated user information management |
| CN106230872A (en) | 2009-11-25 | 2016-12-14 | 安全第公司 | To moving medial according to the system and method protected |
| US20110137980A1 (en)* | 2009-12-08 | 2011-06-09 | Samsung Electronics Co., Ltd. | Method and apparatus for using service of plurality of internet service providers |
| KR20110065247A (en)* | 2009-12-08 | 2011-06-15 | 삼성전자주식회사 | Method and apparatus using services of a plurality of internet service providers |
| US9509790B2 (en) | 2009-12-16 | 2016-11-29 | Oracle International Corporation | Global presence |
| US9503407B2 (en) | 2009-12-16 | 2016-11-22 | Oracle International Corporation | Message forwarding |
| EP2514134A1 (en)* | 2009-12-18 | 2012-10-24 | Nokia Corp. | Credential transfer |
| US20110167258A1 (en)* | 2009-12-30 | 2011-07-07 | Suridx, Inc. | Efficient Secure Cloud-Based Processing of Certificate Status Information |
| US20120303528A1 (en)* | 2010-01-07 | 2012-11-29 | Accells Technologies (2009), Ltd. | System and method for performing a transaction responsive to a mobile device |
| US10719876B2 (en)* | 2010-01-22 | 2020-07-21 | Verient, Inc. | Systems and methods for controlling payment processing |
| US8621214B2 (en) | 2010-02-10 | 2013-12-31 | SecurenCrypt, LLC | Document encryption and decryption |
| US9245419B2 (en) | 2010-02-10 | 2016-01-26 | Leap Forward Gaming, Inc. | Lottery games on an electronic gaming machine |
| US9532222B2 (en) | 2010-03-03 | 2016-12-27 | Duo Security, Inc. | System and method of notifying mobile devices to complete transactions after additional agent verification |
| US9544143B2 (en) | 2010-03-03 | 2017-01-10 | Duo Security, Inc. | System and method of notifying mobile devices to complete transactions |
| US8819447B2 (en)* | 2010-03-10 | 2014-08-26 | Sprint Communications Company L.P. | Secure storage of protected data in a wireless communication device |
| US8495142B2 (en)* | 2010-03-11 | 2013-07-23 | Cisco Technology, Inc. | System and method for providing data channel management in a network environment |
| US9418205B2 (en) | 2010-03-15 | 2016-08-16 | Proxense, Llc | Proximity-based system for automatic application or data access and item tracking |
| US9760885B1 (en)* | 2010-03-23 | 2017-09-12 | Amazon Technologies, Inc. | Hierarchical device relationships for geolocation-based transactions |
| US9628831B2 (en) | 2010-03-25 | 2017-04-18 | Whatsapp, Inc. | Multimedia transcoding method and system for mobile devices |
| US8995965B1 (en) | 2010-03-25 | 2015-03-31 | Whatsapp Inc. | Synthetic communication network method and system |
| US10579995B2 (en)* | 2010-03-30 | 2020-03-03 | Visa International Service Association | Event access with data field encryption for validation and access control |
| WO2011123692A2 (en) | 2010-03-31 | 2011-10-06 | Orsini Rick L | Systems and methods for securing data in motion |
| WO2011123921A1 (en)* | 2010-04-05 | 2011-10-13 | Consumer Mt Inc. | System and method for management of electronic wallet databases |
| US8473414B2 (en)* | 2010-04-09 | 2013-06-25 | Visa International Service Association | System and method including chip-based device processing for transaction |
| US20110271005A1 (en)* | 2010-04-30 | 2011-11-03 | Sonus Networks, Inc. | Load balancing among voip server groups |
| US10157269B2 (en)* | 2010-05-06 | 2018-12-18 | John K. Thomas | Verification system for secure transmission in a distributed processing network |
| US8515077B2 (en)* | 2010-05-12 | 2013-08-20 | Research In Motion Limited | Automatic application management in a short-range wireless system |
| CN103238305A (en) | 2010-05-28 | 2013-08-07 | 安全第一公司 | Accelerator system for use with secure data storage |
| US10032239B2 (en)* | 2010-06-10 | 2018-07-24 | United Parcel Service Of America, Inc. | Enhanced payments for shipping |
| CN102281311B (en)* | 2010-06-10 | 2014-06-04 | 阿里巴巴集团控股有限公司 | Method, system and device for implementing network service based on open application programming interface |
| EP2585997A4 (en) | 2010-06-28 | 2014-08-27 | Mastercard International Inc | Methods, systems, and computer readable media for facilitating in-store or near-store ordering and payment of goods and services through a single-tap of a near field communication (nfc) device |
| US20120047169A1 (en)* | 2010-06-30 | 2012-02-23 | Schroeder B Steven | System for Replication and Delivery of Remote Data and Accumulated Metadata with Enhanced Display |
| US8918854B1 (en) | 2010-07-15 | 2014-12-23 | Proxense, Llc | Proximity-based system for automatic application initialization |
| GB2495877B (en)* | 2010-07-26 | 2013-10-02 | Seven Networks Inc | Distributed implementation of dynamic wireless traffic policy |
| US8996402B2 (en) | 2010-08-02 | 2015-03-31 | Apple Inc. | Forecasting and booking of inventory atoms in content delivery systems |
| US9619801B2 (en)* | 2010-08-02 | 2017-04-11 | Stanton Management Group, Inc. | User positive approval and authentication services (UPAAS) |
| US8990103B2 (en) | 2010-08-02 | 2015-03-24 | Apple Inc. | Booking and management of inventory atoms in content delivery systems |
| GB201014408D0 (en)* | 2010-08-31 | 2010-10-13 | Swipe Pay Ltd | Improvements in and relating to mobile communication devices |
| US8613052B2 (en) | 2010-09-17 | 2013-12-17 | Universal Secure Registry, Llc | Apparatus, system and method employing a wireless user-device |
| WO2012040231A2 (en) | 2010-09-20 | 2012-03-29 | Orsini Rick L | Systems and methods for secure data sharing |
| US20120136796A1 (en) | 2010-09-21 | 2012-05-31 | Ayman Hammad | Device Enrollment System and Method |
| US9607293B2 (en)* | 2010-11-29 | 2017-03-28 | Barclays Bank Plc | Method and system for account management and electronic wallet access on a mobile device |
| US9558481B2 (en)* | 2010-09-28 | 2017-01-31 | Barclays Bank Plc | Secure account provisioning |
| WO2012048122A1 (en) | 2010-10-06 | 2012-04-12 | Vivotech Inc. | Methods, systems, and computer readable media for provisioning location specific content information to a mobile device |
| AU2011316955B2 (en) | 2010-10-20 | 2016-12-01 | Playspan Inc. | Flexible monetization service apparatuses, methods and systems |
| US20120179558A1 (en)* | 2010-11-02 | 2012-07-12 | Mark Noyes Fischer | System and Method for Enhancing Electronic Transactions |
| EP2636201B1 (en) | 2010-11-02 | 2019-02-27 | Telefonaktiebolaget LM Ericsson (publ) | Methods and devices for media description delivery |
| US8706633B2 (en)* | 2010-11-05 | 2014-04-22 | Mastercard International Incorporated | Remittance system with improved service for unbanked individuals |
| US8745716B2 (en)* | 2010-11-17 | 2014-06-03 | Sequent Software Inc. | System and method for providing secure data communication functionality to a variety of applications on a portable communication device |
| US8572699B2 (en) | 2010-11-18 | 2013-10-29 | Microsoft Corporation | Hardware-based credential distribution |
| EP2466522A1 (en)* | 2010-11-30 | 2012-06-20 | Gemalto SA | Method for providing a user with an authentificated remote access to a remote secure device |
| EP2458807A1 (en)* | 2010-11-30 | 2012-05-30 | Gemalto SA | Method for a client device to access to remote secure data on a remote secure device |
| US20120143702A1 (en)* | 2010-12-07 | 2012-06-07 | Mediatek Inc. | Transaction Information Keeping Methods and Mobile Devices Thereto |
| US20120151067A1 (en)* | 2010-12-09 | 2012-06-14 | International Business Machines Corporation | Method and System for Extending Memory Capacity of a Mobile Device Using Proximate Devices and Multicasting |
| EP2649745A4 (en)* | 2010-12-10 | 2014-05-07 | Electronic Payment Exchange | Tokenized contactless payments for mobile devices |
| US8352749B2 (en) | 2010-12-17 | 2013-01-08 | Google Inc. | Local trusted services manager for a contactless smart card |
| US8621168B2 (en) | 2010-12-17 | 2013-12-31 | Google Inc. | Partitioning the namespace of a contactless smart card |
| US9691055B2 (en) | 2010-12-17 | 2017-06-27 | Google Inc. | Digital wallet |
| US8196131B1 (en) | 2010-12-17 | 2012-06-05 | Google Inc. | Payment application lifecycle management in a contactless smart card |
| US9282085B2 (en) | 2010-12-20 | 2016-03-08 | Duo Security, Inc. | System and method for digital user authentication |
| US11004056B2 (en)* | 2010-12-30 | 2021-05-11 | Visa International Service Association | Mixed mode transaction protocol |
| CN102111498B (en)* | 2011-01-13 | 2013-11-06 | 华为终端有限公司 | Electronic mail replying method and mobile terminal |
| US9123040B2 (en) | 2011-01-21 | 2015-09-01 | Iii Holdings 1, Llc | Systems and methods for encoded alias based transactions |
| GB2483318B (en)* | 2011-01-24 | 2013-06-26 | Realvnc Ltd | Software activation systems |
| US20120197691A1 (en)* | 2011-01-31 | 2012-08-02 | Bank Of America Corporation | Mobile wallet payment vehicle preferences |
| US20120197787A1 (en)* | 2011-01-31 | 2012-08-02 | Bank Of America Corporation | Mobile wallet experience for resolving conflicts between different financial institutions and payment vehicles |
| US8857716B1 (en) | 2011-02-21 | 2014-10-14 | Proxense, Llc | Implementation of a proximity-based system for object tracking and automatic application initialization |
| US9544396B2 (en) | 2011-02-23 | 2017-01-10 | Lookout, Inc. | Remote application installation and control for a mobile device |
| US10666732B2 (en) | 2011-03-21 | 2020-05-26 | Iplcontent, Llc | Systems and methods to provide digital amenities for local access |
| US20120246071A1 (en)* | 2011-03-21 | 2012-09-27 | Nikhil Jain | System and method for presentment of nonconfidential transaction token identifier |
| US10083444B1 (en)* | 2011-03-23 | 2018-09-25 | Qualcomm Incorporated | Biometric computing system and method for e-commerce |
| US20120253954A1 (en)* | 2011-03-28 | 2012-10-04 | Wah Cheong Wong | Payment verification system |
| GB201105765D0 (en) | 2011-04-05 | 2011-05-18 | Visa Europe Ltd | Payment system |
| US10210497B2 (en)* | 2011-04-06 | 2019-02-19 | OnDot Systems, Inc. | System and method for cashless peer-to-peer payment |
| US9154826B2 (en) | 2011-04-06 | 2015-10-06 | Headwater Partners Ii Llc | Distributing content and service launch objects to mobile devices |
| KR20140008450A (en)* | 2011-05-09 | 2014-01-21 | 쿰바리 어베 | A system and method for establising communication for network connected devices |
| EP3869443A1 (en)* | 2011-05-10 | 2021-08-25 | Dynamics Inc. | Systems, devices, and methods for mobile payment acceptance, mobile authorizations, mobile wallets, and contactless communication mechanisms |
| US9098850B2 (en) | 2011-05-17 | 2015-08-04 | Ping Identity Corporation | System and method for transaction security responsive to a signed authentication |
| CA2873804A1 (en) | 2011-05-17 | 2012-11-22 | Accells Technologies (2009), Ltd. | System and method for performing a secure transaction |
| US8346672B1 (en) | 2012-04-10 | 2013-01-01 | Accells Technologies (2009), Ltd. | System and method for secure transaction process via mobile device |
| US8656209B2 (en) | 2011-05-27 | 2014-02-18 | Verisign, Inc. | Recovery of a failed registry |
| US10681021B2 (en)* | 2011-06-01 | 2020-06-09 | Qualcomm Incorporated | Selective admission into a network sharing session |
| US8538845B2 (en) | 2011-06-03 | 2013-09-17 | Mozido, Llc | Monetary transaction system |
| US20120331153A1 (en)* | 2011-06-22 | 2012-12-27 | International Business Machines Corporation | Establishing A Data Communications Connection Between A Lightweight Kernel In A Compute Node Of A Parallel Computer And An Input-Output ('I/O') Node Of The Parallel Computer |
| US20120330844A1 (en)* | 2011-06-24 | 2012-12-27 | Lance Kaufman | Multi functional duplex encrypted procurement and payment system and method |
| US9875607B2 (en) | 2011-07-13 | 2018-01-23 | Igt | Methods and apparatus for providing secure logon to a gaming machine using a mobile device |
| EP2737742A4 (en) | 2011-07-27 | 2015-01-28 | Seven Networks Inc | Automatic generation and distribution of policy information regarding malicious mobile traffic in a wireless network |
| US9767262B1 (en) | 2011-07-29 | 2017-09-19 | Amazon Technologies, Inc. | Managing security credentials |
| US11444936B2 (en) | 2011-07-29 | 2022-09-13 | Amazon Technologies, Inc. | Managing security credentials |
| US10362019B2 (en) | 2011-07-29 | 2019-07-23 | Amazon Technologies, Inc. | Managing security credentials |
| EP2557532A1 (en)* | 2011-08-09 | 2013-02-13 | Research In Motion Limited | Methods and apparatus to provision payment services |
| US9008616B2 (en) | 2011-08-19 | 2015-04-14 | Google Inc. | Point of sale processing initiated by a single tap |
| US9179306B2 (en)* | 2011-08-31 | 2015-11-03 | Ncr Corporation | Techniques for third-party content delivery via a unique mobile application address |
| AU2012303620B2 (en) | 2011-08-31 | 2017-09-14 | Ping Identity Corporation | System and method for secure transaction process via mobile device |
| US9467463B2 (en) | 2011-09-02 | 2016-10-11 | Duo Security, Inc. | System and method for assessing vulnerability of a mobile device |
| US20190272704A1 (en) | 2011-09-09 | 2019-09-05 | Igt | Redemption of virtual tickets using a portable electronic device |
| US9367835B2 (en) | 2011-09-09 | 2016-06-14 | Igt | Retrofit devices for providing virtual ticket-in and ticket-out on a gaming machine |
| US8613659B2 (en) | 2011-09-09 | 2013-12-24 | Igt | Virtual ticket-in and ticket-out on a gaming machine |
| US8845422B2 (en)* | 2011-09-09 | 2014-09-30 | Wms Gaming, Inc. | Remote login for a wagering game machine |
| US10297105B2 (en) | 2011-09-09 | 2019-05-21 | Igt | Redemption of virtual tickets using a portable electronic device |
| US10121318B2 (en) | 2011-09-09 | 2018-11-06 | Igt | Bill acceptors and printers for providing virtual ticket-in and ticket-out on a gaming machine |
| US8886558B2 (en)* | 2011-09-11 | 2014-11-11 | Dani Alyamour | Method and system for implementing mobile transaction solution based on early media dynamic content generation |
| US9172539B2 (en)* | 2011-09-14 | 2015-10-27 | Mastercard International Incorporated | In-market personalization of payment devices |
| US8171525B1 (en) | 2011-09-15 | 2012-05-01 | Google Inc. | Enabling users to select between secure service providers using a central trusted service manager |
| US8255687B1 (en) | 2011-09-15 | 2012-08-28 | Google Inc. | Enabling users to select between secure service providers using a key escrow service |
| US8313036B1 (en) | 2011-09-16 | 2012-11-20 | Google Inc. | Secure application directory |
| US9390414B2 (en) | 2011-09-18 | 2016-07-12 | Google Inc. | One-click offline buying |
| US20130080236A1 (en)* | 2011-09-26 | 2013-03-28 | First Data Corporation | Systems and Methods for Enrolling Consumers in Loyalty Programs |
| US9524609B2 (en) | 2011-09-30 | 2016-12-20 | Igt | Gaming system, gaming device and method for utilizing mobile devices at a gaming establishment |
| US9524388B2 (en) | 2011-10-07 | 2016-12-20 | Duo Security, Inc. | System and method for enforcing a policy for an authenticator device |
| US8763077B2 (en) | 2011-10-07 | 2014-06-24 | Duo Security, Inc. | System and method for enforcing a policy for an authenticator device |
| EP2767110A4 (en) | 2011-10-12 | 2015-01-28 | C Sam Inc | A multi-tiered secure mobile transactions enabling platform |
| KR101363753B1 (en)* | 2011-10-18 | 2014-02-17 | 에스케이씨앤씨 주식회사 | Method and system for changing key on SE in mobile device |
| US8954003B2 (en) | 2011-10-18 | 2015-02-10 | Blackberry Limited | System and method of managing pairing information associated with peer-to-peer device pairings |
| US8819428B2 (en)* | 2011-10-21 | 2014-08-26 | Ebay Inc. | Point of sale (POS) personal identification number (PIN) security |
| US11580562B2 (en)* | 2011-10-25 | 2023-02-14 | Alexander Song | Anti-fraud financial transactions system |
| US8811895B2 (en)* | 2011-10-28 | 2014-08-19 | Sequent Software Inc. | System and method for presentation of multiple NFC credentials during a single NFC transaction |
| EP2774099B1 (en) | 2011-11-03 | 2023-03-01 | Mastercard International Incorporated | Methods, systems, and computer readable media for provisioning and utilizing an aggregated soft card on a mobile device |
| CA2852713A1 (en)* | 2011-11-05 | 2013-05-10 | Sequent Software Inc. | System and method for increasing security in internet transactions |
| US9208488B2 (en) | 2011-11-21 | 2015-12-08 | Mozido, Inc. | Using a mobile wallet infrastructure to support multiple mobile wallet providers |
| US10438196B2 (en) | 2011-11-21 | 2019-10-08 | Mozido, Inc. | Using a mobile wallet infrastructure to support multiple mobile wallet providers |
| DE202012100620U1 (en)* | 2011-11-22 | 2012-06-13 | Square, Inc. | System for processing cardless payment transactions |
| US11132672B2 (en)* | 2011-11-29 | 2021-09-28 | Cardlogix | Layered security for age verification and transaction authorization |
| US20140337230A1 (en)* | 2011-12-01 | 2014-11-13 | Sk C&C Co., Ltd. | Method and system for secure mobile wallet transaction |
| US20150269582A1 (en)* | 2011-12-05 | 2015-09-24 | Securus, Llc | Credit Card Point of Service Payment Authorization System |
| US8918855B2 (en)* | 2011-12-09 | 2014-12-23 | Blackberry Limited | Transaction provisioning for mobile wireless communications devices and related methods |
| US8613668B2 (en) | 2011-12-22 | 2013-12-24 | Igt | Directional wireless communication |
| US8880686B2 (en) | 2011-12-30 | 2014-11-04 | Verisign, Inc | Providing privacy enhanced resolution system in the domain name system |
| US9342698B2 (en) | 2011-12-30 | 2016-05-17 | Verisign, Inc. | Providing privacy enhanced resolution system in the domain name system |
| US9923986B2 (en) | 2011-12-30 | 2018-03-20 | Mozido Corfire—Korea, Ltd. | Master TSM |
| US9026461B2 (en)* | 2012-01-23 | 2015-05-05 | Bank Of America Corporation | Enhanced mobile application for assisting users at a point of transaction |
| US8863250B2 (en) | 2012-02-01 | 2014-10-14 | Amazon Technologies, Inc. | Logout from multiple network sites |
| US8955065B2 (en)* | 2012-02-01 | 2015-02-10 | Amazon Technologies, Inc. | Recovery of managed security credentials |
| US9191394B2 (en)* | 2012-02-08 | 2015-11-17 | Microsoft Technology Licensing, Llc | Protecting user credentials from a computing device |
| EP2815535B1 (en)* | 2012-02-13 | 2018-11-14 | Schlage Lock Company LLC | Credential management system |
| US9672504B2 (en)* | 2012-02-16 | 2017-06-06 | Paypal, Inc. | Processing payment at a point of sale with limited information |
| US8763896B2 (en) | 2012-02-23 | 2014-07-01 | XRomb Inc. | System and method of loading a transaction card and processing repayment on a mobile device |
| WO2013127059A1 (en)* | 2012-02-28 | 2013-09-06 | Sinogael Technologies Limited | System to facilitate integration of software |
| US8385553B1 (en) | 2012-02-28 | 2013-02-26 | Google Inc. | Portable secure element |
| US8876596B2 (en) | 2012-02-29 | 2014-11-04 | Igt | Virtualized magnetic player card |
| US11593800B2 (en) | 2012-03-07 | 2023-02-28 | Early Warning Services, Llc | System and method for transferring funds |
| US10318936B2 (en) | 2012-03-07 | 2019-06-11 | Early Warning Services, Llc | System and method for transferring funds |
| US10395223B2 (en) | 2012-03-07 | 2019-08-27 | Early Warning Services, Llc | System and method for transferring funds |
| US10395247B2 (en) | 2012-03-07 | 2019-08-27 | Early Warning Services, Llc | Systems and methods for facilitating a secure transaction at a non-financial institution system |
| US10970688B2 (en) | 2012-03-07 | 2021-04-06 | Early Warning Services, Llc | System and method for transferring funds |
| US9691056B2 (en) | 2012-03-07 | 2017-06-27 | Clearxchange, Llc | System and method for transferring funds |
| US8965800B2 (en) | 2012-03-09 | 2015-02-24 | Mastercard International Incorporated | Systems, methods, and computer readable media for conducting an electronic transaction via a backend server system |
| US20130246132A1 (en)* | 2012-03-17 | 2013-09-19 | David J. Buie | Smart tranportation services & payment system and method |
| US9311769B2 (en) | 2012-03-28 | 2016-04-12 | Igt | Emailing or texting as communication between mobile device and EGM |
| US8429409B1 (en)* | 2012-04-06 | 2013-04-23 | Google Inc. | Secure reset of personal and service provider information on mobile devices |
| US20140019341A1 (en)* | 2012-04-10 | 2014-01-16 | Kabbage, Inc. | Method, apparatus and computer readable storage to effectuate an instantaneous monetary transfer |
| US8774721B2 (en) | 2012-04-10 | 2014-07-08 | Google Inc. | Detecting a communication tap via signal monitoring |
| KR101942797B1 (en)* | 2012-04-13 | 2019-01-29 | 삼성전자 주식회사 | Method and system for establishing wireless local area netwrok link between portable terminals |
| WO2013163185A1 (en)* | 2012-04-23 | 2013-10-31 | Mastercard International Incorporated | Methods, systems and computer readable media for over the air(ota) provisioning of soft cards on devices with wireless communications capabilities |
| US10235668B1 (en) | 2012-04-25 | 2019-03-19 | Wells Fargo Bank, N.A. | System and method for a mobile wallet |
| US8924292B1 (en) | 2012-04-25 | 2014-12-30 | Wells Fargo Bank, N.A. | System and method for a mobile wallet |
| US10192217B1 (en) | 2012-04-25 | 2019-01-29 | Wells Fargo Bank, N.A. | System and method for receipt tracking in a mobile wallet |
| US10275764B2 (en)* | 2012-05-04 | 2019-04-30 | Mastercard International Incorporated | Transaction data tokenization |
| US20130297509A1 (en)* | 2012-05-07 | 2013-11-07 | Infosys Limited | Mobile payment using dynamic authorization code and multi-payer shared card number |
| CN111310619B (en) | 2012-05-18 | 2021-06-04 | 苹果公司 | Device, method and graphical user interface for manipulating a user interface |
| JP5339316B1 (en)* | 2012-05-31 | 2013-11-13 | 楽天株式会社 | IDENTIFICATION INFORMATION MANAGEMENT SYSTEM, IDENTIFICATION INFORMATION MANAGEMENT SYSTEM CONTROL METHOD, INFORMATION PROCESSING DEVICE, AND PROGRAM |
| US10515363B2 (en) | 2012-06-12 | 2019-12-24 | Square, Inc. | Software PIN entry |
| US10089625B2 (en)* | 2012-06-13 | 2018-10-02 | First Data Corporation | Systems and methods for tokenizing financial information |
| TWI462604B (en)* | 2012-06-18 | 2014-11-21 | Wistron Corp | Wireless network client-authentication system and wireless network connection method thereof |
| IN2014MN02537A (en)* | 2012-06-20 | 2015-07-24 | Infotel Broadband Services Ltd | |
| US10255632B2 (en) | 2012-07-02 | 2019-04-09 | Kabbage, Inc. | Method and apparatus to evaluate and provide funds in online environments |
| US9412227B2 (en) | 2012-07-11 | 2016-08-09 | Igt | Method and apparatus for offering a mobile device version of an electronic gaming machine game at the electronic gaming machine |
| US8639619B1 (en) | 2012-07-13 | 2014-01-28 | Scvngr, Inc. | Secure payment method and system |
| US9842333B2 (en) | 2012-07-23 | 2017-12-12 | Wal-Mart Stores, Inc. | Transferring digital receipt data to mobile devices |
| US8738454B2 (en) | 2012-07-23 | 2014-05-27 | Wal-Mart Stores, Inc. | Transferring digital receipt data to mobile devices |
| US8843398B2 (en) | 2012-07-23 | 2014-09-23 | Wal-Mart Stores, Inc. | Transferring digital receipt data to mobile devices |
| JP5980037B2 (en)* | 2012-08-06 | 2016-08-31 | キヤノン株式会社 | Management system, server, client, and method thereof |
| US20150207789A1 (en) | 2012-08-16 | 2015-07-23 | Tango Mobile, LLC | System and method for electronic credentials |
| US20140052613A1 (en) | 2012-08-17 | 2014-02-20 | Square, Inc., A Delaware Corporation | Systems and methods for providing gratuities to merchants |
| WO2014030875A1 (en) | 2012-08-24 | 2014-02-27 | Samsung Electronics Co., Ltd. | Apparatus and method for providing interaction information by using image on device display |
| US9608886B2 (en)* | 2012-08-26 | 2017-03-28 | At&T Intellectual Property I, L.P. | Methods, systems, and products for monitoring domain name servers |
| US10182096B1 (en) | 2012-09-05 | 2019-01-15 | Conviva Inc. | Virtual resource locator |
| US9246965B1 (en) | 2012-09-05 | 2016-01-26 | Conviva Inc. | Source assignment based on network partitioning |
| US10068083B2 (en)* | 2012-09-28 | 2018-09-04 | International Business Machines Corporation | Secure transport of web form submissions |
| US9792035B2 (en)* | 2012-10-09 | 2017-10-17 | Mastercard International Incorporated | System and method for payment using a mobile device |
| WO2014059077A1 (en)* | 2012-10-10 | 2014-04-17 | Mastercard International Incorporated | Methods and systems for prepaid mobile payment staging accounts |
| US10235692B2 (en) | 2012-10-17 | 2019-03-19 | Groupon, Inc. | Consumer presence based deal offers |
| US20140108247A1 (en) | 2012-10-17 | 2014-04-17 | Groupon, Inc. | Peer-To-Peer Payment Processing |
| US9514492B2 (en)* | 2012-11-05 | 2016-12-06 | Mfoundry, Inc. | Systems and methods for providing financial service extensions |
| US10055727B2 (en)* | 2012-11-05 | 2018-08-21 | Mfoundry, Inc. | Cloud-based systems and methods for providing consumer financial data |
| US8898769B2 (en) | 2012-11-16 | 2014-11-25 | At&T Intellectual Property I, Lp | Methods for provisioning universal integrated circuit cards |
| US8959331B2 (en) | 2012-11-19 | 2015-02-17 | At&T Intellectual Property I, Lp | Systems for provisioning universal integrated circuit cards |
| KR101460179B1 (en) | 2012-11-28 | 2014-11-10 | 에스케이씨앤씨 주식회사 | Method for Temporary Payment Card Set-up and Mobile Device using the same |
| US8976784B2 (en)* | 2012-11-29 | 2015-03-10 | At&T Intellectual Property I, Lp | Method and apparatus for provisioning a scalable communications network |
| US8783438B2 (en) | 2012-11-30 | 2014-07-22 | Heb Grocery Company, L.P. | Diverter arm for retail checkstand and retail checkstands and methods incorporating same |
| US9185006B2 (en)* | 2012-12-17 | 2015-11-10 | Microsoft Technology Licensing, Llc | Exchange of server health and client information through headers for request management |
| US10504111B2 (en)* | 2012-12-21 | 2019-12-10 | Intermec Ip Corp. | Secure mobile device transactions |
| KR101330962B1 (en)* | 2012-12-27 | 2013-11-18 | 신한카드 주식회사 | Payment device control method for selecting card settlement |
| TWI494886B (en)* | 2013-01-04 | 2015-08-01 | Irene Tsai | Mobile device, virtual worth of the conversion system and conversion methods |
| US9882713B1 (en) | 2013-01-30 | 2018-01-30 | vIPtela Inc. | Method and system for key generation, distribution and management |
| US9344404B2 (en)* | 2013-01-31 | 2016-05-17 | Dell Products L.P. | System and method for synchronizing connection credentials |
| US20140229375A1 (en) | 2013-02-11 | 2014-08-14 | Groupon, Inc. | Consumer device payment token management |
| US9128944B2 (en)* | 2013-02-13 | 2015-09-08 | Edgecast Networks, Inc. | File system enabling fast purges and file access |
| US9391881B2 (en)* | 2013-02-20 | 2016-07-12 | Ip Technology Labs, Llc | System and methods for dynamic network address modification |
| US9443073B2 (en) | 2013-08-08 | 2016-09-13 | Duo Security, Inc. | System and method for verifying status of an authentication device |
| US9607156B2 (en) | 2013-02-22 | 2017-03-28 | Duo Security, Inc. | System and method for patching a device through exploitation |
| US9338156B2 (en) | 2013-02-22 | 2016-05-10 | Duo Security, Inc. | System and method for integrating two-factor authentication in a device |
| US8893230B2 (en) | 2013-02-22 | 2014-11-18 | Duo Security, Inc. | System and method for proxying federated authentication protocols |
| CN105122856B (en) | 2013-02-27 | 2019-04-23 | 惠普发展公司，有限责任合伙企业 | Perform the next state selection certificate for the target device |
| US9686284B2 (en) | 2013-03-07 | 2017-06-20 | T-Mobile Usa, Inc. | Extending and re-using an IP multimedia subsystem (IMS) |
| CA2941884C (en)* | 2013-03-10 | 2022-09-20 | The Work Shop Limited | Methods and systems for facilitating payment transaction reconciliation |
| US9576286B1 (en) | 2013-03-11 | 2017-02-21 | Groupon, Inc. | Consumer device based point-of-sale |
| US9852409B2 (en) | 2013-03-11 | 2017-12-26 | Groupon, Inc. | Consumer device based point-of-sale |
| US9282098B1 (en) | 2013-03-11 | 2016-03-08 | Amazon Technologies, Inc. | Proxy server-based network site account management |
| US20140279505A1 (en)* | 2013-03-14 | 2014-09-18 | Bank Of America Corporation | Recommending vehicle for payment based on social network data |
| US8924259B2 (en) | 2013-03-14 | 2014-12-30 | Square, Inc. | Mobile device payments |
| US9992021B1 (en) | 2013-03-14 | 2018-06-05 | GoTenna, Inc. | System and method for private and point-to-point communication between computing devices |
| EP2956825B1 (en) | 2013-03-15 | 2020-06-24 | Apple Inc. | Facilitating transactions with a user account using a wireless device |
| US20140304170A1 (en)* | 2013-03-15 | 2014-10-09 | First National Of Nebraska, Inc. | Remote credit issuance system |
| US9338157B1 (en)* | 2013-03-15 | 2016-05-10 | Microstrategy Incorporated | Credential technology |
| US9516018B1 (en)* | 2013-03-15 | 2016-12-06 | Microstrategy Incorporated | Credential technology |
| US9992183B2 (en) | 2013-03-15 | 2018-06-05 | T-Mobile Usa, Inc. | Using an IP multimedia subsystem for HTTP session authentication |
| AU2014239979B2 (en) | 2013-03-15 | 2017-06-22 | Aurora Operations, Inc. | Methods, systems, and apparatus for multi-sensory stereo vision for robotics |
| US20140289061A1 (en)* | 2013-03-24 | 2014-09-25 | I-Pos Systems Llc | Point-of-sale terminal based mobile electronic wallet registration, authorization and settlement |
| US9565181B2 (en)* | 2013-03-28 | 2017-02-07 | Wendell D. Brown | Method and apparatus for automated password entry |
| US9282086B2 (en)* | 2013-04-26 | 2016-03-08 | Broadcom Corporation | Methods and systems for secured authentication of applications on a network |
| US9319088B2 (en)* | 2013-05-09 | 2016-04-19 | Intel Corporation | Radio communication devices and methods for controlling a radio communication device |
| US10592890B2 (en) | 2014-09-03 | 2020-03-17 | Intel Corporation | Methods and arrangements to complete online transactions |
| WO2014183106A2 (en) | 2013-05-10 | 2014-11-13 | Proxense, Llc | Secure element as a digital pocket |
| KR20160008614A (en) | 2013-05-15 | 2016-01-22 | 비자 인터네셔널 서비스 어소시에이션 | Methods and systems for provisioning payment credentials |
| EP2806370A1 (en)* | 2013-05-21 | 2014-11-26 | Knightsbridge Portable Communications SP | Portable authentication tool and method |
| US20140351907A1 (en)* | 2013-05-21 | 2014-11-27 | Personal Credentialing Group, LLC | Credential authentication system and methods of performing the same |
| US20140351126A1 (en)* | 2013-05-22 | 2014-11-27 | Seth Priebatsch | Secure synchronization of payment accounts to third-party applications or websites |
| US9723058B2 (en)* | 2013-05-28 | 2017-08-01 | Vmware, Inc. | Dynamic registration of an application with an enterprise system |
| SG2013042429A (en)* | 2013-05-31 | 2014-12-30 | Mastercard International Inc | Method for receiving an electronic receipt of an electronic payment transaction into a mobile device |
| DE102013106121A1 (en)* | 2013-06-12 | 2014-12-18 | Appbyyou Gmbh | Method for encrypting data |
| US20140372298A1 (en)* | 2013-06-13 | 2014-12-18 | Research In Motion Limited | Communication system with digital wallet having blank user card and related methods |
| US20150006392A1 (en)* | 2013-06-26 | 2015-01-01 | Entersekt (Pty) Ltd. | Batch transaction authorisation |
| US9585006B2 (en)* | 2013-06-26 | 2017-02-28 | Cellco Partnership | Express mobile device access provisioning methods, systems, and apparatus |
| US10325258B2 (en) | 2013-07-03 | 2019-06-18 | Mastercard International Incorporated | Systems and methods for account processing validation |
| EP2821972B1 (en) | 2013-07-05 | 2020-04-08 | Assa Abloy Ab | Key device and associated method, computer program and computer program product |
| PL2821970T5 (en) | 2013-07-05 | 2019-12-31 | Assa Abloy Ab | Access control communication device, method, computer program and computer program product |
| FR3008518B1 (en)* | 2013-07-11 | 2017-03-24 | Compagnie Ind Et Financiere Dingenierie Ingenico | Method of realization, terminal and corresponding computer program. |
| US8770478B2 (en) | 2013-07-11 | 2014-07-08 | Scvngr, Inc. | Payment processing with automatic no-touch mode selection |
| EP3028228A4 (en)* | 2013-07-16 | 2016-12-07 | Intel Corp | Mobile wallet detection at a contactless point of sale terminal |
| US10475027B2 (en)* | 2013-07-23 | 2019-11-12 | Capital One Services, Llc | System and method for exchanging data with smart cards |
| US9053310B2 (en) | 2013-08-08 | 2015-06-09 | Duo Security, Inc. | System and method for verifying status of an authentication device through a biometric profile |
| US10083385B2 (en) | 2014-04-10 | 2018-09-25 | Neology, Inc. | Universal transponder |
| US9355398B2 (en) | 2013-08-13 | 2016-05-31 | Neology, Inc. | Systems and methods for managing an account |
| US10929835B2 (en)* | 2013-08-13 | 2021-02-23 | Neology, Inc. | Detachable radio frequency identification switch tag |
| US10051110B2 (en)* | 2013-08-29 | 2018-08-14 | Apple Inc. | Management of movement states of an electronic device |
| US9858564B2 (en) | 2013-09-02 | 2018-01-02 | Paypal, Inc. | Optimized multiple digital wallet presentation |
| US20150074765A1 (en)* | 2013-09-06 | 2015-03-12 | Oracle International Corporation | Registration and configuration of point-of-service devices |
| US9426140B2 (en)* | 2013-09-09 | 2016-08-23 | Layer, Inc. | Federated authentication of client computers in networked data communications services callable by applications |
| US9092302B2 (en) | 2013-09-10 | 2015-07-28 | Duo Security, Inc. | System and method for determining component version compatibility across a device ecosystem |
| US9608814B2 (en) | 2013-09-10 | 2017-03-28 | Duo Security, Inc. | System and method for centralized key distribution |
| US9036820B2 (en) | 2013-09-11 | 2015-05-19 | At&T Intellectual Property I, Lp | System and methods for UICC-based secure communication |
| US10181117B2 (en) | 2013-09-12 | 2019-01-15 | Intel Corporation | Methods and arrangements for a personal point of sale device |
| US9773240B1 (en) | 2013-09-13 | 2017-09-26 | Square, Inc. | Fake sensor input for passcode entry security |
| US10142254B1 (en) | 2013-09-16 | 2018-11-27 | Cisco Technology, Inc. | Service chaining based on labels in control and forwarding |
| US9558491B2 (en) | 2013-09-30 | 2017-01-31 | Square, Inc. | Scrambling passcode entry interface |
| US9613356B2 (en) | 2013-09-30 | 2017-04-04 | Square, Inc. | Secure passcode entry user interface |
| US9124573B2 (en) | 2013-10-04 | 2015-09-01 | At&T Intellectual Property I, Lp | Apparatus and method for managing use of secure tokens |
| SG11201602731YA (en) | 2013-10-08 | 2016-05-30 | Skywell Llc | Atmospheric water generator system and method |
| US9928501B1 (en) | 2013-10-09 | 2018-03-27 | Square, Inc. | Secure passcode entry docking station |
| US9443362B2 (en) | 2013-10-18 | 2016-09-13 | Assa Abloy Ab | Communication and processing of credential data |
| US10769613B1 (en)* | 2013-10-22 | 2020-09-08 | Ondot Systems, Inc | Delegate cards |
| US9208300B2 (en) | 2013-10-23 | 2015-12-08 | At&T Intellectual Property I, Lp | Apparatus and method for secure authentication of a communication device |
| US9912570B2 (en)* | 2013-10-25 | 2018-03-06 | Brocade Communications Systems LLC | Dynamic cloning of application infrastructures |
| US9240994B2 (en) | 2013-10-28 | 2016-01-19 | At&T Intellectual Property I, Lp | Apparatus and method for securely managing the accessibility to content and applications |
| CN104580125B (en)* | 2013-10-29 | 2019-03-01 | 腾讯科技（深圳）有限公司 | A kind of payment verification methods, devices and systems |
| US11803841B1 (en) | 2013-10-29 | 2023-10-31 | Block, Inc. | Discovery and communication using direct radio signal communication |
| GB2519766A (en)* | 2013-10-29 | 2015-05-06 | Mastercard International Inc | A system and method for disseminating functionality to a target device |
| KR102405189B1 (en) | 2013-10-30 | 2022-06-07 | 애플 인크. | Displaying relevant user interface objects |
| US9313660B2 (en) | 2013-11-01 | 2016-04-12 | At&T Intellectual Property I, Lp | Apparatus and method for secure provisioning of a communication device |
| US9240989B2 (en) | 2013-11-01 | 2016-01-19 | At&T Intellectual Property I, Lp | Apparatus and method for secure over the air programming of a communication device |
| US20150134518A1 (en)* | 2013-11-14 | 2015-05-14 | Google Inc. | Pre-authorized online checkout |
| US11392937B2 (en)* | 2013-11-15 | 2022-07-19 | Apple Inc. | Generating transaction identifiers |
| US11042846B2 (en) | 2013-11-15 | 2021-06-22 | Apple Inc. | Generating transaction identifiers |
| US11037131B2 (en)* | 2013-11-15 | 2021-06-15 | Apple Inc. | Electronic receipts for NFC-based financial transactions |
| US9413759B2 (en) | 2013-11-27 | 2016-08-09 | At&T Intellectual Property I, Lp | Apparatus and method for secure delivery of data from a communication device |
| CN104683961B (en)* | 2013-11-29 | 2019-01-15 | 腾讯科技（深圳）有限公司 | Business card exchange method, device and terminal |
| US10475018B1 (en) | 2013-11-29 | 2019-11-12 | Amazon Technologies, Inc. | Updating account data for multiple account providers |
| US9467478B1 (en) | 2013-12-18 | 2016-10-11 | vIPtela Inc. | Overlay management protocol for secure routing based on an overlay network |
| EP4057203A1 (en) | 2013-12-19 | 2022-09-14 | Visa International Service Association | Cloud-based transactions methods and systems |
| US9922322B2 (en) | 2013-12-19 | 2018-03-20 | Visa International Service Association | Cloud-based transactions with magnetic secure transmission |
| IN2013CH05960A (en)* | 2013-12-20 | 2015-06-26 | Samsung R & D Inst India Bangalore Private Ltd | |
| KR101762376B1 (en)* | 2014-01-10 | 2017-07-27 | 한국전자통신연구원 | System and method for security authentication via mobile device |
| US20150220928A1 (en)* | 2014-01-31 | 2015-08-06 | Robert Allen | Platform for the purchase and sale of digital currency |
| US10147128B2 (en)* | 2014-02-27 | 2018-12-04 | Ebay Inc. | Cross selling platform |
| US9537661B2 (en)* | 2014-02-28 | 2017-01-03 | Verizon Patent And Licensing Inc. | Password-less authentication service |
| US10078835B2 (en) | 2014-03-05 | 2018-09-18 | Mastercard International Incorporated | Authentication token for wallet based transactions |
| US10032168B2 (en)* | 2014-03-07 | 2018-07-24 | Fmr Llc | Secure validation of financial transactions |
| US9779113B2 (en)* | 2014-03-20 | 2017-10-03 | NSONE Inc. | Systems and methods for improving domain name system traffic routing |
| US10511580B2 (en) | 2014-03-31 | 2019-12-17 | Monticello Enterprises LLC | System and method for providing a social media shopping experience |
| SE538681C2 (en)* | 2014-04-02 | 2016-10-18 | Fidesmo Ab | Linking payment to secure download of application data |
| US10430779B2 (en)* | 2014-04-08 | 2019-10-01 | Capital One Services Llc | Systems and methods for transacting at an ATM using a mobile device |
| US20160342979A1 (en)* | 2014-04-08 | 2016-11-24 | Capital One Services, Llc | Systems and methods for transaction authentication using dynamic wireless beacon devices |
| US10402799B1 (en) | 2014-04-15 | 2019-09-03 | United Services Automobile Association (Usaa) | Systems and methods for distributed currency management |
| US10332358B1 (en) | 2014-04-15 | 2019-06-25 | United Services Automobile Association (Usaa) | Systems and methods for distributed currency management |
| US9762590B2 (en) | 2014-04-17 | 2017-09-12 | Duo Security, Inc. | System and method for an integrity focused authentication service |
| CN103902740B (en) | 2014-04-22 | 2017-07-18 | 锤子科技（北京）有限公司 | The staying method and device of short message identifying code |
| US9652770B1 (en) | 2014-04-30 | 2017-05-16 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
| US11288660B1 (en) | 2014-04-30 | 2022-03-29 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
| US11610197B1 (en) | 2014-04-30 | 2023-03-21 | Wells Fargo Bank, N.A. | Mobile wallet rewards redemption systems and methods |
| US11461766B1 (en) | 2014-04-30 | 2022-10-04 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
| US11615401B1 (en) | 2014-04-30 | 2023-03-28 | Wells Fargo Bank, N.A. | Mobile wallet authentication systems and methods |
| US10997592B1 (en) | 2014-04-30 | 2021-05-04 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
| US11748736B1 (en) | 2014-04-30 | 2023-09-05 | Wells Fargo Bank, N.A. | Mobile wallet integration within mobile banking |
| US9713006B2 (en) | 2014-05-01 | 2017-07-18 | At&T Intellectual Property I, Lp | Apparatus and method for managing security domains for a universal integrated circuit card |
| US9959529B1 (en) | 2014-05-11 | 2018-05-01 | Square, Inc. | Open tab transactions |
| US9602328B2 (en)* | 2014-05-14 | 2017-03-21 | Vivek Mundhra | System, method and computer program product for secure peer-to-peer transactions |
| US10846694B2 (en)* | 2014-05-21 | 2020-11-24 | Visa International Service Association | Offline authentication |
| US9400977B2 (en)* | 2014-05-29 | 2016-07-26 | Apple Inc. | User device enabling access to payment information in response to mechanical input detection |
| CN108090760B (en)* | 2014-05-29 | 2022-04-29 | 苹果公司 | User interface for payments |
| US20150348024A1 (en)* | 2014-06-02 | 2015-12-03 | American Express Travel Related Services Company, Inc. | Systems and methods for provisioning transaction data to mobile communications devices |
| US9485267B2 (en)* | 2014-06-02 | 2016-11-01 | Bastille Networks, Inc. | Anomalous behavior detection using radio frequency fingerprints and access credentials |
| FR3023640B1 (en)* | 2014-07-10 | 2016-08-12 | Roam Data Inc | METHOD FOR MANAGING TRANSACTION, SERVER, COMPUTER PROGRAM PRODUCT AND CORRESPONDING STORAGE MEDIUM |
| CN106575398A (en)* | 2014-07-29 | 2017-04-19 | Quadrac株式会社 | Proxy settlement system, proxy settlement device, actual store device, and user device |
| CN114115459B (en) | 2014-08-06 | 2024-04-12 | 苹果公司 | Reduced size user interface for battery management |
| US10008057B2 (en)* | 2014-08-08 | 2018-06-26 | Live Nation Entertainment, Inc. | Short-range device communications for secured resource access |
| US10445739B1 (en) | 2014-08-14 | 2019-10-15 | Wells Fargo Bank, N.A. | Use limitations for secondary users of financial accounts |
| US9775029B2 (en) | 2014-08-22 | 2017-09-26 | Visa International Service Association | Embedding cloud-based functionalities in a communication device |
| WO2016033208A1 (en)* | 2014-08-26 | 2016-03-03 | Hoyos Labs Ip Ltd. | System and methods for secure file sharing and access management |
| KR102143308B1 (en) | 2014-09-02 | 2020-08-10 | 애플 인크. | Reduced-size interfaces for managing alerts |
| WO2016036603A1 (en) | 2014-09-02 | 2016-03-10 | Apple Inc. | Reduced size configuration interface |
| WO2016036552A1 (en) | 2014-09-02 | 2016-03-10 | Apple Inc. | User interactions for a mapping application |
| US20160071071A1 (en)* | 2014-09-05 | 2016-03-10 | Silouet, Inc. | Payment system that reduces or eliminates the need to exchange personal information |
| CN107077763B (en) | 2014-09-10 | 2021-07-06 | 亚萨合莱有限公司 | First entry notification |
| US20160078444A1 (en)* | 2014-09-16 | 2016-03-17 | Mastercard International Incorporated | Systems and methods for providing fraud indicator data within an authentication protocol |
| US9741026B1 (en) | 2014-09-30 | 2017-08-22 | Square, Inc. | Payment by use of identifier |
| US9407762B2 (en) | 2014-10-10 | 2016-08-02 | Bank Of America Corporation | Providing enhanced user authentication functionalities |
| JP6818679B2 (en)* | 2014-10-13 | 2021-01-20 | シークエント ソフトウェア、インコーポレイテッド | Secure host card embroidery credentials |
| US10015147B2 (en) | 2014-10-22 | 2018-07-03 | Visa International Service Association | Token enrollment system and method |
| FR3028646A1 (en)* | 2014-11-14 | 2016-05-20 | Orange | METHOD FOR SECURING A TRANSACTION BETWEEN A MOBILE TERMINAL AND A SERVER OF A SERVICE PROVIDER VIA A PLATFORM |
| US9875468B2 (en) | 2014-11-26 | 2018-01-23 | Buy It Mobility Networks Inc. | Intelligent authentication process |
| US20160162861A1 (en)* | 2014-12-03 | 2016-06-09 | Verizon Patent And Licensing, Inc. | Managing electronic transactions |
| US10305955B1 (en) | 2014-12-08 | 2019-05-28 | Conviva Inc. | Streaming decision in the cloud |
| US10178043B1 (en) | 2014-12-08 | 2019-01-08 | Conviva Inc. | Dynamic bitrate range selection in the cloud for optimized video streaming |
| US20160162900A1 (en)* | 2014-12-09 | 2016-06-09 | Zighra Inc. | Fraud detection system, method, and device |
| CA2967437A1 (en)* | 2014-12-12 | 2016-06-16 | Visa International Service Association | Provisioning platform for machine-to-machine devices |
| US10356053B1 (en)* | 2014-12-12 | 2019-07-16 | Charles Schwab & Co., Inc. | System and method for allowing access to an application or features thereof on each of one or more user devices |
| CN105763594B (en)* | 2014-12-19 | 2021-05-25 | 阿里巴巴集团控股有限公司 | Information pushing method and device |
| WO2016106277A2 (en)* | 2014-12-22 | 2016-06-30 | Capital One Services, LLC. | A system, method and apparatus for reprogramming a transaction card |
| EP3238189A4 (en)* | 2014-12-22 | 2018-08-15 | Capital One Services, LLC | A system, method, and apparatus for locating a bluetooth enabled transaction card |
| US9836620B2 (en) | 2014-12-30 | 2017-12-05 | Samsung Electronic Co., Ltd. | Computing system for privacy-aware sharing management and method of operation thereof |
| KR102264992B1 (en) | 2014-12-31 | 2021-06-15 | 삼성전자 주식회사 | Method and Device for allocating a server in wireless communication system |
| US9979719B2 (en) | 2015-01-06 | 2018-05-22 | Duo Security, Inc. | System and method for converting one-time passcodes to app-based authentication |
| US10997654B1 (en) | 2015-01-15 | 2021-05-04 | Wells Fargo Bank, N.A. | Identity verification services through external entities via application programming interface |
| US9525694B2 (en) | 2015-01-15 | 2016-12-20 | Bank Of America Corporation | Authenticating customers and managing authenticated sessions |
| US9491170B2 (en) | 2015-01-15 | 2016-11-08 | Bank Of America Corporation | Authenticating customers and managing authenticated sessions |
| US20160210634A1 (en)* | 2015-01-19 | 2016-07-21 | Enet It Group, Llc | Method and system for processing payments |
| WO2016116943A2 (en)* | 2015-01-23 | 2016-07-28 | Al Rafae Badr M | Front end transaction system |
| US20160224973A1 (en)* | 2015-02-01 | 2016-08-04 | Apple Inc. | User interface for payments |
| US9424412B1 (en) | 2015-02-02 | 2016-08-23 | Bank Of America Corporation | Authenticating customers using biometrics |
| SG10201806013QA (en) | 2015-02-05 | 2018-08-30 | Uber Technologies Inc | Programmatically determining location information in connection with a transport service |
| US9794522B2 (en)* | 2015-02-06 | 2017-10-17 | Google Inc. | Systems, methods, and devices for managing coexistence of multiple transceiver devices by optimizing component layout |
| US11216468B2 (en)* | 2015-02-08 | 2022-01-04 | Visa International Service Association | Converged merchant processing apparatuses, methods and systems |
| US11250421B2 (en)* | 2015-02-08 | 2022-02-15 | Apple Inc. | Storing secure credential information in different regions |
| US20170011406A1 (en)* | 2015-02-10 | 2017-01-12 | NXT-ID, Inc. | Sound-Directed or Behavior-Directed Method and System for Authenticating a User and Executing a Transaction |
| US9680822B2 (en)* | 2015-02-12 | 2017-06-13 | At&T Mobility Ii Llc | Point of sale pairing |
| US9574896B2 (en) | 2015-02-13 | 2017-02-21 | Apple Inc. | Navigation user interface |
| CN111787154A (en)* | 2015-02-15 | 2020-10-16 | 联想(北京)有限公司 | Information processing method and electronic equipment |
| US20160239840A1 (en)* | 2015-02-17 | 2016-08-18 | Ca, Inc. | System and method of securely transferring payment for an online transaction |
| WO2016137271A1 (en)* | 2015-02-27 | 2016-09-01 | Samsung Electronics Co., Ltd. | Payment means operation supporting method and electronic device for supporting the same |
| US10193700B2 (en) | 2015-02-27 | 2019-01-29 | Samsung Electronics Co., Ltd. | Trust-zone-based end-to-end security |
| EP3262582B1 (en) | 2015-02-27 | 2021-03-17 | Samsung Electronics Co., Ltd. | Electronic device providing electronic payment function and operating method thereof |
| US10078744B2 (en) | 2015-03-02 | 2018-09-18 | Visa International Service Association | Authentication-activated augmented reality display device |
| US11853919B1 (en) | 2015-03-04 | 2023-12-26 | Wells Fargo Bank, N.A. | Systems and methods for peer-to-peer funds requests |
| US10216351B2 (en) | 2015-03-08 | 2019-02-26 | Apple Inc. | Device configuration user interface |
| US11138585B2 (en)* | 2015-03-11 | 2021-10-05 | Paypal, Inc. | NFC cookies for enhanced mobile transactions and payments |
| US10839359B2 (en) | 2015-03-23 | 2020-11-17 | Early Warning Services, Llc | Payment real-time funds availability |
| US10878387B2 (en) | 2015-03-23 | 2020-12-29 | Early Warning Services, Llc | Real-time determination of funds availability for checks and ACH items |
| US10769606B2 (en) | 2015-03-23 | 2020-09-08 | Early Warning Services, Llc | Payment real-time funds availability |
| US10832246B2 (en) | 2015-03-23 | 2020-11-10 | Early Warning Services, Llc | Payment real-time funds availability |
| US10748127B2 (en) | 2015-03-23 | 2020-08-18 | Early Warning Services, Llc | Payment real-time funds availability |
| US11456876B2 (en)* | 2015-03-26 | 2022-09-27 | Assa Abloy Ab | Virtual credentials and licenses |
| US11429975B1 (en) | 2015-03-27 | 2022-08-30 | Wells Fargo Bank, N.A. | Token management system |
| US9641341B2 (en) | 2015-03-31 | 2017-05-02 | Duo Security, Inc. | Method for distributed trust authentication |
| US10204528B2 (en) | 2015-08-05 | 2019-02-12 | Uber Technologies, Inc. | Augmenting transport services using driver profiling |
| CN106161374A (en)* | 2015-04-13 | 2016-11-23 | 阿里巴巴集团控股有限公司 | The exchange method of order data and server |
| CN106161807A (en) | 2015-04-13 | 2016-11-23 | 阿里巴巴集团控股有限公司 | Communication means and server |
| CN106157079A (en) | 2015-04-13 | 2016-11-23 | 阿里巴巴集团控股有限公司 | The exchange method of order data and server |
| US10163083B2 (en) | 2015-04-13 | 2018-12-25 | Bank Of America Corporation | Account activity management system |
| US10878407B1 (en)* | 2015-04-17 | 2020-12-29 | Jpmorgan Chase Bank, N.A. | Systems and methods for facilitating payment application provisioning and transacting |
| CN104935574B (en)* | 2015-04-28 | 2018-07-17 | 北京创鑫旅程网络技术有限公司 | A kind of application process and system of electronic ticket |
| US20160321637A1 (en)* | 2015-04-30 | 2016-11-03 | Kevin Carvalho | Point of sale payment using mobile device and checkout credentials |
| US9781105B2 (en) | 2015-05-04 | 2017-10-03 | Ping Identity Corporation | Fallback identity authentication techniques |
| WO2016185649A1 (en)* | 2015-05-20 | 2016-11-24 | パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ | Communication node, terminal, and communication control method |
| US11403506B2 (en) | 2015-05-21 | 2022-08-02 | Neology, Inc. | Detachable radio frequency identification switch tag |
| US9953318B1 (en)* | 2015-05-22 | 2018-04-24 | Intuit Inc. | Automatic transaction-based verification of account ownership |
| US9900769B2 (en) | 2015-05-29 | 2018-02-20 | Nagravision S.A. | Methods and systems for establishing an encrypted-audio session |
| US10122767B2 (en) | 2015-05-29 | 2018-11-06 | Nagravision S.A. | Systems and methods for conducting secure VOIP multi-party calls |
| US9891882B2 (en) | 2015-06-01 | 2018-02-13 | Nagravision S.A. | Methods and systems for conveying encrypted data to a communication device |
| US10356059B2 (en)* | 2015-06-04 | 2019-07-16 | Nagravision S.A. | Methods and systems for communication-session arrangement on behalf of cryptographic endpoints |
| US20160358133A1 (en) | 2015-06-05 | 2016-12-08 | Apple Inc. | User interface for loyalty accounts and private label accounts for a wearable device |
| US9940637B2 (en) | 2015-06-05 | 2018-04-10 | Apple Inc. | User interface for loyalty accounts and private label accounts |
| NL2014958B1 (en)* | 2015-06-11 | 2017-02-03 | Ok Top B V | Method for configuring a mobile communication device, device thus configured, method, system for authorizing transactions on an online account, and method for obtaining, by an initiating party, a permission from an authorizing party to a service provider for performing a transaction on an account of the user. |
| US20160379207A1 (en)* | 2015-06-25 | 2016-12-29 | Intel Corporation | Secured credential aggregator |
| US10009324B2 (en)* | 2015-06-29 | 2018-06-26 | American Express Travel Related Services Company, Inc. | Host card emulation systems and methods |
| US10242357B1 (en) | 2015-06-30 | 2019-03-26 | Square, Inc. | Configuration of a payment object reader |
| WO2017007705A1 (en)* | 2015-07-06 | 2017-01-12 | Shape Security, Inc. | Asymmetrical challenges for web security |
| US10387846B2 (en) | 2015-07-10 | 2019-08-20 | Bank Of America Corporation | System for affecting appointment calendaring on a mobile device based on dependencies |
| US10387845B2 (en) | 2015-07-10 | 2019-08-20 | Bank Of America Corporation | System for facilitating appointment calendaring based on perceived customer requirements |
| US10803229B2 (en)* | 2015-07-16 | 2020-10-13 | Thinxtream Technologies Pte. Ltd. | Hybrid system and method for data and file conversion across computing devices and platforms |
| US20210390246A1 (en)* | 2015-07-11 | 2021-12-16 | Thinxtream Technologies Ptd. Ltd. | System and method for contextual service delivery via mobile communication devices |
| BR102015017170A2 (en)* | 2015-07-17 | 2017-01-24 | Cielo S A | token generation process for payment service membership, payment terminal, and payment service membership process |
| US11157884B2 (en) | 2015-07-21 | 2021-10-26 | Early Warning Services, Llc | Secure transactions with offline device |
| US11037121B2 (en) | 2015-07-21 | 2021-06-15 | Early Warning Services, Llc | Secure real-time transactions |
| US10963856B2 (en) | 2015-07-21 | 2021-03-30 | Early Warning Services, Llc | Secure real-time transactions |
| US10956888B2 (en) | 2015-07-21 | 2021-03-23 | Early Warning Services, Llc | Secure real-time transactions |
| US11386410B2 (en) | 2015-07-21 | 2022-07-12 | Early Warning Services, Llc | Secure transactions with offline device |
| US10438175B2 (en) | 2015-07-21 | 2019-10-08 | Early Warning Services, Llc | Secure real-time payment transactions |
| US11037122B2 (en) | 2015-07-21 | 2021-06-15 | Early Warning Services, Llc | Secure real-time transactions |
| US11151523B2 (en) | 2015-07-21 | 2021-10-19 | Early Warning Services, Llc | Secure transactions with offline device |
| US11062290B2 (en) | 2015-07-21 | 2021-07-13 | Early Warning Services, Llc | Secure real-time transactions |
| US10970695B2 (en) | 2015-07-21 | 2021-04-06 | Early Warning Services, Llc | Secure real-time transactions |
| US11151522B2 (en) | 2015-07-21 | 2021-10-19 | Early Warning Services, Llc | Secure transactions with offline device |
| US9916735B2 (en) | 2015-07-22 | 2018-03-13 | Igt | Remote gaming cash voucher printing system |
| US9774579B2 (en) | 2015-07-27 | 2017-09-26 | Duo Security, Inc. | Method for key rotation |
| US9866521B2 (en) | 2015-07-30 | 2018-01-09 | At&T Intellectual Property L.L.P. | Methods, systems, and computer readable storage devices for determining whether to forward requests from a physical telephone number mapping service server to a virtual telephone number mapping service server |
| US10277736B2 (en) | 2015-07-30 | 2019-04-30 | At&T Intellectual Property I, L.P. | Methods, systems, and computer readable storage devices for determining whether to handle a request for communication services by a physical telephone number mapping service or a virtual telephone number mapping service |
| US9851999B2 (en) | 2015-07-30 | 2017-12-26 | At&T Intellectual Property I, L.P. | Methods, systems, and computer readable storage devices for handling virtualization of a physical telephone number mapping service |
| US9888127B2 (en) | 2015-07-30 | 2018-02-06 | At&T Intellectual Property I, L.P. | Methods, systems, and computer readable storage devices for adjusting the use of virtual resources providing communication services based on load |
| US11170364B1 (en) | 2015-07-31 | 2021-11-09 | Wells Fargo Bank, N.A. | Connected payment card systems and methods |
| US10055930B2 (en) | 2015-08-11 | 2018-08-21 | Igt | Gaming system and method for placing and redeeming sports bets |
| SG10201506781UA (en)* | 2015-08-27 | 2017-03-30 | Mastercard Asia Pacific Pte Ltd | Method For Managing Digital Wallets |
| US9935961B2 (en)* | 2015-09-11 | 2018-04-03 | Bank Of America Corporation | Controlling access to data |
| US10713660B2 (en)* | 2015-09-15 | 2020-07-14 | Visa International Service Association | Authorization of credential on file transactions |
| US9519901B1 (en)* | 2015-09-16 | 2016-12-13 | Square, Inc. | Biometric payment technology |
| CN106549919B (en) | 2015-09-21 | 2021-01-22 | 创新先进技术有限公司 | Information registration and authentication method and device |
| US11816672B1 (en) | 2015-09-22 | 2023-11-14 | Wells Fargo Bank, N.A. | Flexible authentication |
| US10417867B2 (en) | 2015-09-25 | 2019-09-17 | Igt | Gaming system and method for automatically transferring funds to a mobile device |
| US20170092054A1 (en) | 2015-09-25 | 2017-03-30 | Igt | Gaming system and method for utilizing a mobile device to fund a gaming session |
| SG10201508034PA (en)* | 2015-09-28 | 2017-04-27 | Mastercard Asia Pacific Pte Ltd | Device For Facilitating Identification Of A Fraudulent Payment Card |
| GB2542617B (en)* | 2015-09-28 | 2020-06-24 | Touchtech Payments Ltd | Transaction authentication platform |
| US20170103380A1 (en)* | 2015-10-12 | 2017-04-13 | Wal-Mart Stores, Inc. | System, method, and non-transitory computer-readable storage media related to transactions using a mobile device |
| US11587096B2 (en) | 2015-10-14 | 2023-02-21 | Accreditrust Technologies, LLC | Systems and methods for interdependent identity based credential collection validation |
| US10417632B2 (en) | 2015-10-23 | 2019-09-17 | Openpay, S.A.P.I. de C.V. | System and method for secure electronic payment |
| US10380584B2 (en)* | 2015-10-27 | 2019-08-13 | Jpmorgan Chase Bank, N.A. | Processing transactions using convertible optimized attribute packages |
| SG10201508866SA (en)* | 2015-10-27 | 2017-05-30 | Mastercard International Inc | Method for predicting purchasing behaviour of digital wallet users for wallet-based transactions |
| US9973337B2 (en) | 2015-11-18 | 2018-05-15 | International Business Machines Corporation | Domain-server public-key reference |
| US9980303B2 (en) | 2015-12-18 | 2018-05-22 | Cisco Technology, Inc. | Establishing a private network using multi-uplink capable network devices |
| US10198595B2 (en)* | 2015-12-22 | 2019-02-05 | Walmart Apollo, Llc | Data breach detection system |
| US11017376B1 (en)* | 2015-12-28 | 2021-05-25 | Wells Fargo Bank, N.A. | Mobile device-based dual custody verification using micro-location |
| US10817593B1 (en)* | 2015-12-29 | 2020-10-27 | Wells Fargo Bank, N.A. | User information gathering and distribution system |
| US10489777B2 (en)* | 2016-01-05 | 2019-11-26 | Visa International Service Association | Universal access to an electronic wallet |
| US10110608B2 (en)* | 2016-01-07 | 2018-10-23 | Google Llc | Authorizing transaction on a shared device using a personal device |
| TW201725546A (en)* | 2016-01-11 | 2017-07-16 | 仁寶電腦工業股份有限公司 | Secure payment device and secure payment method thereof |
| US11042878B2 (en) | 2016-01-19 | 2021-06-22 | Priv8Pay, Inc. | Network node authentication |
| CN107016229B (en)* | 2016-01-21 | 2021-12-24 | 株式会社堀场制作所 | Management device for measuring equipment |
| US10943247B1 (en)* | 2016-02-02 | 2021-03-09 | Jpmorgan Chase Bank, N.A. | Systems and methods for providing expedited promotions |
| US10498740B2 (en)* | 2016-02-11 | 2019-12-03 | Samsung Electronics Co., Ltd. | Method, apparatus, and system for creating service account |
| US10297148B2 (en) | 2016-02-17 | 2019-05-21 | Uber Technologies, Inc. | Network computer system for analyzing driving actions of drivers on road segments of a geographic region |
| US10044710B2 (en) | 2016-02-22 | 2018-08-07 | Bpip Limited Liability Company | Device and method for validating a user using an intelligent voice print |
| US10091243B2 (en)* | 2016-02-24 | 2018-10-02 | Qualcomm Incorporated | Apparatus and method for securely connecting to a remote server |
| US9542678B1 (en) | 2016-03-31 | 2017-01-10 | Square, Inc. | Exclusive bonding of wireless devices |
| US10366383B2 (en)* | 2016-03-31 | 2019-07-30 | Square, Inc. | Combined reliable and unreliable data transmission |
| US10210518B2 (en) | 2016-04-13 | 2019-02-19 | Abdullah Abdulaziz I. Alnajem | Risk-link authentication for optimizing decisions of multi-factor authentications |
| US11250432B2 (en)* | 2016-04-13 | 2022-02-15 | America Express Travel Related Services Company, Inc. | Systems and methods for reducing fraud risk for a primary transaction account |
| EP3442677A4 (en) | 2016-04-13 | 2019-09-25 | Skywell, LLC | Atmospheric water generator system and method |
| AU2016403410B2 (en)* | 2016-04-20 | 2022-07-07 | Visa International Service Association | Access credential management device |
| US11107066B1 (en)* | 2016-04-26 | 2021-08-31 | Wells Fargo Bank, N.A. | Mobile wallet with offline payment |
| US10142340B2 (en)* | 2016-05-27 | 2018-11-27 | Bank Of America Corporation | System for detection and identification of electronic devices and allocation of proxy identifiers for same |
| US11361316B2 (en)* | 2016-06-06 | 2022-06-14 | Refinitiv Us Organization Llc | Systems and methods for providing a personal distributed ledger |
| US10672198B2 (en) | 2016-06-14 | 2020-06-02 | Uber Technologies, Inc. | Trip termination determination for on-demand transport |
| US10250596B2 (en)* | 2016-06-29 | 2019-04-02 | International Business Machines Corporation | Monitoring encrypted communication sessions |
| FR3053549B1 (en)* | 2016-06-30 | 2018-07-27 | Ingenico Group | METHOD OF AUTHENTICATING PAYMENT DATA, DEVICES AND PROGRAMS THEREFOR. |
| FR3053548B1 (en) | 2016-06-30 | 2019-07-19 | Ingenico Group | METHOD OF AUTHENTICATING PAYMENT DATA, DEVICES AND PROGRAMS THEREFOR. |
| US11386223B1 (en) | 2016-07-01 | 2022-07-12 | Wells Fargo Bank, N.A. | Access control tower |
| US11935020B1 (en) | 2016-07-01 | 2024-03-19 | Wells Fargo Bank, N.A. | Control tower for prospective transactions |
| US12130937B1 (en) | 2016-07-01 | 2024-10-29 | Wells Fargo Bank, N.A. | Control tower for prospective transactions |
| US10992679B1 (en) | 2016-07-01 | 2021-04-27 | Wells Fargo Bank, N.A. | Access control tower |
| US11615402B1 (en) | 2016-07-01 | 2023-03-28 | Wells Fargo Bank, N.A. | Access control tower |
| US11886611B1 (en) | 2016-07-01 | 2024-01-30 | Wells Fargo Bank, N.A. | Control tower for virtual rewards currency |
| BR102016015611B1 (en)* | 2016-07-04 | 2022-04-05 | Rpc Rede Ponto Certo Tecnologia E Serviços Ltda | Mobile system for transactional updating of information on contactless chips |
| US10129221B1 (en) | 2016-07-05 | 2018-11-13 | Uber Technologies, Inc. | Transport facilitation system implementing dual content encryption |
| EP3482337B1 (en) | 2016-07-11 | 2021-09-29 | Visa International Service Association | Encryption key exchange process using access device |
| US11243567B2 (en) | 2016-07-13 | 2022-02-08 | Motorola Mobility Llc | Deformable electronic device and methods and systems for reconfiguring presentation data and actuation elements |
| US10878771B2 (en) | 2016-07-13 | 2020-12-29 | Motorola Mobility Llc | Deformable electronic device and methods and systems for display remediation to compensate performance degradation |
| US10372892B2 (en) | 2016-07-13 | 2019-08-06 | Motorola Mobility Llc | Electronic device with gesture actuation of companion devices, and corresponding systems and methods |
| US20180020349A1 (en)* | 2016-07-13 | 2018-01-18 | Motorola Mobility Llc | Electronic Device with Biometric Authentication Control of Companion Devices, and Corresponding Systems and Methods |
| US10251056B2 (en)* | 2016-07-13 | 2019-04-02 | Motorola Mobility Llc | Electronic device with gesture actuation of companion devices, and corresponding systems and methods |
| US10803457B2 (en)* | 2016-07-20 | 2020-10-13 | Craig Potts | System for coordinating access to multiple accounts using a single access card |
| CA3032284A1 (en) | 2016-07-29 | 2018-02-01 | Benjamin HAMMEL | Integrated credential data management techniques |
| US10210345B2 (en) | 2016-08-04 | 2019-02-19 | Bank Of America Corporation | Intelligent credential selection system |
| US10217317B2 (en) | 2016-08-09 | 2019-02-26 | Igt | Gaming system and method for providing incentives for transferring funds to and from a mobile device |
| US10916090B2 (en) | 2016-08-23 | 2021-02-09 | Igt | System and method for transferring funds from a financial institution device to a cashless wagering account accessible via a mobile device |
| JP6696373B2 (en)* | 2016-09-09 | 2020-05-20 | 富士通株式会社 | Management device and shared network system |
| US10075300B1 (en) | 2016-09-13 | 2018-09-11 | Wells Fargo Bank, N.A. | Secure digital communications |
| US10057061B1 (en) | 2016-09-13 | 2018-08-21 | Wells Fargo Bank, N.A. | Secure digital communications |
| US11151567B2 (en) | 2016-09-19 | 2021-10-19 | Early Warning Services, Llc | Authentication and fraud prevention in provisioning a mobile wallet |
| CN109417574B (en)* | 2016-09-23 | 2021-10-29 | 苹果公司 | Manage credentials for multiple users on electronic devices |
| US10257190B2 (en)* | 2016-09-23 | 2019-04-09 | Schlage Lock Company Llc | Wi-fi enabled credential enrollment reader and credential management system for access control |
| US10860199B2 (en) | 2016-09-23 | 2020-12-08 | Apple Inc. | Dynamically adjusting touch hysteresis based on contextual data |
| US10621824B2 (en) | 2016-09-23 | 2020-04-14 | Igt | Gaming system player identification device |
| US11468414B1 (en) | 2016-10-03 | 2022-10-11 | Wells Fargo Bank, N.A. | Systems and methods for establishing a pull payment relationship |
| CN106469095A (en)* | 2016-10-08 | 2017-03-01 | 深圳市金立通信设备有限公司 | A kind of processing method of application data and terminal |
| KR102645674B1 (en)* | 2016-10-13 | 2024-03-11 | 삼성전자주식회사 | Electronic device and operating method thereof |
| GB201617620D0 (en)* | 2016-10-18 | 2016-11-30 | Cybernetica As | Composite digital signatures |
| US10438195B2 (en) | 2016-10-28 | 2019-10-08 | Visa International Service Association | Token creation and provisioning |
| FR3058814B1 (en)* | 2016-11-15 | 2019-10-25 | Ingenico Group | METHOD FOR PROCESSING TRANSACTIONAL DATA, COMMUNICATION TERMINAL, CARD READER AND CORRESPONDING PROGRAM. |
| US10853798B1 (en) | 2016-11-28 | 2020-12-01 | Wells Fargo Bank, N.A. | Secure wallet-to-wallet transactions |
| US10062074B1 (en) | 2016-11-30 | 2018-08-28 | Square, Inc. | System for improving card on file transactions |
| US10320771B2 (en)* | 2016-11-30 | 2019-06-11 | Airwatch Llc | Single sign-on framework for browser-based applications and native applications |
| CA3045344A1 (en) | 2016-12-01 | 2018-06-07 | Royal Bank Of Canada | System and method for message recipient verification |
| KR102516571B1 (en)* | 2016-12-06 | 2023-03-31 | 아싸 아브로이 에이비 | Provide access to the service provider's lock |
| US10146924B2 (en) | 2016-12-14 | 2018-12-04 | Fotonation Limited | Systems and methods for authenticating a biometric device using a trusted coordinating smart device |
| US10984411B1 (en)* | 2016-12-16 | 2021-04-20 | Wells Fargo Bank, N.A. | Sending secure proxy elements with mobile wallets |
| US20180189767A1 (en)* | 2016-12-29 | 2018-07-05 | Fotonation Limited | Systems and methods for utilizing payment card information with a secure biometric processor on a mobile device |
| US10057225B1 (en)* | 2016-12-29 | 2018-08-21 | Wells Fargo Bank, N.A. | Wireless peer to peer mobile wallet connections |
| US10373146B2 (en)* | 2016-12-29 | 2019-08-06 | Capital One Services, Llc | Smart card NFC secure money transfer |
| WO2018133853A1 (en)* | 2017-01-22 | 2018-07-26 | 华为技术有限公司 | Communication method and device |
| US11507935B1 (en) | 2017-02-14 | 2022-11-22 | Wells Fargo Bank, N.A. | Mobile wallet card control |
| US10371542B2 (en) | 2017-02-17 | 2019-08-06 | Uber Technologies, Inc. | System and methods for performing multivariate optimizations based on location data |
| WO2018170404A1 (en)* | 2017-03-16 | 2018-09-20 | Jpmorgan Chase Bank, N.A. | Systems and methods for supporting legacy and tokenized e-commerce |
| US10445950B1 (en) | 2017-03-27 | 2019-10-15 | Uber Technologies, Inc. | Vehicle monitoring system |
| US10402771B1 (en) | 2017-03-27 | 2019-09-03 | Uber Technologies, Inc. | System and method for evaluating drivers using sensor data from mobile computing devices |
| GB2574355A (en)* | 2017-03-29 | 2019-12-04 | Innoviti Payment Solutions Private Ltd | Method and system for establishing secure communication between terminal device and target system |
| US11556936B1 (en) | 2017-04-25 | 2023-01-17 | Wells Fargo Bank, N.A. | System and method for card control |
| US11321680B2 (en)* | 2017-04-26 | 2022-05-03 | Ashish Kumar | System and method for processing and management of transactions using electronic currency |
| WO2018234882A1 (en)* | 2017-05-16 | 2018-12-27 | Angus Bernhardt Pohl | A system and method for conducting a transaction |
| US10977361B2 (en) | 2017-05-16 | 2021-04-13 | Beyondtrust Software, Inc. | Systems and methods for controlling privileged operations |
| US11138595B2 (en)* | 2017-05-30 | 2021-10-05 | Visa International Service Association | System, method, and computer program product for maintaining transaction integrity over public networks |
| US10509921B2 (en) | 2017-05-31 | 2019-12-17 | Intuit Inc. | System for managing transactional data |
| US10003464B1 (en)* | 2017-06-07 | 2018-06-19 | Cerebral, Incorporated | Biometric identification system and associated methods |
| US10509774B2 (en)* | 2017-06-09 | 2019-12-17 | Red Hat, Inc. | Secure containerized user specific isolated data storage |
| US10360733B2 (en) | 2017-06-20 | 2019-07-23 | Bank Of America Corporation | System controlled augmented resource facility |
| US10574662B2 (en) | 2017-06-20 | 2020-02-25 | Bank Of America Corporation | System for authentication of a user based on multi-factor passively acquired data |
| US11233634B1 (en) | 2017-06-23 | 2022-01-25 | Wells Fargo Bank, N.A. | Systems and methods for network authentication with a shared secret |
| CN107317928B (en)* | 2017-06-26 | 2020-07-28 | Oppo广东移动通信有限公司 | Information processing method, mobile terminal, and computer-readable storage medium |
| CN107146078A (en)* | 2017-06-30 | 2017-09-08 | 山东开创云软件有限公司 | The mobile device and method of payment of a kind of quick payment |
| US11062388B1 (en) | 2017-07-06 | 2021-07-13 | Wells Fargo Bank, N.A | Data control tower |
| US10332344B2 (en) | 2017-07-24 | 2019-06-25 | Igt | System and method for controlling electronic gaming machine/electronic gaming machine component bezel lighting to indicate different wireless connection statuses |
| SG10201706070TA (en)* | 2017-07-25 | 2019-02-27 | Mastercard International Inc | Offline Payment Using Virtual Card Account Number |
| US10380843B2 (en) | 2017-08-03 | 2019-08-13 | Igt | System and method for tracking funds from a plurality of funding sources |
| US10373430B2 (en) | 2017-08-03 | 2019-08-06 | Igt | System and method for tracking fund transfers between an electronic gaming machine and a plurality of funding sources |
| US10360761B2 (en) | 2017-08-03 | 2019-07-23 | Igt | System and method for providing a gaming establishment account pre-approved access to funds |
| US10360763B2 (en) | 2017-08-03 | 2019-07-23 | Igt | System and method for utilizing a mobile device to facilitate fund transfers between a cashless wagering account and a gaming establishment retail account |
| US10776777B1 (en) | 2017-08-04 | 2020-09-15 | Wells Fargo Bank, N.A. | Consolidating application access in a mobile wallet |
| EP3451262A1 (en)* | 2017-08-29 | 2019-03-06 | Mastercard International Incorporated | A system for verifying a user of a payment device |
| US11688003B2 (en) | 2017-09-19 | 2023-06-27 | The Toronto-Dominion Bank | System and method for integrated application and provisioning |
| CA3017883A1 (en)* | 2017-09-19 | 2019-03-19 | The Toronto-Dominion Bank | System and method for integrated application and provisioning |
| EP3471038A1 (en)* | 2017-10-13 | 2019-04-17 | Mastercard International Incorporated | User authentication and transaction staging |
| WO2019083890A1 (en)* | 2017-10-25 | 2019-05-02 | Klearexpress Corporation | Delivering international shipped items |
| US10997650B2 (en) | 2017-10-31 | 2021-05-04 | Microsoft Technology Licensing, Llc | Conversation as a platform to increase task productivity for end users |
| US20190130496A1 (en)* | 2017-11-01 | 2019-05-02 | Visa International Service Association | System, Method, and Computer Program Product for Providing Merchant-Based Social Networks |
| JP6978898B2 (en)* | 2017-11-01 | 2021-12-08 | シャープ株式会社 | Information processing equipment, information processing systems, control programs and control methods |
| US11188887B1 (en) | 2017-11-20 | 2021-11-30 | Wells Fargo Bank, N.A. | Systems and methods for payment information access management |
| US10819805B2 (en)* | 2017-12-05 | 2020-10-27 | At&T Intellectual Property I, L.P. | Systems and methods for providing ENUM service activations |
| US10855647B2 (en) | 2017-12-05 | 2020-12-01 | At&T Intellectual Property I, L.P. | Systems and methods for providing ENUM service activations |
| US10412113B2 (en) | 2017-12-08 | 2019-09-10 | Duo Security, Inc. | Systems and methods for intelligently configuring computer security |
| US11017403B2 (en) | 2017-12-15 | 2021-05-25 | Mastercard International Incorporated | Systems and methods for identifying fraudulent common point of purchases |
| US11922765B2 (en) | 2017-12-18 | 2024-03-05 | Igt | System and method employing virtual tickets |
| US10643426B2 (en) | 2017-12-18 | 2020-05-05 | Igt | System and method for providing a gaming establishment account automatic access to funds |
| US11341817B2 (en) | 2017-12-18 | 2022-05-24 | Igt | System and method for providing awards for utilizing a mobile device in association with a gaming establishment retail account |
| US10950088B2 (en) | 2017-12-21 | 2021-03-16 | Igt | System and method for utilizing virtual ticket vouchers |
| US11043066B2 (en) | 2017-12-21 | 2021-06-22 | Igt | System and method for centralizing funds to a primary gaming establishment account |
| US10630769B2 (en)* | 2017-12-26 | 2020-04-21 | Akamai Technologies, Inc. | Distributed system of record transaction receipt handling in an overlay network |
| US11106515B1 (en) | 2017-12-28 | 2021-08-31 | Wells Fargo Bank, N.A. | Systems and methods for multi-platform product integration |
| US10846679B2 (en)* | 2018-01-16 | 2020-11-24 | Capital One Services, Llc | Peer-to-peer payment systems and methods |
| WO2019143492A1 (en) | 2018-01-22 | 2019-07-25 | Apple Inc. | Secure login with authentication based on a visual representation of data |
| WO2019152265A1 (en) | 2018-01-30 | 2019-08-08 | Visa International Service Association | System and method for biometric fallback authentication |
| US11917070B2 (en) | 2018-02-17 | 2024-02-27 | Carrier Corporation | Method and system for managing a multiplicity of credentials |
| US11295297B1 (en) | 2018-02-26 | 2022-04-05 | Wells Fargo Bank, N.A. | Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet |
| US20190266591A1 (en)* | 2018-02-27 | 2019-08-29 | Ncr Corporation | Payment interface |
| WO2019173081A1 (en)* | 2018-03-08 | 2019-09-12 | Mastercard International Incorporated | Systems and methods for digitizing payment card accounts |
| US11687929B2 (en)* | 2018-03-23 | 2023-06-27 | American Express Travel Related Services Co., Inc. | Authenticated secure online and offline transactions |
| US11531783B2 (en) | 2018-03-27 | 2022-12-20 | Workday, Inc. | Digital credentials for step-up authentication |
| US11698979B2 (en) | 2018-03-27 | 2023-07-11 | Workday, Inc. | Digital credentials for access to sensitive data |
| US11770261B2 (en) | 2018-03-27 | 2023-09-26 | Workday, Inc. | Digital credentials for user device authentication |
| US11627000B2 (en) | 2018-03-27 | 2023-04-11 | Workday, Inc. | Digital credentials for employee badging |
| US11716320B2 (en) | 2018-03-27 | 2023-08-01 | Workday, Inc. | Digital credentials for primary factor authentication |
| US11792181B2 (en) | 2018-03-27 | 2023-10-17 | Workday, Inc. | Digital credentials as guest check-in for physical building access |
| US11019053B2 (en)* | 2018-03-27 | 2021-05-25 | Workday, Inc. | Requesting credentials |
| US11792180B2 (en) | 2018-03-27 | 2023-10-17 | Workday, Inc. | Digital credentials for visitor network access |
| US11522713B2 (en) | 2018-03-27 | 2022-12-06 | Workday, Inc. | Digital credentials for secondary factor authentication |
| US11683177B2 (en) | 2018-03-27 | 2023-06-20 | Workday, Inc. | Digital credentials for location aware check in |
| US11641278B2 (en) | 2018-03-27 | 2023-05-02 | Workday, Inc. | Digital credential authentication |
| US11700117B2 (en) | 2018-03-27 | 2023-07-11 | Workday, Inc. | System for credential storage and verification |
| US11397935B2 (en) | 2018-04-02 | 2022-07-26 | Hover Developer Services, Inc. | System and method for wireless transactions |
| US10970968B2 (en) | 2018-04-18 | 2021-04-06 | Igt | System and method for incentivizing the maintenance of funds in a gaming establishment account |
| CN111860020B (en) | 2018-04-25 | 2024-10-01 | 创新先进技术有限公司 | Business processing method, device and equipment |
| US11074577B1 (en) | 2018-05-10 | 2021-07-27 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
| US11775955B1 (en) | 2018-05-10 | 2023-10-03 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
| CN108875327A (en) | 2018-05-28 | 2018-11-23 | 阿里巴巴集团控股有限公司 | One seed nucleus body method and apparatus |
| WO2019232329A1 (en)* | 2018-06-01 | 2019-12-05 | Capital One Services, Llc | Beacon-triggered activation of a near field communication application |
| CN109035636A (en) | 2018-06-04 | 2018-12-18 | 阿里巴巴集团控股有限公司 | A kind of Cash collecting equipment, a kind of cashing method and device |
| BE1026342B9 (en)* | 2018-06-04 | 2020-02-04 | Worldline Sa | DEVICE AND METHOD FOR SECURE IDENTIFICATION OF A USER |
| US10965464B1 (en)* | 2018-06-08 | 2021-03-30 | Wells Fargo Bank, N.A. | Tactile binary coded communication |
| US11303632B1 (en)* | 2018-06-08 | 2022-04-12 | Wells Fargo Bank, N.A. | Two-way authentication system and method |
| US10915897B2 (en)* | 2018-06-13 | 2021-02-09 | Clover Network, Inc. | Token management for enhanced omni-channel payments experience and analytics |
| US11546728B2 (en) | 2018-06-15 | 2023-01-03 | Proxy, Inc. | Methods and apparatus for presence sensing reporting |
| US11462095B2 (en) | 2018-06-15 | 2022-10-04 | Proxy, Inc. | Facility control methods and apparatus |
| US11509475B2 (en) | 2018-06-15 | 2022-11-22 | Proxy, Inc. | Method and apparatus for obtaining multiple user credentials |
| US11411735B2 (en)* | 2018-06-15 | 2022-08-09 | Proxy, Inc. | Methods and apparatus for authorizing and providing of distributed goods or services |
| US11109234B2 (en) | 2018-06-15 | 2021-08-31 | Proxy, Inc. | Reader device with sensor streaming data and methods |
| US11438767B2 (en) | 2018-06-15 | 2022-09-06 | Proxy, Inc. | Methods and apparatus for preauthorizing reader devices |
| US11256789B2 (en)* | 2018-06-18 | 2022-02-22 | Visa International Service Association | Recurring token transactions |
| US11205168B2 (en)* | 2018-06-26 | 2021-12-21 | International Business Machines Corporation | Frictionless microlocation detection and authorization |
| US11651369B2 (en)* | 2018-07-12 | 2023-05-16 | American Express Travel Related Services Company, Inc. | Remote EMV payment applications |
| US11637694B2 (en) | 2018-07-16 | 2023-04-25 | Winkk, Inc. | Secret material exchange and authentication cryptography operations |
| US20200052917A1 (en)* | 2018-08-10 | 2020-02-13 | Peertracks Inc. | Systems and methods for an online media marketplace |
| US20200074562A1 (en)* | 2018-08-28 | 2020-03-05 | American Express Travel Related Services Company, Inc. | Systems and methods for generating product-merchant data links |
| US12045809B1 (en) | 2018-08-30 | 2024-07-23 | Wells Fargo Bank, N.A. | Biller consortium enrollment and transaction management engine |
| US12254463B1 (en) | 2018-08-30 | 2025-03-18 | Wells Fargo Bank, N.A. | Biller directory and payments engine architecture |
| US10878402B1 (en) | 2018-08-31 | 2020-12-29 | Square, Inc. | Temporarily provisioning payment functionality to alternate payment instrument |
| US10997583B1 (en) | 2018-08-31 | 2021-05-04 | Square, Inc. | Temporarily provisioning card on file payment functionality to proximate merchants |
| US10733473B2 (en) | 2018-09-20 | 2020-08-04 | Uber Technologies Inc. | Object verification for a network-based service |
| US12200165B1 (en) | 2018-09-27 | 2025-01-14 | Iqx Corp. | Automated silent network authentication protocol security, verification, and access control for cellular handheld devices |
| US11157643B2 (en) | 2018-09-27 | 2021-10-26 | The Toronto-Dominion Bank | Systems and methods for delegating access to a protected resource |
| US11363028B2 (en) | 2018-09-27 | 2022-06-14 | The Toronto-Dominion Bank | Systems and methods for delegating access to a protected resource |
| US11765262B2 (en) | 2018-09-27 | 2023-09-19 | Iqx Corp. | Customer capture using dynamically generated customized webpages |
| US10582386B1 (en) | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10771254B2 (en) | 2018-10-02 | 2020-09-08 | Capital One Services, Llc | Systems and methods for email-based card activation |
| US10581611B1 (en)* | 2018-10-02 | 2020-03-03 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10748138B2 (en)* | 2018-10-02 | 2020-08-18 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10607214B1 (en)* | 2018-10-02 | 2020-03-31 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| WO2020072537A1 (en) | 2018-10-02 | 2020-04-09 | Capital One Services, Llc | Systems and methods for cryptographic authentication of contactless cards |
| US10999299B2 (en) | 2018-10-09 | 2021-05-04 | Uber Technologies, Inc. | Location-spoofing detection system for a network service |
| SG11202103512UA (en)* | 2018-10-11 | 2021-05-28 | Visa Int Service Ass | Tokenized contactless transaction enabled by cloud biometric identification and authentication |
| CA3020929A1 (en)* | 2018-10-16 | 2020-04-16 | The Toronto-Dominion Bank | Integrated credit application and provisioning solution |
| US11538034B2 (en)* | 2018-10-17 | 2022-12-27 | Entersekt International Limited | Providing computer-generated contextual data to an end-point during a digital transaction |
| US11599860B2 (en)* | 2018-11-02 | 2023-03-07 | International Business Machines Corporation | Limit purchase price by stock keeping unit (SKU) |
| US10891530B2 (en) | 2018-11-07 | 2021-01-12 | Neology, Inc. | Detachable radio frequency identification switch tag |
| US11080409B2 (en)* | 2018-11-07 | 2021-08-03 | Ngd Systems, Inc. | SSD content encryption and authentication |
| EP3654264A1 (en)* | 2018-11-14 | 2020-05-20 | Mastercard International Incorporated | Credential management for mobile devices |
| CN110247884B (en)* | 2018-11-21 | 2023-05-19 | 浙江大华技术股份有限公司 | Method, device and system for updating certificate and computer readable storage medium |
| CN109657441B (en)* | 2018-11-27 | 2022-11-29 | Oppo广东移动通信有限公司 | Application opening method and related device |
| CN109743538A (en)* | 2018-11-30 | 2019-05-10 | 与德科技有限公司 | Monitor video checks control method |
| US11258789B2 (en) | 2018-12-04 | 2022-02-22 | Forcepoint Llc | System and method for fingerprint validation |
| US11658962B2 (en) | 2018-12-07 | 2023-05-23 | Cisco Technology, Inc. | Systems and methods of push-based verification of a transaction |
| US11379850B1 (en) | 2018-12-10 | 2022-07-05 | Wells Fargo Bank, N.A. | Third-party payment interfaces |
| WO2020123274A1 (en) | 2018-12-10 | 2020-06-18 | Mastercard International Incorporated | Systems and methods for provisioning accounts |
| US10937030B2 (en) | 2018-12-28 | 2021-03-02 | Mastercard International Incorporated | Systems and methods for early detection of network fraud events |
| US11521211B2 (en) | 2018-12-28 | 2022-12-06 | Mastercard International Incorporated | Systems and methods for incorporating breach velocities into fraud scoring models |
| US11157913B2 (en) | 2018-12-28 | 2021-10-26 | Mastercard International Incorporated | Systems and methods for improved detection of network fraud events |
| US11151569B2 (en) | 2018-12-28 | 2021-10-19 | Mastercard International Incorporated | Systems and methods for improved detection of network fraud events |
| US20200211099A1 (en)* | 2018-12-31 | 2020-07-02 | Finicity Corporation | Decentralized Customer-Controlled Credit Verification |
| US11930439B2 (en) | 2019-01-09 | 2024-03-12 | Margo Networks Private Limited | Network control and optimization (NCO) system and method |
| JP7273523B2 (en)* | 2019-01-25 | 2023-05-15 | 株式会社東芝 | Communication control device and communication control system |
| US11288347B2 (en)* | 2019-03-07 | 2022-03-29 | Paypal, Inc. | Login from an alternate electronic device |
| US11328352B2 (en) | 2019-03-24 | 2022-05-10 | Apple Inc. | User interfaces for managing an account |
| US11528149B2 (en) | 2019-04-26 | 2022-12-13 | Beyondtrust Software, Inc. | Root-level application selective configuration |
| US11206265B2 (en)* | 2019-04-30 | 2021-12-21 | Infoblox Inc. | Smart whitelisting for DNS security |
| US20220043915A1 (en)* | 2019-04-30 | 2022-02-10 | Hewlett-Packard Development Company, L.P. | Storage of network credentials |
| US11227354B2 (en) | 2019-05-20 | 2022-01-18 | The Toronto-Dominion Bank | Integration of workflow with digital ID |
| US11769132B1 (en) | 2019-05-22 | 2023-09-26 | Wells Fargo Bank, N.A. | P2P payments via integrated 3rd party APIs |
| US11481094B2 (en) | 2019-06-01 | 2022-10-25 | Apple Inc. | User interfaces for location-related communications |
| US11477609B2 (en) | 2019-06-01 | 2022-10-18 | Apple Inc. | User interfaces for location-related communications |
| US11551190B1 (en) | 2019-06-03 | 2023-01-10 | Wells Fargo Bank, N.A. | Instant network cash transfer at point of sale |
| US10715996B1 (en)* | 2019-06-06 | 2020-07-14 | T-Mobile Usa, Inc. | Transparent provisioning of a third-party service for a user device on a telecommunications network |
| US11410138B2 (en) | 2019-06-19 | 2022-08-09 | The Toronto-Dominion Bank | Value transfer card management system |
| US11367076B2 (en) | 2019-06-19 | 2022-06-21 | The Toronto-Dominion Bank | Entity-based controls for value transfer cards |
| US11044246B1 (en)* | 2019-06-21 | 2021-06-22 | Wells Fargo Bank, N.A. | Secure communications via third-party systems through frames |
| US11620389B2 (en) | 2019-06-24 | 2023-04-04 | University Of Maryland Baltimore County | Method and system for reducing false positives in static source code analysis reports using machine learning and classification techniques |
| US11281788B2 (en)* | 2019-07-01 | 2022-03-22 | Bank Of America Corporation | Transient pliant encryption with indicative nano display cards |
| US11652638B2 (en)* | 2019-07-10 | 2023-05-16 | Mastercard International Incorporated | Systems and methods for managing user identities in networks |
| US10506426B1 (en)* | 2019-07-19 | 2019-12-10 | Capital One Services, Llc | Techniques for call authentication |
| US11093262B2 (en) | 2019-07-29 | 2021-08-17 | Motorola Mobility Llc | Electronic devices and corresponding methods for switching between normal and privacy modes of operation |
| WO2021022204A1 (en)* | 2019-07-31 | 2021-02-04 | Iigc, Inc. | Image-based authorization and transmission of stored value or sim cards |
| US11068769B2 (en) | 2019-08-08 | 2021-07-20 | Service Point Systems LLC | Secure NFC tag service point messaging system |
| US11270275B2 (en)* | 2019-08-16 | 2022-03-08 | Comenity Llc | One card |
| US11962585B2 (en) | 2019-08-20 | 2024-04-16 | Cisco Technology, Inc. | Guest onboarding of devices onto 3GPP-based networks with use of realm-based discovery of identity providers and mutual authentication of identity federation peers |
| US11165787B2 (en) | 2019-08-26 | 2021-11-02 | Bank Of America Corporation | System for authorization of electronic data access and processing functions within a distributed server network |
| US11113375B2 (en) | 2019-09-09 | 2021-09-07 | Motorola Mobility Llc | Electronic devices with proximity authentication and gaze actuation of companion electronic devices and corresponding methods |
| US11270110B2 (en) | 2019-09-17 | 2022-03-08 | Boston Polarimetrics, Inc. | Systems and methods for surface modeling using polarization cues |
| US12190313B2 (en)* | 2019-09-19 | 2025-01-07 | Jpmorgan Chase Bank, N.A. | Systems and methods for card replacement |
| KR102823721B1 (en)* | 2019-09-24 | 2025-06-23 | 삼성전자 주식회사 | An electronic device for selectively using coils to support power sharing |
| KR102451495B1 (en) | 2019-09-29 | 2022-10-06 | 애플 인크. | Account Management User Interfaces |
| US11169830B2 (en) | 2019-09-29 | 2021-11-09 | Apple Inc. | Account management user interfaces |
| WO2021071992A1 (en) | 2019-10-07 | 2021-04-15 | Boston Polarimetrics, Inc. | Systems and methods for augmentation of sensor systems and imaging systems with polarization |
| US11432149B1 (en) | 2019-10-10 | 2022-08-30 | Wells Fargo Bank, N.A. | Self-sovereign identification via digital credentials for selected identity attributes |
| WO2021076077A1 (en)* | 2019-10-14 | 2021-04-22 | Turkiye Garanti Bankasi Anonim Sirketi | An augmented reality shopping system |
| US12093944B2 (en)* | 2019-10-18 | 2024-09-17 | Mastercard International Incorporated | Methods and systems for provisioning consumer payment credentials to token requestors |
| EP3813265A1 (en) | 2019-10-24 | 2021-04-28 | Mastercard International Incorporated | Data processing apparatuses and methods |
| US11367059B2 (en) | 2019-10-31 | 2022-06-21 | The Toronto-Dominion Bank | Integrated credit application and merchant transaction including concurrent visualization of transaction details |
| US11297065B2 (en)* | 2019-11-01 | 2022-04-05 | International Business Machines Corporation | Technology for computing resource liaison |
| US11356473B2 (en)* | 2019-11-25 | 2022-06-07 | Level 3 Communications, Llc | Web service-based monitoring and detection of fraudulent or unauthorized use of calling service |
| DE112020005932T5 (en) | 2019-11-30 | 2023-01-05 | Boston Polarimetrics, Inc. | SYSTEMS AND METHODS FOR SEGMENTATION OF TRANSPARENT OBJECTS USING POLARIZATION CHARACTERISTICS |
| US12073378B2 (en)* | 2019-12-10 | 2024-08-27 | Winkk, Inc. | Method and apparatus for electronic transactions using personal computing devices and proxy services |
| US12132763B2 (en) | 2019-12-10 | 2024-10-29 | Winkk, Inc. | Bus for aggregated trust framework |
| US12143419B2 (en) | 2019-12-10 | 2024-11-12 | Winkk, Inc. | Aggregated trust framework |
| US12153678B2 (en) | 2019-12-10 | 2024-11-26 | Winkk, Inc. | Analytics with shared traits |
| US11553337B2 (en) | 2019-12-10 | 2023-01-10 | Winkk, Inc. | Method and apparatus for encryption key exchange with enhanced security through opti-encryption channel |
| US12335399B2 (en) | 2019-12-10 | 2025-06-17 | Winkk, Inc. | User as a password |
| US11588794B2 (en) | 2019-12-10 | 2023-02-21 | Winkk, Inc. | Method and apparatus for secure application framework and platform |
| US12341790B2 (en) | 2019-12-10 | 2025-06-24 | Winkk, Inc. | Device behavior analytics |
| WO2021126253A1 (en)* | 2019-12-20 | 2021-06-24 | Hewlett-Packard Development Company, L.P. | Device registration |
| US11416874B1 (en)* | 2019-12-26 | 2022-08-16 | StratoKey Pty Ltd. | Compliance management system |
| US11284264B2 (en) | 2019-12-30 | 2022-03-22 | Motorola Mobility Llc | Shareable device use based on user identifiable information |
| US11315000B1 (en) | 2019-12-30 | 2022-04-26 | American Express Travel Related Services Company, Inc. | Computer-based systems having computing devices configured to interact with dynamic cards and methods of use thereof |
| US11140239B2 (en) | 2019-12-30 | 2021-10-05 | Motorola Mobility Llc | End a shareable device interactive session based on user intent |
| US11019191B1 (en)* | 2019-12-30 | 2021-05-25 | Motorola Mobility Llc | Claim a shareable device for personalized interactive session |
| US11640453B2 (en) | 2019-12-30 | 2023-05-02 | Motorola Mobility Llc | User authentication facilitated by an additional device |
| EP4081933A4 (en) | 2020-01-29 | 2024-03-20 | Intrinsic Innovation LLC | Systems and methods for characterizing object pose detection and measurement systems |
| US11797863B2 (en) | 2020-01-30 | 2023-10-24 | Intrinsic Innovation Llc | Systems and methods for synthesizing data for training statistical models on different imaging modalities including polarized images |
| US11494517B2 (en) | 2020-02-12 | 2022-11-08 | Uber Technologies, Inc. | Computer system and device for controlling use of secure media recordings |
| CN111311265B (en)* | 2020-02-13 | 2023-07-25 | 布比（北京）网络技术有限公司 | Blockchain private transaction proving method, blockchain private transaction proving device, computer equipment and storage medium |
| EP4104124A4 (en)* | 2020-02-14 | 2023-08-30 | Lisnr | Systems and methods for initiating transactions during intended windows based on detected devices |
| US11457057B2 (en)* | 2020-03-11 | 2022-09-27 | Microsoft Technology Licensing, Llc | Systems and methods for establishing highly secure and resilient persistent communication connections |
| US11435914B2 (en)* | 2020-03-30 | 2022-09-06 | Western Digital Technologies, Inc. | Dynamic ZNS open zone active limit |
| DK180985B1 (en) | 2020-04-10 | 2022-09-02 | Apple Inc | User interfaces for enabling an activity |
| CN113641983B (en)* | 2020-04-15 | 2024-06-07 | 支付宝(杭州)信息技术有限公司 | Account binding method, device and system of application program |
| US20210326893A1 (en)* | 2020-04-16 | 2021-10-21 | Pierre Stevens | Universal Intelligent Module For Communications, Transactions, and Payments |
| SG10202003972PA (en)* | 2020-04-30 | 2021-11-29 | Mastercard Asia Pacific Pte Ltd | Identity validation system and method |
| US11363437B2 (en)* | 2020-05-22 | 2022-06-14 | Rajesh Tiwari | Patron service method utilizing near-field communication tag identifiers |
| US11953700B2 (en) | 2020-05-27 | 2024-04-09 | Intrinsic Innovation Llc | Multi-aperture polarization optical systems using beam splitters |
| US12079812B2 (en)* | 2020-06-09 | 2024-09-03 | Capital One Services, Llc | Utilizing machine learning and trusted transaction card locations to generate a geographical map of the trusted transaction cards |
| US11334541B1 (en)* | 2020-07-17 | 2022-05-17 | Rainer Michael Domingo | Knowledge representation using interlinked construct nodes |
| US11853933B1 (en) | 2020-07-29 | 2023-12-26 | Wells Fargo Bank, N.A. | Systems and methods for an interactive customer interface utilizing customer device context |
| GB2598311A (en) | 2020-08-24 | 2022-03-02 | Mastercard International Inc | A multiple payee digital transaction authentication method |
| US11490430B2 (en) | 2020-08-27 | 2022-11-01 | T-Mobile Usa, Inc. | Packet gateway selection based on device capabilities |
| US11461770B2 (en) | 2020-08-28 | 2022-10-04 | Paypal, Inc. | Active application of secondary transaction instrument tokens for transaction processing systems |
| US12126651B2 (en)* | 2020-09-02 | 2024-10-22 | Make the Connection, Inc. | System and method for attorney-client privileged communication |
| US10992606B1 (en) | 2020-09-04 | 2021-04-27 | Wells Fargo Bank, N.A. | Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets |
| US11880693B2 (en) | 2020-11-05 | 2024-01-23 | Bank Of America Corporation | System for automatically generating electronic artifacts using extended functionality |
| US12081979B2 (en)* | 2020-11-05 | 2024-09-03 | Visa International Service Association | One-time wireless authentication of an Internet-of-Things device |
| US11729276B2 (en)* | 2020-11-10 | 2023-08-15 | Paypal, Inc. | Rapid online variable sourcing infrastructure (ROVS) for decision systems |
| US20220147996A1 (en)* | 2020-11-11 | 2022-05-12 | Margo Networks Pvt.Ltd. | Offline payment system and method |
| EP4244795A4 (en) | 2020-11-16 | 2024-10-16 | Mastercard International Incorporated | Peer to peer value transfer |
| US11956628B2 (en) | 2020-11-23 | 2024-04-09 | Cisco Technology, Inc. | Openroaming for private communication systems |
| CN112333088B (en)* | 2021-01-04 | 2021-04-20 | 满金坝(深圳)科技有限公司 | Compatible instant messaging transmission method |
| US11546338B1 (en) | 2021-01-05 | 2023-01-03 | Wells Fargo Bank, N.A. | Digital account controls portal and protocols for federated and non-federated systems and devices |
| US12354083B2 (en)* | 2021-01-29 | 2025-07-08 | Digital First Holdings Llc | Self-sovereign identity structured messaging for cross channel authentication |
| US11438329B2 (en) | 2021-01-29 | 2022-09-06 | Capital One Services, Llc | Systems and methods for authenticated peer-to-peer data transfer using resource locators |
| US20220245652A1 (en)* | 2021-01-29 | 2022-08-04 | Ncr Corporation | Self-Sovereign Identity Verifiable Credentials for Consent Processing |
| US20220261789A1 (en)* | 2021-01-29 | 2022-08-18 | Ncr Corporation | Personal identifiable information verification for decentralized network services |
| US20220258068A1 (en)* | 2021-02-16 | 2022-08-18 | Aquaphant Inc. | Water processing and filling system |
| US11919764B2 (en)* | 2021-02-16 | 2024-03-05 | Aquaphant Inc. | Vehicular water processing and filling system |
| US12069227B2 (en) | 2021-03-10 | 2024-08-20 | Intrinsic Innovation Llc | Multi-modal and multi-spectral stereo camera arrays |
| US12020455B2 (en) | 2021-03-10 | 2024-06-25 | Intrinsic Innovation Llc | Systems and methods for high dynamic range image reconstruction |
| US11593807B2 (en) | 2021-03-22 | 2023-02-28 | Bank Of America Corporation | Information security system and method for multi-factor authentication for ATMS using authentication media |
| US11790120B2 (en) | 2021-03-26 | 2023-10-17 | Bank Of America Corporation | System and method for encrypting storage mediums with an encryption chip |
| US11290658B1 (en) | 2021-04-15 | 2022-03-29 | Boston Polarimetrics, Inc. | Systems and methods for camera exposure control |
| US11954886B2 (en) | 2021-04-15 | 2024-04-09 | Intrinsic Innovation Llc | Systems and methods for six-degree of freedom pose estimation of deformable objects |
| US11620644B2 (en)* | 2021-04-16 | 2023-04-04 | Bank Of America Corporation | Electronic system for initiating resource distributions from a first source retainer with a token associated with a second source retainer |
| US12062068B2 (en) | 2021-05-04 | 2024-08-13 | Margo Networks Pvt. Ltd. | Oneapp system and method |
| US12067746B2 (en) | 2021-05-07 | 2024-08-20 | Intrinsic Innovation Llc | Systems and methods for using computer vision to pick up small objects |
| US11695855B2 (en) | 2021-05-17 | 2023-07-04 | Margo Networks Pvt. Ltd. | User generated pluggable content delivery network (CDN) system and method |
| KR20220156685A (en)* | 2021-05-18 | 2022-11-28 | 삼성전자주식회사 | Ic card including registered biometic information and registerd pin information, and operation method thereof, and operation method of card reader communicating with the ic card |
| US11843943B2 (en) | 2021-06-04 | 2023-12-12 | Winkk, Inc. | Dynamic key exchange for moving target |
| US12189756B2 (en) | 2021-06-06 | 2025-01-07 | Apple Inc. | User interfaces for managing passwords |
| EP4356307A1 (en) | 2021-06-13 | 2024-04-24 | Artema Labs, Inc. | Systems and methods for automated blockchain based recommendation generation, advertising and promotion |
| CA3223361A1 (en)* | 2021-06-14 | 2022-12-22 | Royal Bank Of Canada | System and method for multi-user session for coordinated electronic transactions |
| US12175741B2 (en) | 2021-06-22 | 2024-12-24 | Intrinsic Innovation Llc | Systems and methods for a vision guided end effector |
| US12340538B2 (en) | 2021-06-25 | 2025-06-24 | Intrinsic Innovation Llc | Systems and methods for generating and using visual datasets for training computer vision models |
| US12172310B2 (en) | 2021-06-29 | 2024-12-24 | Intrinsic Innovation Llc | Systems and methods for picking objects using 3-D geometry and segmentation |
| US11689813B2 (en) | 2021-07-01 | 2023-06-27 | Intrinsic Innovation Llc | Systems and methods for high dynamic range imaging using crossed polarizers |
| EP4117230B1 (en)* | 2021-07-07 | 2025-01-29 | Samsung SDS Co., Ltd. | Authentication method between terminals having proximity communication function and terminals implementing the same method |
| US11411805B1 (en) | 2021-07-12 | 2022-08-09 | Bank Of America Corporation | System and method for detecting root cause of an exception error in a task flow in a distributed network |
| EP4371236A4 (en)* | 2021-07-16 | 2025-04-02 | Silicon Craft Technology Public Company Limited (SICT) | A method and apparatus for sustaining a constant time period value for operation and answering by a tag for an nfc transceiver |
| US12293535B2 (en) | 2021-08-03 | 2025-05-06 | Intrinsic Innovation Llc | Systems and methods for training pose estimators in computer vision |
| US11750686B2 (en) | 2021-08-03 | 2023-09-05 | The Toronto-Dominion Bank | System and method for enabling one or more transfer features associated with a real-time transfer protocol |
| US11803837B2 (en)* | 2021-08-04 | 2023-10-31 | Bank Of America Corporation | Intelligent real time card alert system to detect suspicious contactless card reader |
| US12229735B1 (en) | 2021-08-17 | 2025-02-18 | Wells Fargo Bank, N.A. | Multi-modal parameterization of digital tokens involving multiple entities in defined networks |
| US20230055618A1 (en)* | 2021-08-21 | 2023-02-23 | Artema Labs, Inc | Systems and Methods for Management of Token Interactions |
| US12245026B2 (en)* | 2021-09-24 | 2025-03-04 | Apple Inc. | Techniques for secure data transmission using a secondary device |
| US12261841B2 (en) | 2021-09-24 | 2025-03-25 | Apple Inc. | Techniques for secure data reception using a user device |
| US12095744B2 (en)* | 2021-10-01 | 2024-09-17 | TrustFour Technologies, Inc. | Mutual key management service system and method |
| US11995621B1 (en) | 2021-10-22 | 2024-05-28 | Wells Fargo Bank, N.A. | Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services |
| US12430627B1 (en) | 2021-10-26 | 2025-09-30 | Kwi | Method of restricting a feature set of a point-of-sale system based on network quality |
| WO2023075817A1 (en)* | 2021-10-28 | 2023-05-04 | Verifone, Inc. | Digital payment source validation |
| EP4423698A4 (en)* | 2021-10-28 | 2025-07-09 | Verifone Inc | VALIDATION OF A DIGITAL PAYMENT SOURCE VIA THE NEAREST NEIGHBOR |
| US20230146558A1 (en)* | 2021-11-07 | 2023-05-11 | ExtoLabs, LLC | Secure Pairing for Payment Devices |
| US12033102B2 (en) | 2021-11-16 | 2024-07-09 | Bank Of America Corporation | Resource transfer monitoring and authorization |
| US20230169505A1 (en)* | 2021-11-30 | 2023-06-01 | Capital One Services, Llc | System and techniques for authenticated website based checkout using uniform resource locator |
| CN114154099B (en)* | 2021-12-07 | 2024-07-09 | 北京达佳互联信息技术有限公司 | Routing information processing method, device, equipment and storage medium |
| US12015717B2 (en) | 2021-12-08 | 2024-06-18 | Bank Of America Corporation | System for processing offline digital resource transfers using a hardware device based cryptographic application |
| CN116361818A (en)* | 2021-12-27 | 2023-06-30 | 戴尔产品有限公司 | Automatic security verification for access management controllers |
| US11656926B1 (en) | 2022-01-26 | 2023-05-23 | Bank Of America Corporation | Systems and methods for automatically applying configuration changes to computing clusters |
| US20240346482A1 (en)* | 2022-02-17 | 2024-10-17 | Timothy Christopher Bodenmiller | System and method for managing paired a physical tag and a non-fungible token. |
| US12105582B2 (en) | 2022-02-24 | 2024-10-01 | Bank Of America Corporation | System for code base sharing during computing application failure using a distributed register network |
| US11892937B2 (en) | 2022-02-28 | 2024-02-06 | Bank Of America Corporation | Developer test environment with containerization of tightly coupled systems |
| US11438251B1 (en) | 2022-02-28 | 2022-09-06 | Bank Of America Corporation | System and method for automatic self-resolution of an exception error in a distributed network |
| US12028203B2 (en) | 2022-02-28 | 2024-07-02 | Bank Of America Corporation | Self-resolution of exception errors in a distributed network |
| US11979740B2 (en)* | 2022-04-04 | 2024-05-07 | Bank Of America Corporation | Secure data transmission on low power network |
| US12155641B1 (en) | 2022-04-15 | 2024-11-26 | Wells Fargo Bank, N.A. | Network access tokens and meta-application programming interfaces for enhanced inter-enterprise system data promulgation and profiling |
| US12301630B2 (en) | 2022-04-20 | 2025-05-13 | Bank Of America Corporation | System for securing electronic devices and electronic data using automated dynamic control modifications |
| GB202206157D0 (en)* | 2022-04-28 | 2022-06-15 | Microsoft Technology Licensing Llc | Mutually authenticated communication with remote sip device |
| US11810123B1 (en)* | 2022-05-10 | 2023-11-07 | Capital One Services, Llc | System and method for card present account provisioning |
| US11887103B2 (en) | 2022-05-10 | 2024-01-30 | Capital One Services, Llc | System and method for facilitating transaction account provisioning |
| US12346742B2 (en) | 2022-05-12 | 2025-07-01 | Bank Of America Corporation | System for intelligent type-based implementation of restrictions on resource transfers |
| US12405833B2 (en) | 2022-05-12 | 2025-09-02 | Bank Of America Corporation | System for implementing dynamic authentication restrictions for resource instrument use |
| WO2023224680A1 (en) | 2022-05-18 | 2023-11-23 | Margo Networks Pvt. Ltd. | Peer to peer (p2p) encrypted data transfer/offload system and method |
| US20240039702A1 (en)* | 2022-07-28 | 2024-02-01 | Tailscale Inc. | Distribution and use of encryption keys to direct communications |
| US12323424B2 (en)* | 2022-09-15 | 2025-06-03 | Capital One Services, Llc | Systems and methods for determining trusted devices |
| US12438731B2 (en) | 2022-09-21 | 2025-10-07 | Winkk, Inc. | Diophantine system for digital signatures |
| CN115756312A (en) | 2022-11-02 | 2023-03-07 | 平头哥(上海)半导体技术有限公司 | Data access system, data access method, and storage medium |
| US12406055B2 (en) | 2022-11-10 | 2025-09-02 | Bank Of America Corporation | System and method for identifying and redirecting incoming unauthorized data access requests |
| US12407684B2 (en) | 2022-11-10 | 2025-09-02 | Bank Of America Corporation | System and method for implementing authentication control protocols via components of an entity device |
| DE102023103095A1 (en) | 2023-02-08 | 2024-08-08 | Giesecke+Devrient Mobile Security Germany Gmbh | System, methods and applications for authenticating a user of a card-like data carrier |
| US12309277B2 (en) | 2023-02-09 | 2025-05-20 | Bank Of America Corporation | Domain specific tokens for reduced token generation |
| US12373859B2 (en) | 2023-02-22 | 2025-07-29 | Toshiba Global Commerce Solutions, Inc. | Blockchain registered container utilization at point of sale |
| US20240320311A1 (en)* | 2023-03-23 | 2024-09-26 | Jesus Mares | Apparatus and methods for provisioning authorized services |
| US12400477B2 (en) | 2023-03-23 | 2025-08-26 | Bank Of America Corporation | Altering card device attributes in response to detecting a proximity intrusion |
| WO2025019629A2 (en)* | 2023-07-20 | 2025-01-23 | Involute Inc. (doing business as XUNO) | Messaging protocol for near-real time transaction identification |
| US20250053962A1 (en)* | 2023-08-11 | 2025-02-13 | Dentity Partners, Inc. | Apparatus and method for scoring digital identity attribute levels in a computer network with multiple enterprise participants |
| US12148271B1 (en) | 2023-09-06 | 2024-11-19 | Bank Of America Corporation | System and method for detecting anomalous dispensing devices |
| US12436759B2 (en) | 2023-09-18 | 2025-10-07 | Bank Of America Corporation | System and method for dynamic switching between an old version and a new version of a software code |
| US12423092B2 (en) | 2023-09-18 | 2025-09-23 | Bank Of America Corporation | System and method for classifying software code based on functionality and criticality |
| US12407682B2 (en) | 2023-10-03 | 2025-09-02 | Bank Of America Corporation | System, device, and method for performing secured operations |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030028481A1 (en)* | 1998-03-25 | 2003-02-06 | Orbis Patents, Ltd. | Credit card system and method |
| US20030126094A1 (en)* | 2001-07-11 | 2003-07-03 | Fisher Douglas C. | Persistent dynamic payment service |
Family Cites Families (128)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6415271B1 (en) | 1993-02-10 | 2002-07-02 | Gm Network Limited | Electronic cash eliminating payment risk |
| US5892900A (en) | 1996-08-30 | 1999-04-06 | Intertrust Technologies Corp. | Systems and methods for secure transaction management and electronic rights protection |
| US5943423A (en)* | 1995-12-15 | 1999-08-24 | Entegrity Solutions Corporation | Smart token system for secure electronic transactions and identification |
| US5878138A (en)* | 1996-02-12 | 1999-03-02 | Microsoft Corporation | System and method for detecting fraudulent expenditure of electronic assets |
| US6016484A (en)* | 1996-04-26 | 2000-01-18 | Verifone, Inc. | System, method and article of manufacture for network electronic payment instrument and certification of payment and credit collection utilizing a payment |
| US6188899B1 (en) | 1996-07-15 | 2001-02-13 | At&T Wireless Svcs, Inc. | System and method for automatic registration notification for over-the-air activation |
| US5991749A (en) | 1996-09-11 | 1999-11-23 | Morrill, Jr.; Paul H. | Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities |
| US6434159B1 (en) | 1996-10-15 | 2002-08-13 | Motorola, Inc. | Transaction system and method therefor |
| CA2288824A1 (en) | 1997-03-24 | 1998-10-01 | Marc B. Kekicheff | A system and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card |
| US6282522B1 (en)* | 1997-04-30 | 2001-08-28 | Visa International Service Association | Internet payment system using smart card |
| US6085976A (en)* | 1998-05-22 | 2000-07-11 | Sehr; Richard P. | Travel system and methods utilizing multi-application passenger cards |
| US6016476A (en) | 1997-08-11 | 2000-01-18 | International Business Machines Corporation | Portable information and transaction processing system and method utilizing biometric authorization and digital certificate security |
| CA2306139C (en)* | 1997-10-14 | 2007-04-17 | Visa International Service Association | Personalization of smart cards |
| US20020004783A1 (en)* | 1997-11-12 | 2002-01-10 | Cris T. Paltenghe | Virtual wallet system |
| JP4176181B2 (en)* | 1998-03-13 | 2008-11-05 | 富士通株式会社 | Electronic wallet management system, terminal device and computer-readable recording medium recording electronic wallet management program |
| US6796490B1 (en) | 2000-10-04 | 2004-09-28 | Diebold, Incorporated | Automated banking machine system and method |
| US6704690B2 (en)* | 1998-06-08 | 2004-03-09 | St. Logitrack Pte Ltd. | Monitoring system |
| US6606663B1 (en) | 1998-09-29 | 2003-08-12 | Openwave Systems Inc. | Method and apparatus for caching credentials in proxy servers for wireless user agents |
| US6775782B1 (en) | 1999-03-31 | 2004-08-10 | International Business Machines Corporation | System and method for suspending and resuming digital certificates in a certificate-based user authentication application system |
| US7720762B1 (en)* | 2002-10-03 | 2010-05-18 | Gofigure Payments, Llc | System and method for electronically processing commercial transactions based upon threshold amount |
| US7343351B1 (en)* | 1999-08-31 | 2008-03-11 | American Express Travel Related Services Company, Inc. | Methods and apparatus for conducting electronic transactions |
| US7889052B2 (en)* | 2001-07-10 | 2011-02-15 | Xatra Fund Mx, Llc | Authorizing payment subsequent to RF transactions |
| US7239226B2 (en) | 2001-07-10 | 2007-07-03 | American Express Travel Related Services Company, Inc. | System and method for payment using radio frequency identification in contact and contactless transactions |
| US6715679B1 (en) | 1999-09-08 | 2004-04-06 | At&T Corp. | Universal magnetic stripe card |
| DE60003706D1 (en) | 1999-10-15 | 2003-08-07 | Ajit K Zacharias | SECURE CARD SYSTEM FOR MULTIPLE APPLICATIONS |
| US6705520B1 (en) | 1999-11-15 | 2004-03-16 | Satyan G. Pitroda | Point of sale adapter for electronic transaction device |
| WO2001041419A1 (en)* | 1999-11-30 | 2001-06-07 | Citibank, N.A. | System and method for performing an electronic transaction using a transaction proxy with an electronic wallet |
| US6955299B1 (en)* | 1999-12-17 | 2005-10-18 | Centre For Wireless Communications Of National University Of Singapore | System and method for using a smart card |
| TW514844B (en) | 2000-01-26 | 2002-12-21 | Sony Corp | Data processing system, storage device, data processing method and program providing media |
| ES2225471T3 (en)* | 2000-01-28 | 2005-03-16 | Fundamo (Proprietary) Limited | BANKING SYSTEM WITH IDENTIFICATION OF IMPROVED FINANCIAL ACCOUNTS. |
| US6839437B1 (en)* | 2000-01-31 | 2005-01-04 | International Business Machines Corporation | Method and apparatus for managing keys for cryptographic operations |
| JP2003524841A (en)* | 2000-02-10 | 2003-08-19 | ジョン ショアー， | Apparatus, system, and method for performing wireless transaction financial transfers, electronically recordable authorized transfers, and other information transfers |
| WO2001061659A1 (en)* | 2000-02-16 | 2001-08-23 | Mastercard International Incorporated | System and method for conducting electronic commerce with a remote wallet server |
| US7865414B2 (en)* | 2000-03-01 | 2011-01-04 | Passgate Corporation | Method, system and computer readable medium for web site account and e-commerce management from a central location |
| US7627531B2 (en)* | 2000-03-07 | 2009-12-01 | American Express Travel Related Services Company, Inc. | System for facilitating a transaction |
| US7284266B1 (en) | 2000-03-21 | 2007-10-16 | Broadcom Corporation | System and method for secure biometric identification |
| US7376629B1 (en) | 2000-04-03 | 2008-05-20 | Incogno Corporation | Method of and system for effecting anonymous credit card purchases over the internet |
| US6990470B2 (en)* | 2000-04-11 | 2006-01-24 | Mastercard International Incorporated | Method and system for conducting secure payments over a computer network |
| TW513883B (en) | 2000-08-03 | 2002-12-11 | Telepaq Technology Inc | A secure transaction mechanism system and method integrating wireless communication and wired communication |
| US20020038287A1 (en) | 2000-08-30 | 2002-03-28 | Jean-Marc Villaret | EMV card-based identification, authentication, and access control for remote access |
| US7392388B2 (en)* | 2000-09-07 | 2008-06-24 | Swivel Secure Limited | Systems and methods for identity verification for secure transactions |
| US20030220841A1 (en)* | 2000-12-08 | 2003-11-27 | Maritzen L. Michael | Method and system for merchant-to-merchant referrals and item brokering |
| US7774231B2 (en)* | 2000-09-29 | 2010-08-10 | Nokia Corporation | Electronic payment methods for a mobile device |
| US20020052841A1 (en)* | 2000-10-27 | 2002-05-02 | Guthrie Paul D. | Electronic payment system |
| US6754640B2 (en)* | 2000-10-30 | 2004-06-22 | William O. Bozeman | Universal positive pay match, authentication, authorization, settlement and clearing system |
| WO2002037386A1 (en) | 2000-11-06 | 2002-05-10 | First Usa Bank, N.A. | System and method for selectable funding of electronic transactions |
| US20020089410A1 (en) | 2000-11-13 | 2002-07-11 | Janiak Martin J. | Biometric authentication device for use with a personal digital assistant |
| US20040098740A1 (en)* | 2000-12-07 | 2004-05-20 | Maritzen L. Michael | Method and apparatus for using a kiosk and a transaction device in an electronic commerce system |
| WO2002046881A2 (en)* | 2000-12-09 | 2002-06-13 | Singhal Tara Chand | Method and apparatus for an integrated identity security and payment system |
| US6487401B2 (en) | 2000-12-18 | 2002-11-26 | Sbc Technology Resources, Inc. | Prepaid wireless telephone account regeneration in a wireless access protocol system |
| DE60037043T2 (en) | 2000-12-21 | 2008-08-21 | Nokia Corp. | SERVICE TRANSMISSION OVER RADIO IN A MOBILE COMMUNICATION SYSTEM |
| US7587196B2 (en)* | 2001-03-29 | 2009-09-08 | Telefonaktiebolaget Lm Ericsson (Publ) | Wireless point of sale transaction |
| US20020143634A1 (en) | 2001-03-30 | 2002-10-03 | Kumar K. Anand | Wireless payment system |
| FR2824929B1 (en)* | 2001-05-18 | 2003-08-08 | Gemplus Card Int | APPLICATION DEPLOYMENT FROM A CHIP CARD |
| US20020194128A1 (en)* | 2001-06-14 | 2002-12-19 | Michael Maritzen | System and method for secure reverse payment |
| US7478068B2 (en)* | 2001-06-14 | 2009-01-13 | Sony Corporation | System and method of selecting consumer profile and account information via biometric identifiers |
| FI20011312A7 (en)* | 2001-06-20 | 2002-12-21 | Nokia Corp | Improved method and arrangement for handling electronic payment procedures |
| JP2003006168A (en) | 2001-06-25 | 2003-01-10 | Ntt Docomo Inc | Mobile terminal authentication method and mobile terminal |
| US8346659B1 (en) | 2001-07-06 | 2013-01-01 | Hossein Mohsenzadeh | Secure authentication and payment system |
| US7027582B2 (en)* | 2001-07-06 | 2006-04-11 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for resolving an entity identifier into an internet address using a domain name system (DNS) server and an entity identifier portability database |
| US7360689B2 (en) | 2001-07-10 | 2008-04-22 | American Express Travel Related Services Company, Inc. | Method and system for proffering multiple biometrics for use with a FOB |
| US7762457B2 (en)* | 2001-07-10 | 2010-07-27 | American Express Travel Related Services Company, Inc. | System and method for dynamic fob synchronization and personalization |
| US7996324B2 (en)* | 2001-07-10 | 2011-08-09 | American Express Travel Related Services Company, Inc. | Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia |
| US7119659B2 (en) | 2001-07-10 | 2006-10-10 | American Express Travel Related Services Company, Inc. | Systems and methods for providing a RF transaction device for use in a private label transaction |
| US20030074461A1 (en) | 2001-10-09 | 2003-04-17 | I-Dns.Net International Pte. Ltd. | Method of mapping names or identifiers to telecommunications network resource locations |
| WO2003058391A2 (en) | 2001-12-26 | 2003-07-17 | Vivotech, Inc. | Wireless network micropayment financial transaction processing |
| US20040159700A1 (en)* | 2001-12-26 | 2004-08-19 | Vivotech, Inc. | Method and apparatus for secure import of information into data aggregation program hosted by personal trusted device |
| US6755342B1 (en) | 2001-12-31 | 2004-06-29 | Bellsouth Intellectual Property Corporation | Credit card validation for an interactive wireless network |
| US7996888B2 (en)* | 2002-01-11 | 2011-08-09 | Nokia Corporation | Virtual identity apparatus and method for using same |
| DE10204480B4 (en)* | 2002-02-05 | 2004-02-26 | Harman/Becker Automotive Systems (Becker Division) Gmbh | Procedure for triggering an emergency call and emergency call system |
| AU2002319654A1 (en)* | 2002-02-27 | 2003-09-09 | Tang, James | Eliminating fraud using secret gesture and identifier |
| US20030191709A1 (en)* | 2002-04-03 | 2003-10-09 | Stephen Elston | Distributed payment and loyalty processing for retail and vending |
| US7707120B2 (en) | 2002-04-17 | 2010-04-27 | Visa International Service Association | Mobile account authentication service |
| FI113120B (en)* | 2002-04-23 | 2004-02-27 | Nokia Corp | Procedure for logging out a user from a service |
| JP2003316796A (en) | 2002-04-26 | 2003-11-07 | Fuji Xerox Co Ltd | Hierarchical clustering device, hierarchical clustering method, hierarchical clustering program and hierarchical clustering system |
| US20040097217A1 (en)* | 2002-08-06 | 2004-05-20 | Mcclain Fred | System and method for providing authentication and authorization utilizing a personal wireless communication device |
| US7801826B2 (en)* | 2002-08-08 | 2010-09-21 | Fujitsu Limited | Framework and system for purchasing of goods and services |
| US20040107170A1 (en)* | 2002-08-08 | 2004-06-03 | Fujitsu Limited | Apparatuses for purchasing of goods and services |
| JP4433472B2 (en)* | 2002-08-08 | 2010-03-17 | ナンヤン テクノロジカル ユニヴァーシティ | Distributed authentication processing |
| US7822688B2 (en)* | 2002-08-08 | 2010-10-26 | Fujitsu Limited | Wireless wallet |
| JP4553565B2 (en)* | 2002-08-26 | 2010-09-29 | パナソニック株式会社 | Electronic value authentication method, authentication system and device |
| US7280981B2 (en) | 2002-08-27 | 2007-10-09 | Visa U.S.A. Inc. | Method and system for facilitating payment transactions using access devices |
| US7494055B2 (en)* | 2002-09-17 | 2009-02-24 | Vivotech, Inc. | Collaborative negotiation techniques for mobile personal trusted device financial transactions |
| US6776339B2 (en) | 2002-09-27 | 2004-08-17 | Nokia Corporation | Wireless communication device providing a contactless interface for a smart card reader |
| AU2003263506A1 (en)* | 2002-10-18 | 2004-05-04 | Koninklijke Philips Electronics N.V. | Medical examination system |
| KR100474213B1 (en)* | 2002-10-31 | 2005-03-10 | (주)로코모 | Method for Issuing Instant Mobile Card using Wireless Network |
| JP4698117B2 (en)* | 2002-12-16 | 2011-06-08 | 株式会社ユニバーサルエンターテインメント | Information provision device |
| US20040122768A1 (en)* | 2002-12-19 | 2004-06-24 | International Business Machines Corporation | Electronic wallet for wireless computing device |
| US20040156394A1 (en)* | 2003-02-10 | 2004-08-12 | Ilkka Westman | Handling of user identity |
| US7051220B2 (en) | 2003-02-28 | 2006-05-23 | Microsoft Corporation | Mechanism for reducing power consumption of a transmitter/receiver circuit |
| US7945511B2 (en)* | 2004-02-26 | 2011-05-17 | Payment Pathways, Inc. | Methods and systems for identity authentication |
| US8255978B2 (en) | 2003-03-11 | 2012-08-28 | Innovatrend, Inc. | Verified personal information database |
| US20040186883A1 (en)* | 2003-03-19 | 2004-09-23 | Nyman Kai T. | Method and apparatus for interfacing web services with mobile terminal applications during a browser or SIP session |
| US10535049B2 (en)* | 2003-03-21 | 2020-01-14 | Paypal, Inc. | Payment transactions via substantially instant communication system |
| US6983882B2 (en)* | 2003-03-31 | 2006-01-10 | Kepler, Ltd. | Personal biometric authentication and authorization device |
| GEP20104886B (en)* | 2003-05-01 | 2010-02-10 | Interdigital Tech Corp | Delivery of data over wlan coupled to 3gpp |
| US7110792B2 (en)* | 2003-05-19 | 2006-09-19 | Einar Rosenberg | Apparatus and method for increased security of wireless transactions |
| US7013365B2 (en)* | 2003-06-16 | 2006-03-14 | Michael Arnouse | System of secure personal identification, information processing, and precise point of contact location and timing |
| JP4334980B2 (en)* | 2003-09-05 | 2009-09-30 | 株式会社エヌ・ティ・ティ・ドコモ | Article management apparatus and information processing method |
| AR046535A1 (en) | 2003-09-26 | 2005-12-14 | Mastercard International Inc | METHOD FOR BIOMETRICALLY ENABLING A PROXIMITY PAYMENT DEVICE AND PAYMENT DEVICE FOR PROXIMITY BIOMETRICALLY ENABLED |
| US7831519B2 (en)* | 2003-12-17 | 2010-11-09 | First Data Corporation | Methods and systems for electromagnetic initiation of secure transactions |
| US20050137889A1 (en)* | 2003-12-18 | 2005-06-23 | Wheeler David M. | Remotely binding data to a user device |
| US7357309B2 (en) | 2004-01-16 | 2008-04-15 | Telefonaktiebolaget Lm Ericsson (Publ) | EMV transactions in mobile terminals |
| US8615487B2 (en)* | 2004-01-23 | 2013-12-24 | Garrison Gomez | System and method to store and retrieve identifier associated information content |
| US20050165684A1 (en) | 2004-01-28 | 2005-07-28 | Saflink Corporation | Electronic transaction verification system |
| JP4305847B2 (en)* | 2004-03-26 | 2009-07-29 | 富士通株式会社 | Store settlement method, system and program |
| US20050222961A1 (en)* | 2004-04-05 | 2005-10-06 | Philippe Staib | System and method of facilitating contactless payment transactions across different payment systems using a common mobile device acting as a stored value device |
| US7275685B2 (en)* | 2004-04-12 | 2007-10-02 | Rearden Capital Corporation | Method for electronic payment |
| US20050269402A1 (en) | 2004-06-03 | 2005-12-08 | Tyfone, Inc. | System and method for securing financial transactions |
| US7341181B2 (en) | 2004-07-01 | 2008-03-11 | American Express Travel Related Services Company, Inc. | Method for biometric security using a smartcard |
| US7413113B1 (en)* | 2004-07-28 | 2008-08-19 | Sprint Communications Company L.P. | Context-based card selection device |
| DE602004027846D1 (en)* | 2004-07-29 | 2010-08-05 | Mitsubishi Electric Corp | PLACEMENT STATUS MANAGEMENT SYSTEM, RADIO LABEL READER AND MANAGEMENT DEVICE |
| US7126481B2 (en)* | 2004-09-27 | 2006-10-24 | Nokia Corporation | Methods, systems, devices and computer program products for providing dynamic product information in short-range communication |
| US20060087406A1 (en)* | 2004-10-26 | 2006-04-27 | Willins Bruce A | System and method for identifying an RFID reader |
| US7784089B2 (en)* | 2004-10-29 | 2010-08-24 | Qualcomm Incorporated | System and method for providing a multi-credential authentication protocol |
| US20060109084A1 (en)* | 2004-11-24 | 2006-05-25 | Mark Yarvis | Mesh networking with RFID communications |
| US20060131390A1 (en) | 2004-12-16 | 2006-06-22 | Kim Mike I | Method and system for providing transaction notification and mobile reply authorization |
| US8700729B2 (en)* | 2005-01-21 | 2014-04-15 | Robin Dua | Method and apparatus for managing credentials through a wireless network |
| US20060229998A1 (en)* | 2005-03-31 | 2006-10-12 | Mark Harrison | Payment via financial service provider using network-based device |
| TWI259385B (en)* | 2005-05-03 | 2006-08-01 | Shooter Digital Co Ltd | Electronic transaction system capable of enhancing transaction security and electronic transaction method thereof |
| US7353991B2 (en)* | 2006-02-21 | 2008-04-08 | David Benjamin Esplin | System and method for managing wireless point-of-sale transactions |
| US7512567B2 (en)* | 2006-06-29 | 2009-03-31 | Yt Acquisition Corporation | Method and system for providing biometric authentication at a point-of-sale via a mobile device |
| US10102518B2 (en)* | 2007-02-22 | 2018-10-16 | First Data Corporation | Enrollment and registration of a device in a mobile commerce system |
| EP3575951A1 (en)* | 2007-04-17 | 2019-12-04 | Visa USA, Inc. | Method and system for authenticating a party to a transaction |
| US20100217709A1 (en)* | 2008-09-22 | 2010-08-26 | Christian Aabye | Apparatus and method for preventing unauthorized access to payment application installed in contactless payment device |
| US20110246317A1 (en)* | 2009-10-23 | 2011-10-06 | Apriva, Llc | System and device for facilitating a transaction through use of a proxy account code |
| EP2339529A1 (en)* | 2009-12-01 | 2011-06-29 | Mikko Kalervo Väänänen | Method and means for controlling payment setup |
| US8639621B1 (en)* | 2012-04-25 | 2014-01-28 | Wells Fargo Bank, N.A. | System and method for a mobile wallet |
- 2005
- 2005-01-21USUS11/040,847patent/US8700729B2/enactiveActive
- 2014
- 2014-02-24USUS14/187,693patent/US20140172724A1/ennot_activeAbandoned
- 2014-03-28USUS14/228,514patent/US20140222682A1/ennot_activeAbandoned
- 2014-06-12USUS14/302,511patent/US9235839B2/ennot_activeExpired - Lifetime
- 2014-07-22USUS14/337,584patent/US20140337227A1/ennot_activeAbandoned
- 2014-10-03USUS14/505,890patent/US20150095174A1/ennot_activeAbandoned
- 2014-10-09USUS14/510,822patent/US20150095175A1/ennot_activeAbandoned
- 2014-11-05USUS14/533,722patent/US20150058227A1/ennot_activeAbandoned
- 2014-11-20USUS14/549,087patent/US20150077228A1/ennot_activeAbandoned
- 2014-11-24USUS14/551,827patent/US20150081559A1/ennot_activeAbandoned
- 2014-12-02USUS14/557,938patent/US11468438B2/enactiveActive
- 2014-12-08USUS14/564,034patent/US11403630B2/enactiveActive
- 2014-12-16USUS14/572,313patent/US10769633B2/enactiveActive
- 2014-12-16USUS14/572,287patent/US10872333B2/enactiveActive
- 2015
- 2015-07-06USUS14/791,739patent/US11222330B2/ennot_activeExpired - Lifetime
- 2015-08-05USUS14/818,974patent/US20150339667A1/ennot_activeAbandoned
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030028481A1 (en)* | 1998-03-25 | 2003-02-06 | Orbis Patents, Ltd. | Credit card system and method |
| US20030126094A1 (en)* | 2001-07-11 | 2003-07-03 | Fisher Douglas C. | Persistent dynamic payment service |
Cited By (105)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11468155B2 (en) | 2007-09-24 | 2022-10-11 | Apple Inc. | Embedded authentication systems in an electronic device |
| US10956550B2 (en) | 2007-09-24 | 2021-03-23 | Apple Inc. | Embedded authentication systems in an electronic device |
| US11676373B2 (en) | 2008-01-03 | 2023-06-13 | Apple Inc. | Personal computing device control using face detection and recognition |
| US12406490B2 (en) | 2008-01-03 | 2025-09-02 | Apple Inc. | Personal computing device control using face detection and recognition |
| US12262111B2 (en) | 2011-06-05 | 2025-03-25 | Apple Inc. | Device, method, and graphical user interface for accessing an application in a locked device |
| US11200309B2 (en) | 2011-09-29 | 2021-12-14 | Apple Inc. | Authentication with secondary approver |
| US11755712B2 (en) | 2011-09-29 | 2023-09-12 | Apple Inc. | Authentication with secondary approver |
| US10516997B2 (en) | 2011-09-29 | 2019-12-24 | Apple Inc. | Authentication with secondary approver |
| US10484384B2 (en) | 2011-09-29 | 2019-11-19 | Apple Inc. | Indirect authentication |
| US10419933B2 (en) | 2011-09-29 | 2019-09-17 | Apple Inc. | Authentication with secondary approver |
| US10142835B2 (en) | 2011-09-29 | 2018-11-27 | Apple Inc. | Authentication with secondary approver |
| US11539831B2 (en) | 2013-03-15 | 2022-12-27 | Apple Inc. | Providing remote interactions with host device using a wireless device |
| US11768575B2 (en) | 2013-09-09 | 2023-09-26 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on unlock inputs |
| US12314527B2 (en) | 2013-09-09 | 2025-05-27 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on unlock inputs |
| US10372963B2 (en) | 2013-09-09 | 2019-08-06 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| US11287942B2 (en) | 2013-09-09 | 2022-03-29 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces |
| US10803281B2 (en) | 2013-09-09 | 2020-10-13 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| US10410035B2 (en) | 2013-09-09 | 2019-09-10 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| US10055634B2 (en) | 2013-09-09 | 2018-08-21 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| US9898642B2 (en) | 2013-09-09 | 2018-02-20 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs |
| US11494046B2 (en) | 2013-09-09 | 2022-11-08 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on unlock inputs |
| US10262182B2 (en) | 2013-09-09 | 2019-04-16 | Apple Inc. | Device, method, and graphical user interface for manipulating user interfaces based on unlock inputs |
| US20150161592A1 (en)* | 2013-12-05 | 2015-06-11 | Samsung Electronics Co., Ltd. | Method for payment using membership card and electronic device thereof |
| US11836725B2 (en) | 2014-05-29 | 2023-12-05 | Apple Inc. | User interface for payments |
| US10977651B2 (en) | 2014-05-29 | 2021-04-13 | Apple Inc. | User interface for payments |
| US10748153B2 (en) | 2014-05-29 | 2020-08-18 | Apple Inc. | User interface for payments |
| US10438205B2 (en) | 2014-05-29 | 2019-10-08 | Apple Inc. | User interface for payments |
| US10796309B2 (en) | 2014-05-29 | 2020-10-06 | Apple Inc. | User interface for payments |
| US10902424B2 (en) | 2014-05-29 | 2021-01-26 | Apple Inc. | User interface for payments |
| US10616416B2 (en) | 2014-05-30 | 2020-04-07 | Apple Inc. | User interface for phone call routing among devices |
| US10178234B2 (en) | 2014-05-30 | 2019-01-08 | Apple, Inc. | User interface for phone call routing among devices |
| US11907013B2 (en) | 2014-05-30 | 2024-02-20 | Apple Inc. | Continuity of applications across devices |
| US11126704B2 (en) | 2014-08-15 | 2021-09-21 | Apple Inc. | Authenticated device used to unlock another device |
| US11182769B2 (en) | 2015-02-12 | 2021-11-23 | Samsung Electronics Co., Ltd. | Payment processing method and electronic device supporting the same |
| US11129018B2 (en) | 2015-02-27 | 2021-09-21 | Samsung Electronics Co., Ltd. | Payment means operation supporting method and electronic device for supporting the same |
| US10013684B2 (en) | 2015-06-02 | 2018-07-03 | Bank Of America Corporation | Processing cardless transactions at automated teller devices |
| US11861700B1 (en)* | 2015-07-13 | 2024-01-02 | Wells Fargo Bank, N.A. | Systems and methods for real time credit extension and bill pay configuration |
| US12407754B2 (en) | 2015-09-29 | 2025-09-02 | Soracom, Inc | Control apparatus for gateway in mobile communication system |
| US11087304B2 (en)* | 2016-03-14 | 2021-08-10 | Jpmorgan Chase Bank, N.A. | Systems and methods for device authentication |
| US20170262849A1 (en)* | 2016-03-14 | 2017-09-14 | Jpmorgan Chase Bank, N.A. | Systems and methods for device authentication |
| US9847999B2 (en)* | 2016-05-19 | 2017-12-19 | Apple Inc. | User interface for a device requesting remote authorization |
| US10749967B2 (en) | 2016-05-19 | 2020-08-18 | Apple Inc. | User interface for remote authorization |
| DK201670628A1 (en)* | 2016-05-19 | 2017-11-27 | Apple Inc | Remote authorization to proceed with an action |
| US10334054B2 (en) | 2016-05-19 | 2019-06-25 | Apple Inc. | User interface for a device requesting remote authorization |
| US11206309B2 (en) | 2016-05-19 | 2021-12-21 | Apple Inc. | User interface for remote authorization |
| DK179186B1 (en)* | 2016-05-19 | 2018-01-15 | Apple Inc | REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION |
| US12002042B2 (en) | 2016-06-11 | 2024-06-04 | Apple, Inc | User interface for transactions |
| US11481769B2 (en) | 2016-06-11 | 2022-10-25 | Apple Inc. | User interface for transactions |
| US11037150B2 (en) | 2016-06-12 | 2021-06-15 | Apple Inc. | User interfaces for transactions |
| US11900372B2 (en) | 2016-06-12 | 2024-02-13 | Apple Inc. | User interfaces for transactions |
| US11074572B2 (en) | 2016-09-06 | 2021-07-27 | Apple Inc. | User interfaces for stored-value accounts |
| US12165127B2 (en) | 2016-09-06 | 2024-12-10 | Apple Inc. | User interfaces for stored-value accounts |
| US9842330B1 (en) | 2016-09-06 | 2017-12-12 | Apple Inc. | User interfaces for stored-value accounts |
| US12079458B2 (en) | 2016-09-23 | 2024-09-03 | Apple Inc. | Image data for enhanced user interactions |
| WO2018075630A1 (en)* | 2016-10-19 | 2018-04-26 | Visa International Service Association | Digital wallet merchant-specific virtual payment accounts |
| US11170365B2 (en) | 2016-10-19 | 2021-11-09 | Visa International Service Association | Digital wallet merchant-specific virtual payment accounts |
| US11574041B2 (en) | 2016-10-25 | 2023-02-07 | Apple Inc. | User interface for managing access to credentials for use in an operation |
| US10496808B2 (en) | 2016-10-25 | 2019-12-03 | Apple Inc. | User interface for managing access to credentials for use in an operation |
| US11995171B2 (en) | 2016-10-25 | 2024-05-28 | Apple Inc. | User interface for managing access to credentials for use in an operation |
| US11431836B2 (en) | 2017-05-02 | 2022-08-30 | Apple Inc. | Methods and interfaces for initiating media playback |
| US11283916B2 (en) | 2017-05-16 | 2022-03-22 | Apple Inc. | Methods and interfaces for configuring a device in accordance with an audio tone signal |
| US12107985B2 (en) | 2017-05-16 | 2024-10-01 | Apple Inc. | Methods and interfaces for home media control |
| US10992795B2 (en) | 2017-05-16 | 2021-04-27 | Apple Inc. | Methods and interfaces for home media control |
| US11095766B2 (en) | 2017-05-16 | 2021-08-17 | Apple Inc. | Methods and interfaces for adjusting an audible signal based on a spatial position of a voice command source |
| US11412081B2 (en) | 2017-05-16 | 2022-08-09 | Apple Inc. | Methods and interfaces for configuring an electronic device to initiate playback of media |
| US11201961B2 (en) | 2017-05-16 | 2021-12-14 | Apple Inc. | Methods and interfaces for adjusting the volume of media |
| US12244755B2 (en) | 2017-05-16 | 2025-03-04 | Apple Inc. | Methods and interfaces for configuring a device in accordance with an audio tone signal |
| US11750734B2 (en) | 2017-05-16 | 2023-09-05 | Apple Inc. | Methods for initiating output of at least a component of a signal representative of media currently being played back by another device |
| US11683408B2 (en) | 2017-05-16 | 2023-06-20 | Apple Inc. | Methods and interfaces for home media control |
| US11393258B2 (en) | 2017-09-09 | 2022-07-19 | Apple Inc. | Implementation of biometric authentication |
| US11386189B2 (en) | 2017-09-09 | 2022-07-12 | Apple Inc. | Implementation of biometric authentication |
| US10783227B2 (en) | 2017-09-09 | 2020-09-22 | Apple Inc. | Implementation of biometric authentication |
| US11765163B2 (en) | 2017-09-09 | 2023-09-19 | Apple Inc. | Implementation of biometric authentication |
| US10521579B2 (en) | 2017-09-09 | 2019-12-31 | Apple Inc. | Implementation of biometric authentication |
| US10410076B2 (en) | 2017-09-09 | 2019-09-10 | Apple Inc. | Implementation of biometric authentication |
| US10395128B2 (en) | 2017-09-09 | 2019-08-27 | Apple Inc. | Implementation of biometric authentication |
| US10872256B2 (en) | 2017-09-09 | 2020-12-22 | Apple Inc. | Implementation of biometric authentication |
| US12189748B2 (en) | 2018-06-03 | 2025-01-07 | Apple Inc. | Implementation of biometric authentication |
| US11170085B2 (en) | 2018-06-03 | 2021-11-09 | Apple Inc. | Implementation of biometric authentication |
| US11928200B2 (en) | 2018-06-03 | 2024-03-12 | Apple Inc. | Implementation of biometric authentication |
| US20230007484A1 (en)* | 2018-09-21 | 2023-01-05 | Schlage Lock Company Llc | Wireless access credential system |
| US10860096B2 (en) | 2018-09-28 | 2020-12-08 | Apple Inc. | Device control using gaze information |
| US11619991B2 (en) | 2018-09-28 | 2023-04-04 | Apple Inc. | Device control using gaze information |
| US11809784B2 (en) | 2018-09-28 | 2023-11-07 | Apple Inc. | Audio assisted enrollment |
| US12105874B2 (en) | 2018-09-28 | 2024-10-01 | Apple Inc. | Device control using gaze information |
| US11100349B2 (en) | 2018-09-28 | 2021-08-24 | Apple Inc. | Audio assisted enrollment |
| US12124770B2 (en) | 2018-09-28 | 2024-10-22 | Apple Inc. | Audio assisted enrollment |
| US12223228B2 (en) | 2019-05-31 | 2025-02-11 | Apple Inc. | User interfaces for audio media control |
| US11010121B2 (en) | 2019-05-31 | 2021-05-18 | Apple Inc. | User interfaces for audio media control |
| US11853646B2 (en) | 2019-05-31 | 2023-12-26 | Apple Inc. | User interfaces for audio media control |
| US10996917B2 (en) | 2019-05-31 | 2021-05-04 | Apple Inc. | User interfaces for audio media control |
| US11620103B2 (en) | 2019-05-31 | 2023-04-04 | Apple Inc. | User interfaces for audio media control |
| US11755273B2 (en) | 2019-05-31 | 2023-09-12 | Apple Inc. | User interfaces for audio media control |
| US11816194B2 (en) | 2020-06-21 | 2023-11-14 | Apple Inc. | User interfaces for managing secure operations |
| US12112037B2 (en) | 2020-09-25 | 2024-10-08 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
| US11782598B2 (en) | 2020-09-25 | 2023-10-10 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
| US11392291B2 (en) | 2020-09-25 | 2022-07-19 | Apple Inc. | Methods and interfaces for media control with dynamic feedback |
| US12099586B2 (en) | 2021-01-25 | 2024-09-24 | Apple Inc. | Implementation of biometric authentication |
| US12210603B2 (en) | 2021-03-04 | 2025-01-28 | Apple Inc. | User interface for enrolling a biometric feature |
| US12216754B2 (en) | 2021-05-10 | 2025-02-04 | Apple Inc. | User interfaces for authenticating to perform secure operations |
| US11847378B2 (en) | 2021-06-06 | 2023-12-19 | Apple Inc. | User interfaces for audio routing |
| US12423052B2 (en) | 2021-06-06 | 2025-09-23 | Apple Inc. | User interfaces for audio routing |
| WO2023043589A1 (en)* | 2021-09-15 | 2023-03-23 | Visa International Service Association | Multiple interaction processing |
| US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
| US20240320651A1 (en)* | 2023-03-20 | 2024-09-26 | Kakao Corp. | Method and apparatus for payment service |
Also Published As
| Publication number | Publication date |
|---|---|
| US20140297438A1 (en) | 2014-10-02 |
| US20140172724A1 (en) | 2014-06-19 |
| US10872333B2 (en) | 2020-12-22 |
| US20150095174A1 (en) | 2015-04-02 |
| US9235839B2 (en) | 2016-01-12 |
| US11468438B2 (en) | 2022-10-11 |
| US20140222682A1 (en) | 2014-08-07 |
| US20150077228A1 (en) | 2015-03-19 |
| US20150100499A1 (en) | 2015-04-09 |
| US20150088750A1 (en) | 2015-03-26 |
| US8700729B2 (en) | 2014-04-15 |
| US20150302413A1 (en) | 2015-10-22 |
| US10769633B2 (en) | 2020-09-08 |
| US20150095235A1 (en) | 2015-04-02 |
| US20150081559A1 (en) | 2015-03-19 |
| US20150100488A1 (en) | 2015-04-09 |
| US20060165060A1 (en) | 2006-07-27 |
| US20150339667A1 (en) | 2015-11-26 |
| US11403630B2 (en) | 2022-08-02 |
| US20150058227A1 (en) | 2015-02-26 |
| US20140337227A1 (en) | 2014-11-13 |
| US11222330B2 (en) | 2022-01-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11222330B2 (en) | Apparatus and method to perform point of sale transactions using near-field communication (NFC) and biometric authentication | |
| US12081531B2 (en) | Secure communications using loop-based authentication flow | |
| US11615414B2 (en) | Virtualization and secure processing of data | |
| KR100860628B1 (en) | A mobile phone for wireless computing device authenticable transactions, a computer system and a method thereof | |
| US7225156B2 (en) | Persistent dynamic payment service | |
| US7606560B2 (en) | Authentication services using mobile device | |
| US9083680B2 (en) | Systems, methods, and computer readable media for application-level authentication of messages in a telecommunications network | |
| US20030055738A1 (en) | Method and system for effecting an electronic transaction | |
| US20160019536A1 (en) | Secure processing of data | |
| US20140058951A1 (en) | Mobile electronic device and use thereof for electronic transactions | |
| AU2015327722A1 (en) | Secure processing of data | |
| KR20090021993A (en) | Method and system for providing advertisement by region and recording media for it | |
| Pisko | Enhancing Security of Terminal Payment with Mobile Electronic Signatures | |
| KR20090054953A (en) | Regional Ad Serving Servers | |
| KR20090082166A (en) | Telephone | |
| KR20090021992A (en) | Telephone with Equipped Data Transfer Method and System and Optional Data Output |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AS | Assignment | Owner name:EQUISPAN LLC, DELAWARE Free format text:ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:DUA, ROBIN;REEL/FRAME:037893/0502 Effective date:20160304 | |
| AS | Assignment | Owner name:SYNDEFENSE CORP, JAPAN Free format text:ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EQUISPAN LLC;REEL/FRAME:040677/0889 Effective date:20161012 | |
| AS | Assignment | Owner name:SAMSUNG ELECTRONICS CO., LTD., KOREA, REPUBLIC OF Free format text:ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SYNDEFENSE CORP;REEL/FRAME:047562/0927 Effective date:20181121 | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:DOCKETED NEW CASE - READY FOR EXAMINATION | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:NON FINAL ACTION MAILED | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:FINAL REJECTION MAILED | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:DOCKETED NEW CASE - READY FOR EXAMINATION | |
| STPP | Information on status: patent application and granting procedure in general | Free format text:NON FINAL ACTION MAILED | |
| STCB | Information on status: application discontinuation | Free format text:ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |