EP1275064A4 - Systeme de gestion de transactions sur reseaux - Google Patents

Systeme de gestion de transactions sur reseaux

Info

Publication number
EP1275064A4
EP1275064A4 EP00993827A EP00993827A EP1275064A4 EP 1275064 A4 EP1275064 A4 EP 1275064A4 EP 00993827 A EP00993827 A EP 00993827A EP 00993827 A EP00993827 A EP 00993827A EP 1275064 A4 EP1275064 A4 EP 1275064A4
Authority
EP
European Patent Office
Prior art keywords
client
service
access
provider
user
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
EP00993827A
Other languages
German (de)
English (en)
Other versions
EP1275064A1 (fr
Inventor
David M Oliver
Michael J Callahan
William P Densmore Jr
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.)
Clickshare Service Corp
Original Assignee
Clickshare Service Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/599,163 external-priority patent/US7324972B1/en
Application filed by Clickshare Service Corp filed Critical Clickshare Service Corp
Publication of EP1275064A1 publication Critical patent/EP1275064A1/fr
Publication of EP1275064A4 publication Critical patent/EP1275064A4/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/06—Buying, selling or leasing transactions

Definitions

  • This application includes a microfiche appendix comprising ten (10) microfiche having a total of 600 frames.
  • the appendix is hereby incorporated by reference.
  • the appendix contains a source tree for programs embodying the present invention including: the National Center for Supercomputing Applications httpd 1.4.2 web server with customizations in accordance with the present invention, the "cs-log” and “cs-logd” logging daemons in accordance with the present invention; and the "tvsd” token-management daemon according to the present invention.
  • the open-systems Internet offers a very different environment to users when compared with traditional consumer on-line services and Electronic Data Interchange (EDI) value-added networks (NANs).
  • EDI Electronic Data Interchange
  • NANs Electronic Data Interchange
  • the Internet environment is very decentralized, and no one organization controls the user base or access to resources. While this decentralization has tremendous advantages (chief among them, the freedom to select from a wide number of service and content offerings), this lack of "unity” can confuse and sometimes frustrate both potential information providers and users.
  • the "stateless protocol" of the Internet presents difficulties for entities which need to know the identity and usage requirements of their service clients.
  • a challenge is to provide a more unified user-access environment without destroying the freedom of choice inherent in the Internet model.
  • One aspect of this challenge is that the unlimited variety of kinds of transactions which occur on the Internet include some kinds of transactions which are very difficult to manage cost-effectively.
  • One such kind is the low- priced transaction.
  • the prior art systems and methods for managing transactions on networks have been too complex and too expensive to use effectively on low-priced transactions. These and other difficulties experienced with the prior art systems and methods have been obviated in a novel manner by the present invention. It is, therefore, an outstanding object of the present invention to provide a system and method for managing transactions on networks.
  • Another object of this invention is to provide a system and method for managing transactions on networks which is so simple and so inexpensive to use that it can be effectively used to manage low-priced transactions.
  • a further object of the present invention is to provide a system for managing client accounts and controlling access to resources over data networks.
  • It is another object of the invention is to provide a system which provides a mechanism for sharing client information and charges among a plurality of service providers.
  • a still further object of the invention is to provide a system which includes a client who is registered with one of the service providers (the "home provider") and is allowed to access the resources of the other service providers (“outside providers”) that are part of the system.
  • TVS Token Validation Service
  • a system for managing client accounts and controlling access to resources over data networks which includes a mechanism for sharing client information and charges among a plurality of service providers.
  • a client who is registered with one of the service providers (the "home provider") is allowed to access the resources of the other service providers (“outside providers") mat are part of the system.
  • the system settles accounts among service providers by charging the home provider for access by its clients to the resources of the outside providers. The outside providers are then paid for that access through the system.
  • the system allows the providers to share users without requiring an open account for each user at each provider.
  • the system includes a mechanism by which each provider can determine if a particular client is a member of the system, verify that the client has authenticated at his home provider, and determine this client's access privileges and criteria.
  • TVS is a service for validating and profiling a large base of users distributed across independent content providers, simultaneously supporting content usage verification
  • TVS is designed for use in an open-systems, public-network environment such as the
  • TVS is implemented using an object-oriented client/server approach to enhance both scalability (in terms of number of users and number of transactions) and portability among operating environments.
  • TVS servers are operated by any Clickshare-authorized licensee of the server-side software
  • the "clients" of this service are, currently, HyperText Transfer Protocol (HTTP) servers operated by licensed, but otherwise independent, content providers.
  • HTTP is the supporting protocol for the World Wide Web, the Internet's popular user environment.
  • content providers can "share users" through a common validation/profiling technique and exchange value for their content through a common, background, settlement process.
  • TVS creates the economic incentive for content providers to link to each other's content in a manner that leverages the content base of all providers simultaneously, and is completely transparent to the user.
  • Clickshare provides a "reference implementation" of the TVS client based on the 1.4.2 release of the HTTP server from the National Center for Supercomputing Applications
  • NCSA Unix(tm) operating system
  • This "TVS-enabled" HTTP server is written in the C programming language.
  • the TVS service is available through a C language API with a clean and narrow interface to the original HTTP server code.
  • the API is a fully separate library and can be used to build other implementations.
  • FIG. 1 is a diagrammatic representation of a simple version of a system for management of transactions over a network, which system embodies the principles of the present invention
  • FIG. 2 is a diagrammatic representation of a more complex version of a system for management of transactions over a network, which system embodies the principles of the present invention.
  • the lettered items refer to the following:
  • Permanent user data base (includes names/credit data)
  • CSC Clickshare ® Authentication and Logging Service
  • CSC CSC licensees
  • CSP Clickshare ® Service Provider ISP, bank, telco, cable, publisher
  • CPM Clickshare ® Publishing Member publisher, software vendor
  • CM Clickshare ® Member user
  • the invention may, in general, display the following features, in, for example, the following order:
  • the invention may display the following features:
  • the Clickshare/TVS Service is a distributed user-management service for Internet information micropayments, access control, audience measurement and personalization with one-ID, one-bill user convenience. It is designed to address the problem of how to charge Internet users for their use of resources and control their access to those resources. It is also designed to provide for the transfer of information about users among multiple web sites in order to control access or define service authorization.
  • TVS enables: MICROPAYMENTS — It makes it possible for publishers, and information or software owners to sell easily to Internet consumers in units as little as 10 cents per item — so called "micropayments”.
  • PERSONALIZATION It allows consumers to store their custom information preferences as part of their user profile and then optionally give those preferences to web publishers who wish to personalize their offerings. Clickshare 's "Digital Calling Card” technology makes this possible.
  • ACCESS CONTROL It permits a web site to differentiate requests for information by individual users rather than broad domains — even if the user has never registered with that particular web site.
  • This "Service Class" technology avoids users having to maintain multiple IDs and passwords.
  • AUDIENCE MEASUREMENT Advertisers want to measure the effectiveness of their pitches by knowing as much about individual viewers as possible.
  • Basic Internet protocols identify users only by "domain.” Clickshare's "Digital Calling Card” technology transfers a unique identifier for each user worldwide. This creates a platform for fine-grained demographic analysis while protecting user privacy.
  • EASE OF USE The consumer can leverage a single billing relationship with a "most- trusted" Clickshare Service Provider - such as an ISP, telco, cable company or other billing entity — to purchase information at multiple web sites with single-ID and password convenience. No end-user software is required beyond a standard Web browser. 3.2. PARTIES INVOLVED IN SERVICE
  • the parties involved in the Clickshare/TVS Service include:
  • BILLING AGENTS/SERVICE PROVIDERS - Consumers have preexisting, ongoing credit relationships with billing agents or service providers who agree to become Clickshare Service Providers. In exchange for a negotiated share of the "Clickstream" revenue from information sales, or for other consideration, these service providers assume responsibility for servicing and billing consumer or enterprise end users and for authenticating the user at the start of a Clickshare/TVS session. Examples include: Internet Service Providers, newspapers, specialized publishers, online services, telephone companies, cable and utility companies, credit-card issuing banks, health-care providers, retailers, other consumer-credit entities, network or other service providers and other enterprises.
  • CUSTOMERS/END USERS - Internet users who have established an account with a billing agent and who seek convenient access to widely distributed digital information are called Clickshare Users. They are customers of their billing agent and have no direct relationship with Clickshare Corp.
  • CALS Clickshare Access and Logging Service
  • CALS Clickshare Access and Logging Service
  • CALS Operated by Clickshare Service Corp. or its licensees, CALS is a fault-tolerant network of one or many Internet servers which exchange real-time, encoded information with machines operated by information sellers and billing agents.
  • a new revenue stream selling information instead of access or goods Low entry barrier, pay-as-you-profit cost structure
  • the Clickshare/TVS Service is designed to enable a free marketplace for digital information in which business relationships among multiple service providers are reduced to a set of technical protocols providing for significant flexibility in the pricing of resources, the transfer of user attributes and the control of access to system resources, all on a real-time basis across open networks such as the Internet. 4.2 OVERVIEW
  • the open-systems Internet offers a very different environment to users when compared with traditional consumer on-line services and Electronic Data Interchange (EDI) value-added networks (VANs).
  • EDI Electronic Data Interchange
  • VANs Electronic Data Interchange
  • the Internet environment is very decentralized, and no one organization controls the user base or access to resources. While this decentralization has tremendous advantages (chief among them, the freedom to select from a wide number of service and content offerings), This lack of "unity” can confuse and sometimes frustrate both potential information providers and users.
  • the "stateless protocol" of the Internet presents difficulties for entities which need to know the identity and usage requirements of their service clients.
  • Clickshare/TVS Service a network service that allows independent content and service providers to cooperate on user registration, user profiling and verification of site usage in a manner that allows:
  • TVS does not require changes to the user "client” software (i.e. web browsers), and does not negatively impact any of the several credit-card and e-cash transaction facilities being deployed or discussed. Rather, it is designed to enable a class of transactions in a value range (5 cents and up) that is uneconomic as single credit-card purchases — and bundle them for monthly or weekly settlement. Thus, TVS is compatible with most announced e- cash implementations. 4.3 KEY DESIGN FEATURES
  • One method of unifying the Internet is to create a single application or application suite that accesses all services, then attempt to get all users to use it exclusively, possibly using proprietary features that users want (but other vendors can't copy). Instead, the TVS approach is have low impact on client software, and where impact is required, adherence to
  • TVS Internet usage is predicted to grow dramatically as high-quality and exciting services are made available on the Internet.
  • TVS is designed to scale as the number of content providers, users, and exciting services are made available on the Internet.
  • TVS is designed to scale as the number of content providers, users, and content usage increases. Scaling capability is built into all portions of the system including user registration, user authentication, and usage logging.
  • One specific advantage is that the individual publisher/service provider is in control of the customer billing relationship.
  • the system thus presupposes multiple billing agents and requires no centralized database of user-specific demographic data.
  • TVS offers service and user class "infrastructure" as part of the TVS service, which itself is independent of application (though it is currently offered only through the World Wide Web "application”) and provider. Because such classing is not yet well-defined in either engineering or marketing domains, Clickshare intends to work with its early partners on such development.
  • the TVS service classing features are easily extended to provide a flexible growth path and accommodate change.
  • TVS also offers user profiling and preference specification capabilities, again with the same extension capabilities. These capabilities support many of the advantages that are to be gained from developing application-specific profiling, without the inherent incompatibilities of application specific design, application-specific profiling, without the inherent incompatibilities of application specific design.
  • NO SPECIFIC PRIVACY MODEL ENFORCED Clickshare realizes that being involved in the "authentication" universe means dealing with sensitive personal financial information. There is a lively debate on-going among privacy advocates and content providers (who use the sales of lists of such information to enhance their revenues).
  • the TVS model does not enforce a specific privacy model.
  • the service itself operates by identifier numbers, not by names, and Clickshare Service Corp.
  • TVS will be able to collect and aggregate content usage information and "localize" this information to a specific user-ID and provider-ID. This alone will go a long way towards providing third party verification of use without direct reference to personal information.
  • TVS is designed to handle charge-per-page billing in a cross-server settlement type model.
  • the market may demand that such a service is not required (that is, not profitable). Therefore, TVS can operate as an authentication / verification engine without settlement.
  • the presence of a 3rd party verifier has significant value even in this arena.
  • TVS does not "force" publishers to bill the users themselves for each click.
  • TVS merely enables each publisher to develop his own billing technique, with the service financed with any combination of ad subsidy, subscription and a la carte pricing.
  • Clickshare Service Corp. feels that a distributed approach should be taken when developing a high volume service for the Internet. Indeed this is common practice and several existing scalable services, notably BIND-type domain name service, use this technique.
  • the TVS model distributes a very large user base among the independent content providers, but offers a single service-point from which each provider can get information about any active user.
  • the implementation of TVS parallels the BIND model wherein any individual host needs to contact only one "name server" for information, while the name servers themselves "cooperate” to manage user information (in a manner that is not of concern to the individual host).
  • the TVS service is scalable from a single server host to a multi-host environment transparently to its clients.
  • TVS Using the TVS model, individual publishers or service providers authenticate their own users, and then ask TVS to store the user's preference, pricing and service-class information in a "publicly accessible" place. In return, TVS provides an authentication token which is returned to the user (specifically, the user's browser). All subsequent access to any TNS-enabled service is governed by this token (non-TVS services are not affected). TVS validates the token on behalf of any individual service, and passes in return the user's profile and class information. When a server has provided service to a validated user, that server returns to TNS a record of the service provided. This record is used by TVS to generate a number of forms of usage information, particularly billing and settlement information. Periodically, this information is returned to all publishers.
  • each is assigned an ID number, and similarly each content provider (called a “Publishing Member”) is assigned a unique ID. Though an individual customer may have several accounts, each has a separate User Member ID (UID). Each of these Ids is assigned to a specific Publishing Member ID (PMID). This association is referred to as the user's "home”.
  • the TVS concept that each user has a "home” is important as it localizes the service to an individual Publishing Member and allows for graceful support of a number of error conditions that might occur with such a widely distributed user base.
  • TVS introduces the notion of a "session” into the World Wide Web.
  • that Publishing Member provides user profile information to its TVS server, which returns an authentication token that is valid for a restricted period of time. Once given this token, the user can access any TVS-enabled HTTP server for the duration of validity without reauthentication. This time period is the "session". The user may directly end his session prior to the pre-determined time-out, but is not required to do so. Further, upon time-out-out, Clickshare can return the user to his "home" Publishing Member for re-authentication transparently. Thus, sessions can be concatenated as well.
  • Publishing Members maintain a "user profile" of each User Member.
  • This profile contains three types of information: “preference” information, "service class” information and, if desired, "pricing” information. Preference information is given by the user member, while service-class information and pricing information are provided by the Publishing Member. These types of information relate to the variety and quality of services offered by the Publishing Member, and each may affect the cost of that service. Some of the profile information can be changed on a session basis, where other types can only be changed by the Publishing Member at fixed points.
  • this profile information is passed to the TVS server when the HTTP server requests an authentication token for the user.
  • the information is loaded by the TVS server into a Dynamic Session Database.
  • any Publishing Member requests that TNS validate this authentication, TVS returns the profile information to that Publisher as part of the authentication.
  • TVS drops that user's profile from the dynamic session database (though portions of it are logged in a service record).
  • the profile information passed to Clickshare by the Publishing Member's HTTP server does not include personal information that would allow a user to be identified by name or financial association. Clickshare indexes profile information by UID + PMID only.
  • the Clickshare Service has been designed as a distributed set of cooperating components that together provide an integrated user management environment.
  • the initial focus of this environment is to provide micro-transaction settlement and audience measurement services to independent publishers and billing entities of all sizes and service volumes.
  • the environment can also be used to control access to services or intangible goods based upon attributes of the requesting user as revealed to the proposed service provider via the authentication token. These services need not have any monetary value.
  • Some of these components run on computers operated by Clickshare Service Providers (at sites not affiliated with Clickshare Corporation). These are called the client side components. The rest, currently, run at Clickshare Corporation's own site. These are the server site components. 5.3.1. Server Side Components Clickshare Authentication Service
  • This service authenticates users in real time allowing each user access to any Clickshare Service Provider without reauthentication for the duration of one session.
  • This service is provided by a set of server machines distributed around the Internet for better fault tolerance and performance.
  • TVS Token Validation Service
  • tvsd Clickshare Logging Service
  • This service logs user transactions occurring at all Clickshare Service Providers sites, in real time.
  • the major component of this service is the Logging Facility - a large database storing all transaction records for production billing. This facility can be operated behind a firewall, due to the design of the Facility interface server.
  • the service "settles" accounts receivable / accounts payable activity among the Clickshare Service Providers on a periodic basis. It interfaces to the Logging Facility database environment in an "off-line” (non real-time) manner. Activity reports are generated for all parties. An interface to the Automated Clearinghouse (ACH) allows fully automated settlement.
  • ACH Automated Clearinghouse
  • This service provides periodic billing records and account summaries to each of the Clickshare Service Providers. It interfaces to the Logging Facility database environment through a set of billing procedures which themselves are tailored to interface with customer billing systems. Billing records are sent to the Service Providers via electromc mail. As an auxiliary capability, the Clickshare Billing Interface can generate user account update summaries upon request from the Service Providers. Components + billing record generator
  • This service maintains a master database of Clickshare Service Provider and clickshare Publishing member IDs and periodically updates the slave databases on CSPs and CPMs' web servers. Authentication and logging functions cannot be used by client servers unless the client server presents an ID which is contained in the master database.
  • This service replaces the traditional HTTP (web) server on sites that participate in the
  • Clickshare Service It processes user requests for informatiorJentertainment resources stored on the site. It interfaces to the Clickshare Authentication Service and the Clickshare Logging
  • Each Service Provider operates one of these servers.
  • This service allows Service Providers to register users for the purposes of access control, service customization and billing. All user demographic and financial information (in addition to preference and service classing information) is stored in these databases at each Service Provider site. Users are authenticated locally from information stored in these databases, after which a subset of the stored information is provided to the Clickshare Authentication Service so that it can help all Service Providers recognize valid Clickshare users.
  • This section describes the TNS applications programming interface (API).
  • API applications programming interface
  • This interface is written in the C programming language for wide applicability to most Web servers written in C, C+ + , or Objective C.
  • programmers do not have to interact with the TVS wire protocol, or with the details of the internal data structures. Since Clickshare is still in its early development, this interface insulates programmers from the many changes that will occur in the low-level design.
  • the TVS API was developed and written for the Unix(tm) operating system.
  • the API uses widely-available and well- documented Unix(tm) features and functionality, such as Berkeley-type sockets.
  • Clickshare intends that TNS be made available first in the Unix(tm) environment, but does not preclude porting the client API to other operating environments (notably, Microsoft Windows NT).
  • a better mode for implementation of the TVS model might be through the use of the Java programming language, or another language, to construct an applications mini-server which acts as a client to the TVS authentication and logging service.
  • the miniserver When an HTTP request is received by the Clickshare host seeking to vend a service or good, the miniserver would look for a TVS token and, if present, verify it and strip off the URL. Then the miniserver would connect to the waiting, unmodified, HTTP server daemon at the host site.. When the reply is served by the HTTP server, the miniserver would annotate the outgoing HTML code with the TVS token.
  • the system administrator would configure the underlying HTTP server not to accept requests other than from the applications mini-server.
  • the advantage to this approach would be its ability to work with any HTTP server without modification or significant reconfiguration. 5.5. SERVICE INTERFACE
  • the TVS Applications Program Interface defines three data structures used as objects to the TVS library of function calls. Two of these can be accessed directly, but the third, the TVS TOKEN, is opaque. All three are treated as opaque since library function calls (described below) are provided to access the information inside where appropriate.
  • the appellation "tvs" in all the names comes from the pre-Marketing name for the Clickshare Service — "Token Validation Service”.
  • TVS SERVER data structure that will be used in all subsequent service requests. */ extern TVS SERVER tvs initialize serviceO;
  • the TVS client may wish to get a human-readable version of the TVS server identifier for logging.
  • the following functions handle administrative and memory management aspects of using the TVS service. /* when Authentication Tokens are returned, they are allocated from dynamic memory. This function frees a dynamically-allocated token after it has been used.
  • the API library manages local information used in error reporting. These functions are used to access that error information. */ extern void tvs_perror(char *string); extern char * tvs_strerror();
  • TVS When TVS receives a request to validate a valid token, it returns the profile of the user identified by that token.
  • TVS PROFILE data structure is defined in the
  • helper functions are provided. In general, this is the preferred access technique, because it is highly likely that the
  • the TVS wire protocol is simple, compact and invisible under the applications programming interface. Nonetheless, several important points should be discussed. Please note that the API library interface allows Clickshare to perform a full frontal lobotomy on this protocol structure if required without changing the programming interface. Since the TVS service is new, Clickshare Service Corp. expects that the wire protocol (especially) will undergo significant change. Therefore, the wire protocol is not specified here. 5.8. RELIABLE DATAGRAMS FOR VERIFICATION
  • UDP User Datagram Protocol
  • IP Internet protocol
  • All protocol operations involve typically 2 UDP/IP datagrams (one in each direction, assuming no retransmissions), and a maximum of 4 datagrams under certain conditions of re-direction within the Clickshare service "back end" (invisible to the client).
  • the client side of TVS uses the BSD socket connectO system call to assure that only packets coming from its TVS server are accepted.
  • the log record returned to TNS is, currently, compatible with the public domain server logs commonly used. Several pieces of additional information are added to each record, however, using an extensible key/value technique. This information assists TNS in the settlement process.
  • UDP has the advantage of being very lightweight. Since virtually all wire transactions contain under 1,000 bytes and are “atomic", the need for a "stateful” protocol like TCP/IP is greatly diminished. In the prototype, a reliability veneer is added over UDP to handle slow or unreliable networks. TCP/IP is used for logging the access records. This method was chosen because consideration is being given to "batching" log delivery (whereby the client saves all log records for "burst" delivery at slow server-utilization periods) and this will benefit from a stateful protocol. The current implementation of the logger is as a separate process (from the HTTP daemon) to facilitate this change if need be.
  • the current interface to the TVS service is through the World Wide Web, specifically servers offering the HyperText Transfer Protocol.
  • the HTTP server uses both Uniform Resource Locators (URLs) and HTTP Request/Response Headers, the HTTP server communicates with client programs ("web browsers"). Separately, the HTTP server communicates with the TVS service using the TVS protocol.
  • TVS is not dependent upon HTTP for anything beyond delivery/return of the Authentication Token to/from the HTTP server.
  • the TNS service itself (and the delivery interface in TVS "clients") will not be affected if new transfer protocols supersede HTTP.
  • TNS uses the Uniform Resource Locator (URL) to return the Authentication token (until a standard exists for transferring it in a Request/Response header). Therefore, TNS is dependent on the URL format, but not on the HyperText Markup Language (HTML), though HTML is the only widely-accepted text language that uses URLs. Should HTML be superseded by another markup language, TNS delivery is still possible.
  • PDF Adobe Portable Document Format
  • DVI TeX's "Device Independent" format
  • the TNS Service is actually a set of services available to clients through an object- oriented modular architecture. The details of how these services are provided are "hidden" within this object structure and applications programming interface.
  • the Clickshare "session management" (user authentication and validation) services comprise one service, the access logging another, and the settlement service yet another.
  • Session management and access logging services are "real-time” , designed to handle and scale to a very large load with minimum impact on service latency. Settlement is an offline non-real time process which does not effect the provision of the real-time services.
  • the TOKEN VALIDATION SERVICE TVS
  • the Token Validation Service (TVS) handles user session management. After a TVS- enabled HTTP server authenticates a new user, it passes that user's profile information to Clickshare along with a request for a new authentication token.
  • the Clickshare TVS server "validates" the user whenever the user presents a URL request to any TVS-enabled HTTP server.
  • the TVS server maintains a Dynamic Session Database (short-lived) of active sessions, indexed by user identification number, "home” publisher affiliation, and the user's host IP address.
  • Dynamic Session Database Short-lived
  • the Dynamic Session Database Alpha-numeric identifying number of the user — User-owning publishing-member number (Clickshare Service Provider)
  • TVS server databases are very straight-forward, but very fast, hash/value tables which use GDBM from the Free Software Foundation. This technology scales to more than one million entries (one million active sessions), and offers features for restart and fast- startup. Virtually no "database management" functionality is required in this application since no permanent knowledge is stored here. Since the TVS service is provided on machines separate from the HTTP servers, there is a possibility that either machine failure or network outage may make the service unavailable temporarily.
  • the HTTP server's actions of initiating a session with TVS and asking TVS to generate a new Authentication Token require communication with only one TVS server.
  • a single TVS server cannot permanently serve more than a small number of clients. Therefore, the service needs to scale (in terms of addition of servers) to provide service "bandwidth".
  • inter-server communication in addition to client/server communication — for the actions of validating and invalidating authentication tokens.
  • the TVS wire protocol and server software are designed for this multi-server environment. It is anticipated that the Clickshare Service will include a Clickshare Interchange
  • each CALS may be independently licensed and owned but will, using the TNS protocol, have the technical capability to authenticate each others end users and relay realtime log reports for settlement.
  • each CALS functions not only as a server to CSP and CPM clients, but also as a server to its peer CALS. Thus it is relatively transparent to each CALS whether it receive a token validation request or a log report from a CSP, a CPM or another CALS.
  • the TVS client-side (HTTP server) architecture is designed so that on start-up (or soft restart) the HTTP server searches for it's service-provider from a local list of options. If, due to network or service host failure, the Clickshare authentication or logging facilities become unavailable, the HTTP server will restart and search for a new (available) service host. Since authentication tokens handed out by the now-dead TVS service are invalid, users will be returned to their home publishers to re-authenticate. This condition is handled gracefully through HTTP redirects, such that the user may not even see this condition (depends on the user's browser type). Independent of the number of TVS servers, and independent of the number of HTTP servers being served, at most two TVS servers will be involved in validating or invalidating a specific authentication token. Thus, there will be at most four (4) packet transmissions required for the most-commonly occurring activity (validation), assuming no retransmissions. 5.13. THE TVS LOGGING FACILITY
  • the logging service is provided on the client (HTTP) side by a separate process accessible through a Unix-domain UDP socket. This process maintains a reliable TCP/IP connection to the TVS Logging Facility.
  • the HTTP server accesses the logging process as part of the normal (local) logging activity done by the server. Clickshare-specific information is added only to the log information intended for the Clickshare logging facility (not the local log).
  • a master logging process spawns a slave process for each connected client.
  • Each of these slave processes opens a connection to the Facility's log database manager.
  • This database manager can reside on the log server machine or on another machine (accessed through a network socket).
  • the Facility's databases are organized such that as transaction records are returned they are "filtered” by "owning publisher". Thus all records for one user reside in one database - that of his "home” publisher. These log databases are updated in real-time.
  • the Facility's database manager can "dump" these databases into the offline settlement service at any appropriate frequency (daily, weekly, monthly) depending on load.
  • the logging processes use SQL to "talk to" the Facility's database manager.
  • the logging processes are C language programs which use our own API to insulate the programs from the specifics of our vendor's interface to its SQL database manager.
  • the service envisions that some end users will wish to query, through an HTML- forms interface or otherwise, the filtered server log database, to determine charges which have been applied to the user's Clickshare ID number since the last settlement to a billing/credit facility.
  • This application will require a separate real-time application which is aware of the pricing rules being applied by the end user's Clickshare Service Provider - and to which the end-user has "subscribed” — providing the application with the end user's globally unique Clickshare ID number.
  • the application can parse from the owning service provider's server active log database all records associated with access by the querying user's Clickshare ID number and present them in an HTML form for review.
  • the purpose of this application is to permit users to gauge their rate or resource usage, or permit Clickshare Service Providers to apply session-based charges against billing or credit facilities — including smart cards — during periods between system settlement.
  • the TVS client transmits to the server (logging facility) side records of each access in an enhanced Common Log Format. Seven pieces of information are provided in the
  • the TVS client transmits the following Clickshare-specific information:
  • content server ID (cs contentpmid) — A globally unique ID number identifying the company which served the content to the user.
  • Clickshare Service Corp. maintains a map of ID numbers to company names and contact addresses.
  • page class (csjpageclass) — A numeric identifier for the value of the page served. The value is used as a lookup into a table of currency-denominated values which are used to price the page.
  • user ID (cs userid) - A user identifier, unique to each Clickshare service or content provider, that identifies the user within that provider's site.
  • home publisher ID (cs homepmid) — A globally unique ID number identifying the company which maintains the financial relationship with the user (user ID) for billing purposes.
  • session ID An identifier for an activity session by a user.
  • a session is a defined period of time during which an authentication token is valid. The length of a session can be requested by the user, or set by the home provider, upon startup). Sessions may be concatenated in time, but sessions cannot overlap. Session Ids are unique to each publisher for a period of about eight months.
  • customer group (cs custgroup) — A numeric identifier for the customer's local group.
  • Two groups are global within Clickshare: Group 1, the default standard group and Group 15, the "testdrive” group. All other values are set locally by the home publisher for his own reference.
  • Service class (cs serviceclass) — A coded numeric identified for special service classing.
  • Service classes may be related to markup ratios for retail pricing or may specific the types of services or goods which the user is authorized to acquire or receive.
  • flags cs flags
  • flags A coded numeric identifier which concatenates all the user- preference flag information (on/off flags) for this session. These preference flags relate to user privacy, parental-control (content selection) and other features and part of the "contract" between the user and the user's Clickshare Service Provider. Other open data blocks are designed to carry releasable demographics and topical preferences, or other metrics, depending upon the requirements of Clickshare service members.
  • the prototype implementation of the Clickshare/TVS service provides a User Registration Environment as a distinct application which is compatible with the TVS client web server.
  • the user is requested to enter their name, choose a password, and provide certain demographic and account information, including credit-card data.
  • the user In some versions of the User Registration Service, the user is also requested to enter preference information about Service Class, Query Threshhold, Privacy and Parental Control and Content Preferences.
  • the prototype implementation does not provide for realtime verification of credit card information, but this should be provided in commercial implementations.
  • the prototype implementation of the Clickshare/TVS service provides a Settlement Service as a distinct database-management application which operations in conjunction with the TVS logging engine.
  • This Settlement Service shorts records of user access to resources by Service Provider and by user within Service Provider and prepares the records for batch deliveries to the individual user's Service Provider.
  • the Settlement Service also outputs charge records aggregated by Service Provider in a format which can be accepted by gateways to the U.S. banking industry's Automated Clearing House (ACH) service for electronic debiting and crediting of Service Provider and Publishing Member banking accounts.
  • ACH Automated Clearing House
  • the Settlement Service outputs charge records aggregated by end user within Service Provider to a Billing Service in a format specific to the most common PC- based program for application of charges to credit-card gateways.
  • Clickshare contemplates an interface for outputting individual, aggregated user charges in a format which can be employed by resellers of telephone company billing services to apply transactional charges to telephone bills.
  • DIFFERENTIAL CHARGING PER RECORD (“MARKUP RATIO")
  • a unique feature of the TVS protocol is the provision for a field which permits differential charging for information sale between an information owner/publisher and various Service Providers ("user owners").
  • Each logged charge record includes a data field carrying the "[Page] Value Class" of the content or service vended by the vending provider site (publisher).
  • the Value Class is a numeric value assigned by the vending provider from a common table of values known and agreed on a system- wide basis. This Value represents the "wholesale royalty" which the vending site will receive at settlement from Clickshare/TVS, less a transaction fee withheld and charged by Clickshare/TVS.
  • the Service Provider who maintains account records of the end user and is responsible for billing the end user, may wish to apply a retail markup to the Value Class expected by the vending publisher.
  • this retail markup is know as the "markup ratio.”
  • the "markup ratio" is derived from the Service Class identifier, and is among the user preference attributes contained in the token which moves about the service following initial authentication of the user for a TVS session. The operator of the TVS authentication and logging service does not use this field in any way.
  • the vending publisher may need to know the Markup Ratio being applied by the Service Provider in order to "show" the price of a service or resource to the end-user prior to or during the sale process.
  • the markup ratio allows the vending publisher to provide an instantaneous "price tag", including any retail markup, to the requesting user, prior to sale. Because the markup ratio is set by the Service Provider, two users from two different Service Providers may pay a different retail price for the same resource provided at the same time by a vending publisher. In effect, the same good may show different "price tags" simultaneously to different users.
  • This feature is analogous to the operation of the wholesale-retail marketplace in the physical world, where consumers may find widely varying retail prices for the same physical product at different stores as a result of different marketing and cost structures of each retailer. For example, one appliance store might sell the Brand A toaster for $29.95. A competing appliance store might sell the identical Brand A toaster for $25.95. Both purchased the toaster from a wholesaler for $14.95. Under the Clickshare Service, the wholesaler must be able to "show” both prices depending which "store” the consumer is inquiring from.
  • TVS uses the IDEA encryption algorithm with a 128-bit key. Since the encrypted data is only valid for the length of one session, and further since the encrypted data has no "enduring value” that warrants use after the session (e.g., credit card number or index), a 128-bit key is sufficient to protect this data for the duration of the session.
  • TNS service could authorize a limited number of access attempts (say, 150) after which time the session is invalid.
  • the client sends a one-time password, the "base” for which is pre-agreed (such that the server is able to correctly identify the "next" in a series).
  • This has the additional advantage that authentication can be somewhat de-coupled from IP address (as is the case in the current TNS model).
  • the core architecture of TVS assumes that the "owner" of resources served to end- users corresponds to the Publishing Member or Service Provider on whose server the resource resides. By making this assumption, it is possible to automatically allocate royalty payments for chargeable resources according to the PmbMbr/SrvcProviderlD of the vending content server with reference to the contents of the resource itself.
  • XML Extensible Markup Language
  • UDI Universal Document Identifier
  • a Digital Object Identifier in the syntax and form as proposed by the International DOI Foundation [see httpJ/ www. doi.org/] or, if DOI fails to become a publisher standard, in the format of a Uniform Resource Name(URN) as proposed by the Internet Engineering Task Force. 5.20.4.
  • a royalty payment which becomes due to the resource/document originator whenever a copy is served. This field would include both a designation of the currency and the payment value.
  • the initial version of TVS contains no facility for examining the contents of documents for data fields of interest. Subsequent versions should include the ability for the vending
  • vending CPM should be required to use the PubMbrlD and price information from the XML markup in place of default values when submitted a log report of the document purchase to its CSP . 5.22. PROPOSED IMPLEMENTATION OF "DEAD MAN'S SWITCH” IN TVS
  • TVS The prototype implementation of TVS is designed to accommodate the failure of a CALS to respond to an authentication request from a CPM, either because of a network interruption or because the CALS itself is "down" (not operating). In such a circumstance, it is desirable for the CPM to be able to continue to reply affirmatively to HTTP requests for resources from end-user CMs. Later versions of TVS will permit the CPM go ahead and serve resources, storing the log reports in a temporary, local database. On a periodic basis, the CALS will poll all affiliated CPMs and "pull" these log reports for subsequent aggregation and settlement. The business rules of the TVS operating entities will determine who bears financial responsibility for information resources served during the period when real-time authentication of user tokens is unavailable. 5.23. CREDIT MANAGEMENT SERVICE OPTION
  • CMS Credit Management Service
  • CMS Credit Management Service
  • This will be accomplished through the addition of a field to the user-profile data (or the extended use of pricing query threshold field) which is stored in the CSP's dynamic session database when the CM user initiates a session [See 5.13.1, above].
  • the operation of the CMS is as follows: 5.23.1.
  • CM user initiates a session request and user's CSP provide CALS with data for dynamic session database. Included in data is a value, Credit(x), established by the CSP in a reference currency supported by the relevant CALS.
  • This figure might be (a) a percentage of the stored value in the CM user's “smart card”, or (b) in an account linked to the user's “debit card” or (c) an amount established by whatever entity is working with the CSP to extend financial credit to the CM user.
  • CALS Each time the CALS receives an authentication request from a CPM who wishes to vend information to the CM user, CALS responds with the user profile data from its dynamic session database, including the Credit(x) value.
  • the vending CPM's server views the Credit(x) value and computationally compares it against the value of the resource to be vended, incorporating any markup ratio inherent in the cs serviceclass field value also received from the CAPS dynamic session database.
  • the CPM server knows the cs_pageclass of the resource to be served either by reference to its physical directory location or by reference to a Universal Document Identifier field embedded within the resource. If Credit(x) is less than the monetary value of cs_pageclass times the markup ratio, CPM's server refuses to serve the resource. If Credit(x) is greater, and other service rules are met, the CPM server returns the resource to CM user.
  • the Clickshare/TNS-enhanced log report returned by the CPM to the authenticating CALS includes the cs_pageclass data field, as well as the cs userid and cs homepmid.
  • CALS next performs a lookup in its dynamic session database to find the profile information on the relevant cs userid (CM user).
  • CAPS then replaces the Credit (x) value in the dynamic session database with a new value which equals: Credit(x) minus (cs_pageclass times markup ratio [derived from cs serviceclass]) Now the next CPM which requests user authentication will receive a new Credit(x) value decremented by the cost of the first resource.
  • the TVS service model envisions the operation of multiple Authentication and Logging Services (CALS) under common or independent ownership or control.
  • Each such entity may provide authentication and logging services to a number of TVS Service Providers (ISPs, banks, telcos, etc.) and TVS Publishing Members (content owners) limited only by the salability limits of the hardware applied to the task.
  • ISPs TVS Service Providers
  • TVS Publishing Members content owners
  • Each independent Authentication and Logging Service issues to its client partners a globally unique Publishing Member/Service provide ID in a format proscribed by the TVS protocol described herein. And each such service reports the issuance of these Ids to the root Clickshare Interchange Service (CIS).
  • the CIS a. Assigns a globally unique CALS ID number to each independent CALS, b.
  • FIG. 2 The diagram submitted as Figure 2 provides a graphical depiction of the flow of authentication, content and logging among the various entities comprising TVS.
  • the reader may refer to the diagram, which references the numbered paragraphs below.
  • the Exhibit B legend contains the lexicon of abbreviations used in the numbered paragraphs.
  • CM user member initiates a session request, typically by submitting a user name/password string via a common World Wide Web browser to the TVS hop server daemon operated by the end-user's CSP ⁇ .
  • the TVS-enhanced server daemon executes its own custom process to verify that the CM seeking to begin a session has proper authorization to do so.
  • the procedure may include a process to verify the CM's credit with an external source or database or to check the status of balance of an account against which purchases will be debited. If the CM is found to be properly authorized, CSP ⁇ 's TVS-enhanced server daemon employs a pre-established UDP connection to its CALS ⁇ to (a) Submit user-profile information to CALS ⁇ for storage in the CALS ⁇ dynamic session database; and (b) Direct CALS ⁇ to issue and return via UDP a globally unique session token. This token is also stored in the CALS ⁇ dynamic session database and is referenced to the related user-profile information also contained there.
  • the CALS server returns the globally unique session token via UDP to the requesting CSP ⁇ . Its contents are encoded so they may be read only by CALS ⁇ and by other CSPs and CPMs within the CALS ⁇ service group. CSP ⁇ saves the token to assist with later reconciliation and billing of CM information purchases, if any.
  • CSP ⁇ responds to the CM's request to initiate a session by returning a copy of the session token to the CM's Web-browser software.
  • CALSb attempts to un-encode the UDP-transmitted session token and, doing so successfully, finds, by referring to a database table of global CALS provided and updated by
  • CALSb determines that it was generated by CALS ⁇ . Since the CALSb dynamic session database does not contain user-profile information for CMa, CALSb relays the token to CALS ⁇ for authentication via a UDP connection which it opens for this purpose. By this process, CALS ⁇ becomes financially responsible for the purchases of CM ⁇ globally. If CALSb is unable to un-encode the session token, it is discarded and CPMb is told that the user making the information request cannot be authenticated.
  • CALS ⁇ attempts to un-encode the UDP-transmitted session token received from CALSb and, doing so successfully, finds that it was generated by CA Sa. Referring to its dynamic session database, CALS ⁇ finds the user CM's user profile, including class-of-service and, depending upon the version of TVS deployed, credit/debit-limit and demographic/personalization data. CALSa employs the established UDP connection with CALSb to return the profile information.
  • CALSb relays the CMfl profile information to CPMb.
  • CPMb uses the profile information to make a series of decisions about how to respond the end user's information or access request. Among the decisions points which could lead to refusing the request:
  • CPMb returns the requested resource via HTTP, along with a fresh copy of the original session token using the same transfer protocol employed in Step No. 4, above.
  • User has now "bought" information, if it is subject to a monetary charge.
  • CPMfr's TVS-enhanced logging daemon Upon successful completing of the HTTP transmission to the end-user's Web browser, CPMfr's TVS-enhanced logging daemon stores a record of the access in common log format enhanced with a number of TVS-specific fields (see Section XX for a description of the additional fields), and also transmit a copy of the access-log report to CALSb.
  • the log report includes the PubMbr/SrvcProviderlD of CSP ⁇ . Accordingly, CALSb relays the log report to CALS ⁇ and takes no further action on it.
  • the TVS-enhanced common log format data may include a field containing an XML-compliant
  • UFI Universal Document Identifier
  • the UDI should permit determination of the copyright ownership of the original document or resource, regardless of which CPM or CSP vended it. In this manner, TVS partners may "cache" each other's resources to improve network efficiency without affecting the ability of TVS to identify the correct recipient of the wholesale royalty at settlement time.
  • CALS ⁇ receive from CALSb a relayed copy of the access-log report generated by CPMb. Its logging daemon stores a copy in a database of all global access to TVS-enabled resources by users of CSP ⁇ for later settlement and billing.
  • CALS ⁇ also copies a log report to a real-time metering and billing utility which will permit: (a) The end-using CM ⁇ to request and review records of current session access by clicking to an address on a web server at CSP ⁇ . The request generates a call from CSP ⁇ to CALS ⁇ for current-session access logs for end-user CM ⁇ .
  • the logs are then parsed against credit debit account status, pricing and service-class rules maintained by CSP ⁇ for its end-users, and fed into a dynamically-generated page shown to the user; or, (b) The assembly and transmission by CSP ⁇ via Email to the end user once in each 24-hour cycle a compilation of all TVS-enabled resource purchases or accesses during the previous period from data provided on a batch basis from CALS ⁇ . This permits the end- user to verify and/or dispute charges shortly after they are incurred. 6.1.14.
  • the "show the bill” processes are separate and distinct from the periodic settlement by each CALS of all royalty credits to member CPMs and all royalty-plus-transaction-fee debits to member CSPs. Settlement occurs in the prototype implementation across the bank
  • step 1 This page has been designated as "authentication required” by the Publishing Member, so the user's browser receives back from the Publishing Member's HTTP server an appropriate status message. The browser prompts the user for his user-name and password, which it then returns to the HTTP server as Request Header information.
  • TVS does not affect the authentication model used by the HTTP server.
  • Most Web browsers use the Basic Authentication scheme which is not "secure”.
  • One additional scheme has been proposed to the IETF (so-called “Digest Access”), and several other schemes — notably, the BellCore "one-time password” scheme — are of interest.
  • the intent of the new models is to provide a very high level of certainty in the authenticity of the user (client).
  • TVS does not dictate a specific model of "original authentication”.
  • the HTTP server Once the HTTP server has obtained the user's Authentication information and has validated it locally, the HTTP server contacts TVS with a request for a new Authentication Token. In making this request, the HTTP server sends the user's profile to TVS with a request for a new Authentication Token.
  • This profile information (along with other per-user information) is stored in each publisher's registration database.
  • TVS uses information from the user's profile to build the Authentication token. For example, the user's service class information is used to determine what the token's validity period will be.
  • the Authentication Token has an encrypted "payload” and is "unencoded” and “sanitized” to accommodate the Web URL naming syntax where required.
  • the token is
  • TVS uses private-key encryption technology which is well-known to the Internet community and unencumbered by patent or export restrictions to the best of our knowledge.
  • the HTTP server When the HTTP server receives the returned token, it is ready to deliver the requested content (as well as the token) to the requesting client.
  • the content is delivered in the canonical HTTP method (accompanied by MIME Response Headers as appropriate).
  • Authentication token can be delivered to the user's client program (Mosaic, Netscape, Lynx, an "agent”, etc.) in several ways.
  • HTTP 1.0 Request/Response Headers to transfer the token among parties "out of view”. [See 5.18, above: "Other Modes for Transferring Token.” Upon return of this original request, a TVS "session" has begun.
  • the HTTP server contacts the TVS server to verify that the provided token is valid (that is, this is a valid user and a valid session). 7.7 VERIFICATION AND PROFILE RETURN
  • the TVS server receives the request, and verifies it using the internal databases it has constructed from the information provided when Authentication Tokens are issued. As an acknowledgment, TVS returns the user's profile information to the HTTP server. 7.8 CONTENT RETURN
  • the HTTP server uses the profile information to determine how best to respond to the user's request.
  • information in the profile may indicate that the server should not respond — or warn the user about the cost of nature of the information requested.
  • the profile information returned to the HTTP server can be used by the server itself to fulfill the request (typically the case with standard "static" file service requests), and is also made available as part of the execution environment for Common Gateway Interface (CGI) scripts.
  • CGI Common Gateway Interface
  • Steps 7.5 though 7.9 are repeated for every content/service request within a session when the user requests content from another TVS-enabled publisher. Requests sent to other
  • HTTP "Redirect" responses but the key to success is the association with TVS which is the only party that knows where the user's home can be found.
  • TVS instructs the HTTP server to redirect the user to known points (in the current case, to Clickshare Service Corp. 's pages) such that the user can return

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention concerne un système et un procédé servant à gérer des comptes de clients, à contrôler l'accès à des ressources et à contrôler l'accès anonyme à des ressources sur des réseaux de données pour une pluralité de membres fournisseurs, de manière à préserver le secret de l'identité d'un utilisateur figurant dans une base d'utilisateurs/clients de fournisseur de rattachement. Dans un autre aspect, le système et le procédé comprennent un moyen servant à autoriser un utilisateur inscrit comme client auprès du fournisseur de rattachement d'accéder aux ressources d'un fournisseur externe, comme si les ressources étaient consultées directement par le fournisseur de rattachement. Le système comprend de préférence un moyen permettant à un propriétaire de produits de vendre l'accès à ces produits par un réseau de données, et permettant au propriétaire d'afficher instantanément et simultanément sur le réseau de multiples prix différents pour le même produit ou les mêmes classes de produits en fonction de différentes conditions de fixation de prix.
EP00993827A 2000-02-11 2000-08-18 Systeme de gestion de transactions sur reseaux Withdrawn EP1275064A4 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US50546200A 2000-02-11 2000-02-11
US505462 2000-02-11
US09/599,163 US7324972B1 (en) 1997-03-07 2000-06-22 Managing transactions on a network: four or more parties
US599163 2000-06-22
PCT/US2000/022789 WO2001059648A1 (fr) 2000-02-11 2000-08-18 Systeme de gestion de transactions sur reseaux

Publications (2)

Publication Number Publication Date
EP1275064A1 EP1275064A1 (fr) 2003-01-15
EP1275064A4 true EP1275064A4 (fr) 2008-07-16

Family

ID=27055151

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00993827A Withdrawn EP1275064A4 (fr) 2000-02-11 2000-08-18 Systeme de gestion de transactions sur reseaux

Country Status (3)

Country Link
EP (1) EP1275064A4 (fr)
AU (1) AU2001272063A1 (fr)
WO (1) WO2001059648A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9098958B2 (en) 1998-09-15 2015-08-04 U-Paid Systems, Ltd. Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5715314A (en) * 1994-10-24 1998-02-03 Open Market, Inc. Network sales system
US5852812A (en) * 1995-08-23 1998-12-22 Microsoft Corporation Billing system for a network
US5873069A (en) * 1995-10-13 1999-02-16 American Tv & Appliance Of Madison, Inc. System and method for automatic updating and display of retail prices
US5815665A (en) * 1996-04-03 1998-09-29 Microsoft Corporation System and method for providing trusted brokering services over a distributed network
US5889958A (en) * 1996-12-20 1999-03-30 Livingston Enterprises, Inc. Network access control system and process

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
JOHN FRANKS PHILIP HALLAM-BAKER JEFFERY L HOSTETLER PAUL LEACH ARI LUOTONEN ERIC W SINK LAWRENCE C STEWART: "A Proposed Extension to HTTP : Digest Access Authentication; draft-ietf-http-digest-aa-04.txt", 6 June 1996, IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, ISSN: 0000-0004, XP015018736 *
NEIL HALLER BELLCORE CRAIG METZ KAMAN SCIENCES CORPORATION PHILIP NESSER NESSER & NESSER CONSULTING MIKE STRAW BELLCORE: "A One-Time Password System; draft-ietf-otp-01.txt", STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. otp, no. 1, 24 March 1997 (1997-03-24), XP015024796, ISSN: 0000-0004 *
PAUL J LEACH ET AL: "Using Digest Authentication as a SASL Mechanism Author's draft: 16; draft-leach-digest-sasl-05.txt", IETF STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, no. 5, 1 September 1999 (1999-09-01), XP015031425, ISSN: 0000-0004 *
See also references of WO0159648A1 *

Also Published As

Publication number Publication date
AU2001272063A1 (en) 2001-08-20
EP1275064A1 (fr) 2003-01-15
WO2001059648A1 (fr) 2001-08-16

Similar Documents

Publication Publication Date Title
US7324972B1 (en) Managing transactions on a network: four or more parties
US20020133412A1 (en) System for management of transactions on networks
US11551211B1 (en) Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
US7698217B1 (en) Masking private billing data by assigning other billing data to use in commerce with businesses
Herzberg et al. MiniPay: Charging per click on the web
US20180114206A1 (en) Methods and apparatus for conducting electronic transactions
US9779436B2 (en) Payment service capable of being integrated with merchant sites
US7778934B2 (en) Authenticated payment
CA2382922C (fr) Procedes et appareil de transactions electroniques
US8650118B2 (en) Universal merchant platform for payment authentication
US6957199B1 (en) Method, system and service for conducting authenticated business transactions
US7249097B2 (en) Method for ordering goods, services, and content over an internetwork using a virtual payment account
US7778901B2 (en) Integrated electronic presentment and payment of bills by different entities
US6349288B1 (en) Architecture for access over a network to pay-per-view information
US20010029485A1 (en) Systems and methods enabling anonymous credit transactions
JP2001512872A (ja) 広域ネットワーク上の小売り方法
US20020165822A1 (en) Method of billing services, server and telecommunication systems
JP2006518515A (ja) オンライン商取引のシステムおよび方法
JP2003534593A (ja) セキュリティトランザクションプロトコル
WO2002033616A1 (fr) Procede et systeme destines a faciliter une transaction securisee en ligne entre des entreprises et des consommateurs en reseaux
US20030135434A1 (en) System and method for micro-payments
JP2002063524A (ja) 電子商取引における信用保証方法、この方法を適用した取引認証サーバーと商店サーバーと会員管理サーバー
US20030105723A1 (en) Method and system for disclosing information during online transactions
EP1275064A1 (fr) Systeme de gestion de transactions sur reseaux
US8510219B1 (en) Billing management package for internet access and web page utilization

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: 20020916

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

A4 Supplementary search report drawn up and despatched

Effective date: 20080613

17Q First examination report despatched

Effective date: 20080812

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20110301