EP1360661A2 - Procede et dispositif de gestion d'un ou de plusieurs instruments de valeur - Google Patents

Procede et dispositif de gestion d'un ou de plusieurs instruments de valeur

Info

Publication number
EP1360661A2
EP1360661A2 EP01923025A EP01923025A EP1360661A2 EP 1360661 A2 EP1360661 A2 EP 1360661A2 EP 01923025 A EP01923025 A EP 01923025A EP 01923025 A EP01923025 A EP 01923025A EP 1360661 A2 EP1360661 A2 EP 1360661A2
Authority
EP
European Patent Office
Prior art keywords
user
value
ticket
transaction service
bearing instrument
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01923025A
Other languages
German (de)
English (en)
Inventor
Steve Atsushi Okamoto
Steven Miller Schattmaier
Tim Von Kaenel
Mike Todd Zeile
Frederick C. St. Amour
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
CMA Business Credit Services
Original Assignee
CMA Business Credit Services
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
Application filed by CMA Business Credit Services filed Critical CMA Business Credit Services
Publication of EP1360661A2 publication Critical patent/EP1360661A2/fr
Withdrawn legal-status Critical Current

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/02—Marketing; Price estimation or determination; Fundraising
    • 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/04—Payment circuits
    • 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/04—Payment circuits
    • G06Q20/045—Payment circuits using payment protocols involving tickets
    • 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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • 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/22—Payment schemes or models
    • G06Q20/29—Payment schemes or models characterised by micropayments
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/42—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for ticket printing or like apparatus, e.g. apparatus for dispensing of printed paper tickets or payment cards

Definitions

  • This invention relates to the field of computer software, and more particularly to a method and apparatus for generating a value-bearing instrument.
  • a value-bearing instrument is an item that has an intrinsic value and thereby represents a right to a valued item or service.
  • Examples of such value-bearing instruments include currency, coupons, tickets, gift certificates, money order, and traveler's checks.
  • a problem with value-bearing instruments is that it is inconvenient to transfer such instruments from one party to another. In most instances value-bearing instruments are exchanged via a physical transfer of the instrument itself. For example, a donor gives a gift certificate to a recipient by physically providing it to the recipient.
  • a system that allows users to transfer an authenticated version of a value-bearing instrument from one party to another without requiring that a physical version of the instrument be exchanged and/or forwarded to the recipient.
  • value-bearing instruments Most commercial transactions involve the use of value-bearing instruments.
  • a problem with such transactions is that current value-bearing instruments lack flexibility. For example, transferring a value-bearing instrument (e.g., a concert ticket) requires the holder of the instrument to physically send the value-bearing instrument to the recipient. If, after receipt, the value-bearing instrument is lost or destroyed the recipient has little recourse. In some instances, loss of the value-bearing instrument results in a permanent depravation of the right associated with the instrument.
  • a value-bearing instrument e.g., a concert ticket
  • Modern commerce lacks a secure and convenient form for creating, storing, and managing value-bearing instruments.
  • Current methods to reissue, transfer, resell, void, and verify value-bearing instruments are fraught with security and management problems.
  • Current systems for example, lack a method for regenerating and/or revoking authenticated copies of a value-bearing instrument. Additionally, such systems lack a method for managing the organization, assignment, and printing of such instruments. A user cannot, for example, print an authenticated version of a value-bearing instrument from a personal computer.
  • Computers and computer networks are used to exchange information in many fields such as media, commerce, and telecommunications, for example.
  • the exchange of information between computers typically occurs between a "server application” that provides information or services, and a "client application” or device that receives the provided information and services.
  • Multiple server applications are sometimes available on a "system server” such as a single computer server that provides services for multiple clients.
  • system server such as a single computer server that provides services for multiple clients.
  • distributed server systems allow a single client to obtain services from applications residing on multiple servers.
  • client applications are able to communicate with server applications executing on the same computer system or on another computer system accessible via a network, for instance via the Internet.
  • the Internet is a worldwide network of interconnected computers.
  • An Internet client computer accesses a computer on the network via an Internet provider.
  • An Internet provider is an organization that provides a client (computer) with access to the Internet (via analog telephone line or Integrated Services Digital Network line, for example).
  • a client can, for example, read information from, download a file from, or send an electronic mail message to another computer/client using the Internet.
  • To retrieve a file or service on the Internet a client must typically search for the file or service, make a connection to the computer on which the file or service is stored, and download the file or access the service.
  • Each of these steps may involve a separate application and access to multiple, dissimilar computer systems (e.g. Computer systems having operating different systems).
  • the World Wide Web (WWW) was developed to provide a simpler, more uniform means for accessing information on the Internet.
  • the components of the WWW include browser software, network links, servers, and WWW protocols.
  • the browser software, or browser is a tool for displaying a user-friendly interface (i.e., front-end) that simplifies user access to content (information and services) on the WWW.
  • Browsers use standard WWW protocols to access content on remote computers running WWW server processes.
  • a browser allows a user to communicate a request to a WWW server without having to use the more obscure addressing scheme of the underlying Internet.
  • a browser typically provides a graphical user interface (GUI) for displaying information and receiving input. Examples of browsers currently available include Netscape Navigator and Communicator, and Microsoft Internet Explorer.
  • GUI graphical user interface
  • the most common modern protocol is the TCP/IP (Transmission Control Protocol/Internet Protocol) protocol suite.
  • the protocols are based on the OSI (Open Systems Interconnect) seven-layered network communication model.
  • WWW messages are primarily encoded using Hypertext Transport Protocol (HTTP).
  • HTTP instantiates the (top) Application layer of the OSI model.
  • Application layer protocols facilitate remote access and resource sharing and are supported by the reliable communications ensured by the lower layers of the communications model. Therefore, HTTP simplifies remote access and resource sharing between clients and servers while providing reliable messaging on the WWW.
  • Information servers maintain the information on the WWW and are capable of processing client requests.
  • HTTP has communication methods that allow clients to request data from a server and send information to the server.
  • the client browser contacts the HTTP server and transmits the request to the HTTP server.
  • the request contains the communication method requested for the transaction (e.g., GET an object from the server or POST data to an object on the server).
  • the HTTP server responds to the client by sending a status of the request and the requested information. The connection is then terminated between the client and the HTTP server.
  • a client request therefore, consists of establishing a connection between the client and the HTTP server, performing the request, and terminating the connection.
  • the HTTP server typically does not retain any information about the request after the connection has been terminated. That is, a client can make several requests of an HTTP server, but each individual request is treated independent of any other request.
  • the WWW employs an addressing scheme is that uniquely identifies Internet resources (e.g., HTTP server, file, or program) to clients and servers.
  • This addressing scheme is called the Uniform Resource Locator (URL).
  • a URL represents the Internet address of a resource on the WWW.
  • the URL contains information about the protocol, Internet domain name and addressing port of the site on which the server is running. It also identifies the location of the resource in the file structure of the server.
  • HTTP provides a mechanism of associating a URL address with active text.
  • a browser generally displays active text as underlined and color-coded. When activated (by a mouse click, for example) the active text causes the browser to send a client request for a resource to the server indicated in the text's associated URL address.
  • This mechanism is called a hyperlink.
  • Hyperlinks provides the ability to create links within a document to move directly to other information.
  • a hyperlink can request information stored on the current server or information from a remote server.
  • the HTTP server locates the file and sends it to the client.
  • An HTTP server also has the ability to delegate work to gateway programs.
  • CGI Common Gateway Interface
  • a gateway program is referenced using a URL.
  • the HTTP server activates the program specified in the URL and uses CGI mechanisms to pass program data sent by the client to the gateway program.
  • Data is passed from the server to the gateway program via command-line arguments, standard input, or environment variables.
  • the gateway program processes the data and returns its response to the server using CGI (via standard output, for example).
  • the server forwards the data to the client using the HTTP.
  • web pages (referred to as "web pages").
  • the document encoding language used to define the format for display of a Web page is called Hypertext Markup Language (HTML).
  • HTML Hypertext Markup Language
  • a sever sends a Web page to a client in HTML format.
  • the browser program interprets the HTML and displays the Web page in a format based on the control tag information in the HTML.
  • Figure 1 illustrates the process utilized by one embodiment of the invention to generate a ticket and provide a ticket to a user.
  • FIG 2 generally illustrates the elements of the system as utilized by one embodiment of the invention.
  • Figure 3 shows one possible structure of a database utilized by one embodiment of the invention.
  • Figure 4a illustrates an example implementation of one embodiment of the invention.
  • Figure 4b illustrates the elements of a ticket as generated by one embodiment of the invention.
  • Figure 5 shows the how the elements utilized in one embodiment of the invention interconnect.
  • Figure 6 illustrates the process utilized by one embodiment of the invention to securely generate and print a ticket via a network connection.
  • Figure 7 illustrates the elements utilized by one embodiment of the invention to securely generate and print a ticket via a network connection.
  • Figure 8 illustrates how an embodiment of the invention can be implemented as computer software in the form of computer readable program code executed on one ore more general-purpose computers.
  • Figure 9 shows the sequence of events associated with an initial ticket reissue as performed in one embodiment of the invention.
  • Figure 10 illustrates how one embodiment of the invention enables the user to obtain a refund for a ticket.
  • Figure 11 is a flow diagram that shows how one embodiment of the invention provides a mechanism for forwarding a ticket to another party across a communication network.
  • Figure 12 is a flow diagram that shows how one embodiment of the invention provides a mechanism for forwarding a ticket to another party across a communication network after the ticket is acquired.
  • Figure 13 illustrates how one user can obtain a ticket acquired by another user.
  • One embodiment of the present invention comprises a method and apparatus for managing a value-bearing instrument.
  • the system provides transaction services that let users and vendors securely exchange funds and value-bearing instruments.
  • the present invention provides users the conveniences of electronic transactions, and provides the security of authenticated exchange of funds for goods or services.
  • Users of the invention may, among other options, electronically maintain funds on account, exchange purchases with a vendor or other party, auction purchases on the secondary market, restore a lost or destroyed item, create a transaction to be claimed in the future, or forward a purchase to another party.
  • the present invention provides vendors the ability to authenticate transactions the user has made with the invention. If the user generates a value-bearing instrument created with the invention, the vendor is able to interact with the invention to ensure that the generated instrument is authentic. Vendors may use the invention to, among other options, advertise additional goods and services, void transactions, give refunds, create a series of transactions with the user, or offer returned goods or services for resale.
  • the invention comprises a number of elements that could be physically distributed and connected through a network such as the public Internet or Virtual Private Networks. This invention does not define any requirements on the physical form of these connections except to require certain security requirements on the connections as described later in the invention. While certain interactions between these system elements are illustrated, this invention does not preclude other interactions between system elements.
  • the present invention is a method and apparatus for managing a value-bearing instrument.
  • numerous specific details are set forth to provide a more thorough description of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well known features have not been described in detail so as not to obscure the present invention.
  • system is used to refer to a device and/or a method for performing a function that embodies the invention.
  • an interconnection fabric comprises any of multiple suitable communication paths for carrying data between multiple computational devices.
  • the interconnect fabric may be, for example, a local area network implemented as an Ethernet network, a virtual private network, or any other type of interconnect cable of sending data from one device to another.
  • the interconnect fabric may be implemented with a physical medium such as a wire or fiber optic cable, or it may be implemented in a wireless environment.
  • value-bearing instruments comprise, for example, tickets, coupons, gift certificates, money orders, traveler's checks, and other forms of digital content having an intrinsic value.
  • value-bearing instruments may contain embedded data such as a document, music, videos, advertisements, and/or other types of digital information.
  • Figure 1 illustrates the process utilized by one embodiment of the invention to generate a ticket and provide a ticket to a user.
  • the process initiates at step 100 where the user visits a ticketing interface that contains an interface for selecting and purchasing an event ticket.
  • the user may access the ticket interface via a web browser, a kiosk, or any other mechanism that can display an appropriate interface to a user.
  • information associated with the ticket is stored on the ticket as indicium.
  • other embodiments of the invention may use other methods of storing or recording such information.
  • secure content will be used to describe a manifestation of a binary string which represents secure data associated with a value-bearing instrument.
  • the user's web browser is switched to a secure web page hosted by a Ticketing Services System (TSS).
  • TSS Ticketing Services System
  • the TSS provides a secure data tunnel between the TSS and the user's system via a network.
  • a Secure Transaction Service System provides security between the STSS, the Ticket Services System, and the user system.
  • the STSS can secure communications between the STSS and the Ticketing Services System by using a secure connection (e.g., 128 bit SSL). Connections between the STSS and the user system are also secure, but may utilize varying forms and/or strengths of security (e.g., differing levels of encryption). Information stored in the STSS is also electronically secure.
  • the hardware and software systems that comprise the STSS are physically protected in a vaulted facility.
  • the STSS maintains a digital certificate for each user that is protected by that user's unique id, password, and shared secret.
  • STSS supports the ability to associate the user with specific client hardware, and security rules related to the user's client hardware can be enforced.
  • the user Before a user is permitted to access the ticketing interface, the user typically registers with the system (e.g., the first time the user wishes to purchase a ticket). During registration, the user determines the user id, password, and shared secret stored in the STSS. Each subsequent use of the system requires input of the user's id and password. The system will check to see if the version presented by the user matches the version stored in the STSS.
  • the STSS validates the user's client hardware during the registration process and maintains a record of the hardware associated with a particular user.
  • other information associated with the user for example, the user's name, address, credit card or other identifying information is stored in a secure database as a user record.
  • Each user record is associated with a unique digital certificate assigned to the user.
  • the digital certificate is used to create a unique digital signature for each transaction and its associated value-bearing instrument, and therefore allows the ability to trace back each transaction to a certain user.
  • the invention records the unique digital signature generated from each user's unique digital certificate along with other ticket content and/or demographic information on the ticket in the form of a manifestation of a secure binary string of data that is representative of value bearing instrument, such as a two dimensional indicium.
  • the user may log in to the Ticketing Services System.
  • the secure data tunnels and other connections associated with the user's request for the ticket interface are established by the TSS during step 100.
  • the TSS presents a list of available tickets to the user.
  • the list may be customized to present certain types of lists and may contain graphical representations of each item in the list.
  • the TSS may present the user with a list of events that will occur during the month of March.
  • the invention contemplates generating lists based on preferences specified by the user and/or preferences derived from data about the user.
  • the TSS obtains purchase information from the user and determines whether the information presented is valid. If, for example, the user presents a credit card, the system verifies the credit card information and obtains an approval code. The system verifies the purchase information, then transmits confirmation data to the user (e.g., step 106) and displays a list of delivery options (e.g., step 108).
  • the delivery options the system presents comprises a mail option, a reserve option, and a generate-now option.
  • the invention also contemplates other options such as delivery to an electronic device (e.g., a cell phone or PDA). The user may select a delivery preference and the system will provide the selected item
  • the ticket (e.g., the ticket) via the preferred method.
  • the ticketing service system through a secure data connection, passes the ticket content to the STSS.
  • a physical and digital version of the ticket is generated by the STSS.
  • the ticket comprises secure content that contains a digital signature and/or any other information requested or required by the ticket service system.
  • the secure ticket content comprises information that relates to the transaction being performed.
  • the ticket may contain a seating assignment, an event date, a customer name, and/or any other type of information the ticket producer wishes to include.
  • An embodiment of the invention contemplates sale and/or use of available space on the ticket.
  • the providing entity may incorporate advertisements, coupons, and maps on the ticket or on any other type of value-bearing instrument.
  • the ticket may also comprise information associated with the utilization of pre-paid services and/or information related to the acquisition of products, merchandise, and/or services.
  • the ticket comprises a product itself (e.g., if the ticket/value-bearing instrument is a form of currency, a secured instrument, or a stock certificate).
  • the ticketing service system is designed to specify to the STSS which data elements will appear on the ticket as human readable text and which data elements are represented as machine readable secure content.
  • the user selects, via the TSS, a delivery method after generating a ticket.
  • the system determines if the user elected to have the ticket delivered via mail. If so, step 112 executes and the ticket is delivered via mail.
  • the term mail comprises an electronic mail and/or delivery via a postal system such as the U.S. Postal System. If the user did not pick delivery via mail, step 114 executes and the system determines if the user selected the reserve option. If the user selected the reserve option, the system executes step 116, where it provides the ticket and/or the ticket data to a reservation system. The intended recipient of the ticket may acquire the ticket by obtaining it from the reservation system.
  • the ticket is delivered to the reservation system electronically and may be obtained from the system when the intended recipient requests delivery of it.
  • the STSS determines whether the user selected the generate-now option (e.g., step 118).
  • the generate-now option provides the user with a mechanism for generating the selected item (e.g., printing a ticket directly to the user's personal printer.) If the generate-now command is not selected, the TSS continues to display the list of delivery options, until the user chooses one. If the user does not select a delivery option, but instead exits the program, the STSS may use a default delivery option. If, however, the user does select the generate-now option then steps 120 and 122 execute.
  • the STSS transmits the ticket data to the user's computer via a network. Once the ticket data resides on the user's computer, it is output to a printer.
  • the invention may also transmit a value-bearing instrument to other types of devices, such as a PDA or cell phone.
  • FIG. 2 illustrates generally the elements of the system (shown as boxes with thick borders) as utilized by one embodiment of the invention.
  • the system comprises STSS 200, user system 202, ticketing services system 204, and ticket verifier system 206.
  • Functional elements associated with the system elements are shown as boxes with thin lines.
  • the connections between the system elements show possible logical connections between the system elements although in some instances other logical connections may exist.
  • the system elements are assumed secure, and communication between the system elements is achieved through a secure communications channel that mutually authenticates the parties (e.g., SSL or some other secure protocol suite).
  • SSL Secure Sockets Layer Security
  • These system elements may be physically distributed and connected through a network such as the public Internet, a virtual private network, or any other interconnection fabric configured to allow computers to send and receive data.
  • STSS 200 is configured to issue and distribute one or more tickets 208.
  • Each ticket 208 comprises a machine-readable portion and a human readable portion. The machine-readable portion allows ticket 208 to be uniquely identified.
  • STSS 200 is also responsible for securely maintaining transaction records for transactions performed on the ticket.
  • STSS comprises a transaction server 222 and numerous databases configured to support the system.
  • STSS 200 may contain, for example, a user membership database 212, a transaction and ticket database 214, an account database 216, a ticketing services database 218, and a ticket verifier database 220.
  • a secure ticket generator 226, a ticket formatter 228, and an ad server 224 may also be integrated into STSS 200.
  • transaction server 222 interfaces with transaction logic module 230.
  • Transaction logic module 230 is configured to obtain business rules from business rules module 232.
  • STSS 200 also comprises auditing and reporting server 234 as well as billing and payment processing server 236.
  • transaction server 222 provides the external interface with user system 202, ticketing services system 204, and ticket verifier system 206 so that each of these systems can request various ticketing transactions.
  • the communication channel between transaction server 222 and these other system elements is assumed to be secure and mutually authenticated.
  • Transaction server 222 is configured to dispatch transaction requests (e.g., a request for a ticket) to transaction logic module 230.
  • Transaction logic module 230 is configured to carry out the transactions associated with obtaining, generating, and/or verifying tickets. Transaction logic module 230 ensures that the transactions performed on the ticket are carried out to completion and that the appropriate databases are updated. As such, transaction logic module 230 coordinates the activities of other components that participate in execution of the transaction. In one embodiment of the invention, transaction logic module 230 is independent of a particular ticketing application. For example, transaction logic module 230 typically obtains application- specific instructions from business rules module 232.
  • Business rules module 232 enables the system to support a wide variety of ticketing applications. For example, event ticketing, coupon generation, or airline ticketing can all be considered different ticketing applications. As such, these different ticketing applications may require different actions to be taken by the system for a particular transaction.
  • business rules module 232 may, for example, determine the application associated with the transaction and provide instructions to perform various application-specific actions that are to be performed by transaction logic module 230.
  • Business rules module 232 is a logical extension to transaction logic module 230. While transaction logic module 230 is generic and independent of specific ticketing application, business rules module 232 is capable of translating application specific semantics into generic form that transaction logic module 230 understands.
  • Business rules module 232 is capable of storing the logic associated with many different types of business transactions. Each set of logic has a unique identifier that can be used to specify the particular business rules to apply to the transaction being processed.
  • the application specific business rules are input into business rules module 232 using a language capable of expressing the semantics of the business rules. Business rules module 232 can potentially support several such semantic languages.
  • Secure ticket generator 226 is configured to generate a ticket formatted for a specified ticket output apparatus.
  • the ticket comprises secure content that can uniquely identify the ticket.
  • Secure ticket generator 226 passes the ticket to ticket formatter 228, which in turn generates the formatted ticket for the ticket output apparatus (e.g., a printer).
  • Ticket formatter 228 component enables the system to control the placement of different content on the physical form of the ticket.
  • a printed ticket comprises secure content, ticket information, advertisements, secure content for merchandise at a venue, and directions to the venue.
  • Ticket formatter 228 is capable of storing many different formatting rules. Each has a unique identifier that can be used to specify the particular formatting rules to apply for a given ticket.
  • the format rules and constraints are input into ticket formatter 228 using a language capable of expressing the semantics of the formatting rules.
  • Ticket formatter 228 can potentially support several such semantic languages.
  • Ad server 224 interacts with ticket formatter 228 to provide advertisement content for the ticket.
  • Ad server 224 can provide different ad content depending on the user or the particular venue that the ticket is intended for.
  • the ad content rules and constrains are input into ticket formatter 228 using a language capable of expressing the semantics for ad selection.
  • Ad server 224 can potentially support several such semantic languages.
  • Transaction and ticket database 214 is a secure database that keeps track of issued tickets and the state of the ticket. It also keeps track of all transactions performed on the ticket. There are several logical records in the database.
  • Item record 300 in one embodiment of the invention, resides in transaction database 214 and represents each unique good and service tracked by STSS 200.
  • Each item record 300 may, for example, comprise the following information:
  • Item ID A unique identification of the item (i.e., goods or services) generated by STSS 200.
  • Account The account that is the current owner of the item.
  • Item State The state of the item.
  • Item Group Data provided by the TSS 204 to group like-items. Can be used to alter a group of records.
  • Item Data Other data provided by the TSS 204 about the item.
  • Start Date The date from which the invention assumes the item is valid.
  • Expiration date The date on which the item and the associated ticket must be automatically deleted by the system.
  • Each ticket record 302 may, for example, comprise the following information:
  • Ticket ID A unique identification of the ticket.
  • TSS Ticket Content The content of the ticket that Ticketing Service System 204 provided.
  • TSS Transaction Information The content of the transaction provided by Ticketing Service System 204.
  • Ticket Output Format The output format of the ticket.
  • Transaction Record 304 is created for each transaction issued by user system 202 or ticketing services system 206. Transaction record 304 may therefore be used for auditing, billing purposes as well as for recovery purposes. Each transaction record 304 may, for example, comprise the following: • Transaction ID: A unique identification of the transaction. • Transaction Type: The type of the transaction that was requested
  • Transaction State The state of the transaction e.g., pending, completed
  • Target Ticket Ticket ID for which the transaction is intended.
  • Source Ticket Ticket ID for the source ticket if multiple tickets are involved in the transaction.
  • Transfer Authorization Record 306 is created by one embodiment of the invention whenever a ticket is in the process of being transferred.
  • Transfer authorization 306 may, for example, comprise:
  • Transfer Authorization Information used to authorize the ticket transfer.
  • Transfer Authorization Method Indicates the particular method of authorization for transferring the ticket.
  • Accounting database 216 comprises a secure database configured to keep track of funds on behalf of the users for the purchase/refund of tickets, services, and merchandise. A user can be associated with several accounts with funds. The database also contains user- specific authentication data that enables the system to sign ticket content on behalf of the user. A unique digital certificate is generated for the user at the time of membership registration and stored into accounting database 216.
  • User membership database 212 keeps track of the users that have registered with the system.
  • User membership database 212 typically contains general information about the user. Fields include, for example: unique user ID, user name, password, shared secret, email address, last user system (i.e., the id of the user system that was used last), and any other fields the entity generating the database wished to collect.
  • Ticketing services database 218 is configured to keep track of registered ticketing services.
  • the database stores general information as well as authentication data to enable authenticated and secure communication between STSS and the ticketing services system 204.
  • the fields of the database comprise, for example, the unique id of TSS 204, TSS 204 authentication data, email address of TSS 204, postal mailing address of TSS 204, and any other fields the entity generating the database wished to collect.
  • Ticket verifier database 220 keeps track of registered ticket verifier systems 206 by storing general information about each ticket verifier as well as authentication data to enable authenticated and secure communication between STSS 200 and ticket verifier system 206.
  • the fields of the database may comprise, for example, the unique id of the verifier, verifier authentication data, email of the venue (if applicable), venue address, and any other fields the entity generating the database wished to collect.
  • Auditing and reporting server 234 enables external systems to generate auditing and other general reports about transactions that occur on the system.
  • the client computer that communicates with the auditing and reporting server 234 of the server is, in one embodiment of the invention, an authenticated system. This precaution is intended to prevent unauthorized access to the data.
  • Billing and payment server 236 interfaces with the external billing and payment services to enable financial transactions to take place (e.g. credit card companies and/or banks).
  • the client that communicates with the billing and payment server may be an authenticated system.
  • Customer support server 210 interfaces with the internal customer support systems to enable access to data and modification thereof on behalf of customers.
  • the client that communicates with customer support server 210 may also be an authenticated system.
  • Ticketing services system 204 is an agent of the vendor who provides items of value that can be redeemed using a valid ticket.
  • ticketing services system 204 is capable of controlling ticket output apparatus 240. This is the case where ticketing services system 204 itself prints and distributes "secure" tickets with unique secure content added to the standard printed output. However, other systems (e.g., user system 202) may also transmit output to ticket output apparatus 240.
  • Item database 242 optionally keeps track of goods, services and other items of value that the ticket can be redeemed for.
  • Ticketing service system 204 typically maintains the database.
  • User system 202 provides user interface 244 that enables the user to perform various transactions associated with tickets such as issuing ticket 208. As such, it provides a mechanism for communicating with other system elements in carrying out the requested transactions. It also is capable of controlling ticket output apparatus 240 in the case where a physical form of the ticket needs to be generated (e.g. by printing ticket 208).
  • User system 202 can be a PC with a Web browser and a printer. User system 202 can also be a mobile phone, personal digital assistant, smart card, or any other computer system configured to interface with STSS 200.
  • Ticket verifier system 206 typically resides at the location where the ticket is redeemed for goods and services. It has the capability to read the ticket information and, in some embodiments, to contact the STSS 200 to verify the validity of ticket 208. Ticket verifier system 206 is also capable of receiving the results of the ticket verification from transaction server 222, and take appropriate action based on the returned results.
  • ticket verifier system 206 may provide a user interface to the operator to display appropriate message to the operator.
  • the component may also provide the interface to devices such as a gate or turnstile to control entry into a venue.
  • Ticket output apparatus 240 creates the physical form of the ticket.
  • a printer is a ticket output apparatus 240 for printing ticket, and/or any other value-bearing instrument, from a computer such as a PC.
  • a smart card programming device could also be a ticket output apparatus 240.
  • Ticket input apparatus 246 reads the physical form of the ticket.
  • a scanner may act as ticket input apparatus 246 for printed tickets.
  • a smart card reader may also be configured to acts as ticket input apparatus 246.
  • Figure 4A illustrates an example implementation of one embodiment of the invention.
  • the system comprises multiple user systems 400, ticketing services system 408 and ticket verifier system 402. Each system is configured to interact with one another.
  • user system 400 may be a browser that is connected with the ticketing services system 408 and STSS 404.
  • STSS 404 may download a plugin into user system 400 in order to provide additional security beyond what is available through the browser. This plugin can establish a secure connection to STSS 404.
  • User system 400 interacts with ticketing services system 408 to reserve or purchase something of value through a computer network such as the Internet. User system 400 then communicates with STSS 404 to obtain ticket 418 and may use ticket output apparatus 442 to reduce ticket 418 to a tangible form. At the location where ticket 418 is redeemed, ticket input apparatus 420 reads the ticket. Ticket verifier system 402 communicates with STSS 404 to verify ticket 418.
  • STSS 404 comprises a plurality of elements each configured to add functionality to the system.
  • STSS 404 may comprise the following elements: auditing and reporting element 422, secure ticket generator 424, ad server 426, customer support server 428, business rule module 430, billing and payment server 432, ticket formatter 434, transaction server 414, transaction logic module 436, transaction and ticket database 438, user membership database 410, account database 412, ticketing services database 406, and ticket verifier database 440.
  • Figure 5 shows how one embodiment of the invention interconnects.
  • STSS 500, ticket verifier system 502, and ticketing services system 504 do not connect to one another through Internet 506.
  • ticket 514 is a tangible representation of the ticket created by interfacing with ticketing services system 504. Ticket 514 may be verified by scanning the ticket with scanner 516. Scanner 516 communicates with ticket verifier system 502 to determine if the ticket is authentic (e.g., by verifying the digital signature associated with the ticket).
  • One embodiment of the invention comprises one or more data objects.
  • token is used in its broadest sense, to indicate an element of data that may be comprised of one or more sub-elements.
  • TSS confirmation token is an object that uniquely identifies the goods or services that the user has reserved or purchased.
  • the TSS confirmation token and detailed information about the transaction may be stored into the ticketing services database 406.
  • the token can be a simple number, or some other digital form of information.
  • TSS ticket content (TTC) 452 (see e.g., figure 4B) is an object comprising ticketing services system 408 specific information that will be recorded on a ticket. Ticketing services system 408 and ticket verifier system 402 can interpret the content and act on the information. TSS ticket content objects fit into the ticket.
  • TSS transaction information is an object comprising the data supplied by ticketing services system 408 that are be interpreted by and acted upon STSS 404.
  • the data comprises:
  • Verifier ID One or more verifiers that can verify the ticket.
  • Item Data Data to store into the Item Record. For example, Start Date, Expiration Date, Purge Date, Item Group.
  • Transaction system ticket content (TSTC) 450 object comprises content put into the ticket that is specific to STSS 404.
  • the information may include, but is not limited to: Secure Content version number Digital Signature Algorithm
  • STSS ID Uniquely identifies the transaction system that issued the ticket. It may be used in cases where there are multiple transaction systems on the network.
  • User ID Identifies the user of the ticket.
  • TSS ID ID of the TSS that supplied the ticket.
  • Item ID The item to which the ticket is issued for.
  • Verifier ID The verifier of the ticket
  • Start Date Expiration Date Secure Content (SC) 454 object comprises the signed digital content of the secure content that is to be put into the ticket.
  • Secure content may contain the following content: TSTC + TTC+ SIGu (TSTC+TTC) I S sTss (TSTC+TTC+SIGu (TSTC+TTC)). Where the + indicates concatenation operation and
  • S Y (X) represents the output of a digital signature function where message X is signed by entity Y.
  • U refers to the user and STSS refers to STSS 404.
  • Secure content typically indicates which digital signature algorithm is used.
  • DSS Digital Signature Standard
  • Elliptic Curve Digital Signature Algorithm Elliptic Curve Digital Signature Algorithm
  • ticket secure content may take on the form of printable symbologies such as a 2-D barcode.
  • the ticket is formatted to support the particular ticket output format that is to be used.
  • the format typically comprises a ticket secure content and may include additional information requested by TSS 204.
  • TSS 204 may request that an advertisement be included in the printed form of the ticket.
  • Each user establishes a trusted relationship with ticketing service system 408 and STSS 404 in order to participate in various ticketing transactions. In one embodiment of the invention, the user accomplishes this by registering with ticketing service system 408 and STSS 404.
  • User system 400 may authenticate the user before it can participate in any transaction on behalf of the user. If the user has an account in user membership database 410, user system 400 provides the user's authentication data to STSS 404 in order to establish the identity of the user.
  • the authentication data could be, for example, a user name and password. If the user does not have an account, the user may register with STSS 404 to create one. The system will guide the user through the registration process.
  • STSS 404 may request user system 400 to provide registration info and unique authentication data.
  • the authentication data may include a unique user name, password and shared secret.
  • a unique digital certificate is generated for the user, and an account (i.e., an entry) is created in the account database 412. Following registration, the user logs in and proceeds with the transaction.
  • STSS 404 may elect to store the identification of the user system 400 that last accessed the user account in user membership database 410. If transaction server 414 detects that user system 400 is different from the one used last, the system will warn the user if the user account indicates that the user wants such a warning.
  • a software module may be downloaded into user system to facilitate future secure connection with STSS 404.
  • a software module may be downloaded into user system to facilitate future secure connection with STSS 404.
  • user system 400 is a browser
  • a plugin may be downloaded into the browser.
  • the invention in one or more embodiments, provides the user a mechanism to generate an initial value-bearing instrument.
  • Figure 6 illustrates the process utilized by one embodiment of the invention, where for example the user uses the invention to securely generate and print a ticket via an interconnection fabric.
  • the sequence of events associated with the initial ticket issuance begins at step 600 where user system 700, on behalf of the user, interacts with ticketing services system 704 to purchase or reserve certain goods or services. (See figure 7.)
  • step 603 executes and ticketing services system 704 returns a JSS confirmation token and TSS identification for the transaction that occurred between the user and ticketing services system 704.
  • a TSS confirmation token uniquely identifies an item that the user has reserved or purchased. Typically, the item is stored in an item database associated with ticketing services system 704.
  • This TSS confirmation token and detailed information about the transaction is stored into a ticketing services database 406.
  • the token can be formatted as a simple number, or some other structured, digital form of information.
  • user system 700 establishes a secure connection to the STSS, and the two systems are mutually authenticated.
  • step 607 executes and user system 700 provides the user authentication information to STSS 702.
  • STSS 702 authenticates the user.
  • the authentication information could be a user name and a password.
  • step 609 executes and user system 700 transmits a request for a ticket to STSS 702.
  • user system 700 may send a message to STSS 702 requesting that a ticket be issued for the transaction that the user had with ticketing services system 704.
  • the TSS confirmation token is typically provided with the message.
  • the output format of the ticket the user wants may also be indicated.
  • the output format for example, can be a print-ready format appropriate for a printer. It could also be an output format appropriate for a smart card or personal digital appliance.
  • STSS 702 and ticketing services system 704 connect and exchange ticket information.
  • STSS 702 may send a message to ticketing services system 704 requesting information about ticketing services system 704's transaction identified by the confirmation token. While the scenario described here assumes that the information is pulled from ticketing services system 704, ticketing services system 704 may be configured to push the information onto STSS 702. Continuing at step 611, ticketing services system 704 returns the requested information.
  • the information may comprise, but is not limited to:
  • TTC TSS Ticket Content
  • TSS Transaction Information The information that is required by and interpreted by STSS 704.
  • STSS 702's transaction logic module performs the requested transaction and generates a ticket.
  • a ticket generator creates a unique secure content with the digital signature of the user and the digital signature of the STSS.
  • Ticket secure content appropriate for the specified ticket output format, is created.
  • a ticket output format is created using a ticket formatter. The ticket output format is dependent on the ticket output format.
  • a ticket output format may comprise visible data indicated by ticketing services system 704 to be included in the ticket. It could also include advertisement information.
  • Once the ticket is generated the ticket is returned to user system 700 and the transaction and ticket database is updated appropriately.
  • user system 700 outputs ticket 706 using ticket output apparatus 708. Note that ticketing services system 704 can also output ticket 706 directly.
  • Ticketing services system 204 communicates with STSS 200 to provide the formatting rules to ticket formatter 228.
  • the format rules and constraints are input into ticket formatter 228 using a language that expresses the semantics of the formatting rules.
  • Ticket formatter 228 can potentially support several such semantic languages.
  • Ticket formatter 228 also may include a database that contains additional information (e.g., maps).
  • Ad server 224 is also populated with different advertisement information. Ticketing service and item (e.g., venue) specific rules and constraints that specify the advertisement content are supplied.
  • transaction logic module 230 instructs secure ticket generator 226 to generate ticket 208.
  • Secure ticket generator 226 in turn instructs ticket formatter 228 to format the ticket based on the information supplied to it.
  • Ad server 224 interacts with ticket formatter 228 to provide advertisement content for ticket 208.
  • ad server 224 can provide different advertisement content depending on the user or the particular venue that the ticket is intended for.
  • Ad server 224 may also provide data that relates to pre-paid services and/or products.
  • a lost or destroyed value-bearing instrument may be reissued.
  • the value-bearing instrument re-issuing process enables the user to obtain another copy of the original instrument.
  • the user can optionally request that the format of the re-issued instrument be changed.
  • the user can, for example, change the format from printed ticket to a ticket stored on a smart card.
  • the sequence of events associated with the example of an embodiment of the invention which reissues tickets is illustrated in Figure 9.
  • user system 202 establishes a connection to STSS 200, and the two systems are mutually authenticated.
  • User system202 provides the user authentication information to STSS 200.
  • STSS 200 authenticates the user (e.g., step 902).
  • the authentication information could be, for example, a user name and a password.
  • user system 202 transmits a message to STSS 200 to request that a ticket be reissued.
  • the message may request that the ticket be issued in the same format as the original or in a different format.
  • step 904 executes, the invention proceeds to step 906 where STSS 200 sends a message requesting user system 202 to provide a unique identifier such as a ticket ID.
  • the ticket ID identified the ticket that is to be re-issued.
  • step 908 executes.
  • STSS 200 issues the new ticket.
  • ticket generator 226 creates a new unique secure content with the signature of the user and the signature of STSS 200.
  • Step 908 comprises creating a ticket secure content that is appropriate for the specified ticket output format.
  • a ticket output format is also created using ticket formatter 228.
  • the ticket output format is dependent on the ticket output format.
  • a ticket output format may include visible data that ticketing services system 204 indicates should be included. It may also include advertisement information.
  • ticketing services system 204 is contacted and informed of the transaction.
  • the ticket is provided to user system 202 and transaction and ticket database 214 is updated appropriately.
  • the status of the original ticket is flagged in transaction and ticket database 214.
  • user system 202 outputs a reissued ticket 208 using ticket output apparatus 240.
  • the system may invalidate the original ticket.
  • Ticketing services system 204 can also output ticket 208 directly, via ticket output apparatus 240.
  • E. Exchange of a Value-Bearing Instrument (For example, the exchange of a printed ticket with the originating entity over the Internet)
  • a user has the ability to exchange one value-bearing instrument for another with the original content provider.
  • a printed ticket may be exchanged with the originating entity via a network connection such as the Internet.
  • the exchange process involves a two step process involves returning the ticket and then issuing a new ticket if requested.
  • Figure 10 illustrates how one embodiment of the invention enables the user to obtain a refund for a ticket.
  • the sequence of events begins at step 1000 where user system 202 establishes a connection to STSS 200, and the two systems are mutually authenticated.
  • user system 202 provides the user authentication information to STSS 200.
  • STSS 200 authenticates the user.
  • the authentication information could be a user name and a password.
  • user system 202 sends a refund request to STSS 200. For example, user system send a message to STSS 200 to request that the cost of the ticket, minus some content provider specified transaction fee, be refunded to the user.
  • STSS 200 verifies if the user is allowed to perform this transaction.
  • STSS 200 sends a message requesting user system 202 to provide a unique identifier such as a ticket ID.
  • STSS 200 verifies the validity of the unique id.
  • step 1008 executes and thereby STSS 200 updates transaction and ticket database 438 to reflect the request.
  • ticketing services system 204 is informed of the transaction, the appropriate financial transactions are carried out, and the original ticket record in STSS 200 is flagged so that the ticket cannot be used.
  • STSS 200 connects and exchanges information with TSS 204 to make a ticket available for resale or reissue.
  • the invention determines if the user wants to exchange the ticket for another ticket. If the user does not wish to obtain another ticket step 1012 executes and the system exits after having invalidated the ticket, and notified the TSS. If, however, the user does wish to conduct and exchange step 1014 executes. Step 1014 enables the user to exchange the ticket that he/she currently owns with a new ticket (e.g., for a better seat.)
  • Ticketing services system 204 is configured to reconcile any billing issues with the user. The exchange is a two step process involving the returning of the original ticket and issuing a new ticket.
  • the user can transfer a value- bearing instrument to another user.
  • the purchaser of a ticket may forward the ticket to another person over the Internet.
  • the invention provides a mechanism that enables the user to transfer ownership of a value-bearing instrument to another user. This can happen in two scenarios. In the first scenario, the user indicates a desire to forward the ticket when he first purchases or reserves the ticket. In the second scenario, the ticket already exists and the user decides to transfer ownership to another party.
  • Figure 11 is a flow diagram that shows how one embodiment of the invention provides a mechanism for forwarding a ticket to another party across a communication network.
  • user system 202 sends a message to STSS 200 to request that a ticket be issued as forwardable.
  • user system 202 interacts with ticketing services system 204 to purchase or reserve certain goods or services (e.g., select a ticket).
  • ticketing services system 204 returns a TSS confirmation token and TSS identification for the transaction that occurred between the user and ticketing services 204.
  • TSS confirmation token uniquely identifies the goods or services that the user has reserved or purchased.
  • the item is stored in the item database.
  • This TSS confirmation token and detailed information about the transaction is stored into ticketing services database 218.
  • the token can be a simple number, or some other digital form of information.
  • user system 202 establishes a connection to STSS 200, and the two systems are mutually authenticated.
  • user system 202 provides the user authentication information to STSS 200.
  • STSS 200 authenticates the user.
  • the authentication information could be a user name and a password
  • the TSS confirmation token is provided with the message.
  • STSS 200 sends a message requesting user system 202 to provide the transfer authorization to be used by the new user obtain the ticket.
  • user system 202 provides the transfer authorization specified by the user. Note:
  • Steps 1108 and 1110 can be eliminated if secure transaction services system 200 assigns the transfer authorization itself.
  • STSS 200 establishes a connection with ticketing services 204, and the two systems are mutually authenticated. Once this occurs step 1114 executes and STSS 200 sends a message to ticketing services 204 requesting information about the content provider's transaction identified by the confirmation token.
  • ticketing services system 204 returns the requested information.
  • the information comprises, but is not limited to:
  • TSS User Information (TUI)
  • TTC TSS Ticket Content
  • TTI TSS Transaction Information
  • transaction logic module 230 of STSS 200 updates transaction and ticket database 214 to reflect the fact that a ticket is pending for the user who is assigned to the ticket.
  • FIG 12 is a flow diagram that shows how one embodiment of the invention provides a mechanism for forwarding a ticket to another party across a communication network after the ticket is issued.
  • the sequence of events in this case is given below.
  • the process begins at step 1200, where user system 202 establishes a connection to the STSS 200, and the two systems are mutually authenticated.
  • User system 202 provides the user authentication information to STSS 200.
  • STSS 200 authenticates the user.
  • the authentication information could be a user name and a password (e.g., step 1202).
  • user system 202 sends a message to STSS 200 to request that a ticket be issued as a forwardable ticket.
  • STSS 200 sends a message requesting the user system 202 to provide the ticket ID to be used to identify the transaction and the transfer authorization to be used by the new user to obtain the ticket.
  • the transfer authorization is not needed if the secure transaction services system 200 assigns the transfer authorization itself.
  • user system 202 returns the ticket ID and the transfer authorization.
  • the transfer authorization is not required if secure transaction services system 200 assigns the transfer authorization itself.
  • the transaction logic module 230 of STSS 200 updates transaction and ticket database 214 appropriately.
  • Transaction and ticket database 214 is updated to reflect the fact that a ticket is pending for the user who is assigned to the ticket.
  • Step 1208 may also contact ticketing services system 204 and informs it of the transaction.
  • the original ticket record is flagged in the transaction and ticket database to prevent further use.
  • Figure 13 illustrates how one user can obtain a ticket acquired or purchased by another user.
  • the original user gives the transfer authorization to the new user.
  • the following sequence of events describes how the new user gets the ticket issued.
  • the process beings at step 1311, where the original user gives a transfer token to the new user.
  • the new user requests a pending ticket.
  • user system 202 for the new user establishes a connection to STSS 200, and the two systems are mutually authenticated.
  • user system 202 provides the user authentication information to STSS 200.
  • STSS 200 authenticates the user.
  • the authentication information could be a user name and a password.
  • user system 202 sends a message to STSS 200 to request that a ticket be issued to the new user.
  • the output format of the ticket the user wants is also indicated.
  • the output format for example, can be a print-ready format appropriate for a printer. It could also be an output format appropriate for a smart card or personal digital appliance.
  • STSS 200 sends a message requesting user system 202 to provide the transfer authorization to be used to obtain the ticket.
  • transaction logic module 230 of STSS 200 verifies the transfer authorization and issues the new ticket.
  • STSS 200 may contact ticketing services 204 to obtain new TSS ticket content and TSS transaction information to be put into the ticket. This is optional in that ticketing services system 204 may not require this step.
  • Ticket generator 226 in configured to create a unique secure content for the new using an appropriate ticket output format.
  • a ticket output format may include visible data indicated by ticketing services 204 to be included in the ticket. It could also include advertisement information in the case of printed tickets.
  • step 1310 executes and new user system 202 outputs the ticket using ticket output apparatus 240.
  • the ticket can also be output by ticketing services 204 directly via ticket output apparatus 240.
  • An embodiment of the invention can be implemented as computer software in the form of computer readable program code executed on one or more general-purpose computers such as the computer 800 illustrated in Figure 8.
  • a keyboard 810 and mouse 811 are coupled to a bi-directional system bus 818 (e.g., PCI, ISA or other similar architecture).
  • the keyboard and mouse are for introducing user input to the computer system and communicating that user input to central processing unit (CPU) 813.
  • CPU central processing unit
  • I/O (input/output) unit 819 coupled to bi-directional system bus 818 represents possible output devices such as a printer or an A/V (audio/video) device.
  • Computer 800 includes video memory 814, main memory 815, mass storage 812, and communication interface 820. All these devices are coupled to the bi-directional system bus 818 along with keyboard 810, mouse 811 and CPU 813.
  • the mass storage 812 may include both fixed and removable media, such as magnetic, optical or magnetic optical storage systems or any other available mass storage technology.
  • the system bus 818 provides a means for addressing video memory 814 or main memory 815.
  • the system bus 818 also provides a mechanism for the CPU to transferring data between and among the components, such as main memory 815, video memory 814 and mass storage 812.
  • the CPU 813 is a microprocessor manufactured by Motorola, such as the 680X0 processor, an Intel Pentium III processor, or an UltraSparc processor from Sun Microsystems. However, any other suitable processor or computer may be utilized.
  • Video memory 814 is a dual-ported video random access memory. One port of the video memory 814 is coupled to video accelerator 816.
  • the video accelerator device 816 is used to drive a CRT (cathode ray tube), and LCD (Liquid Crystal Display), or TFT (Thin- Film Transistor) monitor 817.
  • the video accelerator 816 is well known in the art and may be implemented by any suitable apparatus. This circuitry converts pixel data stored in video memory 814 to a signal suitable for use by monitor 817.
  • the monitor 817 is a type of monitor suitable for displaying graphic images.
  • the computer 800 may also include a communication interface 820 coupled to the system bus 818.
  • the communication interface 820 provides a two-way data communication coupling via a network link 821 to a network 822.
  • the communication interface 820 is a modem
  • the communication interface 820 provides a data communication connection to a corresponding type of telephone line, which comprises part of a network link 821.
  • the communication interface 820 is a Network Interface Card (NIC)
  • NIC Network Interface Card
  • Physical network links can include Ethernet, wireless, fiber optic, and cable television type links.
  • communication interface 820 sends and receives electrical, electromagnetic or optical signals which carry digital data streams representing various types of information.
  • the network link 821 typically provides data communication through one or more networks to other data devices.
  • network link 821 may provide a connection through local network 822 to a host computer 823 or to data equipment operated by an Internet Service Provider (ISP) 824.
  • ISP 824 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet" 825.
  • Internet 825 uses electrical, electromagnetic or optical signals that carry digital data streams to files.
  • the signals through the various networks and the signals on network link 821 and through communication interface 820, which carry the digital data to and from computer 800, are exemplary forms of carrier waves for transporting the digital information.
  • the computer 800 can send messages and receive data, including program code, through the network(s), network link 821, and communication interface 820.
  • server 826 might transmit a requested code for an application program through Internet 825, ISP 824, local network 822 and communication interface 820.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un système informatique permettant d'opérer une distribution sécurisée d'instruments de valeur, tels que coupons, tickets, bons-cadeaux, mandats et chèques de voyage. Ce système de distribution fait intervenir trois parties, à savoir le consommateur de l'instrument, le fournisseur de l'instrument et une partie de sécurisation appelée 'service de transaction sécurisée'. Le consommateur s'inscrit auprès du service de transaction sécurisée en vue d'une vérification d'identité avant ou après le lancement d'une transaction avec le fournisseur de produits ou de services. La vérification de l'identité du consommateur peut être établie à n'importe quel niveau requis. Dans un mode de réalisation de ce système, le fournisseur muni le consommateur d'un jeton de confirmation que le consommateur doit présenter au service de transaction sécurisée conjointement avec les informations d'identification du consommateur de manière que seul un consommateur autorisé puisse opérer une transaction. Grâce à ce jeton de confirmation, le service de transaction sécurisée peut obtenir des informations en provenance du fournisseur de produits ou de services par échange de données. Dans certains cas, le service de transaction sécurisée génère le produit requis sous forme électronique et le transmet de manière sécurisée au consommateur autorisé. Des signatures numériques peuvent être utilisées pendant le processus pour assurer l'intégrité des données et de l'identité de l'expéditeur. D'autres modes de réalisation de ce système comprennent des procédés destinés à réémettre, échanger et transférer des instruments de valeur pour des utilisateurs d'origine et des tierces parties.
EP01923025A 2000-03-29 2001-03-28 Procede et dispositif de gestion d'un ou de plusieurs instruments de valeur Withdrawn EP1360661A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US19306400P 2000-03-29 2000-03-29
US193064P 2000-03-29
PCT/US2001/010594 WO2001073707A2 (fr) 2000-03-29 2001-03-28 Procede et dispositif de gestion d'un ou de plusieurs instruments de valeur

Publications (1)

Publication Number Publication Date
EP1360661A2 true EP1360661A2 (fr) 2003-11-12

Family

ID=22712147

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01923025A Withdrawn EP1360661A2 (fr) 2000-03-29 2001-03-28 Procede et dispositif de gestion d'un ou de plusieurs instruments de valeur

Country Status (3)

Country Link
EP (1) EP1360661A2 (fr)
AU (1) AU2001249764A1 (fr)
WO (1) WO2001073707A2 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102521925B (zh) * 2011-12-08 2013-10-23 中国工商银行股份有限公司 一种银行终端设备负载均衡方法及系统
US11544708B2 (en) * 2017-12-29 2023-01-03 Ebay Inc. User controlled storage and sharing of personal user information on a blockchain

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3614480B2 (ja) * 1994-11-18 2005-01-26 株式会社日立製作所 電子チケット販売・払戻システム及びその販売・払戻方法
US5903880A (en) * 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
GB9624127D0 (en) * 1996-11-20 1997-01-08 British Telecomm Transaction system
US5999625A (en) * 1997-02-27 1999-12-07 International Business Machines Corporation Method for electronic payment system with issuer control
WO1998043211A1 (fr) * 1997-03-26 1998-10-01 British Telecommunications Public Limited Company Systeme transactionnel
IL120585A0 (en) * 1997-04-01 1997-08-14 Teicher Mordechai Countable electronic monetary system and method
IL122263A0 (en) * 1997-11-20 1998-04-05 Barkan Mordehay Payment system and method using tokens
JP3574559B2 (ja) * 1998-01-27 2004-10-06 株式会社エヌ・ティ・ティ・データ 電子チケットシステム、回収端末、サービス提供端末、利用者端末、電子チケット回収方法及び記録媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0173707A3 *

Also Published As

Publication number Publication date
AU2001249764A1 (en) 2001-10-08
WO2001073707A2 (fr) 2001-10-04
WO2001073707A3 (fr) 2003-08-28

Similar Documents

Publication Publication Date Title
US20030208406A1 (en) Method and apparatus for processing one or more value bearing instruments
US20040128257A1 (en) Method and apparatus for administering one or more value bearing instruments
US20040128516A1 (en) Method and apparatus for verifying bearing instruments
US7318047B1 (en) Method and apparatus for providing electronic refunds in an online payment system
US7647278B1 (en) Method for facilitating a transaction between a merchant and a buyer
US7395242B2 (en) Method and system for restricting the usage of payment accounts
AU2001251286B2 (en) System, method and apparatus for international financial transactions
AU2001248198B2 (en) A method and system for a virtual safe
US20130275301A1 (en) System and method for sending money via e-mail over the internet
WO1998019224A2 (fr) Transfert dirige d'information dans des reseaux informatiques
AU2001251286A1 (en) System, method and apparatus for international financial transactions
CA2402353A1 (fr) Procede et appareil d'envoi d'argent par le biais d'une carte de souhaits electronique par internet
US20100223188A1 (en) Online Payment System and Method
EP1766846A1 (fr) Procédés et appareils pour la validation de transactions dans des réseaux
JP2013101670A (ja) 電子的ライセンスを提供するシステム及び方法
US20040143554A1 (en) Method and apparatus for generating a value bearing instrument
WO2001073709A2 (fr) Procede et appareil de creation d'un ou plusieurs instruments porteur de valeurs
WO2001073644A2 (fr) Procede et appareil de creation d'un instrument porteur de valeurs
EP1360661A2 (fr) Procede et dispositif de gestion d'un ou de plusieurs instruments de valeur
WO2001074031A2 (fr) Procede et appareil de verification d'un instrument porteur de valeurs
EP1360662A2 (fr) Procede et appareil d'administration d'un instrument porteur de valeurs
WO2001001316A2 (fr) Systeme, procede et article de fabrication permettant de distribuer un logiciel electronique, mecanisme de paiement apres telechargement a capacites de cryptage
Dulai et al. IOTP and Payments Protocols
WO2001048658A1 (fr) Vente d'un produit a teneur numerique dans une transaction en ligne
KR20090013456A (ko) 광고 수수료 정산 방법 및 시스템

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20021029

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20031118