WO2013066553A1 - Système et procédé pour la présentation d'un identificateur de jeton de transaction non confidentiel - Google Patents

Système et procédé pour la présentation d'un identificateur de jeton de transaction non confidentiel Download PDF

Info

Publication number
WO2013066553A1
WO2013066553A1 PCT/US2012/058645 US2012058645W WO2013066553A1 WO 2013066553 A1 WO2013066553 A1 WO 2013066553A1 US 2012058645 W US2012058645 W US 2012058645W WO 2013066553 A1 WO2013066553 A1 WO 2013066553A1
Authority
WO
WIPO (PCT)
Prior art keywords
account
confidential
purchase transaction
user
value
Prior art date
Application number
PCT/US2012/058645
Other languages
English (en)
Inventor
Nikhil Jain
Jose R. MENENDEZ
Original Assignee
Qualcomm Incorporated
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US13/278,996 external-priority patent/US20120278236A1/en
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Publication of WO2013066553A1 publication Critical patent/WO2013066553A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/3221—Access to banking information through M-devices

Definitions

  • Issuers of payment tokens usually employ from thirteen to sixteen digits to create an account number for use on a payment token (i.e., a token number), although token numbers for some issuers may be more or less than the thirteen to sixteen digit range.
  • token numbers for some issuers may be more or less than the thirteen to sixteen digit range.
  • sixteen digits are commonly used, wherein the first six digits of the token number form the issuer identifier (including the initial digit which also serves to identify the major industry with which the issuer is associated, such as banking, travel, petroleum, etc.).
  • the nine numbers following the initial six used to form the issuer identifier portion will represent a user's individual account identifier.
  • the number of digits associated with the individual account identifier may vary according to the total number of digits required to form a token number for a given issuer.
  • the final digit in a typical sixteen digit token number is usually referred to as the check digit or the "checksum” digit and may be used to confirm the validity of the previous digits in the token number via application of a verification algorithm (commonly, the "Luhn” algorithm).
  • This algorithm may minimize the success rate of casual attempts to create a valid token number as well as prevent manual entry mistakes at a point of sale (“POS”) terminal.
  • POS point of sale
  • a request for authorization is transmitted to an operator of at least one of portable computing device and a landline phone, wherein the request seeks authorization to debit the value account.
  • the at least one value account may comprise a credit account, also known to one of ordinary skill in the art as a credit card account.
  • the telephone number may form part of the primary account number (PAN) governed by the ISO/IEC 7812 card number standard.
  • FIG. 1 is a high level diagram illustrating exemplary components of a system for leveraging a non-confidential number associated with a portable computing device to effect purchase transactions against a value account or accounts associated with the user of the portable computing device.
  • FIG. 2 is a functional block diagram illustrating exemplary aspects of a
  • FIG. 3 illustrates an exemplary method for leveraging, via an existing card network controlled by a third party issuer, a non-confidential number to effect purchase transactions against a value account or accounts associated with a user.
  • FIG. 4 illustrates an exemplary method for leveraging a unique tender type associated with a non-confidential number to effect purchase transactions against a value account or accounts associated with a user.
  • FIG. 5 is a diagram of exemplary computer architecture for the system of FIG.
  • FIG. 6 is a diagram of an exemplary, non-limiting aspect of a portable computing device
  • FIG. 7A is a diagram of an exemplary, non-limiting payment token including a non-confidential number suitable for routing through an existing card network controlled by a third party issuer.
  • FIG. 7B is a diagram of an exemplary, non-limiting payment token including a non-confidential number suitable for routing through an existing card network controlled by a third party issuer.
  • FIG. 7C is a diagram of an exemplary, non-limiting payment token including a non-confidential number suitable for routing directly to a network associated with a selected tender type.
  • FIG. 8 A is a high level diagram illustrating exemplary components of a system for leveraging a non-confidential number associated with a portable computing device OR a landline phone via a caller identifier to effect purchase transactions against a value account or accounts associated with the user of the portable computing device OR the landline phone.
  • FIG. 9 illustrates an exemplary method for leveraging, via an existing card network controlled by a third party issuer, a non-confidential number via a caller identifier ("Caller ID") to effect purchase transactions against a value account or accounts associated with a user.
  • Caller ID a caller identifier
  • an "application” referred to herein may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed. Further, an "application” may be a complete program, a module, a routine, a library function, a driver, etc.
  • content may also include files having executable content, such as: object code, scripts, byte code, markup language files, and patches.
  • content referred to herein, may also include files that are not executable in nature, such as documents that may need to be opened or other data files that need to be accessed.
  • system and the like are intended to refer to a computer-related entity, either hardware, firmware, a combination of hardware and software, software, or software in execution.
  • a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
  • an application running on a computing device and the computing device may be a component.
  • One or more components may reside within a process and/or thread of
  • a component may be localized on one computer and/or distributed between two or more computers.
  • these components may execute from various computer readable media having various data structures stored thereon.
  • the components may communicate by way of local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems by way of the signal).
  • a portable computing device may include a cellular telephone, a pager, a PDA, a smartphone, a navigation device, a tablet personal computer (“PC”), or a hand-held computer with a wireless connection or link.
  • FIG. 1 depicted is a high level diagram illustrating exemplary components of a system 100 for leveraging a non-confidential number associated with PCD 110A (and in a later embodiment, a non-confidential number associated with a landline phone 810 as illustrated in FIGs. 8A-8B) to effect purchase transactions against a value account or accounts associated with the user of PCD 110A.
  • the illustrated components of an exemplary system 100 include PCD 110 grouped in a storefront 135 with a merchant POS terminal or register (or a merchant with access to the Internet, interactive voice response - IVR system, etc. as illustrated in FIGs. 8A-8B) 125 .
  • a merchant POS terminal or register (or a merchant with access to the Internet, interactive voice response - IVR system, etc. as illustrated in FIGs. 8A-8B) 125 may be any component, application or system operable to receive data in payment for goods or services such as, but not limited to a cash register, a desktop computer, a laptop computer, a personal digital assistant, a tablet computer, a scanner, a cellular "smart” phone, a landline phone using the plain old telephone system (“POTS”), or the like.
  • POTS plain old telephone system
  • storefront 135 may be a physical "brick and mortar" location in some embodiments, it is envisioned that other embodiments may include a virtual storefront 135 for purchase transactions, such as a website or telecommunication, or a remote location relative to the operator of the PCD 100A (or operator of the landline phone 810 as illustrated in FIGs. 8A-8B), wherein the PCD 110 (or the operator of the landline phone 810) and the merchant are not physically co-located.
  • a nonconfidential number such as a wireless phone number assigned to a PCD 11 OA, or phone number assigned to a landline phone 810, being associated with a plurality of value accounts.
  • the plurality of value accounts may include any combination of credit accounts and/or stored value accounts (e.g., merchant-specific gift card accounts).
  • the wireless phone number/landline phone number and plurality of value accounts are all tied to the user of PCD 110A.
  • a merchant establishment whether virtual or physical, may be represented by storefront 135.
  • a user associated with PCD 110A desires to purchase goods and/or services from the merchant's store 135 with a portable computing device 110A running a "cellcard" module 118 (or using a landline phone 810 of FIGs. 8A-8B).
  • the goods and/or services are selected for purchase from the merchant associated with POS 125 (or a merchant with access to the Internet or an IVR as illustrated in FIGs. 8A-8B).
  • the merchant "rings up" the goods for purchase, provides a purchase total to the user and asks for a payment method.
  • cellcard number does not limit the present disclosure to the use of a phone number, or even a number which includes a phone number, as a non-confidential number suitable to be leveraged for a purchase transaction. Rather, the term “cellcard number” is meant to encompass any non-confidential number tied to one or more value accounts, whether such accounts are credit accounts or stored value accounts, and, as such, the term “cellcard number” will not limit the scope of the disclosure to a phone number.
  • the merchant enters the cellcard number into POS 125 as the selected means for payment.
  • the operator of the PCD 110A may dial a phone number 805 associated with the POS 125 using a PCD 110A or a landline phone 810.
  • This phone number (originating from either the PCD 110A or a landline phone 810) may be supported by the credit network (“CN") server 105A1.
  • the CN server 105A1 may retrieve the cellcard number from the Caller ID and relay it back to the POS 125.
  • the cellcard number may include the phone number of the PCD 110A as well as additional numbers such as UN numbers, a checksum, etc.
  • additional numbers may be provided by the operator of the PCD 110 A (or a landline phone 810 or PCD 110A as illustrated in FIGs. 8A-8B).
  • these additional numbers may be the same for a given account type and may be automatically generated by the POS 125 or at a server 105 based on the account type.
  • all VISA TM brand or MASTERCARD TM brand credit card accounts may utilize the same additional numbers that form a primary account number ("PAN”) as will be described in connection with FIG. 7.
  • PAN primary account number
  • the cellcard number or Caller ID may be transmitted to the server 105, along with data specific to the purchase transaction which may include additional numbers forming the cellcard number or Caller ID associated with the account, via a communications network 130.
  • the server 105 may provide the additional numbers beyond the cellcard number or Caller ID to form the PAN (as illustrated in FIG. 7).
  • SVA server 105B may be a server, or servers, configured for the provision and management of accounts associated with a non-confidential payment token, such as a cellcard number, and, as such, it will be understood that the term "stored value account server” is not intended to limit accounts associated with a non-confidential payment token to be of a stored value nature. That is, it is envisioned that accounts managed by SVA server 105B may, in fact, be stored value accounts, such as gift card accounts or debit accounts, but may also be secured or unsecured credit accounts.
  • a non-confidential payment token such as a cellcard number
  • PCD 110A may leverage cellcard module 118 to render the authorization request to the user of PCD 110A via display 114.
  • the user may subsequently accept or decline the authorization to the server via actuation of an interface associated with cellcard module 118. If authorization is received by SVA server 105B from PCD 110A, then the exemplary gift card account may be debited in an amount identified by the purchase transaction data and confirmation of such debit transmitted back to POS 125, thus completing the transaction. If authorization is declined or otherwise not granted, confirmation of the decline is transmitted back to POS 125, thus terminating the payment of the purchase transaction by a cellcard number.
  • the illustrated computer system 100 may comprise a server 105 that may be coupled to a network 130 comprising any or all of a wide area network ("WAN"), a local area network ("LAN”), the Internet, or a combination of other types of networks. It should be understood that the term server 105 may refer to a single server system or multiple systems or multiple servers.
  • the server 105 may be coupled to database 120, which may include a data/service database in addition to a stored value account database.
  • the database 120 may store various records related to, but not limited to, device configurations, software updates, user's manuals, troubleshooting manuals, user-specific PCD configurations, PCD user-specific contact or account information, user-specific contact or account information, historical content, validation algorithms, filters/rules algorithms, audio/video data, etc.
  • the server 105 When the server 105 is coupled to the network 130, the server 105 may
  • PCDs 110 may be comprised of desktop or laptop computers, thin clients, handheld devices such as personal digital assistants ("PDAs"), cellular telephones or other smart devices.
  • PDAs personal digital assistants
  • Each PCD 110 may run or execute web browsing software or functionality to access the server 105 and its various applications.
  • Any device that may access the network 130 either directly or via a tether to a complimentary device may be a PCD 110 according to the computer system 100.
  • the PCDs 110, as well as other components within system 100 such as, but not limited to, a database server (not specifically depicted) associated with data/service database 120 or POS 125, may be coupled to the network 130 by various types of communication links 145.
  • These communication links 145 may comprise wired as well as wireless links.
  • the communication links 145 allow each of the PCDs 110 to establish virtual links 150 with the server 105. While a virtual link 150 is depicted between the server 105 and PCD 110A, an actual wireless link 140 may exist between the PCD 110A and the POS 125. This wireless link 140 may only be used to relay the cellcard number to the PCD 110A as a uni-directional communications channel. In other exemplary embodiments, the PCD 110A may establish bi-directional communications with the POS 125 as understood by one of ordinary skill in the art.
  • Each PCD 110 may include a display 114, wireless communication hardware
  • the display 114 may comprise any type of display device such as a liquid crystal display (“LCD”), a plasma display, an organic light-emitting diode (“OLED”) display, a touch activated display, and a cathode ray tube (“CRT”) display, a brail display, an LED bank, and a segmented display.
  • LCD liquid crystal display
  • OLED organic light-emitting diode
  • CRT cathode ray tube
  • a PCD 110 may execute, run or interface to a cellcard module 118.
  • the cellcard module 118 may comprise a multimedia platform that may be part of a plug-in for an Internet web browser.
  • the cellcard module 118 is designed to work with wireless communication hardware 112, a radio transceiver 116 and any stored or retrievable content to render a cellcard number and/or authorize a purchase transaction against an account associated with a cellcard number.
  • wireless communication hardware 112 a radio transceiver 116 and any stored or retrievable content to render a cellcard number and/or authorize a purchase transaction against an account associated with a cellcard number.
  • various content associated with the PCD user, cellcard number, cellcard number associated accounts and storefront 135 may be rendered on the display 114.
  • the cellcard module 118 may run one or more algorithms or processes required for validation/authentication of a purchase transaction prior to transmitting authorization to server 105.
  • an exemplary portable computing device 110 may
  • geographically proximate transceiver device such as, but not limited to, an exemplary POS 125 as depicted in the system 100 of FIG.l.
  • the cellcard module 118 may be configured to relay non-confidential cellcard information through wireless communication hardware 112 via a communication application programming interface ("API") 111.
  • API application programming interface
  • a cellcard module 118 may be designed to include the
  • the cellcard module 118 may be configured to interface with cellular radio transceiver 116, via a radio API 115 for receiving and transmitting purchase transaction authorization information as well as other information to exemplary server 105, as depicted in the system 100 embodiment. Even further, the cellcard module 118 may be configured to leverage a text to speech (“TTS") module (not depicted) as may be known in the art to relay non-confidential cellcard information in an audible format, wherein the POS 125, or the merchant associated with POS 125, may recognize such an audible transmission.
  • TTS text to speech
  • a cellcard module 118 may also include the radio API 115 and/or cellular radio transceiver 116 and/or a TTS module as part of its module in a unitary design.
  • a PCD 110 may be configured to leverage the cellular radio transceiver 116 to transmit data, such as a purchase transaction authorization, a personal identification number (PIN), a security key or other data generated by cellcard module 118. This data may be useful for verification of a geographical location or user identification by way of a secure channel using wireless link 145A to the server 105. It is also envisioned that PCDs 110 in some exemplary embodiments of system 100 may leverage communication link 145B via an unsecure or lesser secure wireless communication link 140 (relative to cellular wireless link 145A) that may be established between the POS 125 and PCD 110 to transmit data to and from server 105.
  • data such as a purchase transaction authorization, a personal identification number (PIN), a security key or other data generated by cellcard module 118. This data may be useful for verification of a geographical location or user identification by way of a secure channel using wireless link 145A to the server 105.
  • PCDs 110 in some exemplary embodiments of system 100 may leverage communication link 145
  • Wireless link 145A may comprise a secure channel established on a cellular telephone network.
  • communication links 145 in general, may comprise any combination of wireless and wired links including, but not limited to, any combination of radio-frequency (“RF”) links, infrared links, acoustic links, other wireless mediums, wide area networks (“WAN”), local area networks (“LAN”), the Internet, a Public Switched Telephony Network (“PSTN”), and a paging network.
  • RF radio-frequency
  • WAN wide area networks
  • LAN local area networks
  • PSTN Public Switched Telephony Network
  • the exemplary PCD 110 may also comprise a Validation/Rules module 117 for, among other things, automatically processing or filtering received authorization requests prior to accepting or declining a request to the server 105.
  • a Validation/Rules module 117 for, among other things, automatically processing or filtering received authorization requests prior to accepting or declining a request to the server 105.
  • Validation/Rules module 117 or cellcard module 118 may provide user access restriction or other security measures to ensure that purchase transaction authorization is accepted or declined by a user of the PCD 110 authorized to do so. Because a
  • Validation/Rules module 117 is not required in all PCDs 110, the presence or absence of a Validation/Rules module 117 in a PCD 110 will not limit the scope of the disclosure. Even so, it is envisioned that some embodiments of system 100 will include PCDs 110 comprising a Validation/Rules module 117.
  • PCDs 110 comprising a Validation/Rules module 117.
  • an unauthorized user or purchase transaction may be recognized and/or filtered prior to communication with server 105.
  • An exemplary PCD 110 may also comprise a computer readable
  • Data added to, extracted or derived from the purchase transaction data or cellcard data may comprise a user ID, a transaction ID, a directory number ("DN") or calling line ID ("CLID") associated with PCD 110, a merchant ID, a network name, a hash value, a codec key, encryption or decryption data, account numbers and other account related data such as, but not limited to, data related to an item being purchased, price of an item being purchased, purchase discount rates or amounts, customer loyalty data, sales tax rates or amounts, merchant employee identification, etc.
  • DN directory number
  • CLID calling line ID
  • account numbers and other account related data such as, but not limited to, data related to an item being purchased, price of an item being purchased, purchase discount rates or amounts, customer loyalty data, sales tax rates or amounts, merchant employee identification, etc.
  • FIG. 3 illustrated is an exemplary method 300 for leveraging, via an existing card network controlled by a third party issuer, a non-confidential number to effect purchase transactions against a value account or accounts associated with a user of the PCD 110.
  • a merchant scans or otherwise "rings up" items for purchase, creates a total for the purchase transaction, and asks the user of PCD 110A for a payment method.
  • PCD 110A may associate one or more value accounts with a cellcard number uniquely tied to a single PCD 110A user
  • other embodiments may link multiple users of PCDs 110, i.e. a "family" of users of PCDs 110 (PCD 110A, PCD HOB, PCD HOC... PCD 11 On), to common value accounts.
  • PCD 110A a "family" of users of PCDs 110
  • multiple users of PCDs 110 who are linked to common value accounts, may be able to leverage individual non-confidential cellcard numbers or a single, common non-confidential cellcard number to effect purchase transactions against one or more associated value accounts.
  • some embodiments which include a plurality of users of PCDs 110, who are each linked to one or more common value accounts, may provide for a purchase transaction authorization to be requested from only the user of PCD 11 OA or, for that matter, any subset of user of PCDs 110. That is, it is envisioned that some embodiments may provide for a purchase transaction to be initiated by a user of a PCD 110 other than the user of PCD 110A and then authorized by the user of PCD 110A.
  • a college aged child attending school on the west coast may provide a cellcard number for purchase of goods and the authorization request may be transmitted from server 105B to a PCD 110A associated with her father on the east coast.
  • a cellcard number may include a number that is easily remembered and recited, as it may serve dual purposes as a transaction number and a phone number or the like.
  • multiple value accounts may be associated with a single, non-confidential cellcard number, it is a further advantage that a user associated with a plurality of value accounts may only have to remember a single cellcard number in order to leverage each of the plurality of value accounts.
  • the cellcard number may form part of an industry standard sixteen-digit payment number. Sixteen-digit payment numbers are understood by one of ordinary skill in the art as primary account numbers ("PANs").
  • Each unique PAN comprising a phone number may also be referred to in the industry as a bank card number and is the primary account number found on most credit cards and bank cards.
  • the PAN may be governed by an industry standard, such as those made by the International Organization for Standardization/International
  • the PAN may have a certain amount of internal structure and it may share a common numbering scheme among all PANs issued by existing third party card networks.
  • One particular standard for the PAN may include the ISO/IEC
  • the merchant selects payment by the card network of the third party issuer and requests the cellcard number.
  • the user of PCD 110A presents the cellcard number.
  • a cellcard number may be "presented" in any number of ways including, but not limited to, spoken presentation by the user, NFC or short wave radio transmission from a PCD 110 operable to do so, spoken presentation via a PCD 110 configured with a text to speech (“TTS") module, the PCD 110 dialing a phone number 805 associated with the POS 125 and the cellcard number being retrieved from the Caller ID, etc.
  • TTS text to speech
  • the means of cellcard number presentation may be a novel aspect of some embodiments of a system and method for leveraging a cellcard number, the particular means for presentation of a cellcard number will not limit the scope of the disclosure.
  • the cellcard number is entered into/captured by the merchant POS
  • CN server 105A Upon receipt of the cellcard data at CN server 105A, UN data or other data encoded with the cellcard data causes the CN server 105A to forward the cellcard data to SVA server 105B at block 330.
  • the SVA server 105B sends an authorization request to PCD
  • the authorization request may cause cellcard module 118 to render data including, but not limited to, transaction total, date and time of transaction, merchant name and location, etc.
  • the user may authorize or decline the purchase transaction.
  • authorization or declination of a purchase transaction may require the user of PCD 11 OA to authenticate an identity or authorization clearance via the navigation of various security layers promulgated by cellcard module 118 and/or validation/rules module 117. Additionally, in some embodiments, it is envisioned that authorization of a purchase transaction will include selection by the user of an account associated with the cellcard. That is, as a cellcard may be associated with any number of value accounts, the purchase transaction authorization may require that the user select which account the purchase transaction should be debited against.
  • the cellcard module 118 and/or validation/rules module 117 may be configured to automatically select, in lieu of user selection at the time of authorization, one of a plurality of value accounts associated with a cellcard. Also, it is envisioned that some embodiments may include a "time out" feature such that, if a purchase transaction authorization is not received within a certain period of time, a purchase transaction may be automatically declined, deferred until authorization is received or a subsequent request for authorization is transmitted.
  • the authorization may be validated at block 345 via rules/validation module 117 running on PCD 110A or, alternatively, via a rules/validation module 540 running on server 105B (See FIG. 5).
  • an authorization that is not validated may cause a repeat authorization request (step not shown), while in other embodiments an authorization that is not validated may essentially terminate the transaction.
  • server 105B may cause transmission of approval for the purchase transaction to server 105B.
  • server 105B may debit a value account associated with the cellcard number.
  • the SVA server 105B may determine the value account to be debited, from a plurality of value accounts associated with a cellcard number, by querying the location of a merchant POS 125 against value accounts associated with the merchant location.
  • data identifying the merchant POS 125 location may be transmitted from the POS 125 along with the purchase transaction data and cellcard data.
  • some embodiments may leverage location data associated with a merchant POS 125 to automatically authorize the purchase transaction based on a comparison of global positioning system data (“GPS") received from PCD 110A, or any other location system or method that may be known in the art such as, but not limited to, proximate cell tower identification, WiFi mac address maps, acoustic signature recognition, QR code recognition, etc., thus deducing that the user of PCD 110A is present at the POS 125 proximity.
  • GPS global positioning system data
  • the SVA server 105B may transmit purchase transaction approval back to the merchant POS 125 via CN server 105A and the third party card network.
  • a purchase transaction has been effected by use of a non-confidential cellcard number and the method 300 ends.
  • a purchase transaction has been effected by use of a non-confidential cellcard number and the method 300 ends.
  • FIG. 4 illustrates an exemplary method 400, associated with the exemplary embodiment illustrated in FIGs.
  • a merchant creates a purchase transaction total and requests a payment method from the user of PCD 110A.
  • reference to the "user of PCD 110A” does not limit the scope of the disclosure to the provision of a cellcard number via the specific user of PCD 110A. That is, it is envisioned that other parties in possession of a nonconfidential cellcard may provide the cellcard number for purchase of goods; however, one of ordinary skill will recognize that, unlike typical payment tokens known in the art, mere presentment of a cellcard number will not, in and of itself, authorize a purchase transaction as authorization for the transaction may be requested and validated only from the user of a predetermined PCD 110.
  • the user of PCD 110A opts for payment by cellcard number.
  • the merchant selects at a POS register 125 a tender type uniquely associated with a cellcard token.
  • the cellcard number may be rendered in a format not necessarily suitable for transmission across a third party issuer card network, as there is a tender type at the POS 125 configured for specific receipt of a cellcard number.
  • the user of PCD 110A presents the cellcard number (i.e. providing a visual representation of the number, orally stating the number, dialing a phone number 805 associated with the POS 125 in which the cellcard number is extracted from the Caller ID, etc.) and, at block 425, the associated data is received by the POS 125 and routed along with the purchase transaction data directly to SVA server 105B.
  • the cellcard number i.e. providing a visual representation of the number, orally stating the number, dialing a phone number 805 associated with the POS 125 in which the cellcard number is extracted from the Caller ID, etc.
  • the SVA server 105B sends an authentication request to PCD 110A. If the user of PCD 110A authorizes the purchase transaction at block 440, and such authorization is validated at block 445, the cellcard module 118 may transmit purchase transaction authorization back to SVA server 105B at block 450.
  • the SVA server may debit an associated account according to an amount identified by the purchase transaction data and at block 460 transmit approval of the purchase transaction back to POS 125, thus effecting a purchase by non-confidential cellcard number and ending the purchase by cellcard process.
  • the cellcard module may decline authorization for the purchase transaction to the SVA server 105B.
  • the SVA server 105B will transmit rejection of the purchase transaction to the POS 125, thus ending the purchase by cellcard process.
  • the PCD 110 may include a processor 550A and a
  • the memory 119A coupled to the processor 550A.
  • the memory 119A may include instructions for executing one or more of the method steps described herein.
  • the processor 550 A and the memory 119A may serve as a means for executing one or more of the method steps described herein.
  • the memory 119 A may also include a cellcard module 118 and/or a Validation and Rules ("V/R") module 117.
  • the cellcard module 118 and the V/R module 117 may be provided to the PCD 110 by the SVA server 105B.
  • a cellcard module 118 may operate to render a cellcard token and transmit the associated data to POS 125, according to various mechanisms described above relative to FIG. 1. Further, the cellcard module 118 may operate to receive purchase transaction authorization request from SVA server 105B and, subsequently, transmit acceptance or declination of such authorization back to SVA server 105B.
  • a V/R module 117 operates to validate authorization actuations requested by the cellcard module 118 and/or automatically authorize purchase transactions based on the application of various heuristics. For example, V/R module 117 may apply heuristics to automatically authorize purchase transaction requests based on purchase amount, merchant identification, the ID of the PCD 110 associated with the purchase transaction, etc.
  • FIG. 5 shows that the SVA server 105B may include a processor 550B and a memory 119B coupled to the processor 550B.
  • the memory 119B may include instructions for executing one or more of the method steps described herein.
  • the processor 550B and the memory 119B may serve as a means for executing one or more of the method steps described herein.
  • the memory 119B may include a V/R module 540 operable to validate authorization transmissions received from the cellcard module 118 and/or automatically authorize purchase transactions based on the application of various heuristics.
  • V/R module 540 may apply heuristics to automatically authorize purchase transaction requests based on purchase amount, merchant identification, the ID of the PCD 110 associated with the purchase transaction, various data associated with the purchase transaction, etc.
  • the memory 119B may include an SVA management module 535 operable to query database 120 and update records associated with various value accounts tied to a given non-confidential cellcard token.
  • the V/R module 540 within the SVA server 105B may be similar to the V/R module 117 stored within the PCD 110. Further, the V/R module 540 within the SVA server 105B may include substantially the same logic as the V/R module 117 stored within the PCD 110. While a V/R module is not required in both a PCD 110 and SVA server 105B in all embodiments, it is envisioned that redundant filters and validation algorithms may be implemented across V/R modules 117, 540 in some embodiments.
  • a database 120 for storage of V/R algorithms, content for dissemination, value account records, PCD user historical data, etc. may also be connected to the SVA server 105B.
  • V/R module 540 included in some embodiments of an SVA server 105B, it is anticipated that heuristics may be applied to guard against the theft of a PCD 110A or generally misappropriation of a cellcard token associated with PCD 110A.
  • a stolen PCD 110 may be rendered ineffective for the authorization of a purchase request via application of heuristics which include the provision of a PIN, automated call for verification via a security question, provision of a code or key, etc.
  • the V/R module 540 may apply heuristics or rules which dictate that an alternative authentication method be leveraged such as, but not limited to, a voice call when data connectivity is unavailable, entry of a PIN or other security code via the POS 125, etc. Even further, in some embodiments the V/R module 540 may automatically authorize a purchase transaction based the amount of the transaction being below a predetermined threshold, the purchase transaction originating from a user' s preferred merchant or any other heuristic that may occur to one with ordinary skill in the art.
  • CN third party card network
  • the memory 119C may include a transaction routing module 515 operable to route cellcard data and purchase transaction data between a POS 125 and SVA server 105B.
  • a merchant's point of sale (“POS") system 125 may also be connected to the CN server 105A such that cellcard and purchase transaction data may be tracked and transmitted to the SVA server 105B.
  • POS point of sale
  • FIG. 6 this figure is a diagram of an exemplary, non-limiting aspect of a PCD 110 comprising a wireless telephone which corresponds with FIG. 2.
  • the PCD 110 includes an on-chip system 622 that includes a digital signal processor 624 and an analog signal processor 626 that are coupled together.
  • a display controller 628 and a touchscreen controller 630 are coupled to the digital signal processor 624.
  • a touchscreen display 114 external to the on-chip system 622 is coupled to the display controller 628 and the touchscreen controller 630.
  • FIG. 6 further indicates that a video encoder 634, e.g., a phase-alternating line
  • PAL PAL
  • SECAM sequentially energizer
  • NTSC national television system(s) committee
  • a video amplifier 636 is coupled to the video encoder 634 and the touchscreen display 114.
  • a video port 638 is coupled to the video amplifier 636.
  • a universal serial bus (“USB”) controller 640 is coupled to the digital signal processor 624.
  • a USB port 642 is coupled to the USB controller 640.
  • a memory 119A and a subscriber identity module (“SIM”) card 646 may also be coupled to the digital signal processor 624.
  • SIM subscriber identity module
  • a digital camera 648 may be coupled to the digital signal processor 624.
  • the digital camera 648 is a charge-coupled device (“CCD”) camera or a complementary metal-oxide semiconductor (“CMOS”) camera.
  • CCD charge-coupled device
  • CMOS complementary metal-oxide semiconductor
  • a stereo audio CODEC 650 may be coupled to the analog signal processor 626. Moreover, an audio amplifier 652 may be coupled to the stereo audio CODEC 650. In an exemplary aspect, a first stereo speaker 654 and a second stereo speaker 656 are coupled to the audio amplifier 652. FIG. 6 shows that a microphone amplifier 658 may be also coupled to the stereo audio CODEC 650.
  • a microphone 660 may be coupled to the microphone amplifier 658.
  • a frequency modulation ("FM") radio tuner 662 may be coupled to the stereo audio CODEC 650.
  • an FM antenna 664 is coupled to the FM radio tuner 662.
  • stereo headphones 368 may be coupled to the stereo audio CODEC 650.
  • FIG. 6 further indicates that a radio frequency ("RF') transceiver 116 may be coupled to the analog signal processor 626.
  • An RF switch 670 may be coupled to the RF transceiver 116 and an RF antenna 672.
  • a keypad 674 may be coupled to the analog signal processor 626.
  • a mono headset with a microphone 676 may be coupled to the analog signal processor 626.
  • a vibrator device 678 may be coupled to the analog signal processor
  • FIG. 6 also shows that the PCD 110 may include a cellcard module 118 and/or a
  • the cellcard module 118 may communicate with the SVA server 105B to authorize purchase transactions against a value account associated with a nonconfidential cellcard token and managed by SVA server 105B.
  • the touchscreen display 114, the video port 638, the USB port 642, the camera 648, the first stereo speaker 654, the second stereo speaker 656, the microphone 660, the FM antenna 664, the stereo headphones 668, the RF switch 670, the RF antenna 672, the keypad 674, the mono headset 676, the vibrator 678, and the power supply 680 are external to the on-chip system 622.
  • one or more of the method steps described herein may be stored in the memory 119A as computer program instructions, such as cellcard module 118 and V/R module 117. These instructions may be executed by the digital signal processor 624, the analog signal processor 626, or another processor, to perform the methods described herein. Further, the processors, 624, 626, the memory 119A, the instructions stored therein, or a combination thereof may serve as a means for performing one or more of the method steps described herein.
  • FIG. 7A is a diagram of an exemplary, non-limiting payment token 700A including a non-confidential number 710A suitable for routing through an existing card network controlled by a third party issuer.
  • the exemplary payment token 700A may be a token which includes a non-confidential number 710A corresponding to a phone number associated with a PCD 110 or a landline phone 810.
  • the non-confidential number may be a phone number, or other number, easily remembered and uniquely associated with a user of a PCD 110 or a landline phone 810.
  • the token 700A may comprise a physical card.
  • the payment token 700 A may comprise a virtual or digital card that is rendered on the display 114 of the PCD 100A.
  • the exemplary phone number 710A is preceded by a six-digit Issuer Identification Number ("UN") 705A, wherein the last of the six digits may coincide with the first digit of a ten-digit phone number for the PCD 110.
  • UN Issuer Identification Number
  • the exemplary embodiment depicted in FIG. 7A includes a ten-digit phone number, it will be understood that other embodiments may include phone numbers, or other non-confidential numbers, that are less or more than ten digits in length.
  • the last number 715 is a checksum number used for the application of the Luhn algorithm, or other algorithm, to validate the validity of a token number.
  • Each unique PAN comprising the phone number 710A may also be referred to in the industry as a bank card number and is the primary account number found on most credit cards and bank cards.
  • the PAN may be governed by an industry standard, such as those made by the International Organization for Standardization/International
  • the PAN may have a certain amount of internal structure and it may share a common numbering scheme among all PANs issued by existing third party card networks.
  • One particular standard for the PAN may include the ISO/IEC
  • the ISO/IEC 7812 standard contains a single-digit Major Industry Identifier ("Mil”), a six-digit Issuer Identification Number (“UN”), an account number, and a single digit check sum calculated using the Luhn algorithm.
  • the prefix of the PAN may be the sequence of digits at the beginning of the number that determine the credit card network to which the number belongs. As noted above, the first six digits of the PAN may be referred to as the Issuer Identification Number ("UN"). These identify the institution that issued the card to the card holder. While the PAN may comprise a sixteen digit number, other multi-digit numbers as well as alphanumeric identifiers are within the scope of the system and method as described herein.
  • FIG. 7B is a diagram of an exemplary, non-limiting payment token 700B
  • an UN number 705B may be used to route the cellcard data and purchase transaction data without requiring that a digit be used to crossover between the last digit of the UN and the first digit of the non-confidential number 710B.
  • this cellcard or Caller ID payment token 700C does not include an UN number.
  • a cellcard or Caller ID payment token suitable for routing directly to SVA server 105B may include routing prefixes such as an UN number
  • the exemplary cellcard payment token 700C only includes a non-confidential number 7 IOC, such as a phone number, associated with a user of a PCD 110.
  • the exemplary 700C token does not require a checksum digit or a digit crossover between the UN and phone number. That is, because a merchant POS 125 may include a tender type selection uniquely associated with payment by cellcard number in some embodiments, there is no need to "trick" a third party issuer system into routing the cellcard data and purchase transaction data to an SVA server 105B. Rather, in the exemplary 700C embodiment, the cellcard number or Caller ID number 7 IOC itself may be used to route the cellcard data and purchase transaction data directly to an SVA server 105B to trigger a request for authorization to debit a purchase transaction against an associated value account.
  • FIG. 7C of FIG. 7C may comprise a physical card.
  • the payment tokens 700 may comprise a virtual or digital card that is rendered on the display 114 of the PCD 100.
  • FIGS. 7 A, 7B and 7C are offered as exemplary cellcard or Caller ID token formats that may be used in various embodiments of the systems and methods described herein. It will be understood that the exemplary FIGS. 7A, 7B and 7C embodiments are offered for illustrative purposes only and will not be construed to limit the nature, format, content or length of a cellcard or Caller ID token number.
  • any payment token which includes an account number or data that is non-confidential in nature may be leveraged as a cellcard payment token.
  • FIG. 8A this figure is a high level diagram illustrating
  • Caller ID a caller identifier
  • an operator of a landline phone 810 or an operator of a PCD 110A may interact with a merchant by communication links 145 which may comprise a landline or a cellular telephone communication.
  • a merchant 125 who is in a remote location relative to the operator of the landline phone 810 or PCD 110A and who has access to the Internet or an interactive voice response ("IVR") system may process payment for goods and/or services using a caller ID associated with the landline phone 810 or PCD 110A.
  • IVR interactive voice response
  • the merchant 125 may key-in the caller ID or the merchant 125 may have a device or system, or a POS 125 that is integrated with a cellular telephone and/or landline which retrieves a caller ID when the operator of the PCD 110A or operator of the landline communicates with the merchant 125.
  • the merchant 125 who is interacting with the operator of the landline phone 810 or the operator of the PCD 110A via a communication link 145 may be using a Portable Computing Device (PCD), like a smart phone, which has an application program that extracts the caller ID from the communication link 145 and uses that caller ID for processing a payment that is routed across the communications network 130 to the servers 105.
  • PCD Portable Computing Device
  • This exemplary embodiment illustrated in FIG. 8 A operates very similarly to the exemplary embodiment illustrated in FIG. 1 once the caller ID has been extracted from the communication link 145. While it is envisioned that the extraction of the caller ID from the communication link 145 may be automated, in certain instances in which the caller ID is not available or the caller ID has been blocked by the operator of the landline phone 810 or PCD 110A, the operator may relay the phone number associated with the landline 810 or PCD 11 OA by speaking to the merchant during the
  • the merchant 125 may relay the caller ID over the communication link 145 to the communications network 130 by an electronic communication or by communicating with an interactive voice response ("IVR") system that may be supported by the servers 105.
  • IVR interactive voice response
  • FIG. 8B is a diagram similar to FIG. 8 A but includes further examples of merchants who may benefit from leveraging a non-confidential number associated with a portable computing device 110 A OR a landline phone 810 via a caller identifier to effect purchase transactions against a value account or accounts.
  • FIG. 8B has elements which are similar to those illustrated in FIG. 8A. Therefore, only the differences between these two figures will be described below.
  • the merchants 125 may include, but is not limited to, take-out food service providers, food delivery service providers (usually from grocery chains), service professionals like doctors, dentists, lawyers, accountants, plumbers, HVAC technicians, cable TV repairpersons, computer repair service providers, cleaning service providers, painters, babysitters, and other similar merchants 125.
  • an operator of a landline phone 810 may desire to order a pizza from a food delivery service provider (i.e. pizza delivery shop).
  • a food delivery service provider i.e. pizza delivery shop.
  • the merchant 125 may extract the caller ID associated with the phone call originating from the operator of the landline phone 810 (or PCD 11 OA).
  • the operator of the landline phone 810 after making the pizza order, may tell the merchant 125 that his or her payment should be made with the caller ID system.
  • the merchant 125 may key-in the caller ID or the merchant 125 may have been integrated POS system that extracts the caller ID from the communication link 145B. Alternatively, the merchant 125 may conduct the phone call with the operator of the landline 810 (or operator of a first PCD 100) using a second PCD 110 that includes an application program for extracting the caller ID. The system 100' then operates similarly to the system 100 illustrated in FIG. 1 once the phone number associated with the consumer has been secured.
  • the transaction may be verified by the servers 105 which may communicate with the PCD 110 of the operator if the PCD 110 is available or the server 105 may utilize an IVR system to contact the operator of the landline phone 810 after the transaction has been submitted by the merchant 125.
  • the system 100' illustrated in FIG. 8B may be ideal for nontraditional
  • FIG. 810 A block diagram illustrating an exemplary computing environment in accordance with the present disclosure.
  • the operator of the landline phone 810 may simply telephone the babysitter (merchant 125) and tell the babysitter to charge the transaction to the operator's account associated with his or her caller ID.
  • the babysitter 125 may use a landline phone 810 in combination with an IVR system supported by the servers 105 to complete the transaction or the babysitter 125 may utilize a PCD 110 that has a communication link 145B to the communications network 130.
  • FIG. 9 illustrates an exemplary method 900 for leveraging, via an existing card network controlled by a third party issuer, a non-confidential number via a caller identifier to effect purchase transactions against a value account or accounts associated with a user.
  • FIG. 9 has elements which are similar to those illustrated in FIG. 3.
  • the merchant 125 may request the operator of the landline phone 810 or a PCD 110 who may be in a remote location relative to the merchant 125 for payment to cover requested goods or services (or both).
  • the operator of the landline phone 810 or PCD 110A opts to remit payment via a non-confidential caller ID number having a format consistent with confidential payment token account numbers associated with third party issuer and which may be extracted from the caller ID of a communication link 145 between the merchant 125 and the operator of the landline phone 810 or a PCD 110A.
  • the caller ID number may form part of an industry standard sixteen-digit payment number. Sixteen-digit payment numbers are understood by one of ordinary skill in the art as primary account numbers ("PANs"), such as illustrated in FIG. 7 described above. Each unique PAN comprising a phone number may also be referred to in the industry as a bank card number and is the primary account number found on most credit cards and bank cards.
  • PANs primary account numbers
  • the merchant selects payment by the card network of the third party issuer and secures the caller ID number from the communication link 145.
  • CN server 105 A Upon receipt of the caller ID data at CN server 105 A, UN data or other data encoded with the caller ID data causes the CN server 105A to forward the caller ID data to SVA server 105B at block 930.
  • Block 930 which is similar to Block 330 of FIG. 3
  • the SVA server 105 may send an authorization request to either a PCD 110 or a landline phone (or both).
  • Block 950 which is similar to block 350 of FIG. 3 requires the operator of the landline phone 810 or the PCD 11 OA to send the approval for a transaction.
  • the servers 105 may contact either the PCD 110A for approval or they may use an IVR system to ring the landline phone 810 for receiving an approval for the transaction.
  • the servers could contact both devices (phone 810 or PCD 110), such as sending a message to the PCD 110 and calling phone 810 and authorizing the transaction if the user communicates by one of the devices.
  • Block 970 may work similarly in which either the operator of a landline phone 810 or a PCD 110A may transmit a rejection for a particular transaction.
  • the servers 105 may receive a rejection from the PCD 100A or a response to an IVR system initiated phone call to landline phone 810.
  • the landline phone system 100' is not limited to the method 900 which
  • the landline phone system 100' may easily be used for leveraging a unique tender type associated with a non-confidential number, similar to FIG. 3, to effect purchase transactions against a value account or accounts associated with a user.
  • the invention is not limited to the order of the steps or blocks described if such order or sequence does not alter the functionality of the invention. That is, it is recognized that some steps or blocks may performed before, after, or parallel
  • the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted as one or more instructions or code on a computer-readable medium.
  • Computer-readable media include both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • Such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to carry or store desired program code in the form of instructions or data structures and that may be accessed by a computer.
  • any connection is properly termed a computer-readable medium.
  • the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (“DSL"), or wireless technologies such as infrared, radio, and microwave
  • the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, acoustic and microwave are included in the definition of medium.
  • Disk and disc includes compact disc (“CD”), laser disc, optical disc, digital versatile disc (“DVD”), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.
  • CD compact disc
  • DVD digital versatile disc
  • floppy disk floppy disk
  • blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé et un système pour achever une transaction d'achat, lequel procédé consiste à recevoir le numéro non confidentiel pour effectuer une transaction d'achat à partir d'un identificateur d'appelant et à demander à ce qu'un compte de valeur associé au numéro non confidentiel soit débité, le montant de débit étant associé à la transaction d'achat. Une requête d'autorisation est transmise à un opérateur d'au moins l'un d'un dispositif informatique portable et d'un téléphone fixe, la requête cherchant une autorisation pour débiter le compte de valeur. Le ou les comptes de valeur peuvent comprendre un compte de crédit dans lequel le numéro de téléphone peut faire partie du numéro de compte primaire (PAN) régi par la norme de numéro de carte ISO/IEC 7812.
PCT/US2012/058645 2011-10-21 2012-10-04 Système et procédé pour la présentation d'un identificateur de jeton de transaction non confidentiel WO2013066553A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/278,996 2011-10-21
US13/278,996 US20120278236A1 (en) 2011-03-21 2011-10-21 System and method for presentment of nonconfidential transaction token identifier

Publications (1)

Publication Number Publication Date
WO2013066553A1 true WO2013066553A1 (fr) 2013-05-10

Family

ID=47190121

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/058645 WO2013066553A1 (fr) 2011-10-21 2012-10-04 Système et procédé pour la présentation d'un identificateur de jeton de transaction non confidentiel

Country Status (1)

Country Link
WO (1) WO2013066553A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000072109A2 (fr) * 1999-05-25 2000-11-30 Safepay Australia Pty Limited Systeme de gestion de transactions sur reseau
WO2006081525A2 (fr) * 2005-01-28 2006-08-03 Cardinal Commerce Corporation Systeme et methode pour une conversion entre des transactions basees sur internet et des transactions non basees sur internet
US20110251892A1 (en) * 2010-04-09 2011-10-13 Kevin Laracey Mobile Phone Payment Processing Methods and Systems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000072109A2 (fr) * 1999-05-25 2000-11-30 Safepay Australia Pty Limited Systeme de gestion de transactions sur reseau
WO2006081525A2 (fr) * 2005-01-28 2006-08-03 Cardinal Commerce Corporation Systeme et methode pour une conversion entre des transactions basees sur internet et des transactions non basees sur internet
US20110251892A1 (en) * 2010-04-09 2011-10-13 Kevin Laracey Mobile Phone Payment Processing Methods and Systems

Similar Documents

Publication Publication Date Title
US20120278236A1 (en) System and method for presentment of nonconfidential transaction token identifier
US20120246071A1 (en) System and method for presentment of nonconfidential transaction token identifier
US11941615B2 (en) Method and system for transmitting credentials
US10764269B2 (en) Method and system for creating a unique identifier
US20180240115A1 (en) Methods and systems for payments assurance
US9183549B2 (en) System and method of secure payment transactions
US20130185214A1 (en) System and Method For Secure Offline Payment Transactions Using A Portable Computing Device
US20200364720A1 (en) Method and apparatus for facilitating commerce
AU2020200743B2 (en) Real time EFT network-based person-to-person transactions
JP2004533692A (ja) ポイントオブセールス（ｐｏｓ）音声認証取引システム
US20160034891A1 (en) Method and system for activating credentials
KR20110107311A (ko) 모바일 네트워크를 이용한 결제 서비스 시스템 및 그 방법, 그리고 이를 위한 컴퓨터 프로그램
US20160098726A1 (en) Telephone transaction verification system
US11893570B1 (en) Token based demand and remand system
WO2013066553A1 (fr) Système et procédé pour la présentation d'un identificateur de jeton de transaction non confidentiel
US12008542B2 (en) Systems and methods for performing payment transactions using indicia-based associations between user interfaces
WO2014019026A1 (fr) Système et procédé de transaction électronique
WO2016057559A1 (fr) Systèmes de vérification de transactions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12787549

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12787549

Country of ref document: EP

Kind code of ref document: A1