WO2000079411A2 - Method and apparatus for commercial transactions via the internet - Google Patents
Method and apparatus for commercial transactions via the internet Download PDFInfo
- Publication number
- WO2000079411A2 WO2000079411A2 PCT/US2000/015676 US0015676W WO0079411A2 WO 2000079411 A2 WO2000079411 A2 WO 2000079411A2 US 0015676 W US0015676 W US 0015676W WO 0079411 A2 WO0079411 A2 WO 0079411A2
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- card
- smart card
- messages
- computer
- program code
- Prior art date
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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
Definitions
- This invention relates to electronic commerce and, more specifically, to commercial transactions via the Internet.
- Electronic Commerce includes, for example, electronic banking and bill payment, as well as electronic purchases.
- commerce information is exchanged between a "server application” that provides the information or services, and a "client application” that receives the provided information or services.
- Electronic commerce mechanisms that exist on the Internet allow users the ability to exchange commerce information.
- Commerce information exchange on the Internet is accomplished using software that transmits information between the server and the client to perform a transaction.
- the problem with current electronic commerce mechanisms is that electronic commerce software is vulnerable to tampering, particularly where the software resides on a computer system that is accessible to the public.
- kiosks are computer systems that typically unattended and allow a user to walk up and execute software that resides on the system. Where the kiosk is being used for electronic commerce, it is possible for someone to modify the electronic commerce software that resides on the kiosk to capture another user's electronic commerce information (e.g., credit card information), for example.
- a digital wallet has characteristics that imitate a physical wallet. Like a physical wallet, a digital wallet can hold different forms of payment (e.g., currency, credit cards and debit cards). While a physical wallet may have a user's driver's license for identification, a digital wallet might include a digital certificate that can be used to identify (or authenticate) the user. In addition, a digital wallet can contain shipping information (e.g., the buyer's shipping address). The digital wallet may implement an encryption scheme as well for secure transmission of the digital wallet information.
- digiCash available from DigiCash
- the buyer opens an account with an account provider such as a bank and downloads the digital wallet software.
- the buyer in conjunction with the bank creates "coins" (or electronic currency) that are digitally signed by the bank.
- the digital wallet can be used to exchange coins with other wallets.
- the coins can also be presented to the bank to be cashed in for physical currency, for example.
- a digital wallet that uses credit cards is available from CyberCash.
- a user downloads CyberCash's digital wallet and inputs credit card information into the digital wallet.
- the user also registers the credit card with CyberCash.
- the digital wallet registers itself with the user's Internet browser as a helper application.
- an encrypted payment order is sent to the merchant.
- the merchant adds some payment information, signs the order and forwards it to CyberCash.
- a problem with the digital wallet scheme is that software and /or data for the digital wallet is stored on a computer that may be unsecured or unattended. This makes it possible for unauthorized users to pretend they are legitimate users by using the computer to perform a transaction. Another problem is the possibility of obtaining software and data from an unsecured computer and using it to create fraudulent transactions.
- Smart cards are credit card sized devices that can easily be secured by keeping them on your person.
- Smart cards can be used to transfer funds electronically.
- a smart card might be inserted into a card reader of a pay phone to transfer funds from the smart card to pay to, for example, the pay phone to pay for the card holder's telephone call.
- a smart card includes a microprocessor and memory.
- the smart card's microprocessor can be programmed to perform an electronic commerce transaction to transfer electronic funds that are stored in its memory.
- the electronic funds that are stored in the smart card's memory can be obtained from the card issuer, for example.
- Electronic funds can also be transferred between smart cards.
- electronic funds stored on a buyer's smart card can be transferred to a merchant's smart card to pay for the buyer's purchase.
- a single, integrated software application is used to establish communication with both smart cards simultaneously to perform the transaction (e.g., receive the electronic funds from the buyer, verify the electronic funds received from the buyer and transfer the funds to the merchant's card).
- the Internet is an example of a world wide communications network comprised of various physical networks that interconnect computing devices.
- the Internet is comprised of many physical networks that interconnect computing devices.
- a personal computer in a user's home can be connected via one or more networks that comprise the Internet to a computer system regardless of either's location to gain access to information that is resident on that computer system.
- a user's request can be transported via the Internet's networks to the computer system.
- a response from the computer system can be transmitted to the user via the Internet.
- the Transport Control Protocol /Internet Protocol are the basic communications protocol for transmitting information over Internet.
- a communications protocol typically defines the format for a packet, or bundle, of data that is to be transmitted.
- a packet usually includes control information (e.g., destination, origin, packet length, etc.), the data to be transmitted and error detection and correction.
- Other communications protocols such as Hypertext Transmission Protocol (HTTP) and File Transfer Protocol (FTP), are built on top of TCP/IP.
- Resources e.g., servers, services, program code, and files
- a URL is mechanism by which a resource can be identified in a request.
- HTTP and FTP are mechanisms by which the request is communicated.
- HTML Hypertext Markup Language
- GUI graphic user interface
- An HTML document is transmitted via the HTTP communications protocol to a client that is running a software package referred to as a browser.
- a browser provides a GUI to display a page of information that is defined using HTML.
- the browser parses the HTML statements to generate and display the page's GUI elements in the browser's display area.
- the browser further provides a mechanism for the user to input information and /or to submit a request which the browser forwards, via the Internet, to the appropriate Internet server using a communications protocol such as HTTP.
- a communications network can be characterized as either an external network (i.e., extranet) or an internal network (intranet).
- An extranet is a communications network that is considered to be external with reference to a given organization or entity.
- a network may be considered to be external simply because it is under another's administration and control.
- the Internet is comprised of networks that are examples of extranets.
- a communications network to which access is controlled or restricted is an internal network (or intranet).
- An intranet operates over a physical network that is under a given entity's administrative control.
- An intranet can be connected to an extranet via a physical connection such as a modem and telephone line. Routing hardware and/or software is used to route packets between the intranet and an extranet via a physical connection.
- a gateway which is comprised of hardware and /or software is typically used to act as an entrance and exit into a communications network. For example, an intranet can use a gateway through which packets directed to and from the intranet must pass. A gateway can further perform conversions between otherwise incompatible communications networks.
- An entity may wish to limit the packets that are allowed access to its intranet. For example, an entity may wish to limit entry to information that is resident on its intranet such that it is not accessible to extranet users (e.g., an Internet user unaffiliated with the entity).
- a firewall is one example of a technique that implements a restrictive and controlled access approach to an intranet (e.g., between an intranet and an extranet).
- a firewall is hardware and /or software (typically considered part of a gateway) that examines packet data to determine whether the packet should be forwarded to /from the intranet. The firewall identifies the destination and /or origin addresses to determine whether to forward the packet, for example.
- the firewall examines the origin of the message and does not forward a message from an unauthorized source. If, for example, the firewall is configured to stop Internet packets from entering an intranet, the firewall blocks packets whose origin is the Internet. Similarly, a firewall can be used to intercept and stop a packet that is destined for an unauthorized destination (e.g., an extranet).
- the restrictive and controlled access that is enforced by a firewall is advantageous because it reduces the chance of a security breach by an unauthorized user who otherwise might gain access to the intranet.
- a firewall prohibits an intranet user from accessing the extranet via the intranet.
- a proxy server can be installed on the intranet which has access to both the intranet and the Internet.
- a proxy server acts as a proxy to forward requests on another's (e.g., an application's or user's) behalf.
- a proxy server forwards a message without modifying its content.
- a proxy server typically performs application-level filtering of messages. That is, a proxy server examines application-level messages to determine whether and to whom the message should be forwarded.
- a proxy server can be used, for example, to forward information between two applications (or users) that reside on different intranets or between an intranet application (or user) and an extranet (e.g., the Internet).
- an intranet user sends a request directed to the Internet to the proxy server which forwards the request unchanged to the Internet.
- firewall nor a proxy server allow access by an authorized user attempting to gain access to the corporation's intranet from outside the intranet.
- the purpose of the firewall is to prohibit external access to the intranet.
- One purpose of a proxy server is to facilitate access to an extranet from within the intranet.
- Object-oriented programming is a method of creating computer programs by combining certain fundamental building blocks, and creating relationships among and between the building blocks.
- the building blocks in object-oriented programming systems are called "objects.”
- a software application can be written using an object-oriented programming language whereby the program's functionality is implemented using these objects.
- An object is a programming unit that groups together a data structure (one or more instance variables) and the operations (methods) that can use or affect that data.
- an object consists of data and one or more operations or procedures that can be performed on that data.
- the joining of data and operations into a unitary building block is called "encapsulation.”
- An object can be instructed to perform one of its methods when it receives a "message.”
- a message is a command or instruction sent to the object to execute a certain method.
- a message consists of a method selection (e.g., method name) and a plurality of arguments.
- a message tells the receiving object what operations to perform.
- object-oriented programming is the way in which methods are invoked. When a message is sent to an object, it is not necessary for the message to instruct the object how to perform a certain method. It is only necessary to request that the object execute the method. This greatly simplifies program development.
- Object-oriented programming languages are predominantly based on a "class” scheme.
- the class-based object-oriented programming scheme is generally described in Lieberman, "Using Prototypical Objects to Implement Shared Behavior in Object-Oriented Systems," OOPSLA 86 Proceedings, September 1986, pp. 214-223.
- An object class provides a definition for an object which typically includes both fields (e.g., variables) and methods.
- An object class is used to create a particular "object instance.” (The term "object” by itself is often used interchangeably to refer to a particular class or a particular instance.)
- An instance of an object class includes the variables and methods defined for that class. Multiple instances can be created from the same object class. Each instance that is created from the object class is said to be of the same type or class.
- an employee object class can include "name” and “salary” instance variables and a "set_salary” method. Instances of the employee object class can be created, or instantiated for each employee in an organization. Each object instance is said to be of type “employee.” Each employee object instance includes “name” and “salary” instance variables and the "set_salary” method. The values associated with the "name” and “salary” variables in each employee object instance contain the name and salary of an employee in the organization. A message can be sent to an employee's employee object instance to invoke the "set_salary” method to modify the employee's salary (i.e., the value associated with the "salary" variable in the employee's employee object).
- a hierarchy of classes can be defined such that an object class definition has one or more subclasses.
- a subclass inherits its parent's (and grandparent's etc.) definition. Each subclass in the hierarchy may add to or modify the behavior specified by its parent class.
- the parent class is also referred to as a superclass with respect to its subclass(es).
- Some object-oriented programming languages support multiple inheritance where a subclass may inherit a class definition from more than one parent class.
- Other programming languages support only single inheritance, where a subclass is limited to inheriting the class definition of only one parent class.
- the Java programming language also provides a mechanism known as an "interface" which comprises a set of constant and abstract method declarations.
- An object class can implement the abstract methods defined in an interface. Both single and multiple inheritance are available to an interface. That is, an interface can inherit an interface definition from more than one parent interface.
- Object-oriented software applications typically comprise one or more object classes and interfaces. Many programming languages can be used to write a program which is compiled into machine-dependent (or platform-dependent), executable code. However, in other languages such as the Java programming language, program code (e.g., classes) may be compiled into platform-independent bytecode class files. Each class contains code and data in a platform-independent format. A bytecode includes a code that identifies an instruction (an opcode) and none or more operands to be used in executing the instruction. The computer system acting as the execution vehicle contains a program such as a virtual machine, which is responsible for executing the platform-independent code (e.g., bytecodes generated from a program written using the Java programming language).
- platform-independent code e.g., bytecodes generated from a program written using the Java programming language
- Platform-independent programs have an advantage of being usable on multiple platforms. There is no need to develop program code for multiple platforms. The same platform-independent program can be executed on multiple platforms using a virtual machine or other mechanism that is configured to translate the platform-independent code into platform-dependent code. Thus, an application developer can develop one version of an application's program code that can ultimately be executed on multiple platforms, for example.
- Applications may be designed as standalone applications, or as "applets" which are identified by an applet tag in an HTML (Hypertext Markup Language) document, and loaded by a browser application.
- the class files associated with an application or applet may be stored on the local computing system, or on a server accessible over a network. Each class file is loaded into the virtual machine, as needed, by the "class loader.”
- the classes of an applet are loaded on demand from the network (stored on a server), or from a local file system, when first referenced during the applet's execution.
- the virtual machine locates and loads each class file, parses the class file format, allocates memory for the class's various components, and links the class with other already loaded classes. This process makes the code in the class readily executable by the virtual machine.
- Figure 1 illustrates the development and runtime environments for a processing system.
- a software developer creates class source files 100 which contain the programmer readable class definitions, including data structures, method implementations and references to other classes.
- Class source files 100 are provided to compiler 101, which compiles class source files 100 into compiled ".class" (or class) files 102 that contain bytecodes executable by a virtual machine.
- Class files 102 are stored (e.g., in temporary or permanent storage) on a server, and are available for download over a network. Alternatively, class files 102 may be stored locally in a directory on the client platform.
- the runtime environment contains a virtual machine (VM) 105 which is able to execute bytecode class files and execute native operating system ("O/S") calls to operating system 109 when necessary during execution.
- Virtual machine 105 provides a level of abstraction between the machine independence of the bytecode classes and the machine-dependent instruction set of the underlying computer hardware 110, as well as the platform-dependent calls of operating system 109.
- Class loader and bytecode verifier (“class loader”) 103 is responsible for loading bytecode class files 102 and supporting class libraries 104 written using a programming language into virtual machine 105 as needed. Class loader 103 also verifies the bytecodes of each class file to maintain proper execution and enforcement of security rules. Within the context of runtime system 108, either an interpreter 106 executes the bytecodes directly, or a "just-in-time” (JIT) compiler 107 transforms the bytecodes into machine code, so that they can be executed by the processor (or processors) in hardware 110.
- JIT just-in-time
- Native code e.g., in the form of a linked library 111
- a class e.g., from class libraries 1014
- Linked library 111 can be, for example, a "shared object” library in the SolarisTM or UNIX environment that is written as a ".so" file, or linked library 111 may take the form of a dynamic loadable library written as a ".dll” file in a Windows environment.
- Interpreter 106 reads, interprets and executes a bytecode instruction before continuing on to the next instruction.
- JIT compiler 107 can translate multiple bytecode instructions into machine code that is then executed. Compiling the bytecodes prior to execution results in faster execution. If, for example, the same bytecode instruction is executed multiple times in a program's execution, it must be interpreted each time it is executed using interpreter 106. If JIT compiler 107 is used to compile the program, the bytecode instruction may be translated once regardless of the number of times it is executed in the program. Further, if the compilation (i.e., output of JIT compiler 107) is retained, there is no need to translate each instruction during program execution.
- a method and apparatus for electronic commerce on the Internet is described.
- electronic commerce transactions involving the transfer of funds stored on a smart card are accomplished via the Internet.
- the invention provides a smart card server to handle communication between a smart card and the Internet.
- an applet that is running within browser software interacts with the smart card server to access the software and data that resides on a smart card.
- the applet and smart card server communicate using the browser's mechanism for communicating via the Internet. Where, for example, the browser communicates over the Internet using the Hypertext Transfer Protocol (HTTP), the applet and smart card server communicate using HTTP messages.
- HTTP Hypertext Transfer Protocol
- the smart card server communicates with a smart card via the communications protocol of the smart card reader.
- Figure 1 illustrates the compile and runtime environments for a processing system.
- Figure 2 provides an overview of an architecture for use in an electronic commerce transaction using one or more smart cards according to an embodiment of the invention.
- Figure 3 provides an example of communications between smart cards using an applet and card servers according to an embodiment of the invention.
- Figure 4 provides an overview of smart card authentication according to one or more embodiments of the invention.
- Figure 5 is a block diagram of one embodiment of a computer system capable of providing a suitable execution environment for an embodiment of the invention.
- the invention uses a smart card server to handle communication between the smart card and the Internet.
- an applet that is running within a browser interacts with a smart card server to access the software and data that resides on a smart card.
- the applet and smart card server communicate using the same communications protocol that a browser uses to communicate via the Internet. Where, for example, the browser communicates over the Internet using the Hypertext Transfer Protocol (HTTP), the applet and smart card server communicate using HTTP messages.
- HTTP Hypertext Transfer Protocol
- the smart card server communicates with a smart card via the communications protocol of the smart card reader.
- FIG 2 provides an overview of an architecture for use in an electronic commerce transaction using one or more smart cards according to an embodiment of the invention.
- electronic funds are to be transferred from smart card 202 to smart card 204.
- Smart cards 202 and 204 can be, Java Cards from Sun Microsystems, Inc. or smart cards from Mondex International, for example.
- the holder of smart card 202 i.e., the buyer
- Web server 212 responds to a uniform resource locator (URL) request for a Web page sent by browser 210 for the buyer, for example.
- the Web page that is sent may include items that can be purchased by the buyer.
- the buyer selects the desired item and clicks on a button to indicate a desire to purchase the selected item.
- URL uniform resource locator
- Applet 214 executes in browser 210.
- applet 214 may comprise one or more object classes written using the Java programming language. However, it should be apparent that applet 214 can be written using other programming languages. Applet 214 can be downloaded from the merchant's Web server 212 or elsewhere, for example.
- Applet 214 acts as an interface between card servers 216 and 218.
- Card servers 216 and 218 act as interfaces between applet 214 and smart cards 202 and 204 via smart card readers 226 and 228 (respectively).
- Information is transmitted between smart cards 202 and 204 via card servers 216 and 218 and applet 214.
- Card servers 216 and 218 communicate with smart cards 202 and 204 using the communications protocol of smart card readers 226 and 228 (e.g., a serial communications protocol) and the protocol of smart cards 216 and 218 (e.g., a smart card command protocol). Further, card servers 216 and 218 communicate with applet 214 using the communications protocol that is used by browser 210 (e.g., the HTTP protocol).
- the communications protocol of smart card readers 226 and 228 e.g., a serial communications protocol
- the protocol of smart cards 216 and 218 e.g., a smart card command protocol
- applet 214 e.g., the communications protocol that is used by browser 210 (e.g., the HTTP protocol).
- Card servers 216 and 218 present an interface to browser 210 and applet 214 that resembles a set of Web pages. That is, applet 214 sends HTTP requests to card servers 216 and 218 that contain information intended for smart cards 202 and 204. Card servers 216 and 218 send Web page definitions that contain a response from smart cards 202 and 204 to applet 214. Further, card servers 216 and 218 provide a mechanism for applet 214 to communicate with smart cards 202 and 204. For security reasons, browser 210 does not allow an applet (e.g., applet 214) that is running within browser 210 to directly communicate with devices that reside on the platform such as smart card reader 226 and smart card 202. Card server 216 provides a mechanism whereby applet 214 can execute within browser 210 and be able to communicate with smart card 202 via smart card reader 226.
- applet 214 sends HTTP requests to card servers 216 and 218 that contain information intended for smart cards 202 and 204.
- Card servers 216 and 218 send
- Card servers 216 and 218 encapsulate data intended for smart cards 202 and 204 into HTTP messages that can be forwarded via Internet 220 to the other smart card(s).
- the HTTP messages that are generated by card servers 216 and 218 can be forwarded via Internet 220 through one or more Web proxies and firewalls that may otherwise restrict passage of non-HTTP messages.
- embodiments of the invention can be used to facilitate smart card transactions via Internet 220 across one or more web servers, Web proxies and firewalls.
- Figure 3 provides an example of communications between smart cards
- applet 214 provides an interface for the buyer to enter payment information such as a personal identification number (or PIN) and the amount of the purchase.
- Applet 214 generates HTTP message 302 (e.g., a URL request) that is directed to card server 216.
- HTTP message 302 can be, for example, of the form:
- the form data in HTTP message 302 comprises the PIN and purchase amount information entered by the buyer, for example.
- the verifyPin portion of HTTP message 302 identifies the operation that is to be performed by smart card 202.
- Card server 216 is identified in HTTP message 302 using card server 216's URL (e.g., buyerCardServer.com).
- Card server 216 extracts the form data from HTTP message 302 and forwards the information that is needed by smart card 202 in card request 304 to smart card 202 via smart card reader 226 (not shown). Smart card 202 generates a response, card response 306, that is forwarded to card server 216 via smart card reader 226. Card server 216 packages the response received from smart card 202 in HTTP message 308 and forwards HTTP message 308 to applet 214 as a response to HTTP message 302.
- HTTP message 308 can be an HTML Web page definition that contains the response received from smart card 202, for example.
- HTTP message 308 further contains information that identifies the state of the transaction. The state of the transaction can be used by card servers 216 and 218 to determine what request to make of smart cards 202 and 204.
- applet 214 examines the state of the transaction. If the transaction state does not indicate a finished state for the transaction (e.g., a successful completion or an error), applet 214 forwards HTTP message 308 as HTTP message 310 to card server 218.
- HTTP message 310 identifies the URL of card server 218, an operation and form data.
- Card server 218 forwards the data contained in HTTP message 310 along with a command for processing the data as card request 312 to smart card 204 via smart card reader 228 (not shown).
- Smart card 204 processes the data and transmits the result to card server 218 as card response 314.
- Card server 218 generates HTTP message 316 which is transmitted to applet 214 in response to HTTP message 310.
- Applet 214 examines HTTP message 316 to determine the state of the electronic commerce transaction. If the transaction is not finished, the process 91
- applet 214 forwarding HTTP message 316 to card server 216 in a manner similar to that described with reference to HTTP message 302 above.
- Different types of smart cards may use different protocols that may require a different number of steps to perform an electronic commerce transaction. That is, one smart card protocol may require five steps while another may require twenty steps.
- the steps of an electronic commerce transaction correspond to states of the transaction in one embodiment of the invention.
- card servers 216 and 218 may include interface (or communication) software modules (e.g., program code) to accommodate different types of smart cards and their protocols.
- Each interface module communicates with a particular type of smart card (e.g., Java Card and/or Mondex smart card).
- each interface module is capable of generating messages to prompt the smart card to process the data included in the message in the desired manner for the current state of the transaction.
- applet 214 It is not necessary for applet 214 to be aware of the specific interfaces needed to communicate with a particular smart card. Thus, it is not necessary to modify applet 214 when a new type of smart card is introduced. It is only necessary to incorporate a new interface module for a new smart card into the card server (e.g., card servers 216 and 218).
- cards requests 304 and 312 and card responses 306 and 314 are communicated using a set of message types, or command protocol.
- commands such as putString, getString and getNext can be used in an embodiment of the invention.
- card requests 304 and 312 include a putString message that transmits the data to 99
- a getNext message is sent by card servers 216 and 218 to request that smart cards 202 and 204 (respectively) process the data that was sent in the putString message.
- a getString message fetches the information from smart cards 202 and 204 that card servers 216 and 218 determine is needed to be sent to the other card given the current state of the transaction.
- a getString message may be used to retrieve the result calculated by a smart card from the data contained in a putString message.
- HTTP messages 302, 308, 310 and 314 include commands that identify the type of operations to be performed by smart cards 202 and 204.
- verifyPin which might be used to verify a PIN that is entered by the buyer.
- commands that may be used in embodiments of the invention include: checkPin, setPin, changePin, resetPin, resetLog, generateResetLogCode, generateResetPinCode and valueTransfer.
- the checkPin, setPin, changePin, resetPin and generateResetPinCode involve operations that modify PIN information.
- the resetLog and generateResetLogCode commands can be used to maintain an electronic commerce transaction log.
- the valueTransfer command may be used to transfer electronic funds from one smart card to another.
- One or more embodiments of the invention can be used to authenticate a user using smart cards.
- Authentication can comprise one or more of the steps in the course of an electronic commerce transaction, for example. Authentication may also be used for other purposes such as in determining whether a smart card holder is permitted to access capabilities behind a firewall.
- the smart cards that are used in authentication share a secret value that can be used to generate an authentication value and to verify the authenticity of an authentication value. The same secret is used in both the generation and the verification processes.
- Smart cards e.g., Java Cards and/or Mondex smart cards
- Smart cards include authentication and /or verification program code that performs a set of operations which are proprietary to the card that are used to generate or verify an authentication value.
- the secret value is used in conjunction with the authentication program code in a first smart card to generate an authentication value.
- the authentication value is verified using a second smart card's verification program code in conjunction with the same secret.
- Figure 4 provides an overview of smart card authentication according to one or more embodiments of the invention.
- the authentication process is used to restrict access to computer resources.
- Client 400 includes browser 210, card server 216 and smart card 202.
- Server 402 includes computing resources that are access-restricted. Server 402 may act as a gateway to an intranet, for example.
- Reverse proxy 404 may be used in one or more embodiments of the invention to enforce a plurality of access policies.
- Reverse proxy 404 may be used to restrict access to the intranet, for example.
- Reverse proxy 404 can refuse access by an unauthenticated user and /or refuse access by an authenticated user to one or more resources where the authenticated user has insufficient access privileges for these resources, for example.
- Reverse proxy 404 e.g., login request 420
- Reverse proxy 404 generates response 422 which includes a login Web page definition and applet 214.
- the login Web page prompts the user to insert a smart card into the smart card reader (not shown) attached to client 400 and enter the information needed to authenticate and /or identify the user. For example, the user may be prompted to enter the user's identification (userid) and password (e.g., PIN), for example.
- Applet 214 generates HTTP message 424 that contains the userid and PIN and forwards HTTP message 424 to card server 216.
- Card server 216 generates card message 426 that contains the information (e.g., the user's PIN) needed to generate the authentication value.
- Card message 426 is forwarded to smart card 102 by card server 216.
- Smart card 202 performs calculations on the data to generate the authentication value using the secret value.
- Card message 428 includes the authentication value which is transmitted to card server 216.
- Card server 216 generates HTTP message 430 that includes the authentication value and the user's userid. Card server 216 forwards HTTP message 430 to applet 214 which forwards it as HTTP message 434 to reverse proxy 404. Reverse proxy 404 forwards HTTP message 434 to card server 218. Card server 218 retrieves the authentication value from HTTP message 434 and generates card message 436 which is transmitted to smart card 204. Smart card 204 performs a verification operation on the authentication value and returns the result (success or failure) as card message 438.
- card server 218 retrieves access privileges 442 associated with the user's userid (e.g., userid 440) from access database 406. Card server 218 forwards the user's access privileges to reverse proxy 404 via HTTP message 444. Where the verification is unsuccessful, card server 218 forwards the unsuccessful status to reverse proxy 404 via HTTP message 444.
- An embodiment of the invention can be implemented as computer software in the form of computer readable code executed on a general purpose computer such as computer 200 illustrated in Figure 2, or in the form of bytecode class files executable within a Java runtime environment running on such a computer, or in the form of bytecodes running on a processor (or devices enabled to process bytecodes) existing in a distributed environment (e.g., one or more processors on a network).
- a keyboard 210 and mouse 211 are coupled to a system bus 218. The keyboard and mouse are for introducing user input to the computer system and communicating that user input to processor 213. Other suitable input devices may be used in addition to, or in place of, the mouse 211 and keyboard 210.
- I/O (input/ output) unit 219 coupled to system bus 218 represents such I/O elements as a printer, A/V (audio/video) I/O, etc.
- Computer 200 includes a video memory 214, main memory 215 and mass storage 212, all coupled to system bus 218 along with keyboard 210, mouse 211 and processor 213.
- the mass storage 212 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology.
- Bus 218 may contain, for example, thirty-two address lines for addressing video memory 214 or main memory 215.
- the system bus 218 also includes, for example, a 64-bit data bus for transferring data between and among the components, such as processor 213, main memory 215, video memory 214 and mass storage 212. Alternatively, multiplex data/address lines may be used instead of separate data and address lines.
- the processor 213 is a microprocessor manufactured by Sun Microsystems, Inc., such as the SPARCTM microprocessor, or a microprocessor manufactured by Motorola, such as the r
- Main memory 215 is comprised of dynamic random access memory (DRAM).
- Video memory 214 is a dual-ported video random access memory. One port of the video memory 214 is coupled to video amplifier 216.
- the video amplifier 216 is used to drive the cathode ray tube (CRT) raster monitor 217.
- Video amplifier 216 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 214 to a raster signal suitable for use by monitor 217.
- Monitor 217 is a type of monitor suitable for displaying graphic images.
- Computer 200 may also include a communication interface 220 coupled to bus 218.
- Communication interface 220 provides a two-way data communication coupling via a network link 221 to a local network 222.
- ISDN integrated services digital network
- communication interface 220 provides a data communication connection to the corresponding type of telephone line, which comprises part of network link 221.
- LAN local area network
- communication interface 220 provides a data communication connection via network link 221 to a compatible LAN.
- Wireless links are also possible.
- communication interface 220 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information.
- Network link 221 typically provides data communication through one or more networks to other data devices.
- network link 221 may provide a connection through local network 222 to local server computer 223 or to data equipment operated by an Internet Service Provider (ISP) 224.
- ISP 224 in turn provides data communication services through the world wide packet data 97
- Internet 225 uses electrical, electromagnetic or optical signals which carry digital data streams.
- the signals through the various networks and the signals on network link 221 and through communication interface 220, which carry the digital data to and from computer 200, are exemplary forms of carrier waves transporting the information.
- Computer 200 can send messages and receive data, including program code, through the network(s), network link 221, and communication interface 220.
- remote server computer 226 might transmit a requested code for an application program through Internet 225, ISP 224, local network 222 and communication interface 220.
- the received code may be executed by processor 213 as it is received, and /or stored in mass storage 212, or other non-volatile storage for later execution. In this manner, computer 200 may obtain application code in the form of a carrier wave.
- Application code may be embodied in any form of computer program product.
- a computer program product comprises a medium configured to store or transport computer readable code, or in which computer readable code may be embedded.
- Some examples of computer program products are CD-ROM disks, ROM cards, floppy disks, magnetic tapes, computer hard drives, servers on a network, and carrier waves.
Abstract
Description
Claims
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU55988/00A AU5598800A (en) | 1999-06-21 | 2000-06-07 | Method and apparatus for commercial transactions via the internet |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US33717299A | 1999-06-21 | 1999-06-21 | |
US09/337,172 | 1999-06-21 |
Publications (3)
Publication Number | Publication Date |
---|---|
WO2000079411A2 true WO2000079411A2 (en) | 2000-12-28 |
WO2000079411A8 WO2000079411A8 (en) | 2001-06-21 |
WO2000079411A3 WO2000079411A3 (en) | 2002-11-28 |
Family
ID=23319416
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/015676 WO2000079411A2 (en) | 1999-06-21 | 2000-06-07 | Method and apparatus for commercial transactions via the internet |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU5598800A (en) |
WO (1) | WO2000079411A2 (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001035354A2 (en) * | 1999-10-29 | 2001-05-17 | Sun Microsystems, Inc. | Universal smart card access system |
WO2004055744A1 (en) * | 2002-12-16 | 2004-07-01 | Giesecke & Devrient Gmbh | Communication between an operator device, a seller module and a customer module |
EP1550963A1 (en) * | 2002-06-06 | 2005-07-06 | Fujitsu Limited | Data communication mediation apparatus cooperating with purchaser mobile terminal |
WO2005119606A1 (en) | 2004-05-28 | 2005-12-15 | International Business Machines Corporation | Smart card data transaction system and methods for providing storage and transmission security |
US7380125B2 (en) | 2003-05-22 | 2008-05-27 | International Business Machines Corporation | Smart card data transaction system and methods for providing high levels of storage and transmission security |
FR2913551A1 (en) * | 2007-03-07 | 2008-09-12 | Cyrille Rigault | User authenticating method for use in Internet network, involves authenticating authentication server by token and vice versa for each of web pages requested by user, by executing control script e.g. java script, in computer |
EP2144441A1 (en) * | 2007-03-29 | 2010-01-13 | Sony Corporation | Advertisement server, user terminal, advertisement method, and advertisement viewing program |
US8014755B2 (en) | 2007-01-05 | 2011-09-06 | Macronix International Co., Ltd. | System and method of managing contactless payment transactions using a mobile communication device as a stored value device |
US8650124B2 (en) | 2009-12-28 | 2014-02-11 | Visa International Service Association | System and method for processing payment transaction receipts |
US8793156B2 (en) | 2003-08-29 | 2014-07-29 | Visa U.S.A. Inc. | Method and system for providing reward status |
CN104714890A (en) * | 2015-04-13 | 2015-06-17 | 东信和平科技股份有限公司 | Method and system for detecting intelligent card in cross-platform way |
EP1370962B1 (en) * | 2001-03-14 | 2016-05-04 | Nokia Technologies Oy | Separation of instant messaging user and client identities |
US10460338B2 (en) | 2002-09-13 | 2019-10-29 | Visa U.S.A. Inc. | Network centric loyalty system |
US11132691B2 (en) | 2009-12-16 | 2021-09-28 | Visa International Service Association | Merchant alerts incorporating receipt data |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104850878A (en) * | 2015-05-22 | 2015-08-19 | 东信和平科技股份有限公司 | Method and system for detecting smart card by using handheld device and handheld device |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1998005011A2 (en) * | 1996-07-31 | 1998-02-05 | Verifone, Inc. | A system, method and article of manufacture for secure, stored value transactions over an open communication network utilizing an extensible, flexible architecture |
WO1998049658A1 (en) * | 1997-04-30 | 1998-11-05 | Visa International Service Association | Internet payment and loading system using smart card |
-
2000
- 2000-06-07 WO PCT/US2000/015676 patent/WO2000079411A2/en active Application Filing
- 2000-06-07 AU AU55988/00A patent/AU5598800A/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1998005011A2 (en) * | 1996-07-31 | 1998-02-05 | Verifone, Inc. | A system, method and article of manufacture for secure, stored value transactions over an open communication network utilizing an extensible, flexible architecture |
WO1998049658A1 (en) * | 1997-04-30 | 1998-11-05 | Visa International Service Association | Internet payment and loading system using smart card |
Non-Patent Citations (1)
Title |
---|
GUTHERY: "JAVA CARD: Internet Computing on a Smart Card" IEEE INTERNET COMPUTING, IEEE SERVICE CENTER, PISCATAWAY, NJ, US, 1 February 1997 (1997-02-01), pages 57-59, XP002077647 ISSN: 1089-7801 * |
Cited By (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2001035354A3 (en) * | 1999-10-29 | 2002-01-17 | Sun Microsystems Inc | Universal smart card access system |
US6748532B1 (en) | 1999-10-29 | 2004-06-08 | Sun Microsystems, Inc. | Universal smart card access system |
WO2001035354A2 (en) * | 1999-10-29 | 2001-05-17 | Sun Microsystems, Inc. | Universal smart card access system |
EP1370962B1 (en) * | 2001-03-14 | 2016-05-04 | Nokia Technologies Oy | Separation of instant messaging user and client identities |
EP1550963A1 (en) * | 2002-06-06 | 2005-07-06 | Fujitsu Limited | Data communication mediation apparatus cooperating with purchaser mobile terminal |
EP1550963A4 (en) * | 2002-06-06 | 2006-05-03 | Fujitsu Ltd | Data communication mediation apparatus cooperating with purchaser mobile terminal |
US10460338B2 (en) | 2002-09-13 | 2019-10-29 | Visa U.S.A. Inc. | Network centric loyalty system |
WO2004055744A1 (en) * | 2002-12-16 | 2004-07-01 | Giesecke & Devrient Gmbh | Communication between an operator device, a seller module and a customer module |
DE10258769C5 (en) * | 2002-12-16 | 2017-08-17 | Giesecke & Devrient Gmbh | Communication between an operator panel, a vendor module and a customer module |
DE10258769B4 (en) | 2002-12-16 | 2012-05-31 | Giesecke & Devrient Gmbh | Communication between an operator panel, a vendor module and a customer module |
US7380125B2 (en) | 2003-05-22 | 2008-05-27 | International Business Machines Corporation | Smart card data transaction system and methods for providing high levels of storage and transmission security |
US8793156B2 (en) | 2003-08-29 | 2014-07-29 | Visa U.S.A. Inc. | Method and system for providing reward status |
WO2005119606A1 (en) | 2004-05-28 | 2005-12-15 | International Business Machines Corporation | Smart card data transaction system and methods for providing storage and transmission security |
CN1954345B (en) * | 2004-05-28 | 2012-11-21 | 国际商业机器公司 | Smart card data transaction system and method for providing storage and transmission security |
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 |
US8073424B2 (en) | 2007-01-05 | 2011-12-06 | Macronix International Co., Ltd. | System and method of managing contactless payment transactions using a mobile communication device as a stored value device |
US8275353B2 (en) | 2007-01-05 | 2012-09-25 | Macronix International Co., Ltd. | System and method of managing contactless payment transactions using a mobile communication device as a stored value device |
US8045956B2 (en) | 2007-01-05 | 2011-10-25 | Macronix International Co., Ltd. | System and method of managing contactless payment transactions using a mobile communication device as a stored value device |
US8014755B2 (en) | 2007-01-05 | 2011-09-06 | Macronix International Co., Ltd. | System and method of managing contactless payment transactions using a mobile communication device as a stored value device |
FR2913551A1 (en) * | 2007-03-07 | 2008-09-12 | Cyrille Rigault | User authenticating method for use in Internet network, involves authenticating authentication server by token and vice versa for each of web pages requested by user, by executing control script e.g. java script, in computer |
US8533046B2 (en) | 2007-03-29 | 2013-09-10 | Sony Corporation | Advertisement server, user terminal, advertisement method, and advertisement viewing program |
EP2144441A4 (en) * | 2007-03-29 | 2011-06-15 | Sony Corp | Advertisement server, user terminal, advertisement method, and advertisement viewing program |
EP2144441A1 (en) * | 2007-03-29 | 2010-01-13 | Sony Corporation | Advertisement server, user terminal, advertisement method, and advertisement viewing program |
US11132691B2 (en) | 2009-12-16 | 2021-09-28 | Visa International Service Association | Merchant alerts incorporating receipt data |
US8650124B2 (en) | 2009-12-28 | 2014-02-11 | Visa International Service Association | System and method for processing payment transaction receipts |
CN104714890A (en) * | 2015-04-13 | 2015-06-17 | 东信和平科技股份有限公司 | Method and system for detecting intelligent card in cross-platform way |
Also Published As
Publication number | Publication date |
---|---|
WO2000079411A3 (en) | 2002-11-28 |
WO2000079411A8 (en) | 2001-06-21 |
AU5598800A (en) | 2001-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1177654B1 (en) | Method and system for authenticating users | |
US7117364B1 (en) | System and method for downloading application components to a chipcard | |
US7343351B1 (en) | Methods and apparatus for conducting electronic transactions | |
EP1212732B1 (en) | Methods and apparatus for conducting electronic transactions | |
JP5638046B2 (en) | Method and system for authorizing purchases made on a computer network | |
US6061665A (en) | System, method and article of manufacture for dynamic negotiation of a network payment framework | |
WO2000079411A2 (en) | Method and apparatus for commercial transactions via the internet | |
US7698217B1 (en) | Masking private billing data by assigning other billing data to use in commerce with businesses | |
JP4512119B2 (en) | System and method for managing and completing transactions while protecting the privacy of user information | |
US6748532B1 (en) | Universal smart card access system | |
US20010039587A1 (en) | Method and apparatus for accessing devices on a network | |
Tygar et al. | WWW electronic commerce and Java Trojan horses | |
Thomsen et al. | Mobile agents-the new paradigm in computing | |
Zhang | Network Security Middleware Based on USB Key | |
Hoepman et al. | Secure method invocation in Jason | |
Hagimont et al. | JCCap: capability-based access control for Java Card | |
Lacey | Development of an E-commerce Site with Smartcard Payment Mechanism | |
Edition | Application Programming Notes | |
Brinkman et al. | Secure Method Invocation in {JASON} | |
Brinkman | JavaCards As Secure Objects Network | |
Martínez et al. | Application‐Oriented Middleware for E‐Commerce | |
Vogt et al. | Middleware for smart cards | |
Jang | Secure Object Sharing on Java Card | |
Asokan et al. | of Deliverable Deliverable D10 | |
Hunt et al. | Servlets: Serving Java up on the Web |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
AK | Designated states |
Kind code of ref document: C1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: C1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
CFP | Corrected version of a pamphlet front page | ||
CR1 | Correction of entry in section i | ||
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
AK | Designated states |
Kind code of ref document: A3 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A3 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
122 | Ep: pct application non-entry in european phase | ||
NENP | Non-entry into the national phase in: |
Ref country code: JP |