WO1999003243A1 - Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication - Google Patents

Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication Download PDF

Info

Publication number
WO1999003243A1
WO1999003243A1 PCT/FR1997/001239 FR9701239W WO9903243A1 WO 1999003243 A1 WO1999003243 A1 WO 1999003243A1 FR 9701239 W FR9701239 W FR 9701239W WO 9903243 A1 WO9903243 A1 WO 9903243A1
Authority
WO
WIPO (PCT)
Prior art keywords
mediation server
service
service provider
client
request
Prior art date
Application number
PCT/FR1997/001239
Other languages
English (en)
Inventor
Philippe Bazet
Fazal Majid
Bruno Chomel
Original Assignee
France Telecom Interactive
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 France Telecom Interactive filed Critical France Telecom Interactive
Priority to AU36250/97A priority Critical patent/AU3625097A/en
Priority to PCT/FR1997/001239 priority patent/WO1999003243A1/fr
Publication of WO1999003243A1 publication Critical patent/WO1999003243A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content

Definitions

  • the present invention relates to a system for managing transactions between service providers and clients over a communication network. It also relates to a process implemented in this system.
  • HTTP HyperText Transfer Protocol
  • MIME Multimedia Internet Mail Extension
  • S-HTTP Secure HTTP: adaptation of encrypted and secure HTTP
  • SSL Secure Socket Layer
  • URL Uniform Resource Locator
  • a web server is a machine connected to the web and hosting information that can be viewed by a web browser.
  • a reverse proxy is a web server that acts as an intermediary between web clients and several HTTP servers.
  • the client sends its HTTP request to the reverse proxy.
  • the reverse proxy transmits this request to an HTTP server and returns the response from the HTTP server to the client.
  • Business transactions on an open network such as the Internet are expected to experience considerable growth in the short term.
  • a sector particularly concerned is that of paid access to information in the form of pages or documents. It may for example be online information published by newspapers or magazines, or reproductions of literary or artistic works covered by copyright.
  • Cybercash, Kléline, Payline also offer electronic payment solutions on the Internet. These solutions are based on protocols developed respectively by Sligos, Gctech and SG2. Some of these payment solutions only require a Netscape browser using SSL on the client computer. It is the same HTTP protocol, but the exchange is additionally encrypted. For each protocol, the kinematics of the exchanges are specific. The solutions currently proposed have in common to require the use on clients' computers of a suitable software or browser.
  • the service provider collects:
  • This certificate allows the service provider to be identified with certainty in payment transactions.
  • the aim of the present invention is to remedy this drawback by proposing a system for managing transactions between service providers and clients on a communication network, these service providers and these clients having respectively connected servers and client workstations. to the network.
  • this system comprises a mediation server connected to the network and arranged to communicate on the one hand with the client workstations and on the other hand with the respective servers of the service providers, so that all of the transactions between these service providers and these clients must pass through this mediation server.
  • the method according to the invention thus allows access to paid services or information using the open technologies of the Internet, and management of the integrity of paid transactions.
  • the mediation server ensures all of the transaction management operations and in particular the invoicing of services, which eliminates the need to use an encrypted and secure browser.
  • service providers can freely choose the hosting of their services, in particular, locations, server hardware and web server software. They can also retain the freedom to determine their prices and obtain statistical information about their customers.
  • the mediation server and the servers of the service providers communicate according to the HTTP protocol.
  • This HTTP protocol is in practice augmented by additional MIME fields to convey on the one hand information on the customers and on the other hand information relating to the invoicing of the transactions.
  • the system according to the invention thus provides a simplicity of editing the servers of the service providers by requiring only the use of standard HTTP technologies without requiring a modification of the servers or the acquisition of additional software. This contributes to lower development costs than those incurred for processes implementing specific protocols.
  • the servers of the service providers therefore do not need any additional software elements and can use any HTTP server having a CGI interface or a proprietary interface such as the NSAPI or ISAPI interfaces.
  • the mediation server is in practice of the "reverse proxy" type. It is designed to identify and authenticate any client requesting a transaction with a service provider.
  • the mediation server is arranged to manage the reloading of documents during a latency interval of predetermined duration. It is also designed to manage the invoicing of services offered by service providers on subscriber accounts in real time.
  • a method for managing transactions between service providers and clients on a communication network, these service providers and these clients having respectively servers and client workstations connected to the network. , implemented in the system according to the invention.
  • This process includes, in response to a service request from a customer:
  • this response comprising information relating to the invoicing of the service requested by the client.
  • the method according to the invention further comprises, prior to the sending of a request to the server of the service provider, identification and authentication of the client by the mediation server.
  • the method can also ensure, at the level of the mediation server, a control of the integrity of the service provided to the client by the service provider.
  • FIG. 1 is a block diagram of a transaction management system according to the invention.
  • a transaction management system S according to the invention is organized around a mediation server SM connected to the Internet and notably comprises commercial management and billing tools GC, a document reload management module GR, and a or several BD storage and database units.
  • This SM mediation server can itself be managed by an Internet service provider who is then able to offer these subscribed customers access to paid services offered by service providers.
  • the mediation server manages client authentication and invoicing and is the obligatory passage to make pages, images or any object that can be repatriated by HTTP, such as Java applets, payable. It thus performs the following functions: - identification and authentication of customers, - integrity of delivery to the customer, even in the event of a network outage; the customer will then have the possibility of reconnecting and recharging his property free of charge for a predetermined period; - authorization to reload documents for a latent period specified by the service provider; billing of consumption on a subscriber account in real time.
  • the mediation server SM In response to a request (1) from a CL client to use the services offered by an FS service provider, the mediation server SM contacts (4) the web server of this FS service provider using the HTTP protocol and it sends a request including MIME fields containing information about the client.
  • the elements of information included in the request sent by the mediation server can include in the form of fields:
  • Client identifier which can be the identifier of this client assigned by the Internet service provider or a specific identifier for an anonymous client;
  • the mediation server checks (3) that the good or service is being reloaded free of charge.
  • the response (5) sent by the web server of the service provider contains in its MIME fields elements of information making it possible to invoice the customer, in particular prices, product references.
  • the response does not contain any of the MIME fields and this object is automatically considered free by the mediation server.
  • the server of the service provider codes, in the MIME fields of its response, charging information, hereinafter referred to as "ticket", used to control the transaction.
  • the fields of the response are then filtered by the mediation server SM which transmits (6) in particular in the database BD the billing receipt.
  • the SM updates (7) the customer account. Finally, it delivers (8) the good or service to the CL customer.
  • a ticket can contain the following information:
  • the service provider's server is organized in two parts, as shown in Figure 2:
  • the mediation server is a simple HTTP server, not an HTTP proxy server. It must therefore have in the URL address it receives from a client the information necessary for routing to the HTTP server of the service provider.
  • the format of URLs for a mediation server can be determined as follows:
  • the identifier of the service provider granted by the manager of the mediation server can for example be a simple character string (capital letters, maximum 32) allocated once and for all to the FS.
  • URLs referenced from an HTML page on the server are based on the URL transformed by the mediator and not the direct URL to access the server. It is therefore imperative to use either:
  • the header lines are exchanged between the mediation server and the service provider. All the mechanisms defined here are described and formalized in an augmented Backus-Naur (BNF) form similar to that used in RFC-822.
  • BNF Backus-Naur
  • This formalism is described in the version 1.1 specification of the HTTP protocol proposed to the IETF by T.Berners-Lee, R.Frieding and H. Nielsen.
  • the HTTP protocol is a protocol with a simple round trip request-response between client and server. It is built over a TCP connection between the client and the server. For example, reference documents on URLs and the HTTP protocol can be found on the V3C consortium website (address www.w3.org).
  • the document rfc-822 can be viewed on the FTP server of
  • the request format in its simplest form:
  • RFC-822 fields empty line obj and MIME
  • Generic MIME headers that have no special meaning for HTTP, are accessible by the environment variable HTTP_name where name is the name of the field, with translation of the dashes "-" underlined "_". All the fields defined for the definition of the protocol are thus accessible directly from a CGI script on servers supporting CGI 1.1 or later.
  • the headers are in CGI shell environment variables.
  • a CGI script is content to use the library function of the programming language used to obtain the value of an environment variable.
  • a CGI script must send on its standard output: - the headers of the HTTP response to the mediation server;
  • a CGI script must therefore follow the following pseudo-code: 2..Fetch the parameters supplied by the media server;
  • some fields may contain free text: X-FT-Reference-1, X-FT-Reference-2.
  • the content of this field cannot contain the ASCII characters 10 (LF, line feed), 15 (CR, carriage return), or any other non-printable character depending on the ISO 8859-1 standard (including extensions provided by
  • the HTTP protocol defines a date format called HTTP-date.
  • the X-FT-Acknowledgment field contains an absolute URL relative to the same server as that of the initial request.
  • the service provider notifies the mediation server that it wishes to have an acknowledgment of receipt for the purchase in progress.
  • the mediator sends an acknowledgment of receipt to the supplier by sending him an HTTP request of HEAD type on the same server as that which treated the initial request.
  • the URL is the value of the X-FT-Acknowledgment field
  • the mediator sends an X-FT-Confirm header in an acknowledgment.
  • the mediator indicates there whether he billed the client.
  • a request is uniquely identified by the mediation server by a transaction number. It is also dated according to the HTTP-date format mentioned above.
  • An X-FT-ID-Client field contains an identifier characterizing the client. It is provided by the mediation server to service providers. This identifier is stable over time for a given client and a version of the protocol. A major modification of the customer profile can however influence the identifier. It is not guaranteed to be the same between different service providers. This identifier can for example allow a supplier to make statistics or manage context for a customer without knowing it explicitly
  • the X-FT-ID-Supplier field contains the identifier of the supplier. It is provided by the mediation server from the URL of the document requested by the client.
  • Each supplier has a unique identifier. This information is useful for service hosts.
  • An X-FT-ID-Transaction field identifies the transaction on customer invoicing.
  • a customer can reload for free a document which he has purchased during a certain period, less than one hour in all cases, and specified by the service provider.
  • the mediation server checks each client request whether it is a reload or not. This latency can be understood Between
  • the X-FT-PriceHT field contains the price excluding tax of the information requested.
  • the corresponding VAT rate is given in the X-FT-VAT field described below.
  • the X-FT-Reference-1 field allows the supplier to describe the service provided (product reference). It is mandatory to be indicated on the customer's invoice.
  • the single-valued field X-FT-Reference-2 allows the supplier to describe the information more precisely. It is optional and can be added to the customer's invoice.
  • the X-FT-VAT field contains the VAT rate associated with the transaction, the amount given before tax. This rate must be communicated by the supplier, since it depends on the nature of the information.
  • the VAT rate is expressed as a percentage.
  • the header indicates the type of document requested. For example, a customer has just requested a paid document. He was billed and the vendor indicated a one hour lag period. A quarter hour later, the client requests the same document again.
  • a first type of service particularly targeted by the present invention is that of the provision of paid documents and pages. It can be, for example, newspapers, magazines, maps, weather, economics, test or survey results, legal information, etc. It can also be playful documents or artistic, graphic and / or sound.
  • the system according to the invention can also ensure the management of copyright associated with intellectual or artistic creations.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Système (S) pour gérer des transactions entre des fournisseurs de services et des clients sur un réseau de communication, ces fournisseurs de services et ces clients disposant respectivement de serveurs (FS) et de postes clients (CL) connectés au réseau. Le système (S) comprend un serveur de médiation (SM) connecté au réseau et agencé pour communiquer d"une part avec les postes clients et d"autre part avec les serveurs respectifs des fournisseurs de service, de sorte que l"ensemble des transactions entre ces fournisseurs de services et ces clients transite via ce serveur de médiation (SM). Ce procédé intéresse l"ensemble des acteurs commerciaux sur Internet.

Description

" Système et procédé pour gérer des transactions entre des fournisseurs de services et des clients sur un réseau de communication "
La présente invention concerne un système pour gérer des transactions entre des fournisseurs de services et des clients sur un réseau de communication. Elle vise également un procédé mis en œuvre dans ce système.
Elle s'adresse principalement à des fournisseurs d'accès à des réseaux tels qu'Internet, qui mettent en rapport des clients disposant de logiciels de navigation standards et des fournisseurs de service indépendants.
Dans la suite , les abréviations suivantes sont utilisées :
HTTP (HyperText Transfer Protocol): protocole d'accès natif du Web;
MIME (Multimedia Internet Mail Extension) : norme d'extension à la messagerie Internet permettant l'envoi de messages multimédia;
S-HTTP (Secure HTTP) : adaptation de HTTP chiffrée et sécurisée;
SSL (Secure Socket Layer) : adaptation sécurisée et chiffrée de TCP;
URL (ϋniform Ressource Locator) : système pour adresser un document sur le Web. Un navigateur Web est un logiciel permettant d'accéder à l'ensemble des sites sur le Web, de les consulter, de rechercher et de récupérer des données depuis ces sites.
Un serveur Web est une machine connectée sur le Web et hébergeant des informations consultables par navigateur Web.
Un reverse proxy est un serveur Web qui sert d' intermédiaire entre des clients Web et plusieurs serveurs HTTP. Le client envoie sa requête HTTP au reverse proxy. Le reverse proxy transmet cette requête à un serveur HTTP et renvoie au client la réponse du serveur HTTP. Les transactions commerciales sur un réseau ouvert tel qu'Internet sont appelées à connaître une croissance considérable à court terme. En particulier, un secteur particulièrement concerné est celui de 1 ' accès payant à des informations sous la formes de pages ou de documents. Il peut par exemple s'agir d'informations online éditées par des journaux ou des magazines, ou encore de reproductions d'œuvres littéraires ou artistiques couvertes par le droit d'auteur.
Il existe déjà des services d'accès à des informations payantes, mettant notamment en œuvre des transactions par cartes de crédit ou un procédé de porte- monnaie électrique. Dans la majorité des cas, les clients doivent utiliser, en plus de leur logiciel de navigation, un logiciel spécifique de transaction. Des plates-formes d'accès Internet utilisant une notion de porte monnaie électronique ont été développées dans cette voie.
On peut également citer des solutions de paiement électronique s ' appuyant sur des protocoles développés spécifiquement et nécessitant des navigateurs utilisant une couche logicielle SSL (Secure Socket Layer) permettant des échanges cryptés. IL existe aussi des fournisseurs d'accès à Internet tels que Compuserve qui proposent un service de paiement intégré sur la facture de l'abonné.
Cybercash, Kléline, Payline proposent également des solutions de paiement électronique sur Internet. Ces solutions s'appuient sur des protocoles développés respectivement par Sligos, Gctech et SG2. Certaines de ces solutions de paiement ne nécessitent sur le poste client qu'un navigateur Netscape utilisant SSL. Il s'agit du même protocole HTTP, mais l'échange est en plus crypté. Pour chaque protocole, La cinématique des échanges est spécifique. Les solutions actuellement proposées ont en commun de requérir l'utilisation sur les ordinateurs des clients d'un logiciel ou d'un navigateur adapté.
Pour utiliser ces solutions de paiement, le fournisseur de services récupère:
- une interface de programmation spécifique à la solution de paiement,
- éventuellement, un certificat d' authentification. Ce certificat permet d' identifier le fournisseur de services de façon certaine dans les transactions de paiement .
Le but de la présente invention est de remédier à cet inconvénient en proposant un système pour gérer des transactions entre des fournisseurs de services et des clients sur un réseau de communication, ces fournisseurs de services et ces clients disposant respectivement de serveurs et de postes clients connectés au réseau.
Suivant l'invention, ce système comprend un serveur de médiation connecté au réseau et agencé pour communiquer d'une part avec les postes clients et d'autre part avec les serveurs respectifs des fournisseurs de service, de sorte que l'ensemble des transactions entre ces fournisseurs de services et ces clients transite obligatoirement via ce serveur de médiation. Le procédé selon l'invention permet ainsi un accès à des prestations ou informations payantes en utilisant les technologies ouvertes de l'Internet, et une gestion de l'intégrité des transactions payantes. En effet, le serveur de médiation assure l'ensemble des opérations de gestion des transaction et notamment la facturation des prestations, ce qui supprime la nécessité d'utiliser un navigateur crypté et sécurisé.
Par ailleurs, avec le système de gestion de transaction selon l'invention, les fournisseurs de services peuvent choisir librement l'hébergement de leurs services, en particulier, les lieux, les matériels serveurs et les logiciels serveurs Web. Ils peuvent en outre conserver la liberté de déterminer leurs prix et obtenir des informations statistiques sur leurs clients. Dans une version préférée de l'invention appliquée aux transactions sur le réseau Internet, le serveur de médiation et les serveurs des fournisseurs de services communiquent selon le protocole HTTP. Ce protocole HTTP est en pratique augmenté de champs MIME supplémentaires pour véhiculer d'une part des informations sur les clients et d'autre part des informations relatives à la facturation des transactions.
Le système selon l'invention procure ainsi une simplicité d'édition des serveurs des fournisseurs de services en ne requérant que l'utilisation de technologies standards HTTP sans nécessiter une modification des serveurs ou l'acquisition de logiciels supplémentaires. Ceci contribue à des coûts de développement inférieurs à ceux engagés pour des procédés mettant en œuvre des protocoles spécifiques. Les serveurs des fournisseurs de services n'ont donc pas besoin d'éléments logiciels supplémentaires et peut utiliser tout serveur HTTP disposant d'une interface CGI ou d'une interface propriétaire telle que les interfaces NSAPI ou ISAPI. Le serveur de médiation est en pratique du type "reverse proxy". Il est agencé pour identifier et authentifier tout client sollicitant une transaction avec un fournisseur de services.
Dans un mode particulier de réalisation appliqué notamment à l'acquisition de documents payants, le serveur de médiation est agencé pour gérer le rechargement de documents pendant un intervalle de latence de durée prédéterminée. Il est également agencé pour gérer la facturation des prestations offertes par les fournisseurs de services sur des comptes d'abonné en temps réel.
Suivant un autre aspect de l'invention, il est proposé un procédé pour gérer des transactions entre des fournisseurs de services et des clients sur un réseau de communication, ces fournisseurs de services et ces clients disposant respectivement de serveurs et de postes clients connectés au réseau, mis en œuvre dans le système selon l'invention.
Ce procédé comprend, en réponse à une demande de prestation émanant d'un client:
- un envoi d'une requête émise par le serveur de médiation à destination du fournisseur d'accès proposant cette prestation, cette requête comprenant des éléments d'identification du client et du fournisseur de services; et
- un envoi d'une réponse émise par le fournisseur de services à destination du serveur de médiation en réponse à cette requête, cette réponse comprenant des éléments d'information relatifs à la facturation de la prestation demandée par le client.
On peut avantageusement prévoir que le procédé selon l'invention comprenne en outre, préalablement à l'envoi d'une requête au serveur du fournisseur de services, une identification et une authentification du client par le serveur de médiation.
Le procédé peut également assurer, au niveau du serveur de médiation, un contrôle de l'intégrité de la prestation fournie au client par le fournisseur de services .
Il peut en outre avantageusement comprendre, au niveau du serveur de médiation, un traitement des éléments d'information transmis par le serveur du fournisseur de services, et une facturation de la prestation fournie au client.
D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés donnés à titre d'exemples non limitatifs:
- la figure 1 est un schéma synoptique d'un système de gestion de transactions selon l'invention; et
- la figure 2 illustre des traductions d'URLs mises en œuvre dans le procédé de gestion de transactions selon l'invention. On va maintenant décrire un exemple de réalisation d'un système de gestion de transaction selon l'invention. Un système de gestion de transaction S selon l'invention est organisé autour d'un serveur de médiation SM connecté au réseau Internet et comprend notamment des outils de gestion commerciale et de facturation GC, un module de gestion du rechargement de documents GR, et une ou plusieurs unités de stockage et de base de données BD. Ce serveur de médiation SM peut être lui-même géré par un fournisseur d'accès à Internet qui est alors en mesure de proposer à ces clients abonnés un accès à des prestations payantes proposées par des fournisseurs de services.
Le serveur de médiation gère 1 ' authentification des clients et la facturation et est le passage obligé pour rendre payants des pages, images ou tout objet pouvant être rapatriés par HTTP tel que des applets Java. Il assure ainsi les fonctions suivantes: - identification et authentification des clients, - intégrité de la livraison au client, même en cas de coupure réseau; le client aura alors la possibilité de se reconnecter et de recharger son bien gratuitement pendant une durée prédéterminée; - autorisation de rechargement de documents pendant une durée de latente spécifiée par le fournisseur de services; facturation de la consommation sur un compte d'abonné en temps réel.
On va maintenant décrire les étapes essentielles du procédé de gestion de transactions mis en œuvre dans le système selon l'invention.
En réponse à une requête (1) d'un client CL pour utiliser des prestations proposées par un fournisseur de services FS, le serveur de médiation SM contacte (4) le serveur Web de ce fournisseur de services FS en utilisant le protocole HTTP et lui envoie une requête incluant des champs MIME contenant des informations sur le client. A titre d'exemple non limitatif, les éléments d'information inclus dans la requête émise par le serveur de médiation, peuvent comporter sous la forme de champs:
- un identifiant Client, qui peut être l'identifiant de ce client attribué par le fournisseur d'accès Internet ou un identifiant spécifique pour un client anonyme;
- un identifiant de transaction;
- la date et l'heure de la requête;
- un identifiant du fournisseur de services;
- le type de requête] . On peut par exemple envisager deux types de requête:
- une requête suite à une facturation du client,
- une requête suite à une demande de bien ou de service payant par un client. Le client a déjà été facturé pour ce bien ou ce service. Le client est en train de redemander ce bien ou ce service dans le durée de refacturation gratuite. Dans ce dernier cas, le serveur de médiation vérifie (3) que le bien ou le service est en cours de rechargement gratuit.
En retour, la réponse (5) envoyée par le serveur Web du fournisseur de services contient dans ses champs MIME des éléments d'information permettant de facturer le client, notamment des prix, des références de produits.
Si l'objet demandé est gratuit, la réponse ne contient aucun des champs MIME et cet objet est automatiquement considéré comme gratuit par le serveur de médiation.
Dans tous les autres cas, le serveur du fournisseur de services code, dans les champs MIME de sa réponse, des informations de taxation, désignées dans la suite sous le terme de "ticket", servant au contrôle la transaction. Les champs de la réponse sont ensuite filtrés par le serveur de médiation SM qui transmet (6) notamment dans la base de données BD le ticket de facturation. Le SM met à jour (7) le compte client. Enfin, il livre (8) le bien ou le service au client CL.
Cette notion de ticket permet ainsi à un fournisseur qui veut mettre à disposition uniquement des pages gratuites d'utiliser un serveur HTTP sans aucune adaptation. Un ticket peut contenir les éléments d'information suivants:
- montant HT, champ obligatoire,
- taux de TVA, par défaut 20,6%,
- durée de latence, par défaut 1 heure,
- description n°l, champ obligatoire, - description n°2, champ optionnel.
On peut aussi avantageusement prévoir une extension du protocole permettant l'envoi au fournisseur d'une requête pour le prévenir si le client a été facturé ou non. Le serveur du fournisseur de service est organisé en deux parties, comme l'illustre la figure 2:
- une partie gratuite de vitrine et de navigation, accessible directement depuis l'Internet; - une partie payante, accessible uniquement depuis le serveur de médiation qui constitue ainsi une passerelle ou un "reverse proxy".
Le serveur de médiation est un serveur HTTP simple, et non un serveur proxy HTTP. Il doit donc disposer dans l'adresse URL qu'il reçoit d'un client les informations nécessaires au routage vers le serveur HTTP du fournisseur de services.
Le format des adresses URL d'un serveur de médiation peut être déterminé de la façon suivante:
"http://" serveur de médiation [":" port du serveur] "/" identifiant du fournisseur de services "/" reste de 1 ' URL
Il est traduit en une requête pour 1 ' URL suivante sur le serveur du FS :
"http://" serveur du FS [":" port du serveur] "/" reste de l'URL
L'identifiant du fournisseur de services accordé par le gestionnaire du serveur de médiation peut être par exemple une chaîne de caractères simples (majuscules, 32 maximum) attribuée une fois pour toutes au FS .
Par exemple, si l'on utilise le serveur de médiation pay. www. wanadoo . fr sur le port 80 pour accéder à un hypothétique service XYZ (hébergé physiquement sur la machine www. xyz . fr sur le port 2000, l'URL sur le serveur de médiation est: http : //pay .www. wanadoo . fr/XYZ/abc/def .html
et l'URL sur le serveur du fournisseur de services est: http : //www. yz . fr:2000/abc/def .html Le serveur vu du logiciel client est le médiateur.
Les URL référencées depuis une page HTML sur le serveur ont comme base l'URL transformée par le médiateur et non l'URL directe d'accès au serveur. On doit alors impérativement utiliser soit:
- des URL absolues complètes comprenant une référence au serveur de médiation et un code fournisseur;
- des URL relatives.
On va maintenant décrire des exemples de codage des champs utilisés dans les échanges entre les clients, le serveur de médiation et les serveurs des fournisseurs de services .
Les lignes d' en-tête sont échangées entre le serveur de médiation et le fournisseur de services. Tous les mécanismes définis ici sont décrits et formalisés dans une forme Backus-Naur (BNF) augmentée similaire à celle utilisée dans la RFC-822. Ce formalisme est décrit dans la spécification version 1.1 du protocole HTTP proposée a l'IETF par T.Berners-Lee, R.Frieding et H. Nielsen. Le protocole HTTP est un protocole avec un aller-retour simple requête-réponse entre client et serveur. Il est bâti au dessus d'une connexion TCP entre le client et le serveur. Des documents de référence sur les les URLs et sur le protocole HTTP peuvent par exemple être consultés sur le site Web du consortium V3C (adresse www.w3.org).
Le document rfc-822 est consultable sur le serveur FTP de
1 ' INRIA (adresse ftp.inria.fr).
Le format de la requête dans sa forme la plus simple:
Méthode URL et dans le cas le plus général :
Méthode URL Version Champs MIME (RFC-822) ligne vide optionnel obj et MIME optionnel Par exemple : GET /chemin/document. html HTTP/1.0
Accept: */*
Accept: text/html
Accept: image/gif
Toutes les informations additionnelles fournies par le serveur de médiation sont véhiculées dans des champs
MIME supplémentaires par rapport à la requête du client.
Ces champs sont filtrés s'ils existaient déjà dans la requête client.
Le format de la réponse est :
Code Version Texte
Champs RFC-822 ligne vide obj et MIME
Par exemple :
200 HTTP/1.0 Normal
Content-type: text/html
<HTMLXHEADXTITLE>Tout va bien<TITLEX/HEAD>
<BODYXP>Tout va bien</PX/BODY> Les informations de taxation sont fournies par le serveur du fournisseur de services sous la forme de champs MIME supplémentaires. On va maintenant décrire un exemple de gestion du protocole en utilisant l'interface CGI.
Il s'agit tout d'abord d'extraire les paramètres fournis par le serveur de médiation. Les en-tête MIME génériques n'ayant pas de signification spéciale pour HTTP, sont accessibles par la variable d'environnement HTTP_nom où nom est le nom du champ, avec traduction des tirets «-» en soulignés «_». Tous les champs définis pour la définition du protocole sont ainsi accessibles directement à partir d'un script CGI sur les serveurs supportant CGI 1.1 ou ultérieur. Les en-têtes sont dans des variables d'environnement shell du CGI. Pour obtenir la valeur d'un de ces champs, un script CGI se contente d'utiliser la fonction de librairie du le langage de programmation utilisé permettant d'obtenir la valeur d'une variable d' environnement .
En ce qui concerne la génération par le serveur du fournisseur de services au serveur de médiation, un script CGI doit envoyer sur sa sortie standard: - les en-têtes de la réponse HTTP au serveur de médiation;
- la page à envoyer au serveur de médiation.
Un script CGI doit ainsi suivre le pseudo-code suivant : 2..Récupérer les paramètres fournis par le serveur de média tion ;
2. Calculer le prix et les informa tions permettant de générer la page; 3. Envoyer les en-têtes sur la sortie standard;
4 . Envoyer une ligne vide pour marquer la fin des en-têtes ;
5 . Envoyer le corps (texte, . HTML , GIF, etc . ) sur la sortie standard.
Par ailleurs, certains champs peuvent contenir du texte libre : X-FT-Reference-1, X-FT-Reference-2.
Ces champs sont interprétés selon la norme de codage de caractères ISO 8859-1 (ISO Latin-1), qui est celle d'Unix et de Windows, et qui se déduit d' Unicode par masquage du premier octet.
Le contenu de ce champ ne peut pas contenir les caractères ASCII 10 (LF, saut de ligne) , 15 (CR, retour chariot) , ni tout autre caractère non imprimable selon la norme ISO 8859-1 (y compris les extensions apportées par
Microsoft Windows).
S 'agissant des formats de date, le protocole HTTP définit un format de date appelé HTTP-date. Le champ X-FT-Acquittement contient une URL absolue relative au même serveur que celui de la requête initiale.
Le fournisseur de services avertit le serveur de médiation qu'il souhaite avoir un accusé de réception pour l'achat en cours. Le médiateur envoie un accusé de réception au fournisseur en lui envoyant une requête HTTP de type HEAD sur le même serveur que celui qui a traité la requête initiale.
Les caractéristiques de cette requête HTTP d' acquittement sont les suivantes :
- la méthode de la requête est HEAD ;
- l'URL est la valeur du champs X-FT-Acquittement ;
- les en-têtes envoyées sont :
- les en-têtes que le médiateur a envoyé au fournisseur pour lui demander le bien payant ;
- un écho des en-têtes que le fournisseur lui a renvoyé avec le bien;
- un en-tête X-FT-Confirm indiquant si le bien a été facturé. Le médiateur envoie un en-tête X-FT-Confirm dans un accusé de réception. Le médiateur y indique si il a facturé le client.
Une requête est identifiée de façon unique par le serveur de médiation par un numéro de transaction. Elle est également datée suivant le format HTTP-date rappelé ci-dessus .
Un champ X-FT-ID-Client contient un identifiant caractérisant le client. Il est fourni par le serveur de médiation aux fournisseurs de services. Cet identifiant est stable dans le temps pour un client et une version du protocole donnés. Une modification majeure du profil client peut cependant influer sur l'identifiant. Il n'est pas garanti comme étant identique entre fournisseurs de services différents. Cet identifiant peut par exemple permettre à un fournisseur de faire des statistiques ou de gérer du contexte pour un client sans le connaître explicitement
(droits acquis, etc.). Le champ X-FT-ID-Fournisseur contient l'identifiant du fournisseur. Il est fourni par le serveur de médiation à partir de l'URL du document que lui demande le client.
Chaque fournisseur a un identifiant unique. Cette information est utile pour les hébergeurs de services. Un champ X-FT-ID-Transaction identifie la transaction sur la facturation client.
S 'agissant du champ X-FT-Latence, un client peut recharger gratuitement un document qu' il a acheté pendant une certaine période, inférieure à une heure dans tous les cas, et précisée par le fournisseur de services.
Ceci est dû au fait que certains clients HTTP rechargent des documents (à l'impression, lors d'un "View
Source"), et un utilisateur peut être amené à le faire en cas d'incident technique. Le serveur de médiation vérifie à chaque requête d'un client s'il s'agit d'un rechargement ou non. Ca latence peut être comprise entre
1 minute et 1 heure.
Le champ X-FT-PrixHT contient le prix hors taxes de l'information demandée. Le taux de TVA correspondant est donné dans le champ X-FT-TVA décrit par la suite.
Il est à noter que ce montant est le montant de base qui servira pour les calculs ultérieurs. Il peut donc être diffèrent de la rémunération finale du fournisseur, selon les ristournes et commissions applicables. Le champ X-FT-Reference-1 permet de mettre au fournisseur de décrire le service rendu (référence produit) . Il est obligatoire pour être indiqué sur la facture du client. Le champ mono-valué X-FT-Reference-2 permet de mettre au fournisseur de décrire plus finement l'information. Il est facultatif et pourra être ajouté à la facture du client.
On peut par exemple utiliser X-FT-Reference-1 pour la description générale de l'information, et X-FT-Reference-
2 pour donner plus de détails sur la requête particulière.
Le champ X-FT-TVA contient le taux de TVA associé à la transaction, le montant étant donné hors taxes. Ce taux doit être communiqué par le fournisseur, puisqu'il dépend du la nature de l'information. Le taux de TVA est exprimé en pourcentage.
On va maintenant décrire la fonction de rechargement offerte par le système et le procédé selon l'invention. II existe deux types de documents payants: les documents en cours de rechargement gratuitement; le médiateur ne les facture pas. Après une première facturation pour un document donné, un client peut recharger gratuitement ce même document pendant une durée donnée. Le fournisseur fixe cette durée. Elle n'excède pas une heure; les documents payants et facturables; ces documents sont demandés pour la première fois par le client. Ou bien, le client demande un document après que ce document ait déjà été facturé et après la durée de rechargement gratuit du document.
L' en-tête indique quel est le type de document demandé. Par exemple, un client vient de demander un document payant. Il lui a été facturé et le fournisseur a indiqué une période de latence d'une heure. Un quart d'heure plus tard, le client redemande le même document.
Le serveur de médiation génère l' en-tête HTTP
X-FT-Type-Requete: Rechargement
Deux heures plus tard, le même client redemande le même document. Cette fois, le médiateur envoie un en-tête
HTTP
X-FT-Type-Requete: Normal
Le système et le procédé selon l'invention peuvent être appliqués pour des types variés de prestations disponibles sur un réseau. Une premier type de prestations particulièrement visé par la présente invention est celui de la fourniture de documents et de pages payants. Il peut s'agir, par exemple, de journaux, de magazines, de cartes géographiques, météorologiques, économiques, de résultats de tests ou de sondages, d'informations de nature juridique, etc.. Il peut également s'agir de documents ludiques ou artistiques, graphiques et/ou sonores. Le système selon l'invention peut également assurer la gestion de droits d'auteurs associés à des créations intellectuelles ou artistiques.
On peut également mettre en œuvre le système et le procédé selon l'invention pour la gestion d'opérations de vente sur catalogue électronique. Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention. En particulier, les éléments d'identification et de tarification peuvent être écrits suivant des syntaxes différentes de celles qui viennent d'être décrites. En outre, le procédé selon l'invention n'est pas lié au seul protocole HTTP actuel mais pourra être mis en œuvre avec d'autres protocoles futurs.

Claims

REVENDICATIONS
1. Système (S) pour gérer des transactions entre des fournisseurs de services (FS) et des- clients (CL) sur un réseau de communication, ces fournisseurs de services (FS) et ces clients (CL) disposant respectivement de serveurs et de postes clients connectés au réseau, caractérisé en ce que ce système (S) comprend un serveur de médiation (SM) connecté au réseau et agencé pour communiquer selon un protocole de communication prédéterminé, d'une part avec les postes clients et d'autre part avec les serveurs respectifs des fournisseurs de service (FS) , de sorte que l'ensemble des transactions entre ces fournisseurs de services (FS) et ces clients (CL) transite via ce serveur de médiation (SM) .
2. Système (S) selon la revendication 1, caractérisé en ce que le serveur de médiation (SM) et les serveurs des fournisseurs de services (FS) communiquent selon le protocole HTTP.
3. Système (S) selon la revendication 2, caractérisé en ce que le protocole HTTP est augmenté de champs MIME supplémentaires pour véhiculer d'une part des informations sur les clients et d'autre part des informations relatives à la facturation des transactions.
4. Système (S) selon l'une des revendications précédentes, caractérisé en ce que le serveur de médiation (SM) est du type "reverse proxy".
5. Système (S) selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de médiation (SM) est agencé pour identifier et authentifier tout client sollicitant une transaction avec un fournisseur de services.
6. Système (S) selon la revendication 5, appliqué notamment à l'acquisition de documents payants, caractérisé en ce que le serveur de médiation (SM) est agencé pour gérer un rechargement gratuit de documents pendant un intervalle de latence de durée prédéterminée.
7. Système (S) selon l'une des revendications 5 ou 6, caractérisé en ce que le serveur de médiation (SM) est agencé pour gérer la facturation des prestations offertes par les fournisseurs de services.
8. Système (S) selon la revendication 7, caractérisé en ce que le serveur de médiation (SM) gère des facturations sur des comptes d'abonné.
9. Système (S) selon l'une des revendications 7 ou 8, caractérisé en ce que le serveur de médiation (SM) gère des facturations en temps réel.
10. Procédé pour gérer des transactions entre des fournisseurs de services et des clients sur un réseau de communication, ces fournisseurs de services et ces clients disposant respectivement de serveurs (FS) et de postes clients (CL) connectés au réseau, mis en œuvre dans le système (S) selon l'une quelconque des quelconque des revendications précédentes, caractérisé en ce qu'il comprend, en réponse à une demande de prestation émanant d'un client:
- un envoi d'une requête émise par le serveur de médiation (SM) à destination du fournisseur d'accès proposant cette prestation, cette requête comprenant des éléments d'identification du client et du fournisseur de services; et
- un envoi d'une réponse émise par le fournisseur de services à destination du serveur de médiation (SM) en réponse à cette requête, cette réponse comprenant des éléments d'information relatifs à la facturation de la prestation demandée par le client.
11. Procédé selon la revendication 10, caractérisé en ce qu'il comprend en outre, préalablement à l'envoi d'une requête au serveur du fournisseur de services (FS) , une identification et une authentification du client par le serveur de médiation (SM) .
12. Procédé selon la revendication 11, caractérisé en ce qu'il comprend en outre, au niveau du serveur de médiation (SM) , un contrôle de l'intégrité de la prestation fournie au client par le fournisseur de services, comportant notamment une vérification du format des en-têtes émises par le fournisseur de services.
13. Procédé selon l'une des revendications 10 à 12, caractérisé en ce qu'il comprend en outre, au niveau du serveur de médiation (SM) , un traitement des éléments d'information transmis par le serveur du fournisseur de services (FS) , et une facturation de la prestation fournie au client.
14. Procédé selon la revendication 13, caractérisé en ce qu'il comprend en outre un envoi par le serveur de médiation (SM) d'un accusé de réception au fournisseur de services, en réponse à une requête de celui-ci.
15. Procédé selon l'une des revendications 13 ou 14, caractérisé en ce que des prestations sont facturées sur des comptes d'abonnés.
16. Procédé selon l'une des revendications 13 à 15, caractérisé en ce que des prestations sont facturées en temps réel.
17. Procédé selon l'une quelconque des revendications 10 à 16, caractérisé en ce qu'il autorise un rechargement de documents fournis par un fournisseur de services à un client pendant un intervalle de latence prédéterminé.
18. Procédé selon l'une quelconque des revendications 10 à 16, mis en œuvre avec le protocole HTTP, caractérisé en ce que les informations d'identification et de tarification sont véhiculées dans des champs MIME supplémentaires des en-têtes du protocole HTTP.
REVENDICATIONS MODIFIEES
[reçues par le Bureau international le 11 Juin 1998 (11.06.98) ; revendications originales 1-18 remplacées par les revendications
1-15 modifiées (4 pages) ]
1. Système (S) pour gérer des transactions entre des fournisseurs de services (FS) et des clients (CL) sur un réseau de communication, ces fournisseurs de services (FS) et ces clients (CL) disposant respectivement de serveurs et de postes clients connectés au réseau, ce système (S) comprenant un serveur de médiation (SM) connecté au réseau et agencé pour communiquer selon un protocole de communication prédéterminé, d'une part avec les postes clients et d'autre part avec les serveurs respectifs des fournisseurs de service (FS), de sorte que l'ensemble des transactions entre ces fournisseurs de services (FS) et ces clients (CL) transite via ce serveur de médiation (SM) , caractérisé en ce que le serveur de médiation (SM) est agencé pour gérer la facturation des prestations offertes par les fournisseurs de services, et en ce que des informations sur les clients émises par le serveur de médiation et des informations de facturation émises par les serveurs des fournisseurs de service (FS) sont transmises en utilisant des mécanismes d'extension du protocole de communication.
2. Système (S) selon la revendication 1, dans lequel le serveur de médiation (SM) et les serveurs des fournisseurs de services (FS) communiquent selon le protocole HTTP, caractérisé en ce que le protocole HTTP est augmenté de champs MIME supplémentaires pour transmettre d'une part des informations sur les clients et d'autre part des informations relatives à la facturation des transactions .
3. Système (S) selon l'une quelconque des revendications précédentes, dans lequel le serveur de médiation (SM) est agencé pour identifier et authentifier tout client sollicitant une transaction avec un fournisseur de services, caractérisé en ce que le serveur de médiation (SM) est agencé pour gérer un rechargement gratuit de documents pendant un intervalle de latence de durée prédéterminée.
4. Système (S) selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de médiation (SM) gère des facturations sur des comptes d'abonné.
5. Système (S) selon l'une quelconque des revendications précédentes, caractérisé en ce que le serveur de médiation (SM) gère des facturations en temps réel .
6. Procédé pour gérer des transactions entre des fournisseurs de services et des clients sur un réseau de communication, ces fournisseurs de services et ces clients disposant respectivement de serveurs (FS) et de postes clients (CL) connectés au réseau, mis en œuvre dans le système (S) selon l'une quelconque des quelconque des revendications précédentes, caractérisé en ce qu'il comprend, en réponse à une demande de prestation émanant d'un client:
- un envoi d'une requête émise par le serveur de médiation (SM) à destination du fournisseur d'accès proposant cette prestation, cette requête comprenant des éléments d'identification du client et du fournisseur de services; et
- un envoi d'une réponse émise par le fournisseur de services à destination du serveur de médiation (SM) en réponse à cette requête, cette réponse comprenant des éléments d'information relatifs à la facturation de la prestation demandée par le client.
7. Procédé selon la revendication 6, caractérisé en ce que la réponse émise par le fournisseur de services comprend en outre une demande d'accusé de réception.
8. Procédé selon la revendication 7, caractérisé en ce qu'il comprend en outre, préalablement à l'envoi d'une requête au serveur du fournisseur de services (FS), une identification du client par le serveur de médiation (SM) et une validation que le client a accès aux prestations du fournisseur de services.
9. Procédé selon la revendication 8, caractérisé en ce qu'il comprend en outre, au niveau du serveur de médiation (SM) , un contrôle de l'intégrité de la prestation fournie au client par le fournisseur de services, comportant notamment une vérification du format des informations émises par le fournisseur de services.
10. Procédé selon l'une des revendications 7 à 9, caractérisé en ce qu'il comprend en outre, au niveau du serveur de médiation (SM), un traitement des éléments d'information transmis par le serveur du fournisseur de services (FS), et une facturation de la prestation fournie au client.
11. Procédé selon la revendication 10, caractérisé en ce qu'il comprend en outre un envoi par le serveur de médiation (SM) d'un accusé de réception au fournisseur de services, en réponse à une requête de celui-ci.
12. Procédé selon l'une des revendications 10 ou 11, caractérisé en ce que des prestations sont facturées sur des comptes d'abonnés.
13. Procédé selon l'une des revendications 10 à 12, caractérisé en ce que des prestations sont facturées en temps réel .
14. Procédé selon l'une quelconque des revendications 7 à 13, caractérisé en ce qu'il autorise un rechargement de documents fournis par un fournisseur de services à un client pendant un intervalle de latence prédéterminé.
15. Procédé selon l'une quelconque des revendications 7 à 14, mis en œuvre avec le protocole HTTP, caractérisé en ce que les informations d'identification et de tarification sont véhiculées dans des champs MIME supplémentaires des en-têtes du protocole HTTP.
PCT/FR1997/001239 1997-07-08 1997-07-08 Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication WO1999003243A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU36250/97A AU3625097A (en) 1997-07-08 1997-07-08 System and method for managing transactions between service suppliers and customers on a communication network
PCT/FR1997/001239 WO1999003243A1 (fr) 1997-07-08 1997-07-08 Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/FR1997/001239 WO1999003243A1 (fr) 1997-07-08 1997-07-08 Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication

Publications (1)

Publication Number Publication Date
WO1999003243A1 true WO1999003243A1 (fr) 1999-01-21

Family

ID=9503303

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1997/001239 WO1999003243A1 (fr) 1997-07-08 1997-07-08 Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication

Country Status (2)

Country Link
AU (1) AU3625097A (fr)
WO (1) WO1999003243A1 (fr)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000039979A1 (fr) * 1998-12-30 2000-07-06 Bottomline Technologies (De), Inc. Systeme automatique de delivrance de remises
EP1164749A1 (fr) * 2000-06-15 2001-12-19 Schrör Jochen Procédé pour obtenir une rémuneration en fonction du temps pour l'usage d'informations d' un réseau d'ordinateurs
WO2002001829A1 (fr) * 2000-06-26 2002-01-03 Swisscom Mobile Ag Confidentialite de bout en bout de transactions realisees entre un terminal mobile et un serveur internet au niveau application
WO2002071350A2 (fr) * 2001-03-02 2002-09-12 Siemens Aktiengesellschaft Procede de paiement de services payants proposes par le biais d'un reseau
EP1266323A1 (fr) * 2000-02-25 2002-12-18 Ipass, Inc. Procede et systeme pour faciliter le reglement financier de l'acces aux services entre differentes parties
EP1269373A1 (fr) * 2000-02-25 2003-01-02 Ipass, Inc. Procede et systeme de normalisation de donnees de transactions relatives a des acces a un service fourni par une pluralite de fournisseurs de services
US6567821B1 (en) 1998-05-15 2003-05-20 Acs State & Local Solutions, Inc. Method and apparatus for electronic collection, translation, grouping and delivery of wage assignment information
US7146505B1 (en) 1999-06-01 2006-12-05 America Online, Inc. Secure data exchange between date processing systems
US7225155B1 (en) * 1997-09-30 2007-05-29 Acs State & Local Solutions, Inc. Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
US7739195B2 (en) 2001-01-12 2010-06-15 Acs State & Local Solutions, Inc. Apparatus and methods for providing a payment system over a network
US8694581B2 (en) 1999-10-22 2014-04-08 Facebook, Inc. Modifying browser requests to track browsing activities
US10026120B2 (en) 2012-01-06 2018-07-17 Primerevenue, Inc. Supply chain finance system
US10592943B2 (en) 2011-05-20 2020-03-17 Primerevenue, Inc. Supply chain finance system
US10970777B2 (en) 2008-09-15 2021-04-06 Mastercard International Incorporated Apparatus and method for bill payment card enrollment

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2294132A (en) * 1994-10-10 1996-04-17 Marconi Gec Ltd Data communication network
US5586260A (en) * 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms
WO1997015885A1 (fr) * 1995-10-25 1997-05-01 Open Market, Inc. Gestion des transferts d'informations dans un reseau de communication

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5586260A (en) * 1993-02-12 1996-12-17 Digital Equipment Corporation Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms
GB2294132A (en) * 1994-10-10 1996-04-17 Marconi Gec Ltd Data communication network
WO1997015885A1 (fr) * 1995-10-25 1997-05-01 Open Market, Inc. Gestion des transferts d'informations dans un reseau de communication

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
STAINOV R: "AUFBAUPRINZIPIEN DER INTERNETDIENSTE UND DES WWW", NTZ NACHRICHTENTECHNISCHE ZEITSCHRIFT, vol. 49, no. 6, 1996, pages 26 - 28, 30 - 33, XP000624584 *
TANENBAUM ANDREW: "COMPUTER NETWORKS, THIRD EDITION", PRENTICE HALL INTERNATIONAL, INC, 1996, XP002055084 *

Cited By (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6223168B1 (en) * 1995-07-25 2001-04-24 Bottomline Technologies, Inc. Automatic remittance delivery system
US8626654B2 (en) 1997-09-30 2014-01-07 Acs State & Local Solutions, Inc. Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
US7788173B1 (en) 1997-09-30 2010-08-31 Acs State & Local Solutions, Inc. Methods and apparatus for child support payment processing and child support disbursement processing by a processing entity
US7752131B1 (en) * 1997-09-30 2010-07-06 Acs State & Local Solutions, Inc. Methods and apparatus for child support payment processing and child support disbursement processing
US7225155B1 (en) * 1997-09-30 2007-05-29 Acs State & Local Solutions, Inc. Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
US8392326B2 (en) 1997-09-30 2013-03-05 Acs State & Local Solutions, Inc. Method and apparatus for payment processing using debit-based electronic funds transfer and disbursement processing using addendum-based electronic data interchange
US7809638B1 (en) 1997-09-30 2010-10-05 Acs State & Local Solutions, Inc. Methods and apparatus for child support payment processing and child support disbursement processing
US7877423B2 (en) 1998-05-15 2011-01-25 Acs State And Local Solutions, Inc. Method and apparatus for electronic collection, translation, grouping, and delivery of wage assignment information
US7720797B2 (en) 1998-05-15 2010-05-18 Acs State & Local Solutions, Inc. Method and apparatus for electronic collection, translation, grouping, and delivery of wage assignment information
US6567821B1 (en) 1998-05-15 2003-05-20 Acs State & Local Solutions, Inc. Method and apparatus for electronic collection, translation, grouping and delivery of wage assignment information
US8527548B2 (en) 1998-05-15 2013-09-03 Acs State And Local Solutions, Inc. Method and apparatus for electronic collection, translation, grouping, and delivery of wage assignment information
US8229978B2 (en) 1998-05-15 2012-07-24 Acs State And Local Solutions, Inc. Method and apparatus for electronic collection, translation, grouping, and delivery of wage assignment information
US7072909B2 (en) 1998-05-15 2006-07-04 Acs State & Local Solutions, Inc. Method and apparatus for electronic collection, translation, grouping, and delivery of wage assignment information
WO2000039979A1 (fr) * 1998-12-30 2000-07-06 Bottomline Technologies (De), Inc. Systeme automatique de delivrance de remises
US7895446B2 (en) 1999-06-01 2011-02-22 Aol Inc. Secure data exchange between data processing systems
US7146505B1 (en) 1999-06-01 2006-12-05 America Online, Inc. Secure data exchange between date processing systems
US9043892B2 (en) 1999-06-01 2015-05-26 Facebook, Inc. Secure data exchange
US9363237B2 (en) 1999-06-01 2016-06-07 Facebook, Inc. Secure data exchange between data processing systems
US8694581B2 (en) 1999-10-22 2014-04-08 Facebook, Inc. Modifying browser requests to track browsing activities
US9294540B2 (en) 1999-10-22 2016-03-22 Facebook, Inc. Processing selected browser requests
EP1266323A4 (fr) * 2000-02-25 2005-04-20 Ipass Inc Procede et systeme pour faciliter le reglement financier de l'acces aux services entre differentes parties
EP1269373A4 (fr) * 2000-02-25 2005-04-20 Ipass Inc Procede et systeme de normalisation de donnees de transactions relatives a des acces a un service fourni par une pluralite de fournisseurs de services
EP1269373A1 (fr) * 2000-02-25 2003-01-02 Ipass, Inc. Procede et systeme de normalisation de donnees de transactions relatives a des acces a un service fourni par une pluralite de fournisseurs de services
EP1266323A1 (fr) * 2000-02-25 2002-12-18 Ipass, Inc. Procede et systeme pour faciliter le reglement financier de l'acces aux services entre differentes parties
EP1164749A1 (fr) * 2000-06-15 2001-12-19 Schrör Jochen Procédé pour obtenir une rémuneration en fonction du temps pour l'usage d'informations d' un réseau d'ordinateurs
WO2002001829A1 (fr) * 2000-06-26 2002-01-03 Swisscom Mobile Ag Confidentialite de bout en bout de transactions realisees entre un terminal mobile et un serveur internet au niveau application
US7444674B1 (en) 2000-06-26 2008-10-28 Swisscom Mobile Ag End-to-end security of transactions between a mobile terminal and an internet server at the application level
AU2000252044B2 (en) * 2000-06-26 2005-01-06 Swisscom Mobile Ag End-to-end security of transactions between a mobile terminal and an internet server at the application level
US8015111B2 (en) 2001-01-12 2011-09-06 Acs State And Local Solutions, Inc. Apparatus and methods for providing a payment system over a network
US8386385B2 (en) 2001-01-12 2013-02-26 Acs State & Local Solutions, Inc. Apparatus and methods for providing a payment system over a network
US8738530B2 (en) 2001-01-12 2014-05-27 Acs State & Local Solutions, Inc. Apparatus and methods for providing a payment system over a network
US7739195B2 (en) 2001-01-12 2010-06-15 Acs State & Local Solutions, Inc. Apparatus and methods for providing a payment system over a network
WO2002071350A2 (fr) * 2001-03-02 2002-09-12 Siemens Aktiengesellschaft Procede de paiement de services payants proposes par le biais d'un reseau
WO2002071350A3 (fr) * 2001-03-02 2003-09-25 Siemens Ag Procede de paiement de services payants proposes par le biais d'un reseau
US10970777B2 (en) 2008-09-15 2021-04-06 Mastercard International Incorporated Apparatus and method for bill payment card enrollment
US11475492B2 (en) 2010-05-21 2022-10-18 Primerevenue, Inc. Supply chain finance system
US11741513B2 (en) 2010-05-21 2023-08-29 Primerevenue, Inc. Supply chain finance system
US10592943B2 (en) 2011-05-20 2020-03-17 Primerevenue, Inc. Supply chain finance system
US10026120B2 (en) 2012-01-06 2018-07-17 Primerevenue, Inc. Supply chain finance system
US10878498B2 (en) 2012-01-06 2020-12-29 Primerevenue, Inc. Supply chain finance system
US11334942B2 (en) 2012-01-06 2022-05-17 Primerevenue, Inc. Supply chain finance system

Also Published As

Publication number Publication date
AU3625097A (en) 1999-02-08

Similar Documents

Publication Publication Date Title
EP0891062B1 (fr) Système et procédé pour la facturation multipartite d&#39;accès au web
US7305354B2 (en) Media asset management system
US6570870B1 (en) Method and system for making a charged telephone call during an Internet browsing session
US8661557B2 (en) Method and system for granting access to system and content
US6804660B2 (en) System method and article of manufacture for internet based affiliate pooling
US20070287413A1 (en) Method and system for mobile billing and content delivery
US20060242038A1 (en) Method for charging costs of enjoying contents transmitted over a telecommunications network, preferably by the internet network, and related system
US20020165822A1 (en) Method of billing services, server and telecommunication systems
WO2000030002A9 (fr) Procede et dispositif de negociation des termes d&#39;une publicite locale
WO1999003243A1 (fr) Systeme et procede pour gerer des transactions entre des fournisseurs de services et des clients sur un reseau de communication
CN100591056C (zh) 用于处理消息的方法和系统
WO2001075696A1 (fr) Procede permettant a un adjudicateur de faire parvenir un appel d&#39;offre a un ou plusieurs prestataires selectionnes
FR2810433A1 (fr) Systeme et procede de couponnage electronique
EP1187393A2 (fr) Procédé et système de paiement d&#39;opérations de transmission et/ou de services effectuées au sein d&#39;un réseau de transmission de données par paquets
US20060031168A1 (en) Method for access to multimedia content and a platform for implementation of the method
FR2816422A1 (fr) Procede pour le paiement de transactions effectuees par exemple sur internet
JP2004500643A (ja) 電子的ライセンスを提供するシステム及び方法
US20060059006A1 (en) System method and article of manufacture for internet based affiliate pooling
US20040143554A1 (en) Method and apparatus for generating a value bearing instrument
EP1187392A1 (fr) Procédé et système de paiement des services effectuées au sein d&#39;un réseau de transmision de paquets
EP2320623B1 (fr) Procédé de fourniture d&#39;un service
WO2002097685A9 (fr) Procedes et systemes dans un reseau de communication de donnees permettant de fournir et de facturer des services
Succi et al. Supporting electronic commerce of software products through pay-per-use rental of downloadable tools
WO2005034427A1 (fr) Procede et systeme de mise a disposition d’informations de taxation d’un service payant delivre par un fournisseur de services
FR2858441A1 (fr) Systeme et procede de paiement electronique

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GE GH HU IL IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: KR

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: CA