Classifications

• • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
• • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • 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/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
• • 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
  • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
• • 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

Definitions

• aspects of the present invention relate in general to authenticating a user, and in particular to a method and system ⁇ of verifying users in electronic transactions.
• FIG. 1 illustrates an embodiment of a system that authenticates users in an electronic transaction.
• FIG. 2 is a block diagram of an apparatus that authenticates users in an electronic transaction.
• FIG. 3 is a block diagram of an embodiment that authenticates users in an electronic transaction.
• FIG. 4 is flowchart of a method that requests authentication of users in an electronic transaction.
• FIGS. 5a and 5b are flowcharts of a method that authenticates users in an electronic transaction.
• FIG. 1 is a simplified functional block diagram depicting system 100, constructed and operative in accordance with an embodiment of the present invention.
• System 100 is configured to authenticate a user in an electronic transaction.
• Electronic transactions are any transactions that take place over a computer network (i.e., an "on-line" transaction). Examples of such transactions include, but are not limited to, any sale or purchase of goods and services, or any operation that involves the electronic authorization of a party.
• An example of the former is purchasing a book, compact disk, or any other goods or services, via an Internet browser on the World- Wide- Web (“WWW" or the "web”).
• WWW World- Wide- Web
• An example of the latter transaction is the doctor's approval of a medical prescription being filled by an electronic pharmacy.
• the method relies on the fact that a user is pre-registered with a caller database, and the user's wireless telephone number is unique to a particular user.
• a known transaction code e.g., Personal Identification number, PIN
• PIN Personal Identification number
• the network 110 may also include other networkable devices known in the art, such as other computers 120, servers 130, printers 125 and storage media 140. It is well understood in the art, that any number or variety of computer networkable devices or components may be coupled to the network 110 without inventive faculty. Examples of other devices include, but are not limited to, servers, computers, workstations, terminals, input devices, output devices, printers, plotters, routers, bridges, cameras, sensors, or any other such device known in the art.
• Computer 120 may be of any kind known in the art that are able to communicate on the network 110.
• Servers 130A-C may be any servers known in the art, including web, database, print, or application servers. More importantly, servers 130A-C may generate, originate, or participate in an electronic transaction that requires user authentication. A server participating in an electronic transaction is referred to as a "transaction server" 130.
• Network 110 may be any communication network known in the art, including the Internet, a local-area-network (LAN), a wide-area-network (WAN), or any system that links a computer to an authentication server 135. Further, network 110 may be of configured in accordance with any topology known in the art, including star, ring, bus, or any combination thereof.
• LAN local-area-network
• WAN wide-area-network
• network 110 may be of configured in accordance with any topology known in the art, including star, ring, bus, or any combination thereof.
• Authentication server 135 is connected to a telephone network 150 that supports Calling Number Delivery (CND), also known as Caller ID (CID).
• Telephone network 150 may be configured as a packet switch telephone network (PSTN), plain ordinary telephone service (POTS), Integrated Services Digital Network (ISDN), or any other telephone network 150 known in the art that supports caller ID.
• PSTN packet switch telephone network
• POTS plain ordinary telephone service
• ISDN Integrated Services Digital Network
• telephone network 150 is connected to a wireless telephone system 160 that also supports Caller ID.
• Authentication server 135 knows each user's wireless telephone number and stores the wireless telephone number in a caller database.
• transaction server 130 requiring user authentication, may also be the same apparatus as the authentication server 135, without any loss of functionality.
• Authentication server 135 runs a multi-tasking operating system and includes at least one central processing unit (CPU) 102.
• CPU 102 may be any microprocessor or micro-controller as is known in the art.
• CPU 102 may be a microprocessor, such as the Pentium IIITM processor manufactured by Intel Corporation.
• the software for programming the CPU may be found at a computer-readable storage medium 140 or, alternatively, from another location across network 110.
• CPU 102 is connected to computer memory 118.
• Authentication server 135 is controlled by an operating system (OS) that is executed within computer memory 118.
• OS operating system
• CPU 102 communicates with a plurality of peripheral equipment, including computer network interface 116 and telephone network interface 112.
• Additional peripheral equipment may include a display 104, manual input device 106, storage medium 140, microphone 108, and data input port 114.
• Display 104 may be a visual display such as a cathode ray tube (CRT) monitor, a liquid crystal display (LCD) screen, touch-sensitive screen, or other monitors as are known in the art for visually displaying images and text to a user.
• Manual input device 106 may be a conventional keyboard, keypad, mouse, trackball, or other input device as is known in the art for the manual input of data.
• Storage medium 140 may be a conventional read/write memory such as a magnetic disk drive, floppy disk drive, compact-disk read-only-memory (CD-ROM) drive, transistor-based memory or other computer-readable memory device as is known in the art for storing and retrieving data.
• storage medium 140 may be remotely located from CPU 102, and be connected to CPU 102 via a network 110 such as a local area network (LAN), a wide area network (WAN), or the Internet.
• LAN local area network
• WAN wide area network
• Internet the Internet
• Microphone 108 may be any suitable microphone as is known in the art for providing audio signals to CPU 102.
• a speaker (not shown) may be attached for reproducing audio signals from CPU 102. It is understood that microphone 108 and speaker may include appropriate digital-to-analog and analog-to-digital conversion circuitry as appropriate.
• Data input port 114 may be any data port as is known in the art for interfacing with an external accessory using a data protocol such as RS-232, Universal Serial Bus (USB), or Institute of Electrical and Electronics Engineers (IEEE) Standard No. 1394 ('Firewire').
• Network interface 116 may be any interface as known in the art for communicating or transferring files across a computer network, examples of such networks include Transmission Control Protocol/Internet Protocol (TCP/IP), Ethernet, Fiber Distributed Data Interface (FDDI), token bus, or token ring networks.
• TCP/IP Transmission Control Protocol/Internet Protocol
• FDDI Fiber Distributed Data Interface
• token bus or token ring networks.
• network interface 116 may consist of a modem connected to the data input port 114.
• telephone network interface 112 provides connectivity to authentication server 135 to communicate with a telephone network 150.
• the telephone network interface 112 allows the authentication server 135 to communicate and process input from a telephone line.
• FIG. 3 is an expanded functional block diagram of CPU 102 and storage medium 140. It is well understood by those in the art, that the functional elements of FIG. 3 may be implemented in hardware, firmware, or as software instructions and data encoded on a computer-readable storage medium 140.
• central processing unit 102 is functionally comprised of a data processor 202, an application interface 204, a transaction processor 206, and a call handler 210.
• Data processor 202 interfaces with display 104, manual input device 106, storage medium 140, microphone 108, data input port 114, Internet network interface 116, and telephone network interface 112.
• the data processor 202 enables CPU 102 to locate data on, read data from, and write data to, these components.
• Application interface 204 enables CPU 102 to take some action with respect to a separate software application or entity.
• application interface 204 may take the form of a windowing user interface, as is commonly known in the art.
• Transaction processor 206 handles an electronic commerce transaction. Transaction processor 206 approves or disapproves of transactions depending upon the verification of a user by call handler 210. The results of transaction processor 206 may be recorded on storage media 140 as a transaction log 242. Call handler 210 may be further comprised of a caller ID processor 212 and a caller verifier 214. These components of call handler 210 interact with a known caller database 244, and may best be understood with respect to the flowcharts of FIGS. 4, 5a and 5b, as described below.
• FIG. 4 is a flow diagram depicting process 300, constructive and operative in accordance with an embodiment of the present invention.
• process 300 initially determines whether transaction server 130 is participating in an electronic transaction that requires a user authentication. This determination may be accomplished by any means known in the art, including a table-look-up of a list of electronic transactions that require user authentication, or may be embedded within a program being executed by transaction server 130.
• Process 300 in block 304, may suspend the transaction while the user is being authenticated.
• process 300 initiates transaction server 130 to sends authentication request (also known as a "transaction notification") to authentication server 135.
• the authentication request may comprise a user identifier and a transaction identifier.
• the user identifier can be any information that identifies the user as a party of the transaction, including: name, social security number, or any other similar identifier.
• the transaction identifier identifies the transaction that requires the authentication. Additionally, in some embodiments, the user's electronic mail address may also be encoded within the authentication request.
• the notification is conveyed to authentication server 135 via network 110. In embodiments that combine authentication server 135 with transaction server 130, the notification may be sent internally within the device itself.
• process 300 waits for authentication server 135 to respond to the authentication request. Upon receiving a response from authentication server 135, process 300 determines whether the received response indicates that the user is authenticated. When the user is authenticated by the authentication server 135, the transaction is approved, block 312. Otherwise, the transaction is disallowed in block 314.
• FIG. 5a and FIG. 5b are flow diagrams depicting process 400 and 450, respectively.
• Process 400 and 450 describe the authentication sequence from the point of view of authentication server 135.
• Authentication server 135 receives an authentication request or transaction notification from the transaction server 130 in block 401.
• Transaction processor 206 decodes the user identifier and the transaction identifier from the authentication request.
• transaction processor 206 generates a transaction PIN that comprises a sequence of numbers, between zero and nine. The sequence is used in conjunction with a user's wireless telephone number to authenticate the user's participation in a transaction.
• the transaction PIN may contain alphanumeric characters including as well the symbols "*" and "#", words or a sequence of letters that can be entered via a telephone keypad.
• Embodiments that generate numeric transaction PINs may generate a pseudo- random number by any means known in the art.
• Embodiments that use letters may generate a pseudo-random series of letters and numbers or may use a dictionary to generate the transaction pin.
• Some embodiments look up the user's entry in the caller database 244, and append or store the transaction identifier and the transaction pin as fields in the caller database 244, or as part of the transaction log 242.
• process 400 transmits the transaction PIN to the user.
• PIN is sent to the user by transaction processor 206 via network interface 116 and network 110.
• the user is provided a telephone number that they are required to call to authenticate themselves as a valid user in the transaction.
• the telephone number provided is connected to authentication server 135 via telephone network 150.
• the telephone number is conveyed by looking up the electronic mail address of the user in a caller database 244, and then electronic-mailing the user convey the telephone number.
• Other embodiments include using the electronic mail address encoded within the authentication request.
• Still other embodiments display the transaction PIN before the user via a World- Wide- Web page.
• Process 450 of FIG. 5b authenticates the user by matching the user's caller- identified wireless phone number with the transaction PIN provided by process 400 in FIG. 5a.
• the user calls the provided telephone number, reaching authentication server 135.
• Authentication server 135 receives the call from the user at block 402.
• Authentication server 135 identifies the user by matching the user as a caller from a certain wireless phone number via caller ID.
• Authentication server 135 receives the call via its telephone network interface 112. The call is then routed to call handler 210.
• the caller ID signal delivered as a V.23 modem signal between the 1st and 2nd ring cycles.
• the Caller ID is delivered over the D (signaling) channel at the initial onset of call setup in compliance with ITU-T specification Q.81.3.
• the caller ID processor 212 derives the user's telephone number.
• Caller verifier 214 takes the telephone number and looks up the caller identity in caller database 244.
• the phone call is ignored, and authentication server 135 hangs up, block 408.
• the caller is prompted to enter the transaction PIN, block 410. If the transaction PIN entered by the caller matches the one sent to the user by process 400, as determined by transaction processor 206, the user is authenticated, and transaction server 130 is informed of the authentication by internet network interface 116, block 414. If the transaction PP entered by the caller does not matches the one sent to the user, as determined by transaction processor 206, the authentication fails, and transaction server 130 is informed of the failure by the internet network interface 116. In some embodiments users can be offered an opportunity to re-enter the transaction PIN, block 416. The outcome of the authentication may be recorded in a transaction log 242.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Computer Security & Cryptography (AREA)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• General Engineering & Computer Science (AREA)
• Computing Systems (AREA)
• Finance (AREA)
• Computer Hardware Design (AREA)
• Telephonic Communication Services (AREA)
• Mobile Radio Communication Systems (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=24414354

Family Applications (1)

Country Status (4)

Families Citing this family (14)

Family Cites Families (4)

• 2001
  • 2001-06-01 EP EP01939805A patent/EP1330797A2/de not_active Withdrawn
  • 2001-06-01 AU AU2001265284A patent/AU2001265284A1/en not_active Abandoned
  • 2001-06-01 CN CNA018118232A patent/CN1486476A/zh active Pending
  • 2001-06-01 WO PCT/US2001/017704 patent/WO2002001516A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events