EP1446778A2 - Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge - Google Patents

Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge

Info

Publication number
EP1446778A2
EP1446778A2 EP02791681A EP02791681A EP1446778A2 EP 1446778 A2 EP1446778 A2 EP 1446778A2 EP 02791681 A EP02791681 A EP 02791681A EP 02791681 A EP02791681 A EP 02791681A EP 1446778 A2 EP1446778 A2 EP 1446778A2
Authority
EP
European Patent Office
Prior art keywords
server
payment
data
account
customer
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.)
Ceased
Application number
EP02791681A
Other languages
English (en)
French (fr)
Inventor
Dirk Ammermann
Gero Offer
Andreas Marra
Stephan Kruppa
Denis Bouceka
Andreas Schulze
Damian Hackett
Bernd Biechele
Manfred Männle
Holger Zimmermann
Ove Blumert
Michael Weber
Lysann Most
Frank Köhntopp
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.)
Encorus Technologies GmbH
Original Assignee
Encorus Technologies GmbH
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 EP02005763A external-priority patent/EP1313074A3/de
Priority claimed from EP02005762A external-priority patent/EP1313073A3/de
Priority claimed from EP02010457A external-priority patent/EP1361551A1/de
Application filed by Encorus Technologies GmbH filed Critical Encorus Technologies GmbH
Priority to EP02791681A priority Critical patent/EP1446778A2/de
Publication of EP1446778A2 publication Critical patent/EP1446778A2/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/347—Passive cards
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1025—Identification of user by a PIN code
    • G07F7/1075—PIN is checked remotely
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/68—Payment of value-added services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0196—Payment of value-added services, mainly when their charges are added on the telephone bill, e.g. payment of non-telecom services, e-commerce, on-line banking

Definitions

  • This invention relates primarily to payment systems and, more particularly, to a protocol for handling messages between multiple wallet servers and payment servers from many different providers.
  • Dealers and service providers are increasingly involved in business processes that are carried out via several channels.
  • a customer visits a department store, selects items to be bought and exits (checks out), i.e. purchases the items at the retailer's cash register.
  • the customer typically pays for the items in cash, with a credit card or check.
  • a retailer may be able to increase sales by improving customer friendliness when shopping for goods and services.
  • customers who purchase items over the Internet may also wish to complete the actual transaction over the Internet.
  • the fact that customers can buy goods over the Internet without physically entering a department store enables a retailer to increase sales and find more goodwill.
  • the trader can actually lose sales and good will lose.
  • Another customer friendliness available to merchants is to enable customers to make purchases even when the customer does not carry cash, credit card, or check.
  • known systems allow a customer to make purchases using wireless devices (for example a cell phone, a PDA (Personal Digital Assistant)).
  • wireless devices for example a cell phone, a PDA (Personal Digital Assistant)
  • Retailers therefore typically want to provide customers with multiple payment options and multiple accesses through which goods and services can be purchased.
  • these traders are reluctant to offer such flexibility until the transaction can be carried out correctly and on time.
  • legacy systems exist to carry out transactions and significant investments have been made to build the legacy system infrastructure.
  • Traders are typically reluctant to invest in systems that require the replacement of such legacy systems if the time it takes to get a return of such investments is too long. This means that if a merchant needs to replace an existing legacy system with a completely new system to make payments through a wireless device, the merchant will not be willing to make such an investment.
  • the invention is therefore based on the object of specifying a method and an arrangement for the simplified processing of payment transactions using a telecommunication network which takes account of the legal regulations existing in various countries and established and proven procedural procedures for monetary transactions.
  • the present invention relates to a protocol for performing transactions between multiple customers and merchants.
  • the protocol controls the flow of messages and the execution of instructions contained in these messages across a payment system that enables conventional and non-conventional payment methodologies.
  • the protocol offers a variety of advantages including that complex transactions can be completed in a reasonable time and with an acceptable customer experience.
  • the protocol comprises various sub-protocols. Each sub-protocol has its own defined scope with a clear distinction from other sub-protocols.
  • the protocol contains two sub-protocols.
  • a sub-protocol is the wallet server, central processor platform and payment server protocol, sometimes referred to as the interoperable mobile payment protocol (IMPP).
  • the other sub-protocol is the payment server and merchant server protocol, sometimes referred to as the open payment protocol (OPP).
  • OPP controls the exchange of information between a wallet server, a merchant system and a payment server.
  • a merchant system can access a payment server via the merchant API rather than the OPP.
  • the IMPP is supported by a central processor platform (CPP), which is a central instance for forwarding (routes) messages and other uses payment-related processing.
  • CPP central processor platform
  • the CPP manages central offer data and, in certain scenarios, finds out a customer's wallet server during payment initiation.
  • the CPP also provides the forwarding of payment reports in both directions between a wallet server and a payment server.
  • the wallet server contains core customer data, which is required for authentication and payment as well as a transaction history.
  • the wallet server is triggered during the payment initiation phase and subsequently sends payment reports to the payment server through the CPP.
  • the payment server sends notification messages to the wallet server through the CPP.
  • each party can send demand reports to update and review the status of a transaction.
  • the payment server keeps the core customer data on payment and transaction history data.
  • the payment server also receives payment reports from the CPP and processes the reports.
  • the payment server sends a message to the authorized person on the buyer side in accordance with the IMPP and triggers a result report to the CPP and the merchant system.
  • the payment server sends and receives the required information to / from the merchant system during the various phases of the payment process.
  • All transaction-related messages and message attributes are not stored in each of the three servers, i.e. the wallet server, the payment server and the CPP.
  • generation data for the OfferlD are only saved in the CPP.
  • the term "merchant system” refers to a purchasing system (for example a commercially available commerce server) and payment plug-in components which are available in a local merchant domain of an SD model-compliant payment system.
  • the dealer system sends and receives the required information to / from the Payment server during the different phases of the payment process.
  • the transmission of messages between the CPP and the payment server is handled via the IMPP.
  • the IMPP makes it easier for merchants to give customers the option to make payments using mobile devices in a reliable, correct and timely manner.
  • integration with existing legacy systems is made possible by providing a gateway through which standardized, open protocols (e.g. the IUTP protocol) can be used to communicate with the system.
  • the gateway uses the IUTP protocol to translate IUTP messages into IMPP messages and data streams. Retailers therefore do not need to replace old systems and simply connect to the platform (plug-in) on which the IMPP is implemented.
  • the invention includes the essential idea of specifying a largely universal payment method based on a conventional bank account ("postpaid”) or electronic credit (“prepaid”), which is particularly suitable for payment processing in so-called B2C (business-to- Consumer) area as well as in the P2P (person-to-person) area is applicable, that means shopping in real and virtual shops, payment in gastronomic or cultural institutions etc. and the "sending" of money amounts in the private area.
  • postpaid bank account
  • prepaid electronic credit
  • the invention also includes the idea of using the possibilities of a telecommunications network for this, in particular the possibility of extensive processing in almost real time (real time).
  • the invention also includes the central idea of providing and using a unique identifier - the context identifier - for the cross-transactional identification of goods or services offered by a provider (in particular an entire “shopping cart”) for handling all data transmission associated with offering and paying - and processing operations, in particular the reliable authorization of payment.
  • no period of validity is established when the context identifier is generated, so that it is potentially is valid for a limited period.
  • the term "static offer” can be used for this. It will be used in particular for the payment of goods or services offered via television channels ("TV Shopping") and for the products offered on vending machines (VM) via a telecommunications network using a telecommunications device.
  • TV Shopping television channels
  • VM vending machines
  • a period of validity is defined and is automatically invalidated when it expires.
  • a dynamic offer it will be used for various other shopping and payment processes, in particular for individual shopping campaigns in virtual shops or real shops or department stores.
  • the context identifier can be deleted or destroyed at the request of the provider of the goods or services.
  • an elimination signal is sent to the provider upon expiry of the period of validity or at the request of the provider, in order to inform the provider of the invalidation of the identifier in question.
  • the information transfer of the context identifier to the - potential - customer or customer takes place in a first variant as an invariant optical display, in particular lettering on a shop window display or automatic dispenser or printing on a brochure or catalog or the like.
  • the context identifier is transmitted to potential customers as a variable optical display on an electro-optical display device or by voice output or an acoustic signal.
  • the context identifier is used in a broadcast procedure outside the telecommunications network, in particular by radio or television transmission or sales sand or distribution of printed matter or e-mail broadcast, during the period of validity is transmitted to a large number of potential customers.
  • the possibilities for purchasing goods or services (information!) Offered directly via a telecommunications network have become significantly more important.
  • a variant is advantageous for this, in which the context identifier, in particular in a broadcast process, in a short message or via WAP, is transmitted to the customer's telecommunications terminal via the telecommunications network and displayed there.
  • the steps of requesting a context identifier by the provider and sending such to the provider or dealer (merchant) preferably run as essentially automated data transmissions between the system administration server and a dealer server or provider data terminal via a data and / or telecommunications network, especially the Internet. This applies both to Internet shopping and to the use of the proposed system by "classic" retail establishments.
  • the context identifier is transmitted by the customer via the telecommunications network to a customer server of the network operator or a service provider in the telecommunications network, by the customer server, service server or dealer Server sent a request message to the provider for a binding offer, the provider sent an offer data record to the customer server and the offer data record was transmitted from the customer server to the telecommunications terminal of the potential customer and there for menu navigation Confirmation of the transaction displayed.
  • the data transmission is carried out in the steps of the request for a binding offer and the transmission of the offer data via the system administration server, which in particular carries out search and routing functions between network operator or service provider and provider.
  • the context identifier can be generated entirely by a suitable generator at a system management server of the proposed system. However, it can alternatively also be generated entirely externally and transmitted to the system management server for confirmation by the provider as part of the request.
  • a variant is particularly advantageous for “catalog providers”, in which the context identifier has a first and a second section, the first section being a provider identifier generated or managed by the system management server and the second section being a provider identifier generated or managed by the provider Is goods or goods group identifier and the method comprises a transmission of the second section to the system administration server, the linking of the first and second section in the system administration server and the sending or confirmation of the entire context identifier to the customer or to the customer ,
  • the provider can be assigned "number ranges", whereby he continues to use his own catalog number behind a section ("prefix") that represents his identity as a provider. This makes it much easier to use context identifiers in catalog scenarios.
  • the combination of the first section (prefix) with the second section (catalog number) - after the prefix has been assigned by the system administrator - can also be done by the provider himself, whereby the responsibility for the uniqueness of the context identifier lies naturally with the provider.
  • the customer who is informed of the context identifier will enter it himself on his telecommunications terminal or, if necessary, also by voice input.
  • the above-mentioned options for issuing the identifier to the customer can result in an automatic entry process, which is of course more error-resistant than manual entry.
  • the identifier is converted in or on a telecommunications terminal, in particular by a camera or a scanner connected to it, from an optical or acoustic signal to an electrical signal.
  • the proposed system can be implemented in a number of different configurations, whereby it is technically fundamentally centered around a system management server to which a customer server (hereinafter also referred to as a valid server) and a merchant server (payment server) are assigned and with which these are connected by communication channels.
  • a customer server hereinafter also referred to as a valid server
  • a merchant server payment server
  • a dealer or customer server is used in this context, this also means a plurality of servers from different service providers, financial institutions, etc., which have a corresponding function in the overall system.
  • a telecommunications company or customer-oriented service provider, which connects both providers and customers to the system.
  • Telco the telecommunications company
  • the customer service provider operates Customer and dealer server
  • the system administration server is operated by a separate company (hereinafter also referred to as Opco) and is essentially only required for the generation of the context identifier and the ongoing determination of the responsible dealer server.
  • the relevant information for the assignment of the dealer and customer servers responsible for a specific transaction is in this case in particular the system administration server.
  • a third configuration there are separate customer and dealer service providers, each of which only operates the associated server, while the system operating company (Opco) operates the system management server.
  • the system management server essentially only generates or confirms the context identifier and is used to find the dealer server later.
  • the system administration server essentially carries the transaction in terms of processing and transmission technology. Finally, it makes sense to configure the system in which the operating company management server as well as the dealer server, while only customer servers are operated by Telco or the customer service provider.
  • the second and third of the system configurations mentioned above where there is an independent system management company and thus a so-called "opco domain", are advantageous for the implementation of a very large, in particular global, system with a connection of a large number of providers and customers. They enable the central data storage of the relevant data (OfferlD and server addresses) for a large number of users who process electronic transactions via a large number of dealer servers and / or customer servers.
  • the system management server has a code generator unit for generating the context identifier in response to a received request and a code transmission device for transmitting the generated context identifier directly or indirectly to the requesting provider terminal.
  • the code generator unit In a modification to a special procedure (“catalog provider”) already mentioned, the code generator unit only serves to generate a first identifier section that identifies a provider, and in a further modification, instead of the code generator unit, means for receiving and for checking the uniqueness are provided externally generated codes and to issue a confirmation signal to confirm the uniqueness (and thus usability) of an externally generated offer.
  • the system management server has timer means assigned to the code generator unit and time storage means for assigning and storing a validity period to each context identifier, and a time comparator unit connected to the timer and time storage means for monitoring the process a specified period of validity and for the output of an elimination signal for invalidating the context identifier when expired. It is understood that in the case of the use of static remote IDs, these components are replaced by a deletion unit which responds to a deletion request received from the outside and eliminates the identifier.
  • An essential functional component of the proposed system architecture is furthermore a data storage system (OfferlD Repository) for storing and managing all valid context identifiers and information associated with them in the system, in particular data relevant to payment transactions and identifications of data transmission processes that have taken place. With the help of this, for example, for every transaction the responsible customer or Find the dealer server.
  • the TK network devices of the customers or customers using the network and on the other hand at least one customer server of the operator of the TK network or a customer-oriented service provider are connected to the TK network.
  • the invention also includes the idea of providing a system administration server for the administration and routing of the transaction-related data in relation to the customer as well as the provider side, which is network-connected to at least one dealer server of a dealer-oriented service provider. This will typically involve data network connections that can be linked to the telecommunications network to connect customers, but do not necessarily have to.
  • the invention includes the idea of providing suitable data traffic routing means for routing the data records to be exchanged between the parties involved in the course of offer and payment processes.
  • the main component of the proposed system thus forms a system management server which, in a practical practical implementation, is essentially permanently connected to a plurality of customer servers in a number of telecommunication networks, in particular mobile radio networks.
  • the system management server can be connected to a plurality of dealer servers, each dealer server in turn being connected or connectable to a plurality of provider terminals, and it has a dealer memory for storing identification and Address data of the connected providers.
  • the system management server and / or the dealer server (s) are arranged in a telecommunications network, in particular a mobile radio network, and one or more of these form a functional unit with the customer server or customer servers.
  • the proposed system can also be implemented in a number of different configurations, although technically it is basically centered around a system management server, which is normally a customer server (hereinafter also called a valid server) and a merchant server (payment server). assigned and with which they are connected by message transmission channels. If "a" dealer or customer server is used in this context, this is also to be understood in the following as a plurality of servers from different service providers, financial institutions etc., which have a corresponding function in the overall system.
  • a system management server which is normally a customer server (hereinafter also called a valid server) and a merchant server (payment server). assigned and with which they are connected by message transmission channels.
  • a customer server hereinafter also called a valid server
  • merchant server payment server
  • a telecommunications company or customer-oriented service provider, which connects both providers and customers to the system.
  • Telco the telecommunications company
  • the customer service provider operates customer and dealer servers, but the system management server is operated by a separate company (hereinafter also referred to as Opco) and essentially only for the generation of the context identifier and the ongoing determination of the responsible dealer server is required.
  • Opco a separate company
  • a third configuration there are separate customer and dealer service providers, each of which also operates only the associated server, while the system operating company (Opco) operates the system administration server.
  • the system management server essentially only generates or confirms the context identifier and is used to find the dealer server later.
  • the system management server carries processing and transmission From a technical point of view, essentially the transaction.
  • a system configuration also makes sense in which the operating company operates both the system management server and the dealer server, while only customer servers are operated by the Telco or the customer service provider.
  • the second and third of the system configurations mentioned above, where there is an independent system management company and thus a so-called "opco-domain", are advantageous for the implementation of a very large, in particular global, system with a connection of a large number of providers and customers. They enable central data storage of the relevant data (OfferlD and server addresses) for a large number of users who process electronic transactions via a large number of dealer servers and / or customer servers.
  • the system administration server has a code generator unit for generating the context identifier in response to a received request and a code transmission device for sending the generated context identifier directly or indirectly to the requesting provider terminal.
  • the code generator unit In a modification to a special procedure (“catalog provider”) already mentioned, the code generator unit only serves to generate a first identifier section that identifies a provider, and in a further modification, instead of the code generator unit, there are means for receiving and for checking the uniqueness externally generated codes and to issue a confirmation signal to confirm the uniqueness (and thus usability) of an externally generated offer.
  • the system management server has timer means and time storage means assigned to the code generating unit for assigning and storing a validity period to each context identifier, and a time comparator unit connected to the timer and time storage means for monitoring the expiry of a specified period of validity and for the output of an elimination signal to invalidate the context identifier on expiry. It is understood that if static information is used, these components are replaced by a deletion unit that is based on one of these components are replaced by a deletion unit which responds to an externally received deletion request and eliminates the identifier.
  • An essential functional component of the proposed system architecture is furthermore a data storage system (OfferlD Repository) for storing and managing all valid context identifiers and information associated with them in the system, in particular data relevant to payment transactions and identifications of data transmission processes that have taken place. With the help of this, for example, for every transaction determine the responsible customer or dealer server.
  • At least one account management server is directly assigned to the or a telecommunications network, and this works with the system administration server and / or with the customer server to carry out a payment, in particular with access to a prepaid credit , together.
  • the or at least one account management server can be arranged outside the network-internal control area of the or each telecommunications network and in particular can be connected directly to the customer's telecommunications terminal.
  • the system administration server has a sequence program memory for storing at least one transaction sequence program for data communication between the or each customer. Server and the provider end devices or the or each dealer server.
  • a unique identifier - the context identifier - for the cross-transactional identification of goods or services offered by a provider (in particular an entire “shopping cart”) for handling all the offers and Payment related data transmission and processing operations, in particular the reliable authorization of payment, provided.
  • no period of validity is established when the context identifier is generated, so that it is potentially valid indefinitely.
  • the term "static offer” can be used for this. It will be used in particular for the payment of goods or services offered via television channels ("TV Shopping") and for the products offered on vending machines (VM) via a telecommunications network using a telecommunications device.
  • TV Shopping television channels
  • VM vending machines
  • Context identifier defines a period of validity and it is automatically invalidated when it expires. Here one can speak of a "dynamic offer”. It will be used for various other shopping and payment processes, in particular for individual shopping campaigns in virtual shops or real countries or department stores.
  • the context identifier can be deleted or destroyed at the request of the provider of the goods or services.
  • an elimination signal is sent to the provider upon expiry of the period of validity or at the request of the provider to indicate to the provider that the identifier in question has become invalid.
  • the context identifier is transmitted to the - potential - customer or customer as an invariant optical display, in particular lettering on a shop window display or Vending machines or printed on a prospectus or catalog or the like.
  • the context identifier is transmitted to potential customers as a variable optical display on an electro-optical display device or by voice output or an acoustic signal.
  • the context identifier in a broadcast process outside the telecommunications network / in particular by radio or television transmission or sending or distributing printed matter or e-mail broadcast, during the period of validity is transmitted to a large number of potential customers.
  • the possibilities for purchasing goods or services (information!) Offered directly via a telecommunications network have become significantly more important.
  • a variant is advantageous for this, in which the context identifier, in particular in a broadcast process, in a short message or via WAP, is transmitted to the customer's telecommunications terminal via the telecommunications network and displayed there.
  • the steps of requesting a context identifier by the provider and sending such to the provider or dealer (merchant) preferably run as essentially automated data transmissions between the system administration server and a dealer server or provider data terminal via a data and / or telecommunications network, especially the Internet. This applies both to Internet shopping and when the proposed system is used by "classic" retail establishments.
  • the context identifier is transmitted by the customer via the telecommunication network to a customer server of the network operator or a service provider in the telecommunication network, through which Customer server, service server or dealer server sent a request message to obtain a binding offer to the provider, the provider sends an offer data record to the customer server and the offer data record is transmitted from the customer server to the telecommunications terminal of the potential customer and displayed there as part of a menu to confirm the transaction.
  • the data transmission is carried out in the steps of requesting a binding offer and sending the offer data via the system administration server, which in particular carries out search and routing functions between network operator or service provider and provider.
  • the context identifier can be generated entirely by a suitable generator at a system management server of the proposed system, but alternatively it can also be generated entirely externally and transmitted to the system management server for confirmation by the provider.
  • a variant is particularly advantageous for "catalog providers", in which the context identifier has a first and a second section, the first section being a provider identifier generated or managed by the system management server and the second section being one generated by the provider or managed goods or goods group identifier and the method comprises transmitting the second section to the system administration server, linking the first and second sections in the system administration server and sending or confirming the entire context identifier to the customer or to the customer ,
  • the provider can be assigned "number ranges", whereby he continues to use his own catalog number behind a section ("prefix") that represents his identity as a provider. This makes it much easier to use context identifiers in catalog scenarios.
  • the combination of the first section (prefix) with the second section (catalog number) can - after the prefix has been assigned by the system administration - also be carried out by the provider himself, whereby the responsibility for the uniqueness of the context identifier lies naturally with the provider.
  • the customer who is informed about the context identifier will enter it himself on his telecommunications terminal or, if necessary, also by voice input.
  • the above-mentioned options for issuing the identifier to the customer can result in an automatic entry process, which is of course more error-resistant than manual entry.
  • the identifier is converted in or on a telecommunication terminal, in particular by a camera or a scanner connected to it, from an optical or acoustic signal into an electrical signal.
  • the invention includes the essential idea of specifying a largely universal system for processing financial transactions on the basis of a conventional bank account ("postpaid”) or electronic credit (“prepaid”), which is particularly suitable for payment processing in the P2P area is applicable, that is, the "transmission" of amounts of money allowed in the private sector.
  • postpaid bank account
  • prepaid electronic credit
  • the telecommunications terminals of the subscribers using the network and, on the other hand, at least one transaction server of the operator of the telecommunications network or a customer-oriented service provider are connected to the telecommunications network.
  • a person-to-person payment in the sense of the present invention presupposes the existence of an account “wallet account” suitable for electronic credit transfer on the part of both the payer and the payee.
  • the implementation can be done on the one hand in a two-step process by (1) paying to a "merchant" (P2P engine) and (2) crediting to a payee account on the part of the "merchant” or on the other hand - more user-friendly - by integrating the P2P engine implemented at a payer's account management server.
  • P2P engine essentially stands for the P2P engine
  • the account management server which was also mentioned above, also means "payment instrument”. (PI) can be called.
  • PI payment instrument
  • the payer contacts the transaction server or the P2P engine via his telecommunications terminal via a telecommunications network (in particular a mobile network) or via his data terminal via a data network (especially the Internet) and specifies an address or another Identifier of the recipient and the payment amount.
  • a telecommunications network in particular a mobile network
  • a data network especially the Internet
  • the payment currency and a text message can be entered.
  • a second payment instruction record which is ultimately used to credit the payee, is formed from a first payment instruction record created from the payer entry. In this case (unless already entered when entering) the specification of an account identifier of the payee takes place.
  • the transformation between the first and second payment instruction data records typically includes the determination of the server address of the (second) account management server of the payee and a request to the payee's account identifier , After they have been answered, the payment amount can be credited.
  • Authentication of the payer with access to subscriber data identifying him as a subscriber of a telecommunications network is provided in the payment process in any case. If the payment process is triggered by its TK terminal (mobile terminal), the authentication uses its MSISDN for an ab initio authentication. If, on the other hand, the payment process is initiated from a data terminal, a confirmation step with access to the telecommunications network, the subscriber of which is the payer, is provided. A confirmation request is also optionally provided as an additional step in the first-mentioned method.
  • the first payment instruction record has a first currency code and the second payment instruction record has a second, different currency code, and when the second payment instruction record is created, a conversion from the amount information of the first payment instruction record into an amount information of the second payment instruction record performed due to a pre-stored exchange ratio.
  • the hardware and software equipment required for this is provided by the system operator or service provider, and it can be thought of as being implemented in a conversion server or as an additional functionality of one of the account management servers involved.
  • the exchange ratio to be applied is provided by the system operator's transaction server, or the latter also performs the conversion as an additional functionality.
  • the data transmissions are carried out by and to the payer's telecommunications terminal for a payment, all by short message in accordance with SMS, data file transmission in accordance with WAP or via IVR voice communication.
  • SMS variant - especially without additional confirmation - is more useful for low amounts (including "micropayments").
  • WAP shop the P2P engine is implemented in the manner of a "WAP shop” that is now known. In any case, it is advantageous to avoid changes in the access medium during the sub-steps of triggering the payment, authenticating and confirming the transfer of credit.
  • one of the payee is preferably provided on the basis of user data stored in the system (in particular the transaction server or second account management server). This represents an important measure against the misdirection of substantial payments.
  • a procedure is also advantageous in which the payer triggers a deletion process regarding the payment data transfer via a suitable execution of the first transaction server - or also a special interface to his account management server who can cancel the payment.
  • a notification of the payee about the proposed credit transfer is provided, and in a special further training the latter can also specify a special payment instrument (an account management server) to which the electronic payment is to be directed. In this sense, current interventions in the payment process by the recipient are also possible.
  • the realization of a commercial operation for the system operator or service provider involves the implementation of transaction fees on the message or data side (hereinafter referred to as "settlement amount information").
  • the transaction costs can be borne by the payer or payee or split between the two Together with the settlement amount information, a corresponding identification is added to the second payment instruction data record as to whether the payer account or the payee account or both are to be debited proportionately.
  • a so-called spread must be implemented in the data transfer process.
  • corresponding spread information is included in the conversion of the amount information of the first payment instruction record (in the first currency) into that of the second payment instruction record (in the second currency). This is stored in particular in a database assigned to the transaction server or system management server.
  • transaction servers represent an essential component of the proposed system and - depending on the specific system design - with telecommunications terminals and optionally additional data terminals from the payer and - directly or indirectly via further transaction servers - with account management servers on payer and Communicate the payee side.
  • the centerpiece of the system is a system administration server, which is connected to several transaction servers in the is essentially permanently connected and can also form a functional unit with a transaction server.
  • the system administration server is assigned to a telecommunications network or to several telecommunications networks (in particular mobile radio network (s)). In a preferred system version, this assignment also applies to the (or at least one) account management server.
  • the system management server typically has a sequence program memory for storing at least one transaction sequence program for data communication between a payer's telecommunications terminal and the account management server or the transaction server or the transaction servers, and it is expediently a dedicated data storage system for storing and managing all valid user data and, in particular of data-relevant data and identifications of data transfer processes that have taken place.
  • Figure 1 shows a block diagram of a publisher and buyer system.
  • Figure 2 illustrates a payment flow in the system shown in Figure.
  • FIG 3 illustrates an embodiment of the interoperable mobile payment protocol (IMPP).
  • IMPP interoperable mobile payment protocol
  • FIG. 4 shows an exemplary architecture of an IMPP sub-protocol.
  • Figure 5 illustrates WOPP message processing
  • FIG. 6 shows processing for a web WAP macro payment (macro payment).
  • FIG. 7 shows processing for a Web WAP micropayment.
  • FIG. 8 shows processing for a WAP-WAP macro payment (macro payment).
  • Figure 9 illustrates processing for a web WAP address transfer without payment.
  • FIG. 10 shows processing for an automatic macro payment.
  • FIG. 11 shows processing for a static OfferID generation.
  • Figure 12 shows an IMPP status model for direct macro payments.
  • FIG. 13 shows an IMPP status model for macro payment credits.
  • FIG. 14 shows an IMPP status model for delayed macro payments.
  • FIG. 15 represents an IMPP status model for partial macro payments.
  • FIG. 16 shows an IMPP status model for direct micropayments.
  • FIG. 17 shows an IMPP status model for delayed micropayments.
  • FIG. 18 shows an IMPP status model for micropayment credits.
  • Figure 19 shows an IMPP message structure.
  • FIG. 20 shows processing for version agreement in the context of IMPP.
  • FIG. 21 shows an OfferID status diagram.
  • FIG. 22 shows processing for an example currency conversion.
  • FIG. 23 shows processing for micropayment clearing and settlement.
  • Figure 24 illustrates a balancing data status diagram.
  • Figure 25 illustrates processing for fee distribution.
  • Figure 26 illustrates processing for billing.
  • FIG. 27 represents background processing (back-office processing).
  • 29A to 29C show a schematic flow diagram (sequence diagram) and a list of the step sequence of an embodiment of the method according to the invention (web WAP scenario).
  • 30A to 30C show a schematic flow diagram (sequence diagram) and a list of the step sequence of a further embodiment of the method according to the invention (WAP-WAP scenario).
  • 31A to 31C show a schematic flow diagram (sequence diagram) and a list of the step sequence of a further embodiment of the method according to the invention (push-fall-back scenario).
  • 32A and 32B show a schematic sequence diagram and a list of the sequence of steps in the generation of a static open ID in the context of an automatic dispenser / TV shopping scenario.
  • 33A and 33B show a schematic sequence diagram and a list of the sequence of steps in the deletion of a static OfferID in the same context.
  • 34A to 34C show a schematic flow diagram (sequence diagram) and a list of the step sequence of a further embodiment of the method according to the invention (automatic dispenser / TV shopping scenario).
  • 35A and 35B show a schematic flowchart (sequence diagram) and a list of steps in the execution of a clearing procedure in the transaction of larger amounts of money (macro payment).
  • 36A to 36C show a schematic flow diagram (sequence diagram) and a list of the sequence of steps of a further embodiment of the method according to the invention (micro-payment scenario with "stored value accounts”).
  • an interoperable mobile payment protocol (IMPP) is described in connection with a system which provides for message transmission between a publisher domain and an acquirer domain. Both mobile devices and non-mobile devices can be used in conjunction with the IMPP.
  • the IMPP is not limited to use in connection with the specific system described here and can be used in other systems with architectures that differ from the system architecture described here.
  • the term "interoperable” refers to the interoperations that are performed between the publisher domain and the acquirer domain.
  • the term "publisher domain” (sometimes referred to herein as “publisher”), as used herein, refers to wallet issues. Means of payment are authorized by, for example, banks or are value storage cards. An editor declares a customer valid and the customer has payment methods in his wallet. In some transactions, such as micro payments, a telco or ISP can be a publisher.
  • acquisition berdomäne (sometimes referred to here as an" acquirer "), as used here, refers to institutions that acquire transaction-related data from merchants and send this data to a compensation network for authorization.
  • customer and “buyer” used here refer to the owners of means of payment (e.g. credit cards) who make purchases from a retailer.
  • dealer refers to those who offer goods for sale and / or provide services to a customer against payment by the customer.
  • wallet server refers to a secure repository for payment credentials from cardholders that allow a customer to complete a remote payment transaction from any of the multiple devices.
  • payment server refers to a server that accepts payment requests from the issuer domain (e.g. a customer or wallet server) to merchants. A payment server may also have merchant deployment capabilities.
  • the system requires that a publisher has contracts with consumers and that their accounts (account) handle information.
  • the account information includes payment and security information.
  • the retailer has contracts with retailers and provides payment services.
  • a central processor platform (interop domain) manages interoperability and offers central services such as transaction settlement and billing.
  • This architecture maintains traditional merchant and merchant acquirer workflows and extends the existing payment infrastructure with mobile payments.
  • the system includes a central processor platform (CPP) which communicates with a wallet server and a payment server.
  • the CPP carries out both real time and non-real time processing. For example, the CPP performs routing, OfferlD, search (look-up), currency conversion and transaction management functions in real time.
  • Non-real-time processing includes, for example, micro payment billing and settlement, fee processing and invoicing, and asset distribution.
  • the CPP includes a routing engine for routing transaction related messages between wallet servers and payment servers in accordance with the IMPP.
  • the forwarding machine interrupts the IMPP and forwards requests that include payment transactions as well as responses between external parties. Transactions (macro and micro payments) are therefore carried out by the forwarding machine.
  • the CPP also includes a currency conversion server, which is coupled to an exchange rate file, an offer identification (OfferID) server, which is connected to an OfferlD repository (repository), a search (look-up) server, which is connected to a wallet server (WS) / Payment server (PS) directory and a negative file server, which is connected to a customer and merchant negative file.
  • the CPP also includes back end processing functionality such as micro-payment settlement and billing, and billing and management.
  • the CPP comprises a billing and administration server and a micro payment server, which are coupled to a transaction protocol (lock).
  • the billing and administration server is coupled to a new company rule database, which contains rules for the billing and distribution of investments to companies that are new to the system.
  • the billing and management server is also coupled to a database which contains billing data.
  • the CPP forwarding engine listens to IMPP messages, allowing multiple wallet servers to communicate with multiple payment servers through a single entity. By forwarding payment transactions through the CPP, adding additional participants has no impact on the existing installation and simplifies adding additional participants.
  • the CPP forwarding engine receives external notifications of macro payment entitlements and completes the transaction logs and exchanges notifications of any status changes between the other involved parties to keep the WS, MS and Encorus processor platform transaction logs consistent.
  • the authorization between WI and providers of micro payment means is carried out.
  • the authorizations are therefore transferred to the payment server with the payment message flows.
  • the forwarding machine maintains transaction records and stores all information about a transaction together with a unique transaction ID (transaction ID).
  • the search for the payment server and merchants involved in a transaction is carried out on the basis of an OfferlD (OID) or RangelD.
  • OID OfferlD
  • RangelD RangelD
  • the BasketlD is dissolved and transferred to the MC together with the OID in order to inquire about the shopping basket.
  • the specific retailer determines whether the OID or the BasketlD are used to identify the shopping basket.
  • the combination of RangelD and dealer catalog number is transferred to the MC to inquire about the shopping basket.
  • the participant list contains all MSISDNs and pseudonyms (aliases) of the customers, which are registered for mobile payment.
  • the home wallet server ID (home wallet server ID) is also saved for each MSISDN / pseudonym.
  • the MSISDNs / pseudonyms, which are not entered, can be rejected early by the CPP during processing.
  • the OfferlD identifies a shopping basket. In order to identify the basket information in a comprehensive (cross) WI / MA scenario, the OfferlD is generated centrally. The OfferlD can be used for the mobile payment scenarios for both micro and macro payments. In most cases, OfferlDs are entered via a mobile device with limited capabilities regarding the size of the display and usability of the keyboard.
  • the OfferlD generator generates an OfferlD on request and the OfferlD repository stores generated OfferlDs together with additional data for search purposes and manages the OfferlD lifespan. Subsequent payment transactions can use the same offer for payment transactions (e.g. VM, TV purchase (shopping)). Static OfferlDs can be "rented" by dealers on a monthly or yearly basis. Dynamic OfferlDs mark a temporary offer, have a certain lifespan and are used by a single customer. A dynamic offer is automatically deleted as soon as a transaction is completed or the maximum lifespan is exceeded.
  • the OfferlD repository stores information about a requested OfferlD. If age checks, address changes or GI data transfer are requested, the relevant identifiers are set in the OfferlD repository data record.
  • the OfferlD repository also monitors the issued OfferlDs and sets one OfferlD status to "locked" (black-out) as soon as the associated service life expires.
  • the OfferlD repository also supports manual deletion requests.
  • the search services use the OfferlD repository to find the associated payment server.
  • the merchant negative file either prevents registered merchants from signing up for mobile payment with any merchant acquirer or initiating any transaction in the registered state.
  • the ID, the URL and the dealer name are saved together with a time.
  • the buyer negative file either prevents registered buyers from signing up for mobile payment on any wallet server or initiating any transaction in the registered state.
  • the ID, name, name, date of birth and MSISDN are saved together with a time.
  • CPP Since international transactions are handled by CPP, CPP provides a central foreign exchange (FX) rate acquisition, spread management and a currency conversion service.
  • the CPP calculates amounts in customer currency (if they are different from the merchant transaction currency).
  • the FX server stores foreign currency exchange rates and performs currency conversions to settle international micropayments and fee statements.
  • the wallet server communicates with buyer devices e.g. via device-specific gateways such as WAP and SMS gateways and stores buyer and transaction-related data such as MSISDN, billing and shipping address, credit card numbers.
  • the wallet server provides customer support functionalities and handles payment protocol processing.
  • the wallet server sends authorization requests to a micro payment instrument ( ⁇ PI).
  • ⁇ PI micro payment instrument
  • Each wallet publisher provides at least one micro-payment means, which is either operated by the publisher or is accepted on the wallet server of a third party.
  • the ⁇ PI can be different Type, for example a dedicated value storage account system, a Telco prepaid account or a Telco telephone exchange.
  • the payment server PS processes the IMPP protocol between the CPP and the merchant and processes an open payment protocol (OPP (open payment protocol)) in the direction of a merchant component.
  • the PS is connected to macro payment officers (e.g. credit card payment officers) via a payment gateway in order to forward authorization requests.
  • the merchant component (MC) is integrated in the merchant's purchasing system to enable an OPP.
  • a buyer accesses a merchant's shop, e.g. via a specific purchasing channel (e.g. WEB, WAP, IVR, TV) or reads information and product offers on a vending machine.
  • a specific purchasing channel e.g. WEB, WAP, IVR, TV
  • the buyer uses his mobile phone to connect to a wallet server (access scenario (pull scenario)) or is called by a wallet server (push scenario).
  • the authorization is provided by the mobile phone network and the authorization to pay for any type of payment means (e.g. micro-payment means, credit card, debit card) can be carried out.
  • a 3-domain model defines a process for electronic payments.
  • issuer domain refers to the issuer and owner of bank cards or other means of payment (e.g. publishers and customers) and to those who act on behalf of the issuer (e.g. the wallet server).
  • issuer domain refers to those who acquire payments from a publisher domain.
  • agreement domain refers to the interface between the publisher and acquirer domains to enable interoperations (i.e., processes between the publisher domain and the acquirer domain) for electronic payments.
  • the usual payment flow is described below as a sequence of steps and with reference to FIG. 2.
  • the payment flow described below is based on a a purchase that was carried out via a network such as a wide area network (e.g. the Internet).
  • a network such as a wide area network (e.g. the Internet).
  • a wide area network e.g. the Internet
  • Step 1 Shopping. A customer browses (buys) an offer of a merchant's goods / services. As a result, an order is stored in the retailer's purchasing system.
  • Step 1 Initiate payment.
  • the URL contains information that enables the wallet server to determine the context of the payment (e.g. merchant URL and order identification).
  • the customer provides the trader with the URL of the wallet server (e.g. the customer can select the URL from a drop-down list) so that the trader can compile the correct URL for the reference.
  • the wallet server can at least identify the trader and the order.
  • Step 2. Authorization The customer logs into the wallet server. The authorization is carried out by the wallet server (which in many cases is the same as the publisher). Once the customer is authorized, the customer retains access to the customer data.
  • Step 3 Obtain the order information.
  • the wallet server retrieves the order information (order description, payment amount) from the trader.
  • the merchant also returns the URL of his payment server and the accepted payment methods.
  • the wallet server shows the customer the order data.
  • Step 4. Choosing the payment method.
  • the wallet server represents a list of available payment methods / means from which the buyer can choose, based on the list of payment types accepted by the merchant and the stored payment means of the buyer.
  • the wallet server retrieves the order details and the accepted payment methods.
  • Step 5. Check the payment method.
  • the wallet server first contacts the publisher to verify that the selected form of payment is valid.
  • the publisher can return further data (in addition to a simple yes / no answer) at this point (eg for a one-time token, which is used specifically for the upcoming payment).
  • Step 6 Payment.
  • the wallet server sends a payment request to the payment server on behalf of the customer.
  • Step 7. Review the job.
  • the payment server connects to the merchant's shopping system to verify that the order data received from the wallet server is authentic.
  • the payment server receives all the data needed to process the payment.
  • Step 8 Capture.
  • the payment server forwards the payment data to the acquirer.
  • the acquisition step can be performed asynchronously if a postponed delivery is used.
  • Step 9 Compensation.
  • the acquirer makes a physical payment, i.e. the acquirer executes the payment request through a financial institution in a backend operation.
  • the compensation can take place asynchronously (e.g. in stacks (batches)).
  • the clearing network processes the transaction and the money is transferred to the merchant's account.
  • Step 10 Notification.
  • the payment server notifies the merchant of the success of the transaction.
  • the notification can also be done asynchronously.
  • Step 11 Delivery request.
  • the wallet server provides the merchant with the delivery address. This step can be carried out at other points in the message sequence, e.g. before payment or later, asynchronously.
  • the SET gateway checks the Signature of the cardholder.
  • Current payment systems may also omit some of these messages, or the way certain information is processed may vary, for example, the buyer notification may be returned to the merchant or, in some cases, omitted entirely.
  • the steps can also be intertwined or further split.
  • the protocol includes various sub-protocols. Each sub-protocol has its own defined scope with clear boundaries to other sub-protocols.
  • a sub-protocol is referred to as the interoperable mobile payment protocol (IMPP) and is used for messages between and via the wallet server OpCo and the payment server protocol.
  • the other sub-protocol is the open payment protocol for the exchange of information between the payment server and the merchant system.
  • the IMPP determines the communication between the following components through the OpCo domain.
  • the IMPP introduces a central instance for forwarding messages and other payment-related processing, which are sometimes referred to here as the OpCo domain.
  • the OpCo keeps the central offer data and in certain scenarios finds out the customer's wallet server during the payment initiation.
  • the OpCo (via the CPP) provides the forwarding of payment reports in both directions between a wallet server and a payment server.
  • the wallet server contains core customer data that is primary to authorization and payment, as well as a transaction history.
  • the wallet server is driven during the payment initiation phase (triggered) and subsequently sends payment messages to the Becomposingsser ⁇ ver on the OpCo.
  • the wallet server is notified by the OpCo when the status of a payment transaction has changed and can query the status of a particular transaction to update the transaction history.
  • the payment server keeps the merchant core data for the payment and the transaction history.
  • the payment server also receives payment reports from the OpCo and processes the reports.
  • the payment server sends messages to the authorized person on the part of the acquirer and triggers result notifications to the OpCo and the dealer system.
  • the payment server sends and receives the required information to / from the merchant system during the various phases of the payment process.
  • the term “merchant system” relates to a purchasing system and payment plug (p! Ug-in) components, which are provided on the local domain of a 3D system II-compliant payment system of the merchant.
  • the merchant system sends and receives the required information to / from the payment server during the various phases of the payment process.
  • the merchant system provides a local technical indication of the payment system in the merchant's purchasing system, often supplemented by a shopping plug-in.
  • Step 1 A description of the method or protocol which is used in connection with the messages between the wallet server and the payment server in connection with a transaction follows, as shown in FIG. 3.
  • Step 1. Shopping. A customer searches (buys) goods / services and an order is stored in the retailer's purchasing system.
  • Step 2 and 3 Initialize the offer context.
  • the request is forwarded to the OpCo by the payment server.
  • the offer context is saved and the related OfferlD is sent back to the payment server and the merchant system in the response.
  • the offer context includes information which indicates whether an age check should be carried out and whether a delivery address is required by the dealer.
  • Step 4 View the OfferlD.
  • the buyer is either shown the OfferID to continue the interaction via the (different) payment channel, or the buyer is forwarded to his wallet server via the OpCo (with the same payment channel, not shown).
  • Finding the wallet / payment server URL is done within OpCo and URL if necessary.
  • the URL is not required if the wallet server does not need the payment server address.
  • the payment channel can be different from the purchasing channel. Sufficient information is provided to the buyer to identify the order and to enable the CPP to generate a payment call.
  • Step 5 Enter the OfferlD.
  • the buyer is asked to enter the OfferID received from the store in their wallet.
  • the buyer is identified and authorized on the wallet server by the MSISDN of the buyer's cell phone in the payment channel.
  • Step 6 Payment call.
  • the wallet server forwards the OfferlD to the OpCo and receives the payment request information back. This includes whether an age check should be carried out and whether a delivery address is required from the dealer. The buyer is authorized and receives access to his data.
  • Step 7. Submit the offer. The wallet server looks up the order information (e.g. order description, final payment amount).
  • Step 8 The data is forwarded by the OpCo to the associated payment server.
  • Step 9 The payment server queries order details from the merchant.
  • the merchant system also returns the accepted payment methods.
  • the wallet server then shows the customer the final order data.
  • the message exchange takes place through the OpCo, but not directly to the dealer as in the 3D model.
  • the wallet server therefore does not need to know the retailer's network address.
  • the wallet server also forwards the delivery address to the merchant to recalculate the final payment amount and the result of an age check that may be desired by the merchant.
  • the wallet server receives the order details and the accepted payment methods.
  • the means of payment to be used are selected and declared valid.
  • Step 10 Select the payment method.
  • the wallet server represents a list of available payment methods / means, from which the customer can choose, based on the list of accepted payment methods of the merchant and stored means of payment of the customer.
  • Step 11 Pre-authorization.
  • the wallet server contacts the authorizing officer on the publisher's side to check whether the selected means of payment are valid, to carry out limit checks and to pre-authorize payment in the case of a new company scheme that conforms to interoperable micropayments.
  • Steps 12 and 13 Authorize payment.
  • the wallet server sends a payment request to the OpCo on behalf of the customer. This can include the result of pre-authorization in the case of schema-compliant micropayments.
  • the OpCo forwards the request to the associated payment server.
  • the payment server receives all the data required to process the payment. Step 14. Cross-check the offer.
  • the payment server connects to the merchant's purchasing system to check whether the order data received from the wallet server is authentic.
  • Step 15 Eligibility.
  • the wallet server forwards the payment data in the case of macro payments to the payment authorized person on the part of the acquirer or checks the result of the pre-authorization in the case of schema-compliant micro payments. Both steps 11 or 16 are carried out mutually exclusive in order to authorize payment by OpCo.
  • the clearing network processes the transaction.
  • Step 16 Billing.
  • the payment officer on the part of the acquirer makes the physical payment, i.e. processes the request in the financial end components (financial back-ends). Equalization can be carried out asynchronously (e.g. in batches).
  • the wallet server notifies the merchant of the success of the transaction. Such notification can also take place asynchronously. The trader therefore knows whether the payment was successful and is able to start delivering the goods.
  • Step 17. Delivery.
  • the result of the payment is displayed to the customer. Once the ongoing payment is complete, the customer can continue to interact with the store.
  • a payment slip is typically important for the customer, especially to start accessing the digital content immediately after payment.
  • the goods are delivered in the shopping channel or asynchronously.
  • the wallet server receives a payment receipt on behalf of the buyer.
  • Step 18 through 19 Capture.
  • deferred or split amounts can be recorded and the payment is (partially) refunded or a credit is given asynchronously by the dealer.
  • This action can be triggered by retailers in the purchasing systems and is forwarded to the payment server.
  • the payment request is sent by the payment server to the authorized payment officer forwarded on the part of the acquirer.
  • the money is booked to the dealer and transferred after settlement.
  • Steps 20 through 23 Status notifications and request status.
  • the OPP manages the exchange of information between the wallet server, the merchant system and the payment server.
  • the IMPP manages the communication between these components and the OpCo domain.
  • the OPP specifies additional messages for information exchange via IMPP and the OPP manages the information exchange via the OpCo domain, which depends on the specific purchase and a payment channel or a combination of both.
  • the OPP depends in part on the supported payment and purchasing scenario.
  • the OPP determines the exchange of information between the components involved via the OpCo domain by using the IMPP.
  • the OPP does not manage communication within the publisher and acquirer domains.
  • the OPP message flow is described in the "Payment initiation" phase and the "Post-payment" phase of the 3D model.
  • the "initiation of payment” phase of the model describes the location of the wallet server and the wake-up message.
  • the "postpay” phase describes the notification and delivery process.
  • the OPP does not manage the communication between the customer and the dealer system, since this communication is determined by the dealer or the purchasing system.
  • the OPP hides the payment, the shopping and scenario-specific data so that the underlying IMPP does not have to take this data into account.
  • the OPP uses the underlying protocol to exchange messages between the wallet server and the payment server. This means that the wallet server and the payment server do not support direct network communication. All communication between the wallet server and the payment server is managed by the same IMPP, which manages the entire communication between the three components wallet server, process platform and payment server. Therefore, message pairs must be encapsulated by the OPP in additional messages in order to use the to transfer the underlying sub-protocol. Two new pairs of messages are required for the exchange server (WS Transfer (WSTransfer)) and the payment server (PS Transfer (PSTransfer)). The message pairs are described below.
  • the wake-up call request is issued by the merchant system in order to initiate a wallet attempt in certain payment scenarios. This request is sent to the processor platform, which initiates payment through the customer's corresponding home wallet server.
  • the wake-up call process depends on the combination of the purchasing and payment channels.
  • Delivery request and response message The delivery request is submitted by the wallet server in order to inform the merchant system of a completed payment transaction.
  • the dealer system can use this notification to initiate the delivery process.
  • the delivery process depends on the payment and purchasing scenario.
  • the Resume Request is issued by the Wallet Server to complete an interrupted delivery of online content.
  • the IMPP manages the payment-specific communication between the wallet server, the dealer system of the processor platform and the payment server.
  • the OPP manages the exchange of information via the OpCo domain, which depends on a special purchasing and payment channel or a combination of both.
  • the IMPP is independent of the supported payment and purchasing scenario.
  • the IMPP performs the following functions: It provides a brand transfer between customer and dealer, recalculation of amounts through the dealer system; it provides job information exchange; it provides age testing skills; it provides address exchange with and without payment; it provides an extension mechanism for the exchange of additional information in the defined message flow. supply; it provides payment entitlements including "capture now" facilities for macro and micro payments; it provides an OfferlD administration; and it provides an extension mechanism for the exchange of additional messages through the CPP.
  • Wallet server and between a merchant and the payment server is independent of the IMPP.
  • the IMPP takes no account of the combination of different purchasing and payment channels. Problems resulting from the combination of different purchasing and payment channels are managed by the OPP part of the protocol stack.
  • the IMPP provides a protocol layer to manage global communication between wallet servers and payment servers through a single processor platform.
  • the OPP and IMPP take account of payment, purchasing, customers, dealers or telco-specific requirements.
  • the IMPP provides a mechanism for the transmission of messages from higher protocol layers via the CPP.
  • Different wallet servers or payment server providers are able to extend the function to a higher protocol layer without direct communication between the wallet server and payment server outside the IMPP.
  • Providers of wallet servers or payment servers implement the IMPP for communication via the CPP.
  • the IMPP processes messages between all components involved via the OpCo domain. It does not cover communication within the publisher or the domain of the acquirer.
  • the IMPP processes the message flows described in the "order exchange” phase and "payment” phases of an SD payment phase model.
  • IMPP reports are classified according to different areas.
  • all message pairs in a payment area are interpreted as OpCo.
  • these messages are issued by the wallet server to perform a payment transaction.
  • the OpCo receives the message and interprets its content for transaction logging or fee management.
  • the messages to the payment forwarded for special processing.
  • the corresponding message response is sent to the wallet server via the CPP.
  • the CPP picks up the incoming request and sends a response back to the wallet server.
  • the CPP interprets all messages within this area.
  • Other areas include an extension area, a notification area and an offer area.
  • FIG. 5 shows IMPP messages and each message type would be explained below.
  • the PayPurchase request is submitted by the wallet server in order to initiate a purchase via IMPP.
  • This request is sent to the payment server via the CPP.
  • the CPP acts as a proxy for this pair of messages.
  • the Paylnquire request is given by the wallet server to initiate a request via IMPP. This request is sent to the payment server via the CPP.
  • the CPP acts as a proxy for this pair of messages.
  • the PayStateUpdate request is submitted by the payment server to update the transaction status on the wallet server. This request is sent to the wallet server via the CPP.
  • the WSTransfer request is submitted by the wallet server to initiate a transfer of additional information via IMPP. This request is sent to the payment server via the CPP.
  • the CPP acts as a proxy for this pair of messages.
  • the WSTransfer message pair can be used to transfer messages from a higher protocol layer via IMPP.
  • the content of this pair of messages is processed as an anonymous date by the CPP.
  • the PSTransfer request is issued by the wallet server to initiate a transfer of additional information via IMPP.
  • This request is sent to the payment server via the CPP.
  • the CPP acts as a proxy for this pair of messages.
  • This PSTransfer message pair can be used to transfer messages from a higher protocol layer via IMPP.
  • the content of this pair of messages is processed as an anonymous date by the CPP.
  • the WSNotify request is made by the wallet server to notify the CPP of additional information.
  • the CPP processes the request and replies with an appropriate response. For example, this request is used to inform the CPP about the interruption of the message flow by the customer. In this way, the CPP is able to handle the situation within the CPP, for example deleting the dynamic OfferlD in the context repository.
  • the PSNotify request is made by the payment server to notify the CPP of additional information.
  • the CPP processes the request and replies with an appropriate response. For example, this request is used to inform the CPP of an interruption in the message flow.
  • the OfferCreateContext request is submitted by the payment server to create a new OfferlD in the context repository. After processing the request in the corresponding OfferlD server, a response message is sent back to the payment server. This pair of messages is not visible to the wallet server.
  • the OfferDestroyContext request is submitted by the payment server to delete an OfferID entry in the context repository. After processing the request in the corresponding OfferlD server, a response message is sent back to the payment server. This pair of messages is not visible to the wallet server.
  • the OfferModifyContext request is given by the payment server to change an OfferID entry in the context repository. After processing the request in the corresponding OfferlD server, a response message is sent back to the payment server. This pair of messages is not visible to the wallet server.
  • FIG. 6 shows a valid message sequence for the protocol.
  • FIG. 7 shows an OfferID message sequence.
  • the currency conversion is on the side of the Wallet servers performed.
  • FIG. 8 shows a WAP-WAP micro payment sequence. In FIG. 8 there are two redirects, in particular a redirection to the CPP, which was initiated by the trader, and one to the home wallet server, which is initiated by the CPP was initiated.
  • FIG. 9 shows a WAP-WAP address transmission without a payment sequence and
  • FIG. 10 shows a vending machine macro payment sequence.
  • FIG. 11 shows a static OfferID generation sequence.
  • the OfferlD has the following status.
  • Deactivate The dynamic transaction models for macro payment have in common that the owner of the transaction status is the payment server. In the status model shown in FIG. 12, the transaction states and transitions are used for an immediate macro payment, often referred to as “sales” transactions. No separate step to finance the payment is carried out on the part of the dealer / acquirer.
  • the status model shown in FIG. 13 describes the transaction states and transitions which are used for a macro payment credit. It is used by traders to issue a credit on a macro cash. This is done by merchants to refund payment after the actual transaction has been cleared.
  • the status model shown in FIG. 14 describes the transaction states and transitions which are used when the macro payment is delayed. This is used when the merchant makes an authorized payment with some delay, e.g. when the goods are shipped. If only partial dispatch is possible, the partial entry can be used once or continuously. The customer can track the detailed payment status in his wallet.
  • One state machine is provided for the life of the initial transaction and another state machine is provided for the life of partial transactions.
  • FIG. 15 represents a status model for partial macro payment.
  • a partial macro payment transaction has its own lifespan and the buyer's wallet is notified of all events relevant to partial payment.
  • the dynamic micro-payment transaction models have in common that the owner of the transaction status is the wallet server, due to the fact that the customer's billing system maintains payment until billing.
  • Figure 16 illustrates the status model for the transaction states and transitions which are used for immediate micropayment, e.g. a low value transaction is used, which was initiated at a vending machine.
  • Figure 17 illustrates a status model for the transaction states and transitions used in delayed micropayments. This is used if the trader only partially or several times with an authorized schema-compliant micropayment with very low entry amounts ("Sofort (Instant)” payment, eg "Pay per time” or “Pay per extent (pay per volume) "transactions).
  • Figure 18 illustrates a status model for transaction states and transitions, which is used to execute a micro-payment credit. This is used by merchants to transfer a credit to a customer microbe payment medium. Merchants need this to refund payment after the actual transaction has been cleared.
  • the IMPP message structure consists of a two-layer structure, namely a message wrapper and (an HTTP request or response) and a message (an XML unit (entity)).
  • An IMPP message is processed synchronously and has an XML message element (request / response pair), which is contained in the corresponding HTTP request and response (wrapped). This request / response pair represents a complete protocol conversation unit. If an IMPP message is simply forwarded to another unit by a specific technical function, only the message envelope is processed by the forwarding unit. The message itself can remain unprocessed in order to avoid additional processing above XML syntax analysis (parsing) and writing (writing).
  • the message envelope depends on the protocol used
  • the transport wrapper is a valid one HTTP / 1.0 request header / response header according to RFC822.
  • the HTTP request procedure (verb) used is POST.
  • Figure 19 shows an IMPP message structure.
  • the request and the response to a message are both shown as a serialized XML structure.
  • the XML basic element (root element) ⁇ ImppMessage> contains an XML 'element only' element ⁇ Header> and exactly one request or response XML 'element only' element.
  • the ⁇ Header> element contains the sub-elements Id (for message idepotency) and version.
  • a generic example message is the following: ⁇ ImppMessage>
  • a connection that has been established can be reused after the exchange of a complete protocol conversion unit in order to exclude a TCP connect / accept / close overhead and to increase the efficiency.
  • the HTTP keep-alive protocol is used to coordinate the technical functions involved at the application level.
  • a connection that has already been established can be reused in the same direction, i.e. within the same client / server role allocation.
  • the applications of the wallet server and payment server process recognition (non-repudiation). Either corresponding attributes in the protocol elements or extended elements / attributes can be used.
  • the VPN processes the encryption of all communication between wallet servers and OpCo as well as between payment servers and OpCo. The VPN only establishes connections between two parties that have successfully mutually authorized. The sending of application data requires the authorization process to be ended.
  • the protocol also specifies a version negotiation mechanism between the technical functions, but is independent of the specific version compatibility rules applied.
  • the protocol includes sending the protocol version used in the message header.
  • the version agreement process is shown in FIG. 20 and described further below.
  • Step 1 A payment component sends an IMPP request to the OpCo using the highest IMPP version that is supported by the sender.
  • Step 2 The OpCo checks the version and processes the result.
  • Step 3 a) Check OK: The request is forwarded to the recipient.
  • the payment component sends the IMPP request again using the highest common version or stops with an error.
  • Step 4. The payment component checks the version and processes the result.
  • Step 5 The answer is sent back to the OpCo.
  • Step 6 The OpCo creates an average between own and by versions supported by the recipient and sends cisa error messages back to the sender, which contains this information.
  • the payment component sends the IMPP request again using the highest common version or stops with an error.
  • IMPP flows occur in pairs. Every message sent by a requesting participant is replied to by a responding participant. The flow of errors (in contrast to other flows) is determined with regard to the inquirer and respondent, since this is used when the respondent cannot reliably identify the incoming message. An error indicates that a respondent rejects a message because of a format error or content verification tests have failed. The responder sends an error (rather a negative response code) if the responder cannot trust any of the fields in the incoming message. Typically, an error is used to respond directly to the sender of a message if it is not possible to clearly limit the error to an incorrect value of a field. The error message is not used to display normal business results such as a denied authorization. Business results are displayed using explicit codes in standardized response messages.
  • IMPP messages may be grammatically determinable (parseable) but malformed by not following the protocol requirements, values may be incorrect, or messages may be corrupted, usually as a result of transmission errors.
  • duplicate messages enough information appears in the plain text of the message cover so that it can be found out whether a message is a retransmission or not.
  • the response of the recipient to a double Message depends on the indemotency property (described in detail below) of the message type, the number of doubled messages, the source of the double messages and the observed frequency between subsequent double messages. If a system is suspected of being exposed to flooding or ad fraud, duplicate messages can be ignored.
  • a damaged message is a message that cannot be parsed. Typically, a possibly corrupted message should not be received because the message transport mechanisms cause corrupted data to be returned. However, if a damaged message is received, a corresponding error message is returned, which indicates that a damaged message has been received and provides a request / response pair identifier of the message if it is available. It is accepted to ignore the message completely if insufficient data has been extracted to be able to respond to it. With regard to malformed messages, a corresponding error message is returned by the sender if a message can be determined grammatically but is otherwise incorrect due to values outside of a range or inconsistent options.
  • An application does not generate an error message in response to another error message. All IMPP components send an error message if a low-level processing error occurs on an IMPP response avoidance. Any message that is not recognized as an IMPP message is ignored. The IMPP components usually avoid sending error messages on the same channel as request messages.
  • ErrorCode Numbered code that defines the error condition.
  • ErrorDescription A free description of the cause of the error.
  • ErrorObjectID The object identifier of an unsupported critical extension that triggered the error.
  • ErrorMessage The message that generated the error.
  • the IMPP protocol is based on request / response pairs throughout the protocol.
  • the error message does not conform to this paradigm because it can be an answer to either a request or an answer.
  • the former case is not a problem.
  • difficulties can arise if the underlying transport is based on a request / response paradigm, as in a World Wide Web browser.
  • the error message can be sent as a request message and the protocol will not request a response message (the underlying protocol can be time out). User permission may be required for an error message sent as a result of the operational limitations of a World Wide Web browser.
  • the HTTP message header contains a status code which indicates the processing status of the corresponding message unit as a whole. Each business error is indicated by the components regardless of the notification status.
  • the following status codes are defined as a specific message, which the 5xx status code areas of the HTTP standard use to display application-specific errors.
  • the XML body of the HTTP response is omitted.
  • the application-independent status codes as defined by HTTP are used for all HTTP-specific outputs (eg 400 bad requests).
  • idempotency is a property of how a recipient replies to a message. Every request in the IMPP that does not receive a response is sent again because the sender does not know whether the request or response was lost. The transmitted message is bitwise identical to the original request message. Usually a double message is not an error condition.
  • the IMPP protocol works in environments where reporting is not guaranteed. If an IMPP application does not receive a response in a reasonable amount of time (determined by the application or possibly in response to a user question), it sends the message again. If the received IMPP application determines that it has previously processed the same message, it retrieves the previous response and sends the previous response again. If the sender of a message does not receive the response, it is usually not possible to determine whether the request or response has been lost. To further complicate this condition, the original request may simply have been delayed anywhere in the network and then possibly processed shortly before the retransmitted request arrives. Therefore, the protocol allows the sender to repeat the request with the guarantee that the result will be the same regardless of whether the request or response was lost.
  • the IMPP contains messages that are designed so that they can be sent at any time, so that it is not necessary for a recipient to save every request to determine whether a duplicate has been received.
  • the IMPP products guarantee the identity of the protocol by checking a transaction ID and generating a time stamp in the message header. For example, a payment server refuses attempts to repeat pay authorization requests from a wallet server. The payment server recognizes these attempts by checking the message header of the Authorization request. If an IMPP component detects that it is exposed to malicious flooding or adware attacks that involve no or more idempotent IMPP message types, it is not necessary to respond to these messages in this situation.
  • the IMPP component can use any method to identify idempotent requests.
  • One possible method is to store the SHA-1 hash of the message header for all messages. If a duplicate is recognized, the hash of the message header can be generated and used to look up a stored Idempot entry. In this approach, the IMPP component must keep a full copy of every incoming request, but can produce a bit-by-bit identical response. A bit-wise response is generated here as a new response with the same information. If multiple responses to an idempotent request are received, the recipient can ignore all such responses after the first.
  • An IMPP component is not required to respond to messages if it detects that it is exposed to malicious flood or adware attacks that involve one or more types of IMPP messages.
  • the IMPP components can build their own criteria for detecting such attacks.
  • a protocol extension is used.
  • the mechanism used to extend IMPP messages is the same as how X.509 certificates are extended.
  • an extension field is made available which contains a sequence of extension data.
  • the extension data indicate the type of extension and the criticality of the extension.
  • An extension has three components.
  • an object identifier that uniquely identifies the extension. This identifier allows IMPP components to recognize an extension and to process data.
  • a criticality indicator indicates whether the recipient understands the extension to process the message that contains the extension.
  • the data provide the additional business information, which makes it necessary to define the extension. The interpretation of the data is determined by the organization that created the extension.
  • the criticality indicator is a boolean value. An extension is considered critical if this value is True. Otherwise the extension is classified as uncritical. The default value is False. If an extension is critical, recipients of the report recognize and process the extension. If an extension is not critical, recipients who cannot process the extension can safely ignore the data. A set of information objects was created for each data structure, which can contain an extension. These records define the extensions that are allowed in the data structure for processing.
  • IMPP applications fall into one of two categories. In particular, in an application that does not support message extensions and in an application that supports some selected sets of message extensions.
  • An IMPP component that does not support message extensions detects the presence of an extension in a message and checks the criticality indicator. If the extension is critical, the IMPP component does not process the message and rejects it with an error code unrecognizedExtension. If the extension is not critical, the application can ignore the data in the extension and process the rest of the message.
  • An application that supports message extensions detects the presence of an extension in a message and processes the extension as follows.
  • the application does not support the object identifier for this avoidance and the extension is critical, the application does not process the message and rejects it with an unrecognizedExtension error code.
  • the OpCo is the ultimate decision-making body as to whether a given data element is encrypted within a message.
  • the OpCo can do that
  • Extension Refuse to use any extension that contains data that may affect the integrity of the IMPP.
  • Each extension is identified by its extension name, owner name, and a unique extension identifier.
  • An IMPP component can decide to add a critical extension to carry additional information in the normal IMPP message flow to use. If the receiving IMPP component does not understand the data without the extension and therefore cannot process it, the message should be rejected.
  • transaction management is distributed, i.e. a wallet server and payment server involved in a transaction communicate using IMPP messages.
  • Both servers contain a status mechanism, e.g. Waiting for replies, checking for interruptions (time-out) and sending query and recovery messages in the event of errors.
  • the CPP also maintains status information because IMPP messages are forwarded by the CPP.
  • the "owner" of a transaction is the party responsible for the primary status transitions during the life of a particular transaction.
  • the synchronization mechanism used depends on the technical ownership of the transaction. There are different possible ownerships for different payment models supported by IMPP, as described below.
  • the IMPP provides the corresponding messages or message sequences to support the payment model. There are at least two different ways to synchronize transactions using IMPP.
  • Notify the distribution of information about a status transition is carried out by the owner of the transaction.
  • Synchronize The distribution of information about a status transition is triggered by a remote participant of the transaction.
  • Notify / Confirm is available if it is supported in the corresponding protocol flow. If available, only one notification is made per transition. As a result, unacknowledged notifications from the owner are not considered.
  • the synchronization is available for remote participants in order to query transitions to a final status several times. The statuses and their transitions are described in detail from the protocol perspective, which means an abstraction from the implementation in the payment components. If a component needs the "history" of a status, i.e. the transition that leads to a status, the component can instead maintain a 'composite state'.
  • each payment component defines its own way to delete transactions, i.e. to convert a particular transaction from an ultimate business status to an ultimate technical status. This is done asynchronously and is not covered by IMPP protocol messages.
  • CPP components that perform centralized tasks, such as the OfferID generator, the search (look-up) service and the FX server, are used by the forwarding engine to support the payment process.
  • Transaction log entries are created to meet legal requirements and to enable decoupled (offline) mode processes such as billing.
  • Address change inquiries, age verification inquiries and inquiries about changing the means of payment are also supported together with regular payment inquiries. Quality marks are transmitted together with these inquiries / answers and indicate the level of quality of the underlying data.
  • the forwarding engine receives external notifications of macro payment entitlements and acquisitions, completes the transaction logs and status change exchange notifications between the other involved parties to keep WS, MS and CPP transaction logs consistent.
  • the redirection engine provides a redirection component which processes redirects 1 in which the customer's browser moves from the merchant URL to his or her home wallet URL via a CPP URL and directly back to the merchant URL is redirected after the transaction is completed.
  • the redirection component provides a central redirection URL, which traders can usually use to display the OfferlD.
  • the buyer can enter MSISDN / pseudonym / alias in a familiar environment to enable push-back or fall-back scenarios (if MSISDN cannot be recognized).
  • the redirection component forwards the buyer's pseudonym to the wallet server.
  • the WS then triggers an IVR call (WAP) to the buyer.
  • the redirection component should not be used for non-mobile customer authorization (web-web scenario), for example with a pseudonym PIN, because customer authorization is the responsibility of the wallet server.
  • the redirect engine supports redirects, in which the customer's browser redirects from the merchant URL to his home wallet URL via an OpCo URL and directly back to the merchant URL after the transaction is completed is redirected.
  • the CPP provides a central URL to display the OfferlD. Therefore, the retailer does not need to integrate the OfferlD display into the purchase flow.
  • this URL provides input fields for MSISDN / pseudonym to initiate a start.
  • Each transaction by the CPP is checked to see if the type of transaction is 'under us', in which case the 'under us' flag is set within the transaction record (affects both variants).
  • the initiated payment flow is ended by sending the PS search information to the WS.
  • All requests originating from either the wallet server or payment server are logged together with the ID of the corresponding wallet server or payment server.
  • the logging of 'among us' transactions is done in the same way as for schema transactions, but the 'under us' indicator is set.
  • the search service performs searches for the wallet server and payment server on request. Based on an OfferlD, the search service determines the corresponding payment server by searching the OfferlD repository. In the opposite direction, the home wallet server can be accessed by accessing the subscriber list.
  • the search for the PS and retailer involved in a transaction is based on the OfferlD or RangelD.
  • the BasketlD is resolved and transferred to the MC together with the OID in order to request the shopping basket.
  • the retailer decides whether the OID or the BasketlD is used to identify the shopping basket.
  • the combination of RangelD and dealer catalog number is transferred to the MC in order to query the shopping basket.
  • the participant list contains all MSISDNs and pseudonyms of the buyer who is registered for mobile payment.
  • the HeimgeldbörsenserverlD is also saved for each MSISDN / pseudonym.
  • the wallet server instances use online inquiries or generate a flat file that contains all new or changed participants and transfer the file to the OpCo to update the participant list.
  • Pseudonyms are generated on the WS in accordance with the alias generation rules (3 digits identify the WI, 8 digits as the buyer ID and a checksum number).
  • the OfferlD server component of the CPP comprises the OfferlD generator, which generates an OfferlD on request, and the OfferlD repository, which saves generated OfferlDs together with additional data for search purposes and manages their lifespan.
  • the OfferID numbering system ensures, depending on the number of OfferIDs used at a certain time, that the number of digits used can vary in order to always provide the smallest possible number. For some mobile payment scenarios, the size of the OfferlD is not critical at all (e.g. bank nodes). Depending on the requested service life, the following table shows the minimum length of an OID:
  • the length of the OfferlDs (table above) is configurable. Depending on the contract with a dealer, certain areas of OfferlDs can be reserved for a dealer. The dealer pays a usage fee for the area and can use any (catalog) number after the area code to map the ID for his offer. By using this mechanism, the dealer can reuse existing catalog numbers by simply adding up his specific dealer prefix.
  • Checksum tests enable the wallet server to check an OfferlD immediately and to request additional user input without having to communicate with the CPP. The probability of accidentally identifying another active shopping basket by incorrectly entering an incorrect OfferID should be low enough to make the risk tolerable. At least a single wrong digit, additional / missing digits and mixed up digits can be recognized. The checksum digit is not available for RangelDs.
  • the prefix (not necessarily a whole number) carries certain tax information, where it is important to call it up directly from the OfferlD without access to the OID repository.
  • the CPP_ID is encoded in the OfferlD prefix to enable OID forwarding.
  • the OfferlD generator generates OfferlDs on request. Static and dynamic OfferlDs can be generated. OfferlDs are issued once. Subsequent payment transactions can use the same offer for payment transactions (eg VM, TV purchase). Static OfferlDs are 'rented' by traders on a monthly or yearly basis. When the rental period expires, the OID switches to the 'black-out' status, from which the OID can be reactivated if the dealer continues the rental agreement. The trader must handle the parallel use of the static OID. OfferlDs identify a temporary offer with a certain lifespan and are used exclusively by a single customer.
  • An offer is automatically deleted as soon as a transaction is ended or the maximum lifespan is exceeded.
  • Bank node scenarios use, for example, a dynamic OfferlD with an extended lifespan. If a customer cancels a transaction after entering the OfferlD, the OID is not deleted. However, all OfferlDs can be explicitly deleted on request.
  • an OfferlD is determined by the dealer upon request for dynamic OfferlDs. After the lifespan has expired, the status is set to 'lock (black-out)'. The maximum lifespan will be one month. OIDs cannot be reissued during the blocking period. The lockout period is configurable and depends on the lifespan of the OID:
  • the merchant can set certain attributes to indicate the type of request (payment, age verification, address transfer, PI transfer of details).
  • the retailer can issue a list of brands to support brand matching with PI detail transfers.
  • the shopping basket can be connected to the offer.
  • the OfferlD is determined by the dealer upon request for a static OfferlD. After the rental period has expired, the OfferlD status is switched to 'blocked'. The minimum rental period is 1 month. The rental period begins with the generation of the OID, not with activation.
  • the request for a single OID can be made by the MC (same for dynamic OIDs). Because the shopping basket is transferred with the request, the static OID is automatically activated after the request.
  • the trader can request batch generation of OfferIDs according to the CPP numbering scheme. This request is carried out by the dealer self-service and not directly by the dealer component. As a result, the dealer receives a file that contains all generated OIDs and the expiry date of the rental period.
  • the retailer has the opportunity to reuse existing catalog numbers with the mobile payment scheme.
  • the dealer Upon request for a RangelD, the dealer specifies the number of sub-IDs that he wants to use. The dealer is identified during the search. The combination of RangelD and catalog number is forwarded to the retailer to receive the shopping basket.
  • the OfferlD repository contains all information about requested OfferlDs. If age checks, address exchange or PI data transfer is required, the relevant flags are set in the OfferlD repository record.
  • the OfferlD repository monitors the issued OfferlDs and sets statuses to 'lock' as soon as an associated lifespan expires.
  • the OfferlD repository also supports the manual deletion of inquiries.
  • the search service uses the OfferlD repository to inquire about related payment servers.
  • the OfferlD repository supports the deactivation of OIDs.
  • the MC only allows deactivation for individual OIDs. This feature can also be used if an item is temporarily unavailable or the retailer wants to have an extended blocking period. The deactivation does not extend the rental period. If several OIDs have to be deactivated, the MSS is used.
  • the repository supports changing static OIDs (ie linking other BasketIDs, change request types or extending the rental period).
  • the repository supports batch modification of static OIDs (ie linking of other BasketIDs, change request types or extension of the rental period). This request is carried out by the MSS.
  • a single OID can be activated. Multiple OIDs can also be activated by the MSS. In order to carry out such an activation, the dealer loads a list of BasketIDs together with all other request parameters. After the OID block has been generated, the dealer receives a location file.
  • the OfferlD repository automatically deletes OIDs when the lifespan expires or when a transaction is ended. A buyer's termination does not result in the OID being deleted.
  • the OID repository also allows the deletion of OIDs in simple (single) and batch (batch) mode. With dynamic OIDs, deletion results in immediate removal, while with static OIDs, deletion sets the OID status to 'lock (black-out)'.
  • the MSS enables the trader to restore an OID with the status 'blocked'. Static OIDs must be blocked when the lease expires. During the blocking period, the dealer is able to reactivate the OID by asking the MSS to extend the rental period.
  • the negative file service provides a central and common (consolidated) database to block traders as well as customers.
  • the wallet server and payment server instances can check against the database on the basis of a query, just as can synchronize their local negative file directories with the negative file service on the processor platform.
  • a single trader can be added to the negative file together with a time entry.
  • the negative file can be checked to determine if a record exists for a single trader.
  • a dealer-acquirer can trigger this check from outside.
  • a single dealer can be removed from the negative file.
  • a list of dealers can also be imported into a negative file. When a Dealer is already listed in the negative file, the associated data record is skipped. Merchant file records in the file can also be flagged for removal. These dealers are removed from the negative file during the import.
  • a dealer negative file can also be exported. For example, a file can be downloaded (downloaded) or transferred to a dealer-acquirer to update a local negative file.
  • a single buyer can be added to the negative file along with a time entry in the record.
  • the negative file can be checked to see if it contains a record of a single buyer.
  • a purse issuer can trigger this check from outside.
  • the CPP can also check every transaction against the internal negative file.
  • a single buyer can be removed from the negative file.
  • a list of buyers can also be imported into the negative file. If a buyer is already listed in the negative file, the associated data record of the file can be skipped.
  • Buyer records in the file can also be flagged for removal. These buyers are removed from the negative file during the import.
  • a file that contains all negative file records that have been generated after a certain time can be exported. This file can then be downloaded or transferred to a wallet issuer to update a local negative file.
  • the system supports three different currencies: the currency on which the transaction is based; the registration currency of buyers at WI; and the currency that the MA settles with the CPP.
  • the amount of a transaction from the transaction currency to the WI settlement currency is calculated before the authorization of the Customers and deduction converted by the SVA. Since both currencies are displayed to the customer and the SVA is deducted based on the underlying exchange rate, there may be currency risks that are covered by additional exchange rates.
  • the OpCo contains a currency risk if a ⁇ PI is justified if the settlement with the MA cannot be carried out on the same day. In these cases, the OpCo can add a surcharge to the exchange rate.
  • the currency conversion table stores currency rates.
  • a record is generated for each currency pair (EUR / GBP) and (GBP / EUR).
  • the time stamp stores the information of the last update of the data record. Additional status information can be saved in the 'Status' field (e.g. expired).
  • the currency conversion table is updated on a predetermined regular basis by contacting an exchange rate service provider and importing the updated exchange rates into the conversion tables. The timestamp and status are also updated.
  • the status field of the currency conversion table is set to 'expired' 1 when the currency pair has been updated for a certain number of days (ie one day, configurable). Expired currency pairs have no influence on the currency conversion.
  • the conversion table can be exported to a file that can be downloaded by the wallet provider or the OpCo finance department.
  • the courses include the OpCo surcharge.
  • An example table is shown below.
  • Timestamp status (current, expired) With regard to the spreadsheets, additional OpCo spreads are stored in an additional spreadsheet (ie a spreadsheet). A record is generated for each currency pair (EUR / GBP) and (GBP / EUR). The time stamp stores the information of the last update of the data record. Additional status information can be saved in the 'Status' field (eg expired). Administrators can update markup percentages for currency pairs by transferring a flat file to the FX server, which is then imported into the markup table.
  • An example of a surcharge table is shown below:
  • the CPP converts amounts based on exchange rates and CPP surcharge and transfers the amounts in TX currency, converted currency, and conversion rate. With this process, the exchange rate synchronization can be omitted because the most current exchange rate is used.
  • Currency conversion is carried out in accordance with the rules of the European Central Bank (ECB European Central Bank)). When units of national currency are expressed in EUR, the amount includes six numbers before and / or after the decimal point. When converting the currencies into EUR, interim results are calculated to a minimum of 3 decimal places (after the decimal point). Currency amounts that are shown in EUR are rounded up or down to the nearest euro cent.
  • Administrative facilities for OpCo administrators and the finance or securities department of OpCo are provided. This facility Examples include managing the process for getting exchange rates via the defined interface to the exchange rate provider, setting rules for updating the status, viewing and manual editing of exchange rates, viewing and manual editing of exchange rate surcharges and viewing the exchange log and historical data.
  • the administrator alerts certain event triggers. For example, the following event triggers trigger messages to the administrator:
  • the administrator receives alarms as a message in the administrator GUI. In addition, he can choose to also receive alarms by email or SMS.
  • the administrator uses the administrator service GUI to access detailed error lists / reports. Detailed error messages are not transmitted with a notification.
  • Log events only with key attributes Log events only Log errors only.
  • the log files are stored for processing for up to three months.
  • the transaction logs are then archived for 10 years. All operational processes comply with legal requirements, such as the Data Protection Act.
  • a NewCo data protection strategy should be established and made binding for all NewCo participants in order to increase buyer confidence.
  • the CPP Compensation and Billing (C8-S) service processes compensation requests initiated by dealer acquirers, collects amounts to be settled by the MA and settled with the ⁇ PI provider. Additional billing data records and information are generated in order to make billing details available to all ⁇ PI providers (WI and MAs). The transfer of funds is triggered on a general ledger system.
  • the clearing and billing service supports both single currency billing and multi-currency billing. With multi-currency billing, the MA is billed in different TX currencies. For each MA, the main data record shows all the accounting currencies of the MA and whether the MA was selected for single or multi-currency accounting.
  • preprocessing Mediation and coordination
  • Collecting PIs and MAs can be done in parallel.
  • the result of the process is documented in a settlement report (including error codes) and a 'aggregation table', which is used for posting in the general ledger.
  • the dealer-acquirer initiates C-S by sending the compensation file containing the registration / authorization token to the CPP-C&S service.
  • the C8 ⁇ S service reconciles the MA clearing file with the internally collected transaction logs.
  • a settlement report is generated to inform the trader of all transactions that are being settled and of all rejected transactions.
  • a TX clearing data record contains the AcquisitionID, PaymentMediaD, TransactionID, amounts and the processing status as described below:
  • Transaction data from the MAs are compared with the internal CPP-TX protocols belonging to the same time period for validation purposes. Data records that do not match are collected in an error file.
  • the error file serves as the basis for error detection and the parts that are to be assigned to a special employee are copied into the employee's billing report. Four classes of matching results are possible.
  • TX incompatibility incompatibility between data belonging to the same TX in the accounting file and in the EPP TX protocol.
  • Missing TX The EPP TX protocol contains an entry that has a counterpart in the MA's accounting file. (The log record is marked with "missing TX” if a collection for compensation was not received within a certain time, e.g. a week; "garbage collection").
  • the compensation with the MA provider takes place according to the MA compensation process.
  • Reconciled transaction records of the preprocessing procedure are collected for each merchant acquirer.
  • the collection process leads to an MA billing report and provides the basis for the MA billing (aggregation table).
  • the collection table stores amounts that were collected over a certain accounting period.
  • the format of the collection table is shown below:
  • a separate collective table is calculated for each billing currency.
  • the collective table forms the basis for the posting (instructions for billing) and part of the billing report is sent to the MA.
  • the settlement report contains results of the reconciliation and collection steps (including error messages) with regard to a special dealer acquirer. According to the report process, the billing report is saved in the corresponding MA directory (probably daily).
  • the compensation with the ⁇ PI provider is done according to the PI compensation process.
  • Reconciled transaction records from the preprocessing procedure are collected for each payment method provider.
  • the collection process leads to PI billing reports and provides the basis for the PI
  • the collective table is the basis for posting (initiation of settlement) and part of the settlement report is sent to the PI provider.
  • the settlement report contains the results of the reconciliation and collection steps (including error messages) regarding a payment method provider.
  • the accounting report is saved in the corresponding PI directory (probably daily).
  • the CPP-C&S service triggers the G / L system to initiate the physical transfers of funds to the MA and from the ⁇ PI provider.
  • the OpCo settles gross amounts with the PI provider (car payment). Fees are billed separately.
  • the CPP scrolls through the PI collective table for PI posting and creates a flat file with posting data records (eg direct debit inquiries) for batch input to a G / L system (eg SAP FI) and sets the indicator for the associated log records and the collection table.
  • posting data records eg direct debit inquiries
  • G / L system e.g SAP FI
  • the CPP scrolls through the MA collective table and creates a flat file with posting data records for batch input to a G / L system (e.g. SAP FI) and sets the indicator for the associated log data records and the collective table.
  • SAP FI e.g. SAP FI
  • the G / L prints invoices and instructions and initiates transfers of funds.
  • the transfer of funds can follow a different process than posting, for example, depending on the value to be settled.
  • the reconciliation step identifies incorrect transactions which are stored in an error TX file. An attempt is made to correct errors manually. Results of this error correction step (eg 'corrected', 'rejected' 1 ) are included in the corresponding MA billing report. Rejected data records are marked with error codes.
  • reports are generated to track the correct processing of billing-related data and to detect suspicious behavior (eg there * s Deleting collection tables, manual Buchun- gene, log file manipulation).
  • intelligent deception detection algorithms can be used to update negative files, eg user profile checks: detection of unusual user behavior, suspicious increases in a user's turnover, payment location checks: checking whether payments came from distant locations within a short time.
  • a process mechanism triggers the switching, the coordination and MA and ⁇ PI compensation.
  • the booking step can be planned for each MA or ⁇ PI.
  • the booking process and the threshold for the minimum settlement amount are stored in the main data record. The administrator monitors the correct process and manually triggers processing steps if this is necessary.
  • a batch process (e.g. daily, weekly, monthly) is carried out for billing transaction fees, since the number of transactions can be very high, i.e. in the range of several million a day.
  • the task of fee processing can be split into the following steps, as shown in FIG. 26.
  • the rating catalog contains event definitions and pricing / rating information. Rules for special fees (e.g. monthly fee) and discounts are stored in the calculation catalog. Stored procedures define processing and billing periods and trigger the various processing steps.
  • the invoice detail repository contains the cleared events and forms the basis for detailed reports such as EPA (electronic payment advice). Invoices are sent to the G / L to initiate billing (payment run).
  • a mediation module keeps track of the log files that are received from various log file sources.
  • the main source is the daily log files from the processor platform routing module.
  • Other sources include data that could not yet be processed, e.g. corrected records from the rejected and returned processes.
  • the data is filtered and possibly reformatted.
  • measuring means to assign a price to each event.
  • a valuation table is used to set the prices for each event class.
  • the evaluation table is generated before the evaluation process is started and remains unchanged during at least one billing period.
  • An individual evaluation table can be used for each invoice or instruction recipient, depending on the individual business agreements between OpCo, NewCo, the MAs, PI providers and the WIs.
  • the fee structure is designed in such a way that it is generally sufficient to cover all fees that usually occur in transaction invoicing.
  • Transaction pricing may depend on the actual number of transactions and the average value of the merchant or merchant acquisition payment transactions.
  • a general approach to covering such a fee structure is to use a price table in matrix form.
  • Event type (OfferlD request, address verification, recording, etc.) payment channel (WAP, IVR, SMS)
  • the settlement currency (a separate price table for each currency can be used if an MA has been selected for multi-currency settlement).
  • IMPP expansion messages volume-related, for example per message or per kilobyte
  • Other central services tbd.
  • ie PayPurchase request ie PayPurchase request
  • currency conversion ie PayPurchase request
  • PS search ie PayPurchase request
  • the billing process gathers all rated events related to an account (receivable or payable) in a single billing record. Recurring participation fees or special fees are added up and discounts are deducted. Special fees and discounts may vary for each instruction recipient.
  • the evaluated events are compiled by invoice (receivable accounts / affordable accounts) and the fees are collected. A valued event that contains multiple sub-fees is part of multiple invoices. Discounts or other fees (e.g. participation fees) are added to each invoice.
  • the invoices contain the total amount to be calculated (credited or collected).
  • the invoice detail reports contain the data records that are used to calculate an invoice for a special recipient.
  • the files of the invoice detail reports are sent to the participant on request.
  • the invoice instructions contain collected items in an invoice. Formatting and issuing instructions is subject to the general booking system.
  • the booking initiates the collection of charges and the distribution via the main booking system. Invoices are marked “booked” as soon as the booking has been initiated. At the end of the billing cycle, all invoices are transferred to the general ledger (payment run).
  • invoice details are marked “delivered” or invoices are marked “booked"
  • the data is archived in a mass storage device.
  • Archived transaction logs and invoice files form the basis for the settlement of disputes.
  • the CPP provides an access interface to the logged transaction details and invoice details for the disputed managing authority available, such as a customer care center. Disputes regarding the collection and distribution of fees (transfers of funds) are managed by downstream services (back office). Deception detection reports should also be generated in order to track the correct processing of invoice-related data and to find suspicious behavior (eg deletion of invoice files, manual postings, manipulation of log files).
  • the Securities Department uses a General Ledger (G / L) system to manage fee collection and distribution bookings and micropayments.
  • G / L General Ledger
  • the clearing and billing service and the billing machine initiate bookings on the G / L system.
  • Bookings can be made to reception customers and payment customers of OpCo, NewCo, all WIs, PI providers and MAs.
  • Recurring bookings are made for each micro-payment billing cycle and for each billing period (daily, weekly or monthly). Instructions are printed for each booking (micro-booking billing or billing) and sent to each recipient. Physical transfers of funds to / from MA, to / from WI and to NewCo bank accounts are initiated. Micropayments with MAs should not be done until the ⁇ PIs receive payment.
  • Irregularities in the flow of funds are tracked and reported, and calls are generated automatically when funds transfers are late.
  • the G / L operator can request reports on cash flow and pending cash transfers (for cash management). In the event of incorrect postings, retransmissions can be be initiated manually due to incorrect fee calculations.
  • Connection data address, telephone, email, etc.
  • ID payment server address URL
  • Internal G / L booking account number Bank account number
  • Billing and billing processes (possibly multiple) Billing currencies status (registered, active, inactive, deleted)
  • Connection data (address, telephone, email, etc.) ID
  • connection data address, telephone, email, etc.
  • NewCo main data name Connection data (address, telephone, email, etc.) Internal G / L booking account number Bank account number
  • Billing and billing processes (possibly multiple) billing currencies status (registered, active, inactive, deleted)
  • connection data address, telephone, email, etc.
  • the administration service encapsulates the diverse administration facilities of the various components, provides a single sign-on for the administration user and logs of all user activities. The following administration tasks are carried out centrally since they are valid for all CPP components.
  • the security manager has exclusive access to security and system logs to review system operations and detect inside delusions
  • the main data administrator creates and changes main data entries and changes the status of the shareholders (e.g. active / inactive),
  • the customer care role assigns these access rights to the main data, transaction logs, billing details and settlement reports.
  • the customer and dealer validity check during the registration process is carried out centrally.
  • the WS sends a test request to the CPP for each customer.
  • the CPP carries out the validity check by checking information such as name, address and age.
  • the test result is sent to the WS together with a quality indicator that indicates the service used for the validity check (this can be based on agreements between the CPP and WI / MA).
  • IMPP interoperable mobile payment protocol
  • the protocol has a core or base layer (IMPP Core Layer) and an extension layer (IMPP Extension Layer), whereby for the former the actual payment area (payment ranks), the context identifier area (OfferlD ranks) and the message area (Notification ranks) belong.
  • the extension layer includes optional requests and responses between the customer and dealer server instances. It also enables a communicative connection to third customer servers. Communication between the customer and the customer server on the one hand and the provider and dealer server on the other is outside this protocol.
  • FIGS. 29A to 29C, 30A to 30C, 31A to 31C, 34A to 34C and 36A to 36C for essential types of transactions or payment transactions are self-explanatory.
  • FIGS. 32A and 32B and 33A and 33B This also applies to the processes illustrated in FIGS. 32A and 32B and 33A and 33B during the generation and the deletion or destruction of a static offer.
  • FIGS. 35A and 35B The steps and aspects of a clearing procedure illustrated in FIGS. 35A and 35B depend on whether a so-called merchant acquirer is involved or not. They follow the organizational practices of established clearing procedures in conventional money transactions.
  • Figures 37 to 40 are essentially self-explanatory due to their labeling, so that an additional verbal description is not necessary.
  • the following abbreviations apply:

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Verfahren zur Ausführung einer Transaktion auf einem System, das mindestens eine Zentralprozessorplattform, mindestens einen Geldbörsenserver und mindestens einen Bezahlungsserver aufweist, wobei die Zentralprozessorplattform eine Weiterleitungsmaschine, die per Kommunikationsverbindung mit dem Geldbörsenserver und dem Bezahlungsserver gekoppelt ist, aufweist und das Verfahren diese Schritte aufweist: Empfangen einer Transaktionsanfrage am Bezahlungsserver oder am Geldbörsenserver, Weiterleiten der Anfrage vom Bezahlungsserver oder vom Geldbörsenserver an die Zentralprozessorplattform und Betrieb der Zentralprozessorplattform, um die Transaktion durchzuführen.

Description

Bezahlunqsprotokoll sowie Datenübertraqunqsverfahren und -anordnunq für Bezahlvorqänqe
Beschreibung
Diese Erfindung betrifft im wesentlichen Bezahlungssysteme und im besonderen ein Protokoll zur Abwicklung von Nachrichten zwischen mehreren Geldbörsenservern und Bezahlungsservern vieler verschiedener Anbieter.
Händler und Dienstleister sind in zunehmendem Umfang in Geschäftsabläufe einbezogen, welche über mehrere Kanäle ausgeführt werden. Im herkömmlichen Rahmen besucht z.B. ein Kunde ein Kaufhaus, sucht einzukaufende Gegenstände aus und verlässt (checks out), d.h. kauft die Gegenstände an der Registrierkasse des Händlers. Der Kunde zahlt typischerweise für die Gegenstände bar, mit Kre- ditkarte oder Scheck.
Ein Händler kann jedoch möglicherweise den Umsatz durch Verbessern der Kundenfreundlichkeit beim Einkaufen von Waren und Dienstleistungen erhöhen. Als ein Beispiel können Kunden, welche Gegenstände über das Internet einkaufen, auch wünschen, die eigentliche Transaktion ebenso über das Internet durchzuführen. Dadurch, dass Kunden Waren über das Internet einkaufen können, ohne physisch ein Kaufhaus betreten zu haben, kann ein Händler Umsätze steigern und mehr Zuspruch (good will) finden. Wird die Transaktion jedoch nicht richtig und zeitig durchgeführt, kann der Händler tatsächlich Umsätze und good will einbü- ßen.
Eine weitere Händlern zur Verfügung stehende Kundenfreundlichkeit besteht darin, Kunden selbst dann Einkäufe zu ermöglichen, wenn der Kunde kein Bargeld, keine Kreditkarte oder keinen Scheck bei sich trägt. Z.B. erlauben bekannte Sys- teme einem Kunden Einkäufe mittels drahtloser Geräte (z.B. ein Mobiltelefon, ein PDA (Personal Digital Assistent)) durchzuführen. Wie beim Internet können durch Bereistellen solcher Annehmlichkeiten für den Kunden Umsätze gesteigert und good will verbessert werden, doch wenn die Transaktion nicht richtig und zeitig durchgeführt wird, können Umsätze und good will verloren gehen. Händler möchten deshalb üblicherweise Kunden mit mehreren Bezahlungsoptionen und mehreren Zugängen ausstatten, über welche Waren und Dienstleistungen eingekauft werden können. Diese Händler sind jedoch im Anbieten derartiger Flexibilität zurückhaltend, bis die Transaktion richtig und rechtzeitig ausgeführt werden kann.
Darüber hinaus existieren Altsysteme zum Durchführen von Transaktionen und erhebliche Investitionen wurden für den Aufbau der Altsysteminfrastruktur getätigt.
Händler sind typischerweise zurückhaltend beim Investieren in Systeme, welche den Ersatz solcher Altsysteme notwendig machen, wenn der zum Erzielen eines Rückflusses derartiger Investitionen erforderliche Zeitaufwand zu hoch ist. Das bedeutet, wenn ein Händler ein existierendes Altsystem durch ein vollkommen neues System ersetzen muss, um Bezahlungen über ein drahtloses Gerät zu ermöglichen, wird der Händler nicht Willens sein, eine solche Investition vorzunehmen.
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren und eine Anord- nung zur vereinfachten Abwicklung von Zahlungsverkehr unter Nutzung eines Telekommunikationsnetzes anzugeben, welches den in verschiedenen Ländern bestehenden gesetzlichen Vorschriften und etablierten und bewährten Verfahrensabläufen des Geldverkehrs Rechnung trägt.
In erheblichem Maße müssen auch private Zahlungsvorgänge, die über einen kommerziellen Dienstanbieter abgewickelt werden, diesen etablierten Regeln folgen. An einer Abwicklung derartiger privater Zahlungsvorgänge mit modernsten technischen Mitteln - also insbesondere über das Internet bzw. die Telekommunikationsnetze - besteht speziell im Zusammenhang mit der weiteren Durchset- zung des elektronischen Geldverkehrs und im Zusammenhang mit dem nichtgewerblichen Verkauf von Produkten oder Dienstleistungen (darunter Informationen) zwischen Privatleuten zunehmender Bedarf. Die bisher vorgeschlagenen und in Ansätzen auch in der Praxis verfügbaren Datenübertragungsverfahren, die diesem Zweck gewidmet sind, sind aufgrund unzureichender Zuverlässigkeit und Si- cherheit und/oder unbequemer Handhabung zur Befriedigung eines entsprechenden Massenbedarfs noch nicht geeignet.
Der Erfindung liegt daher auch die Aufgabe zugrunde, ein Verfahren und eine Anordnung zur vereinfachten Abwicklung von privatem Zahlungsverkehr ("P2P = Person-to-Person) unter Nutzung eines Telekommunikationsnetzes anzugeben, welches den in verschiedenen Ländern bestehenden gesetzlichen Vorschriften und etablierten und bewährten Verfahrensabläufen des Geldverkehrs Rechnung trägt.
In einer Hinsicht betrifft die vorliegende Erfindung ein Protokoll zum Ausführen von Transaktionen zwischen mehreren Kunden und Händlern. Das Protokoll steuert den Meldungsfluss und die Ausführung von in diesen Meldungen beinhalteten Instruktionen über ein Bezahlungssystem hinweg, welches herkömmliche wie auch nicht herkömmliche Bezahlungsmethodiken ermöglicht. Das Protokoll bietet eine Vielzahl von Vorteilen einschließlich dem, dass komplexe Transaktionen in einer vernünftigen Zeit und mit einer akzeptablen Kundenerfahrung abgeschlossen werden können.
Insbesondere und in einer spezifischen Ausführungsform umfasst das Protokoll verschiedene Unterprotokolle. Jedes Unterprotokoll verfügt über seinen eigenen definierten Umfang mit einer klaren Abgrenzung zu anderen Unterprotokollen. In einer beispielhaften Ausführungsform enthält das Protokoll zwei Unterprotokolle. Ein Unterprotokoll ist das Geldbörsen(Wallet)server, Zentralprozessorplattform und Bezahlungs(Payment)serverprotokoll, manchmal auch als das interoperable mobile Bezahlungsprotokoll (IMPP) bezeichnet. Das andere Unterprotokoll ist das Bezahlungsserver und Händlerserverprotokoll, manchmal auch als das offene Bezahlungsprotokoll (OPP) bezeichnet. Das OPP steuert den Informationsaustausch zwischen einem Geldbörsenserver, einem Händlersystem und einem Bezahlungs- Server. In der beispielhaften Ausführungsform kann ein Händlersystem alternativ auf einen Bezahlungsserver über das Händler API eher als über das OPP zugreifen.
Das IMPP wird durch eine Zentralprozessorplattform (CPP) unterstützt, welche eine zentrale Instanz zum Weiterleiten (Routen) von Meldungen und anderen be- zahlungsbezogenen Verarbeitungen nutzt. Die CPP verwaltet zentrale Angebotsdaten und findet in bestimmten Szenarien den Geldbörsenserver eines Kunden während der Bezahlungseinleitung heraus. Weiterhin stellt die CPP das Weiterleiten von Bezahlungsmeldungen in beiden Richtungen zwischen einem Geldbörsen- server und einem Bezahlungsserver zur Verfügung.
Der Geldbörsenserver enthält Kernkundendaten, welche zur Authentifizierung und Bezahlung wie auch eine Transaktionshistorie erforderlich sind. In Übereinstimmung mit dem IMPP wird der Geldbörsenserver während der Bezahlungseinlei- tungsphase angesteuert (triggered) und verschickt in der Folge Bezahlungsmeldungen an den Bezahlungsserver durch das CPP. Wenn sich der Transaktionsstatus bei einem Erwerber ändert, verschickt der Bezahlungsserver Benachrichtigungsmeldungen an den Geldbörsenserver durch das CPP. Darüber hinaus kann jede Partei Nachfragemeldungen senden, um den Status einer Transaktion zu ak- tualisieren und zu überprüfen.
Der Bezahlungsserver hält die Kundenkerndaten zu Bezahlung und Transaktionshistoriendaten. Der Bezahlungsserver empfängt auch Bezahlungsmeldungen von dem CPP und verarbeitet die Meldungen. Insbesondere verschickt der Bezah- lungsserver in Übereinstimmung mit dem IMPP eine Meldung an den Befugten auf Erwerberseite und löst eine Ergebnismitteilung an das CPP und das Händlersystem aus. Der Bezahlungsserver versendet und empfängt die benötigte Information an/von dem Händlersystem während der verschiedenen Phasen des Bezahlungsprozesses.
Alle transaktionsbezogenen Meldungen und Meldungsattribute werden nicht in jedem der drei Server gespeichert, d.h. dem Geldbörsenserver, dem Bezahlungsserver und der CPP. Z.B. werden Erzeugungsdaten für die OfferlD nur in der CPP gespeichert.
Der Begriff "Händlersystem" bezieht sich auf ein Einkaufssystem (z.B. einen kommerziell erhältlichen Handels(Commerce)server) und Bezahlungsstecker(plug- in)-Komponenten, welche in einer lokalen Händlerdomäne eines SD-Modell-konformen Bezahlungssystems verfügbar sind. In Übereinstimmung mit dem OPP sendet und empfängt das Händlersystem die benötigte Information an/von dem Bezahlungsserver während der verschiedenen Phasen des Bezahlungsprozesses. Die Übertragung von Meldungen zwischen dem CPP und dem Bezahlungsserver werden über das IMPP abgewickelt.
Das IMPP erleichtert es Händlern, Kunden die Option zur Verfügung zu stellen, Bezahlungen durch Verwenden mobiler Geräte in einer verlässlichen, richtigen und rechtzeitigen Art und Weise durchzuführen. Zusätzlich wird die Integration mit existierenden Altsystemen durch Bereitstellen eines Gateways ermöglicht, durch welches standardisierte, offene Protokolle (z.B. das IUTP-Protokoll) zum Kommunizieren mit dem System genutzt werden können. Z.B. übersetzt das Gateway mit dem IUTP-Protokoll IUTP-Meldungen in IMPP-Meldungen und Datenströme. Händler brauchen deshalb Altsysteme nicht ersetzen und sich einfach an die Plattform anbinden (plug-in), auf welcher das IMPP implementiert ist.
Die Erfindung schließt in einem weiteren Aspekt den wesentlichen Gedanken ein, ein weitgehend universelles Zahlungsverfahren auf der Grundlage eines herkömmlichen Bankkontos ("Postpaid") oder elektronischen Guthabens ("Prepaid") anzugeben, welches insbesondere für eine Zahlungsabwicklung im sogenannten B2C(Business-to-Consumer)-Bereich wie auch im P2P(Person-to-Person)-Bereich anwendbar ist, also den Einkauf in realen und virtuellen Geschäften, die Bezahlung in gastronomischen oder kulturellen Einrichtungen etc. und die "Übersendung" von Geldbeträgen im privaten Bereich ermöglicht.
Sie schließt weiter den Gedanken ein, hierzu die Möglichkeiten eines TK-Netzes zu nutzen, und zwar insbesondere die Möglichkeit einer weitgehenden Abwicklung in nahezu Echtzeit (Real Time). Weiter gehört zur Erfindung der zentrale Gedanke der Bereitstellung und Verwendung einer eindeutigen Kennung - des Kontext- Identifikators - zur transaktionsübergreifenden Kennzeichnung von durch einen Anbieter offerierten Waren oder Dienstleistungen (insbesondere eines ganzen "Warenkorbes") für die Abwicklung aller mit dem Anbieten und Bezahlen verbundenen Datenübertragungs- und -Verarbeitungsvorgänge, insbesondere die verlässliche Autorisierung der Bezahlung.
In einer ersten Ausführungsvariante der Erfindung wird mit der Generierung des Kontext-Identifikators keine Gültigkeitsdauer festgelegt, so dass er potentiell un- begrenzt gültig ist. Hierfür kann der Begriff "statische OfferlD" gebraucht werden. Sie wird insbesondere für die Bezahlung von über Fernsehkanäle angebotenen Waren bzw. Dienstleistungen ("TV Shopping") sowie für die an Ausgabeautomaten (Vending Machines = VM) angebotenen Produkte über ein TK-Netz unter Einsatz eines TK-Endgerätes genutzt werden.
In einer alternativen Ausführung der Erfindung wird mit der Generierung des Kontext-Identifikators eine Gültigkeitsdauer definiert und er bei deren Ablauf automatisch ungültig gemacht. Hierbei kann man von einer "dynamischen OfferlD" sprechen. Sie wird für verschiedene sonstige Einkaufs- und Bezahlvorgänge genutzt werden, insbesondere für einzelne Einkaufsaktionen in virtuellen Shops oder realen Läden bzw. Kaufhäusern.
In beiden Fällen kann der Kontext-Identifikator auf Anforderung des Anbieters der Waren oder Dienstleistungen gelöscht bzw. zerstört werden. Zum Ungültigmachen des Kontext-Identifikators wird bei Abiauf der Gültigkeitsdauer oder auf Anforderung des Anbieters ein Eliminierungssignal an den Anbieter gesandt, um diesen auf das Ungültigwerden des fraglichen Identifikators hinzuweisen.
Die Informationsübertragung des Kontext-Identifikators an den - potentiellen - Abnehmer bzw. Kunden (Customer) erfolgt in einer ersten Variante als invariante optische Anzeige, insbesondere Beschriftung auf einem Schaufensterdisplay oder Ausgabeautomaten oder Aufdruck auf einem Prospekt oder Katalog oder dergleichen. In anderen Varianten erfolgt die Übermittlung des Kontext-Identifikators an potentielle Abnehmer als variable optische Anzeige auf einer elektrooptischen Anzeigeeinrichtung oder durch Sprachausgabe oder ein akustisches Signal. Mit diesen verschiedenen Übermittlungsarten wird den spezifischen Einkaufssituationen der Industriegesellschaft Rechnung getragen, wo neben den traditionellen Ladeneinkauf und die insbesondere als Getränke-, Zigaretten- und Süßigkeitenau- tomaten etablierten Ausgabeautomaten längst das Internet-Shopping und TV- Shopping getreten ist.
Für die Mehrzahl der bestehenden Vertriebskanäle ist es von Vorteil, wenn der Kontext-Identifikator in einem Broadca st- Verfahren außerhalb des Telekommuni- kationsnetzes, insbesondere durch Rundfunk- oder Fernsehübertragung oder Ver- sand bzw. Verteilung von Druckschriften oder E-Mail-Broadcast, während der Gültigkeitsdauer an eine Vielzahl potentieller Abnehmer übermittelt wird. In letzter Zeit haben aber die unmittelbar über ein Telekommunikationsnetz angebotenen Möglichkeiten zum Bezug von Waren oder Dienstleistungen (Informationen!) er- heblich an Bedeutung gewonnen. Hierfür ist eine Variante von Vorteil, bei der der Kontext-Identifikator, insbesondere in einem Broadcast-Verfahren, in einer Kurznachricht oder per WAP über das Telekommunikationsnetz an das Telekommuni- kations-Endgerät des Abnehmers übermittelt und dort angezeigt wird.
Bevorzugt laufen die Schritte der Anfrage nach einem Kontext-Identifikator durch den Anbieter und der Zusendung eines solchen an den Anbieter bzw. Händler (Merchant) als im wesentlichen automatisierte Datenübertragungen zwischen dem Systemverwaltungsserver und einem Händler-Server oder Anbieter-Datenendgerät über ein Daten- und/oder Telekommunikationsnetz, insbesondere das Internet, ab. Dies gilt sowohl für das Internet-Shopping als auch bei der Inanspruchnahme des vorgeschlagenen Systems durch "klassische" Handelseinrichtungen.
In einem typischen Szenario wird nach dem Schritt der Übermittlung des Kontext- Identifikators an den Abnehmer der Kontext-Identifikator durch den Abnehmer über das Telekommunikationsnetz an einen Kunden-Server des Netzbetreibers oder eines Dienstanbieters im Telekommunikationsnetz übermittelt, durch den Kunden-Server, Dienstserver oder Händler-Server eine Anfragenachricht zur Einholung eines verbindlichen Angebots an den Anbieter gesandt, durch den Anbie- ter ein Angebotsdatensatz an den Kunden-Server übersandt und der Angebotsdatensatz vom Kunden-Server an das Telekommunikations-Endgerät des potentiellen Abnehmers übermittelt und dort im Rahmen einer Menüführung zur Bestätigung der Transaktion angezeigt. Hierbei wird die Datenübertragung in den Schritten der Anfrage nach einem verbindlichen Angebot und der Übersendung der An- gebotsdaten über den Systemverwaltungsserver ausgeführt, welcher insbesondere Such- und Routing-Funktionen zwischen Netzbetreiber bzw. Dienstanbieter und Anbieter ausführt.
Der Kontext-Identifikator (OfferlD) kann vollständig durch einen geeigneten Ge- nerator bei einem Systemverwaltungsserver des vorgeschlagenen Systems gene- riert werden, er kann aber alternativ auch vollständig extern erzeugt und im Rahmen der Anfrage durch den Anbieter zur Bestätigung an den Systemverwaltungsserver übermittelt werden. Insbesondere für "Kataloganbieter" ist eine Variante von Vorteil, bei der der Kontext-Identifikator einen ersten und einen zweiten Abschnitt aufweist, wobei der erste Abschnitt ein durch den Systemverwaltungsserver generierter oder verwalteter Anbieter-Identifikator und der zweite Abschnitt ein durch den Anbieter generierter oder verwalteter Waren- oder Waren- gruppen-Identifikator ist und das Verfahren eine Übermittlung des zweiten Abschnitts an den Systemverwaltungsserver, die Verknüpfung von erstem und zwei- tem Abschnitt im Systemverwaltungsserver und die Zusendung oder Bestätigung des gesamten Kontext-Identifikators an den Abnehmer bzw. diesem gegenüber umfasst.
Dem Anbieter können somit gewissermaßen "Nummernbänder" zugeordnet wer- den, wobei er seine eigene Katalognummer hinter einem seine Identität als Anbieter repräsentierenden Abschnitt ("Präfix") weiterhin benutzt. Hierdurch lässt sich die Verwendung von Kontext-Identifikatoren bei Katalog-Szenarien wesentlich vereinfachen. Die Kombination des ersten Abschnitts (Präfix) mit dem zweiten Abschnitt (Katalognummer) kann - nach Vergabe des Präfix durch die Sys- temverwaltung - auch durch den Anbieter selbst erfolgen, wobei die Verantwortung für die Eindeutigkeit des Kontext-Identifikators dann natürlich bei diesem liegt.
Üblicherweise wird der über den Kontext-Identifikator informierte Abnehmer die- sen an seinem Telekommunikationsendgerät manuell oder ggf. auch per Spracheingabe selbst eingeben. Die oben erwähnten Möglichkeiten der Ausgabe des Identifikators an den Abnehmer können aber in einen automatischen Eingabevorgang münden, der natürlich fehlerresistenter als die manuelle Eingabe ist. Der Identifikator wird hierzu in oder an einem Telekommunikationsendgerät, insbe- sondere durch eine mit diesem verbundene Kamera oder einen Scanner, des Abnehmers aus einem optischen oder akustischen Signal in ein elektrisches Signal umgewandelt.
Die wesentlichen erfindungsgemäßen Vorrichtungsaspekte und ihre vorteilhaften Fortbildungen ergeben sich weitgehend bereits aus den oben erläuterten Verfah- rensaspekten in ihrer Abbildung auf eine Systemstruktur, so dass sie hier nicht nochmals im einzelnen erläutert werden.
In organisatorischer Hinsicht ist das vorgeschlagene System in einer Mehrzahl verschiedener Konfigurationen realisierbar, wobei es technisch grundsätzlich um einen Systemverwaltungsserver zentriert ist, dem im Normalfall ein Kunden- Server (nachfolgend auch Valid Server) sowie ein Händler-Server (Payment Server) zugeordnet und mit dem diese durch Nachrichtenübertragungskanäle verbunden sind. Wenn in diesem Zusammenhang von "einem" Händler- bzw. Kun- den-Server die Rede ist, so ist hierunter im folgenden jeweils auch eine Mehrzahl von Servern verschiedener Dienstanbieter, Geldinstitute etc. zu verstehen, die im Gesamtsystem eine entsprechende Funktion haben.
In einer ersten Systemgestaltung befinden sich sämtliche genannten Server bei einem Telekommunikationsunternehmen bzw. kundenorientierten Dienstanbieter, welcher sowohl Anbieter als auch Abnehmer an das System anbindet, In einer zweiten Systemkonfiguration betreibt das Telekommunikationsunternehmen (nachfolgend auch als abgekürzt als Telco) bzw. der Kunden-Dienstanbieter zwar Kunden- und Händler-Server, der Systemverwaltungsserver wird jedoch von ei- nem getrennten Unternehmen (nachfolgend auch als Opco bezeichnet) betrieben und im wesentlichen nur für die Generierung des Kontext-Identifikators sowie die laufende Ermittlung des zuständigen Händler-Servers benötigt. Die relevanten Informationen zur Zuordnung der für eine bestimmte Transaktion zuständigen Händler- und Kunden-Server liegen hierbei insbesondere beim Systemverwal- tungsserver.
In einer dritten Konfiguration gibt es separate Kunden- und Händler-Dienstanbieter, die jeweils auch nur den zugehörigen Server betreiben, während das Systembetriebsunternehmen (Opco) den Systemverwaltungsserver betreibt. Hierbei ist ein erstes Szenario denkbar, bei dem (wie bei der vorgenannten Variante) der Systemverwaltungsserver im wesentlichen nur den Kontext-Identifikator erzeugt oder bestätigt und zum späteren Auffinden des Händler-Servers dient. In einem zweiten Szenario trägt der Systemverwaltungsserver verarbeitungs- wie übermittlungstechnisch im wesentlichen die Transaktion. Schließlich ist auch eine System- konfiguration sinnvoll, bei der das Betriebsunternehmen sowohl den Systemver- waltungsserver als auch den Händler-Server betreibt, während lediglich Kunden- Server durch das Telco bzw. den Kunden-Dienstanbieter betrieben werden.
Die zweite und dritte der oben genannten Systemkonfigurationen, wo es ein selbstständiges Systemverwaltungsunternehmen und somit eine sogenannte "Op- co-Domäne" gibt, sind vorteilhaft für die Realisierung eines sehr großen, insbesondere globalen, Systems mit Anbindung sehr vieler Anbieter und Abnehmer. Sie ermöglichen nämlich eine zentrale Datenhaltung der relevanten Daten (OfferlD und Serveradressen) sehr vieler Nutzer, die über eine Vielzahl von Händler-Ser- vern und/oder Kunden-Servern elektronische Transaktionen abwickeln.
Zur Realisierung einer seiner wichtigsten Funktionen hat der Systemverwaltungsserver eine Codeerzeugereinheit zur Generierung des Kontext-Identifikators im Ansprechen auf eine empfangene Anfrage und eine Codesendeeinrichtung zur Übersendung des generierten Kontext-Identifikators direkt oder mittelbar an das anfragende Anbieter-Endgerät. In einer Modifikation zu einer oben bereits erwähnten speziellen Verfahrensführung ("Kataloganbieter") dient die Codeerzeugereinheit lediglich zur Erzeugung eines ersten Identifikator-Abschnittes, der einen Anbieter kennzeichnet, und in einer weiteren Abwandlung sind statt der Co- deerzeugereinheit Mittel zum Empfang und zur Eindeutigkeitsprüfung eines extern generierten Codes sowie zur Ausgabe eines Bestätigungssignals zur Bestätigung der Eindeutigkeit (und damit Brauchbarkeit) einer fremderzeugten OfferlD vorgesehen.
Speziell zur Erzeugung und Handhabung der oben erwähnten dynamischen OfferlD hat der Systemverwaltungsserver der Codeerzeugereinheit zugeordnete Zeitgebermittel und Zeitdauer-Speichermittel zur Zuordnung und Speicherung einer Gültigkeitsdauer zu jedem Kontext-Identifikator sowie eine mit den Zeitgeber- und Zeit-Speichermitteln verbundene Zeitdauer-Vergleichereinheit zur Überwachung des Ablaufes einer festgelegten Gültigkeitsdauer und zur Ausgabe eines Eliminierungssignals zum Ungültigmachen des Kontext-Identifikators bei Ablauf aufweist. Es versteht sich, dass im Falle der Verwendung statischer Of- ferlDs an die Stelle dieser Komponenten eine Löscheinheit tritt, die auf eine von extern erhaltene Löschanforderung anspricht und den Identifikator eliminiert. Eine wesentliche Funktionskomponente der vorgeschlagenen Systemarchitektur stellt weiterhin ein Datenhaltungssystem (OfferlD Repository) zur Speicherung und Verwaltung aller gültigen Kontext-Identifikatoren und von diesen im System zugeordneten Informationen, insbesondere zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge, dar. Mit dessen Hilfe lassen sich beispielsweise für jede Transaktion die zuständigen Kundenbzw. Händler-Server ermitteln. Die im vorangehenden Absatz erwähnten und dort dem Systemverwaltungsserver zugeschriebenen Komponenten zur Verwaltung dynamischer OfferlDs können auch dem Repository zugeschrieben werden; An das TK-Netz sind gemäß einem weiteren wesentlichen Aspekt der Erfindung einerseits die TK-Endgeräte der das Netz nutzenden Abnehmer bzw. Kunden (Customer) und andererseits mindestens ein Kunden-Server des Betreibers des TK-Netzes oder eines kundenorientiert arbeitenden Dienstanbieters angeschlossen. Zur Erfindung gehört weiter der Gedanke der Bereitstellung eines Systemverwaltungs- Servers zur Verwaltung und zum Routing der transaktionsnotwendigen Daten im Bezug auf die Abnehmer- wie auch die Anbieter-Seite, der netzmäßig mit mindestens einem Händler-Server eines händlerorientiert arbeitenden Dienstanbieters verknüpft ist. Hier wird es sich typischerweise um Datennetzverbindungen handeln, die mit dem TK-Netz zur Anbindung der Kunden verknüpft sein können, aber nicht notwendigerweise müssen. Schließlich gehört zur Erfindung der Gedanke der Bereitstellung von geeigneten Datenverkehrsleitmitteln zum Routing der im Rahmen von Angebots- und Bezahlvorgängen zwischen den Beteiligten auszutauschenden Datensätze.
Die Hauptkomponente des vorgeschlagenen Systems bildet also ein Systemverwaltungsserver, der in einer sinnvollen praktischen Ausführung mit einer Mehrzahl von Kunden-Servern in mehreren Telekommunikationsnetzen, insbesondere Mobilfunknetzen, im wesentlichen dauerhaft verbunden ist. Zudem ist in einer praktikablen Systemkonfiguration der Systemverwaltungsserver mit einer Mehr- zahl von Händler-Servern verbindbar, wobei jeder Händler-Server wiederum mit einer Mehrzahl von Anbieter-Endgeräten verbunden oder verbindbar ist, und er weist einen Händler-Speicher zur Speicherung von Identifizierungs- und Adressdaten der angeschlossenen Anbieter auf. In einer weiteren bevorzugten Ausführungsform sind der Systemverwaltungsserver und/oder der oder die Händler-Server in einem Telekommunikationsnetz, insbesondere Mobilfunknetz, angeordnet, und einer oder mehrere hiervon bilden eine Funktionseinheit mit dem Kunden-Server oder Kunden-Servern.
In organisatorischer Hinsicht ist das vorgeschlagene System im übrigen in einer Mehrzahl verschiedener Konfigurationen realisierbar, wobei es technisch grundsätzlich um einen Systemverwaltungsserver zentriert ist, dem im Normalfall ein Kunden-Server (nachfolgend auch Valid Server) sowie ein Händler-Server (Pay- ment Server) zugeordnet und mit dem diese durch Nachrichtenübertragungskanäle verbunden sind. Wenn in diesem Zusammenhang von "einem" Händler- bzw. Kunden-Server die Rede ist, so ist hierunter im folgenden jeweils auch eine Mehrzahl von Servern verschiedener Dienstanbieter, Geldinstitute etc. zu verstehen, die im Gesamtsystem eine entsprechende Funktion haben.
In einer ersten Systemgestaltung befinden sich sämtliche genannten Server bei einem Telekommunikationsunternehmen bzw. kundenorientierten Dienstanbieter, welcher sowohl Anbieter als auch Abnehmer an das System anbindet. In einer zweiten Systemkonfiguration betreibt das Telekommunikationsunternehmen (nachfolgend auch als abgekürzt als Telco) bzw. der Kunden-Dienstanbieter zwar Kunden- und Händler-Server, der Systemverwaltungsserver wird jedoch von einem getrennten Unternehmen (nachfolgend auch als Opco bezeichnet) betrieben und im wesentlichen nur für die Generierung des Kontext-Identifikators sowie die laufende Ermittlung des zuständigen Händler-Servers benötigt. Die relevanten In- formationen zur Zuordnung der für eine bestimmte Transaktion zuständigen Händler- und Kunden-Server liegen hierbei insbesondere beim Systemverwaltungsserver.
In einer dritten Konfiguration gibt es separate Kunden- und Händler-Dienstanbie- ter, die jeweils auch nur den zugehörigen Server betreiben, während das Systembetriebsunternehmen (Opco) den Systemverwaltungsserver betreibt. Hierbei ist ein erstes Szenario denkbar, bei dem (wie bei der vorgenannten Variante) der Systemverwaltungsserver im wesentlichen nur den Kontext-Identifikator erzeugt oder bestätigt und zum späteren Auffinden des Händler-Servers dient. In einem zweiten Szenario trägt der Systemverwaltungsserver verarbeitungs- wie übermitt- lungstechnisch im wesentlichen die Transaktion. Schließlich ist auch eine Systemkonfiguration sinnvoll, bei der das Betriebsunternehmen sowohl den Systemverwaltungsserver als auch den Händler-Server betreibt, während lediglich Kunden- Server durch das Telco bzw. den Kunden-Dienstanbieter betrieben werden.
Die zweite und dritte der oben genannten Systemkonfigurationen, wo es ein selbstständiges Systemverwaltungsunternehmen und somit eine sogenannte "Op- co-Domäne" gibt, sind vorteilhaft für die Realisierung eines sehr großen, insbesondere globalen, Systems mit Anbindung sehr vieler Anbieter und Abnehmer. Sie ermöglichen nämlich eine zentrale Datenhaltung der relevanten Daten (OfferlD und Serveradressen) sehr vieler Nutzer, die über eine Vielzahl von Händler-Servern und/oder Kunden-Servern elektronische Transaktionen abwickeln.
Zur Realisierung einer seiner wichtigsten Funktionen hat der Systemverwaltungs- Server eine Codeerzeugereinheit zur Generierung des Kontext-Identifikators im Ansprechen auf eine empfangene Anfrage und eine Codesendeeinrichtung zur Übersendung des generierten Kontext-Identifikators direkt oder mittelbar an das anfragende Anbieter-Endgerät. In einer Modifikation zu einer oben bereits erwähnten speziellen Verfahrensführung ("Kataloganbieter") dient die Codeerzeu- gereinheit lediglich zur Erzeugung eines ersten Identifikator-Abschnittes, der einen Anbieter kennzeichnet, und in einer weiteren Abwandlung sind statt der Codeerzeugereinheit Mittel zum Empfang und zur Eindeutigkeitsprüfung eines extern generierten Codes sowie zur Ausgabe eines Bestätigungssignals zur Bestätigung der Eindeutigkeit (und damit Brauchbarkeit) einer fremderzeugten OfferlD vorgesehen.
Speziell zur Erzeugung und Handhabung der oben erwähnten dynamischen OfferlD hat der Systemverwaltungsserver der Codeerzeugereinheit zugeordnete Zeitgebermittel und Zeitdauer-Speichermittel zur Zuordnung und Speicherung ei- ner Gültigkeitsdauer zu jedem Kontext-Identifikator sowie eine mit den Zeitgeber- und Zeit-Speichermitteln verbundene Zeitdauer-Vergleichereinheit zur Überwachung des Ablaufes einer festgelegten Gültigkeitsdauer und zur Ausgabe eines Eliminierungssignals zum Ungültigmachen des Kontext-Identifikators bei Ablauf aufweist. Es versteht sich, dass im Falle der Verwendung statischer Of- ferlDs an die Stelle dieser Komponenten eine Löscheinheit tritt, die auf eine von die Stelle dieser Komponenten eine Löscheinheit tritt, die auf eine von extern erhaltene Löschanforderung anspricht und den Identifikator eliminiert.
Eine wesentliche Funktionskomponente der vorgeschlagenen Systemarchitektur stellt weiterhin ein Datenhaltungssystem (OfferlD Repository) zur Speicherung und Verwaltung aller gültigen Kontext-Identifikatoren und von diesen im System zugeordneten Informationen, insbesondere zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge, dar. Mit dessen Hilfe lassen sich beispielsweise für jede Transaktion die zuständigen Kunden- bzw. Händler-Server ermitteln. Die im vorangehenden Absatz erwähnten und dort dem Systemverwaltungsserver zugeschriebenen Komponenten zur Verwaltung dynamischer OfferlDs können auch dem Repository zugeschrieben werden.
Zur zweckmäßigen und zeitnahen Ausführung der eigentlichen finanziellen Trans- aktion ist insbesondere mindestens ein Kontenverwaltungsserver dem oder einem Telekommunikationsnetz direkt zugeordnet, und dieser wirkt mit dem Systemverwaltungsserver und/oder mit dem Kunden-Server zur Ausführung einer Bezahlung, insbesondere unter Zugriff auf ein Prepaid-Guthaben, zusammen. Andererseits kann der oder mindestens ein Kontenverwaltungsserver außerhalb des netz- internen Steuerungsbereiches des oder jedes Telekommunikationsnetzes angeordnet und insbesondere direkt mit dem Telekommunikations-Endgerät des Abnehmers verbindbar sein.
Zur Gewährleistung einer systemautarken Steuerung aller Transaktionen (unab- hängig von externen Triggern, die bei einer sehr großen Anzahl gleichzeitig ablaufender Transaktionen leicht zu Störungen führen könnten) weist der Systemverwaltungsserver einen Ablaufprogrammspeicher zur Speicherung mindestens eines Transaktions-Ablaufprogrammes der Datenkommunikation zwischen dem oder jedem Kunden-Server und den Anbieter-Endgeräten bzw. dem oder jedem Händler-Server auf.
Wesentliche Aspekte der wichtigsten Verfahrensabläufe im vorgeschlagenen System sind bereits aus den obigen Erläuterungen des Systemaufbaus ableitbar, so dass die korrespondierenden Verfahrensaspekte nachfolgend nicht nochmals er- schöpfend dargelegt werden. Es wird im weiteren auf einige prägende Verfah- rensgedanken der Erfindung bzw. ihrer bevorzugten Ausführungen näher eingegangen.
In einer besonders vorteilhaften Systemgestaltung ist die Bereitstellung und Ver- wendung einer eindeutigen Kennung - des Kontext-Identifikators - zur transakti- onsübergreifenden Kennzeichnung von durch einen Anbieter offerierten Waren oder Dienstleistungen (insbesondere eines ganzen "Warenkorbes") für die Abwicklung aller mit dem Anbieten und Bezahlen verbundenen Datenübertragungsund -Verarbeitungsvorgänge, insbesondere die verlässliche Autorisierung der Be- Zahlung, vorgesehen.
In einer ersten Ausführungsvariante der Erfindung wird mit der Generierung des Kontext-Identifikators keine Gültigkeitsdauer festgelegt, so dass er potentiell unbegrenzt gültig ist. Hierfür kann der Begriff "statische OfferlD" gebraucht wer- den. Sie wird insbesondere für die Bezahlung von über Fernsehkanäle angebotenen Waren bzw. Dienstleistungen ("TV Shopping") sowie für die an Ausgabeautomaten (Vending Machines = VM) angebotenen Produkte über ein TK-Netz unter Einsatz eines TK-Endgerätes genutzt werden.
In einer alternativen Ausführung der Erfindung wird mit der Generierung des
Kontext-Identifikators eine Gültigkeitsdauer definiert und er bei deren Ablauf automatisch ungültig gemacht. Hierbei kann man von einer "dynamischen OfferlD" sprechen. Sie wird für verschiedene sonstige Einkaufs- und Bezahlvorgänge genutzt werden, insbesondere für einzelne Einkaufsaktionen in virtuellen Shops oder realen Länden bzw. Kaufhäusern.
In beiden Fällen kann der Kontext-Identifikator auf Anforderung des Anbieters der Waren oder Dienstleistungen gelöscht bzw. zerstört werden. Zum Ungültigmachen des Kontext-Identifikators wird bei Ablauf der Gültigkeitsdauer oder auf Anforderung des Anbieters ein Eliminierungssignal an den Anbieter gesandt, um diesen auf das Ungültigwerden des fraglichen Identifikators hinzuweisen.
Die Informationsübertragung des Kontext-Identifikators an den - potentiellen - Abnehmer bzw. Kunden (Customer) erfolgt in einer ersten Variante als invariante optische Anzeige, insbesondere Beschriftung auf einem Schaufensterdisplay oder Ausgabeautomaten oder Aufdruck auf einem Prospekt oder Katalog oder dergleichen. In anderen Varianten erfolgt die Übermittlung des Kontext-Identifikators an potentielle Abnehmer als variable optische Anzeige auf einer elektrooptischen Anzeigeeinrichtung oder durch Sprachausgabe oder ein akustisches Signal. Mit diesen verschiedenen Übermittlungsarten wird den spezifischen Einkaufssituationen der Industriegesellschaft Rechnung getragen, wo neben den traditionellen Ladeneinkauf und die insbesondere als Getränke-, Zigaretten- und Süßigkeitenautomaten etablierten Ausgabeautomaten längst das Internet-Shopping und TV- Shopping getreten ist.
Für die Mehrzahl der bestehenden Vertriebskanäle ist es von Vorteil, wenn der Kontext-Identifikator in einem Broadcast-Verfahren außerhalb des Telekommunikationsnetzes/ insbesondere durch Rundfunk- oder Fernsehübertragung oder Versand bzw. Verteilung von Druckschriften oder E-Mail-Broadcast, während der Gül- tigkeitsdauer an eine Vielzahl potentieller Abnehmer übermittelt wird. In letzter Zeit haben aber die unmittelbar über ein Telekommunikationsnetz angebotenen Möglichkeiten zum Bezug von Waren oder Dienstleistungen (Informationen!) erheblich an Bedeutung gewonnen. Hierfür ist eine Variante von Vorteil, bei der der Kontext-Identifikator, insbesondere in einem Broadcast-Verfahren, in einer Kurz- nachricht oder per WAP über das Telekommunikationsnetz an das Telekommuni- kations-Endgerät des Abnehmers übermittelt und dort angezeigt wird.
Bevorzugt laufen die Schritte der Anfrage nach einem Kontext-Identifikator durch den Anbieter und der Zusendung eines solchen an den Anbieter bzw. Händler (Merchant) als im wesentlichen automatisierte Datenübertragungen zwischen dem Systemverwaltungsserver und einem Händler-Server oder Anbieter- Datenendgerät über ein Daten- und/oder Telekommunikationsnetz, insbesondere das Internet, ab. Dies gilt sowohl für das Internet-Shopping als auch bei der Inanspruchnahme des vorgeschlagenen Systems durch "klassische" Handelseinrich- tungen.
In einem typischen Szenario wird nach dem Schritt der Übermittlung des Kontext- Identifikators an den Abnehmer der Kontext-Identifikator durch den Abnehmer über das Telekommunikationsnetz an einen Kunden-Server des Netzbetreibers oder eines Dienstanbieters im Telekommunikationsnetz übermittelt, durch den Kunden-Server, Dienstserver oder Händler-Server eine Anfragenachricht zur Einholung eines verbindlichen Angebots an den Anbieter gesandt, durch den Anbieter ein Angebotsdatensatz an den Kunden-Server übersandt und der Angebotsdatensatz vom Kunden-Server an das Telekommunikations-Endgerät des potentiel- len Abnehmers übermittelt und dort im Rahmen einer Menüführung zur Bestätigung der Transaktion angezeigt. Hierbei wird die Datenübertragung in den Schritten der Anfrage nach einem verbindlichen Angebot und der Übersendung der Angebotsdaten über den Systemverwaltungsserver ausgeführt, welcher insbesondere Such- und Routing-Funktionen zwischen Netzbetreiber bzw. Dienstanbieter und Anbieter ausführt.
Der Kontext-Identifikator (OfferlD) kann vollständig durch einen geeigneten Generator bei einem Systemverwaltungsserver des vorgeschlagenen Systems generiert werden, er kann aber alternativ auch vollständig extern erzeugt und im Rahmen der Anfrage durch den Anbieter zur Bestätigung an den Systemverwaltungsserver übermittelt werden. Insbesondere für "Kataloganbieter" ist eine Variante von Vorteil, bei der der Kontext-Identifikator einen ersten und einen zweiten Abschnitt aufweist, wobei der erste Abschnitt ein durch den Systemverwaltungsserver generierter oder verwalteter Anbieter-Identifikator und der zweite Ab- schnitt ein durch den Anbieter generierter oder verwalteter Waren- oder Waren- gruppen-Identifikator ist und das Verfahren eine Übermittlung des zweiten Abschnitts an den Systemverwaltungsserver, die Verknüpfung von erstem und zweitem Abschnitt im Systemverwaltungsserver und die Zusendung oder Bestätigung des gesamten Kontext-Identifikators an den Abnehmer bzw. diesem gegenüber umfasst.
Dem Anbieter können somit gewissermaßen "Nummernbänder" zugeordnet werden, wobei er seine eigene Katalognummer hinter einem seine Identität als Anbieter repräsentierenden Abschnitt ("Präfix") weiterhin benutzt. Hierdurch lässt sich die Verwendung von Kontext-Identifikatoren bei Katalog-Szenarien wesentlich vereinfachen. Die Kombination des ersten Abschnitts (Präfix) mit dem zweiten Abschnitt (Katalognummer) kann - nach Vergabe des Präfix durch die Systemverwaltung - auch durch den Anbieter selbst erfolgen, wobei die Verantwortung für die Eindeutigkeit des Kontext-Identifikators dann natürlich bei diesem liegt. Üblicherweise wird der über den Kontext-Identifikator informierte Abnehmer diesen an seinem Telekommunikationsendgerät manuell oder ggf. auch per Spracheingabe selbst eingeben. Die oben erwähnten Möglichkeiten der Ausgabe des Identifikators an den Abnehmer können aber in einen automatischen Eingabevorgang münden, der natürlich fehlerresistenter als die manuelle Eingabe ist. Der Identifikator wird hierzu in oder an einem Telekommunikationsendgerät, insbesondere durch eine mit diesem verbundene Kamera oder einen Scanner, des Abnehmers aus einem optischen oder akustischen Signal in ein elektrisches Signal umgewandelt.
In einer weiteren Hinsicht schließt die Erfindung den wesentlichen Gedanken ein, ein weitgehend universelles System zur Abwicklung finanzieller Transaktionen auf der Grundlage eines herkömmlichen Bankkontos ("Postpaid") oder elektronischen Guthabens ("Prepaid") anzugeben, welches insbesondere für eine Zahlungsabwicklung im P2P-Bereich anwendbar ist, also die "Übersendung" von Geldbeträgen im privaten Bereich erlaubt.
Sie schließt weiter den Gedanken ein, hierzu primär ein TK-Netz zu nutzen, und zwar insbesondere die Möglichkeit einer weitgehenden Abwicklung in nahezu Echtzeit (Real Time). An das TK-Netz sind einerseits die TK-Endgeräte der das Netz nutzenden Teilnehmer und andererseits mindestens ein Transaktionsserver des Betreibers des TK-Netzes oder eines kundenorientiert arbeitenden Dienstanbieters angeschlossen.
Eine Person-to-Person-Zahlung im Sinne der vorliegenden Erfindung setzt das Vorliegen eines für eine elektronische Guthabentransferierung geeigneten Kontos "Wallet Account" sowohl auf Seiten des Zahlers als auch des Zahlungsempfängers voraus. Die Implementierung kann einerseits in einem Zwei-Schritt-Ablauf durch (1) Zahlung an einen "Händler" (P2P-Engine) und (2) Kreditierung auf ein Zahlungsempfängerkonto seitens des "Händlers" oder andererseits - nutzerfreundlicher - durch Integration der P2P-Engine bei einem Kontoverwaltungsserver des Zahlers implementiert werden. Für die P2P-Engine steht nachfolgend im wesentlichen der deutsche Terminus "Transaktionsserver", während der ebenfalls bereits erwähnte Kontoverwaltungsserver im Englischen auch als "Payment Instrument" (PI) bezeichnet werden kann. Der Verfahrensablauf der beiden Varianten wird in den Figuren genauer beschrieben.
Zur Auslösung des P2P-Zahlungsvorganges kontaktiert der Zahler mittels seines TK-Endgerätes über ein TK-Netz (insbesondere Mobilfunknetz) oder mittels seines Datenendgerätes über ein Datennetz (speziell das Internet) den Transaktionsserver bzw. die P2P-Engine und spezifiziert eine Adresse oder einen anderen Identifikator des Empfängers und den Zahlungsbetrag. Wahlweise können zusätzlich - im internationalen Zahlungsverkehr - die Zahlungswährung und eine Textnach- rieht (z.B. zum Zahlungszweck) eingegeben werden. Bei dem durch den Zahler angesprochenen Transaktionsserver oder einem mit diesem verbundenen weiteren Transaktionsserver wird aus einem aus der Zahler-Eingabe erstellten ersten Zahlungsanweisungs-Datensatz ein letztlich die Gutschrift beim Zahlungsempfänger bewirkender zweiter Zahlungsanweisungs-Datensatz gebildet. Hierbei erfolgt (sofern nicht bereits bei der Eingabe geschehen) die Spezifikation eines Konten- identifikators des Zahlungsempfängers.
Werden die elektronisch geführten Konten von Zahler und Zahlungsempfänger auf verschiedenen Kontenverwaltungsservern geführt, schließt die Transformation zwischen erstem und zweitem Zahlungsanweisungs-Datensatz typischerweise die Ermittlung der Serveradresse des (zweiten) Kontenverwaltungsservers des Zahlungsempfängers und eine an diesen gerichtete Anfrage nach dem Kontenidentifi- kator des Zahlungsempfängers ein. Nach deren Beantwortung kann die Gutschrift des Zahlungsbetrages ausgeführt werden.
In den Zahlungsvorgang ist in jedem Falle eine Authentisierung des Zahlers unter Zugriff auf Teilnehmerdaten, die ihn als Teilnehmer eines TK-Netzes identifizieren, vorgesehen. Sofern der Zahlungsvorgang von seinem TK-Endgerät (Mobilfunk-Endgerät) ausgelöst wird, nutzt die Authentisierung dessen MSISDN zu einer ab-initio-Authentisierung. Wird der Zahlungsvorgang hingegen von einem Datenendgerät aus angestoßen, so ist ein Bestätigungsschritt unter Zugriff auf das TK- Netz, dessen Teilnehmer der Zahler ist, vorgesehen. Eine Bestätigungs-Anfrage ist im übrigen optional auch als zusätzlicher Schritt des erstgenannten Verfahrens vorgesehen. Im internationalen Zahlungsverkehr hat der erste Zahlungsanweisungs-Datensatz einen ersten Währungscode und der zweite Zahlungsanweisungs-Datensatz einen zweiten, vom ersten verschiedenen Währungscode, und bei der Erstellung des zweiten Zahlungsanweisungs-Datensatzes wird eine Umrechnung aus der Betragsinformation des ersten Zahlungsanweisungs-Datensatzes in eine Betragsinformation des zweiten Zahlungsanweisungs-Datensatzes aufgrund eines vorgespeicherten Umtauschverhältnisses ausgeführt. Die hierfür benötigte Hard- und Softwareausstattung wird vom Systembetreiber bzw. Dienstanbieter bereitgestellt, und man kann sie sich in einem Umrechnungs-Server oder als zusätzliche Funktionalität eines der beteiligten Kontenverwaltungsserver realisiert denken. Das anzuwendende Umtauschverhältnis wird vom Transaktionsserver des Systembetreibers bereitgestellt, oder dieser führt auch - als Zusatzfunktionalität - die Umrechnung durch.
Die Datenübermittlungen werden von dem und zu dem Telekommunikations-End- gerät des Zahlers für eine Zahlung sämtlich per Kurznachricht gemäß SMS, Datenfile-Übertragung gemäß WAP oder über IVR-Sprachkommunikation ausgeführt. Hierbei ist die SMS-Variante - speziell ohne zusätzliche Bestätigung - eher für niedrige Beträge (darunter "Micropayments") sinnvoll. Bei der WAP-Variante ist die P2P-Engine in Art eines inzwischen bekannten "WAP-Shop" ausgeführt. Vorteilhaft dürfte jedenfalls eine Vermeidung von Wechseln im Zugriffsmedium während der Teilschritte des Auslösens der Zahlung, der Authentisierung und der Bestätigung des Guthabenübertrages sein.
Neben der bereits angesprochenen Authentisierung des Zahlers ist vorzugsweise bei höheren Geldbeträgen auch eine solche des Zahlungsempfängers anhand von im System (insbesondere beim Transaktionsserver oder zweiten Kontenverwaltungsserver) gespeicherten Nutzerdaten vorgesehen. Dies stellt eine wichtige Maßnahme gegen die Fehlleitung erheblicher Zahlungen dar. Im übrigen ist auch eine Verfahrensführung von Vorteil, bei der der Zahler über eine geeignete Ausführung des ersten Transaktionsservers - oder auch eine spezielle Schnittstelle zu seinem Kontenverwaltungsserver - einen Löschvorgang bezüglich der Zahlungs-Datenübertragung auslösen, die Zahlung also stornieren kann. In einer weiteren Option ist eine Benachrichtigung des Zahlungsempfängers über den vorgesehenen Guthaben-Übertrag vorgesehen, und in einer speziellen Fortbildung kann dieser weiterhin ein spezielles Zahlungsinstrument (einen Kontenverwaltungsserver) spezifizieren, zu dem die elektronische Zahlung gelenkt wer- den soll. Es sind also in diesem Sinne auch aktuelle Eingriffe in den Zahlungsvorgang seitens des Empfängers möglich.
Weiterhin ist zur Realisierung eines für den Systembetreiber bzw. Dienstanbieter wirtschaftlichen Betriebes die nachrichten- bzw. datenseitige Implementierung von Transaktionsgebühren (nachfolgend gefasst unter den Begriff "Abwicklungs- Betragsinformation) vorgesehen. Hierbei können die Transaktionskosten zu Lasten des Zahlers oder Zahlungsempfängers gehen oder zwischen beiden aufgespalten werden. Es wird zusammen mit der Abwicklungs-Betragsinformation dem zweiten Zahlungsanweisungs-Datensatz eine entsprechende Kennzeichnung dar- über hinzugefügt wird, ob das Zahlerkonto oder Zahlungsempfängerkonto oder beide anteilig zu belasten sind.
Zur Sicherung einer wirtschaftlich tragfähigen Ausführung internationaler Zahlungsvorgänge zwischen Währungen, für die kein fixes Umrechnungsverhältnis besteht, ist ein sogenannter Spread im Datenübertragungsablauf zu implementieren. Hierzu wird bei der Umrechnung der Betragsinformation des ersten Zahlungsanweisungs-Datensatzes (in der ersten Währung) in diejenige des zweiten Zahlungsanweisungs-Datensatzes (in der zweiten Währung) eine entsprechende Spread-Information eingerechnet. Diese ist insbesondere in einer dem Transakti- onsserver oder Systemverwaltungs-Server zugeordneten Datenbasis gespeichert.
Wesentliche Anordnungsaspekte des vorgeschlagenen Systems ergeben sich bereits aus den oben hervorgehobenen Verfahrensaspekten, so dass insoweit Wiederholungen entbehrlich sind. Es versteht sich nach obigem, dass Transaktions- Server eine wesentliche Komponente des vorgeschlagenen Systems darstellen und diese - je nach konkreter Systemausführung - mit TK-Endgeräten und wahlweise zusätzlich Datenendgeräten der Zahler sowie - direkt oder mittelbar über weitere Transaktionsserver - mit Kontenverwaltungsservern auf Zahler- und Zahlungsempfänger-Seite kommunizieren. Kernstück des Systems ist in bevorzugter Aus- führung ein Systemverwaltungsserver, der mit mehreren Transaktionsservern im wesentlichen dauerhaft verbunden ist und im übrigen eine Funktionseinheit mit einem Transaktionsserver bilden kann. Der Systemverwaltungsserver ist einem TK-Netz oder auch mehreren TK-Netzen (insbesondere Mobilfunknetz(en)) zugeordnet. Diese Zuordnung gilt in bevorzugter Systemausführung auch für den (bzw. mindestens einen) Kontenverwaltungsserver.
Der Systemverwaltungsserver hat typischerweise einen Ablaufprogrammspeicher zur Speicherung mindestens eines Transaktions-Ablaufprogrammes der Datenkommunikation zwischen dem Telekommunikations-Endgerät eines Zahlers und dem Kontenverwaltungsserver bzw. dem Transaktionsserver oder den Transaktionsservern, und ihm ist zweckmäßigerweise ein dediziertes Datenhaltungssystem zur Speicherung und Verwaltung aller gültigen Nutzerdaten und, insbesondere von zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge zugeordnet.
Figur 1 zeigt ein Blockdiagramm eines Herausgeber- und Erwerbersystems.
Figur 2 stellt einen Bezahlungsfluss in dem in Figur gezeigten System dar.
Figur 3 stellt eine Ausführungsform des interoperablen mobilen Bezahlungsprotokolls (IMPP) dar.
Figur 4 stellt eine beispielhafte Architektur eines IMPP-Unterprotokolls dar.
Figur 5 stellt eine WOPP-Meldungsverarbeitung dar.
Figur 6 stellt eine Verarbeitung für eine Web-WAP-Makrobezahlung (Macropay- ment) dar.
Figur 7 stellt eine Verarbeitung für eine Web-WAP-Mikrobezahlung (Micropay- ment) dar.
Figur 8 stellt eine Verarbeitung für eine WAP-WAP-Makrobezahlung (Macropay- ment) dar. Figur 9 stellt eine Verarbeitung für eine Web-WAP-Adressübertragung ohne Bezahlung dar.
Figur 10 stellt eine Verarbeitung für eine Automaten-Makrobezahlung dar.
Figur 11 stellt eine Verarbeitung für eine statische OfferlD-Erzeugung dar.
Figur 12 stellt ein IMPP Statusmodell für direkte Makrobezahlungen dar.
Figur 13 stellt ein IMPP Statusmodell für Makrobezahlungsgutschriften (Macro- payment credits) dar.
Figur 14 stellt ein IMPP Statusmodell für verzögerte Makrobezahlungen dar.
Figur 15 stellt ein IMPP Statusmodell für teilweise Makrobezahlungen dar.
Figur 16 stellt ein IMPP Statusmodell für direkte Mikrobezahlungen dar.
Figur 17 stellt ein IMPP Statusmodell für verzögerte Mikrobezahlungen dar.
Figur 18 stellt ein IMPP Statusmodell für Mikrobezahlungsgutschriften (Micropay- ment credits) dar.
Figur 19 stellt eine IMPP Meldungsstruktur dar.
Figur 20 stellt eine Verarbeitung zur Versionsabsprache im Kontext von IMPP dar.
Figur 21 stellt ein OfferlD Statusdiagramm dar.
Figur 22 stellt eine Verarbeitung für eine beispielhafte Währungsumrechnung dar.
Figur 23 stellt eine Verarbeitung für Mikrobezahlungsausgleich und -abrechnung (Micropayment Clearing and settlement) dar.
Figur 24 stellt ein Ausgleichsdatenstatusdiagramm dar. Figur 25 stellt eine Verarbeitung zur Gebührenverteilung dar.
Figur 26 stellt eine Verarbeitung zur Rechnungsstellung dar.
Figur 27 stellt eine Hintergrundverarbeitung (back-office processing) dar.
Fig. 28 zeigt eine schematische Übersichtsdarstellung wesentlicher Komponenten bzw. Schichten sowie Prozessabläufe eines erfindungsgemäßen Systems.
Fig. 29A bis 29C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer Ausführungsform des erfindungsgemäßen Verfahrens (Web-WAP-Scenario).
Fig. 30A bis 30C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens (WAP-WAP-Scenario).
Fig. 31A bis 31C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens (Push-Fall-Back-Scenario).
Fig. 32A und 32B zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge bei der Erzeugung einer statischen Offe- rlD im Kontext eines Ausgabeautomaten/TV-Shopping-Szenarios.
Fig. 33A und 33B zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge bei der Löschung einer statischen OfferlD im gleichen Kontext.
Fig. 34A bis 34C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens (Ausgabeautomaten/TV-Shopping-Szenario). Fig. 35A und 35B zeigen ein schematisches Ablaufdiagramm (Sequence Diagram) sowie eine Liste von Schritten beim Ablauf einer Clearing-Prozedur bei der Transaktion größerer Geldbeträge (Makro Payment).
Fig. 36A bis 36C zeigen eine schematische Ablaufdarstellung (Sequence Diagram) sowie eine Liste der Schrittfolge einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens (Micro-Payment-Szenario mit "Stored Value Accounts").
Fig. 37 zeigt eine schematische synoptische Darstellung aus System Struktur und Verfahrensschritten bei einer ersten Verfahrensvariante.
Fig. 38 zeigt eine Liste der Verfahrensschritte bei dieser ersten Variante.
Fig. 39 zeigt eine schematische synoptische Darstellung aus Systemstruktur und Verfahrensschritten bei einer zweiten Verfahrensvariante und
Fig. 40 zeigt eine Liste der Verfahrensschritte bei dieser zweiten Variante.
Vorliegend wird ein interoperables mobiles Bezahlungsprotokoll (IMPP) im Zu- sammenhang mit einem System beschrieben, welches Nachrichtenübermittlung zwischen einer Herausgeberdomäne und einer Erwerberdomäne vorsieht. Sowohl mobile Geräte als auch nicht mobile Geräte können in Verbindung mit dem IMPP benutzt werden. Das IMPP ist nicht auf einen Einsatz im Zusammenhang mit dem hier beschriebenen spezifischen System begrenzt und kann in anderen Systemen mit Architekturen, welche von der hier beschriebenen Systemarchitektur abweichen, genutzt werden.
Der Begriff "interoperabel" bezieht sich auf die Interoperationen, welche zwischen der Herausgeberdomäne und der Erwerberdomäne ausgeführt werden. Der Begriff "Herausgeberdomäne" (manchmal hier auch als "Herausgeber" bezeichnet), wie hier verwendet, bezieht sich auf Geldbörsenherausgeber (wallet issues). Bezahlungsmittel werden autorisiert durch z.B. Banken oder sind Wertspeicherkarten. Ein Herausgeber erklärt einen Kunden für gültig und der Kunde verfügt über Bezahlungsmittel in seiner Geldbörse. Bei einigen Transaktionen, z.B. Mik- robezahlung, kann ein telco oder ISP ein Herausgeber sein. Der Begriff "Erwer- berdomäne" (manchmal hier als ein "Erwerber" bezeichnet), wie hier benutzt, bezieht sich auf Institutionen, welche von Händlern transaktionsbezogene Daten erwerben und diese Daten an ein Ausgleichsnetzwerk zur Berechtigung senden.
Die hier benutzten Begriffe "Kunde" und "Käufer" betreffen die Besitzer von Be- zahlungsmitteln (z.B. Kreditkarten), welche Einkäufe bei einem Händler tätigen. Der Begriff "Händler" bezieht sich auf diejenigen, welche Waren zum Verkauf anbieten und/oder Dienstleistungen für einen Kunden gegen Bezahlung durch den Kunden zur Verfügung stellen. Der Begriff "Geldbörsen(wallet)server" bezieht sich auf ein sicheres Repositorium (secure repository) für Bezahlungsberechti- gungsnachweise von Karteninhabern, welche einem Kunden erlauben, eine entfernte (remote) Bezahlungstransaktion von irgendeinem der mehreren Geräte abzuschließen. Der Begriff "Bezahlungs(payment)server" bezieht sich auf einen Server, welcher Bezahlungsanfragen aus der Herausgeberdomäne (z.B. eines Kun- den- oder Geldbörsenservers) an Händler akzeptiert. Ein Bezahlungsserver kann auch Bereitstellungsfähigkeiten für Händler aufweisen.
Nachfolgend wird ein allgemeiner Überblick in Form einer Beschreibung eines Systems gegeben, welches elektronische Transaktionen ermöglicht, einschließlich mittels Geräten wie an Netzwerke gekoppelte Computer (z.B. Weitbereichsnetzwerken (wide area networks) wie dem Internet) und drahtloser Geräte (z.B. mobile Telefone) ausgeführte Transaktionen. Dem Überblick über das System folgend sind Details hinsichtlich des IMPP beschrieben. Zusätzlich wird eine detaillierte Beschreibung der Verarbeitung geliefert, welche unter Steuerung des IMPP in dem beispielhaften System auftritt.
Das System setzt voraus, dass ein Herausgeber Verträge mit Konsumenten hat und deren Konten(Account)Informationen handhabt. Die Konteninformationen umfassen Bezahlungs- und Sicherheitsinformationen. Der Händleraquisiteur (Er- werberdomäne) verfügt über Verträge mit Händlern und stellt Bezahlungsdienstleistungen zur Verfügung. Eine Zentral prozessorplattform (interop domain) verwaltet die Interoperabilität und bietet zentrale Dienstleistungen wie Transaktionsausgleich und Abrechnung an. Diese Architektur hält herkömmliche Händler- und Händleraquisiteursarbeitsabläufe (work flows) aufrecht und erweitert die existierende Bezahlungsinfrastruktur um mobile Bezahlungen. Unter besonderer Bezugnahme auf Figur 1 umfasst das System eine Zentralprozessorplattform (CPP), welche mit einem Geldbörsenserver und einem Bezahlungsserver kommuniziert. Die CPP führt sowohl Realzeit (real time) und NichtRealzeit (non-real time) Verarbeitung durch. Zum Beispiel vollzieht die CPP Wei- terleitungs(Routing, OfferlD)-, Such(look-up)-, Währungsumrechnungs- und Transaktionsverwaltungsfunktionen in Realzeit (real time). Nicht-Realzeit-Verarbeitung umfasst z.B. Mikrobezahlungsabrechnung und Ausgleich, Gebührenbearbeitung und Rechnungsstellung und Anlagenausschüttung.
Die CPP umfasst eine Weiterleitungsmaschine (routing engine) zum Weiterleiten von transaktionsbezogenen Nachrichten zwischen Geldbörsenservern und Bezahlungsservern in Übereinstimmung mit dem IMPP. Insbesondere unterbricht die Weiterleitungsmaschine das IMPP und leitet Anfragen weiter, welche Bezahlungs- transaktionen wie auch Antworten zwischen externen Parteien einschließen. Transaktionen (Makro- und Mikrobezahlungen) erfolgen deshalb durch die Weiterleitungsmaschine.
Die CPP umfasst ebenso einen Währungsumrechnungsserver, welcher mit einer Umrechnungskursdatei gekoppelt ist, einen Angebotsidentifikations(OfferID)ser- ver, welcher mit einem OfferlD Repositorium (repository) verbunden ist, einen Such(look-up)server, welcher mit einem Geldbörsenserver(WS)/Zahlungsser- ver(PS)-Verzeichnis verbunden ist und einen Negativdateiserver, welcher mit einer Kunden- und Händlernegativdatei verbunden ist. Die CPP umfasst weiterhin eine Endstück(back end)-Bearbeitungsfunktionalität wie Mikrobezahlungsausgleich und -abrechnung und Gebührenabrechnung und -Verwaltung. Insbesondere umfasst die CPP einen Gebührenabrechnungs- und -Verwaltungsserver und einen Mikrobezahlungsserver, welche mit einem Transaktionsprotokoll (lock) gekoppelt sind. Der Gebührenabrechnungs- und -Verwaltungsserver ist mit einer Neuunter- nehmensregeldatenbank gekoppelt, welche Regeln zur Gebührenabrechnung und Ausschüttung von Anlagen an Unternehmen enthält, welche neu in dem System sind. Der Gebührenabrechnungs- und -Verwaltungsserver ist auch an eine Datenbank gekoppelt, welche Abrechnungsdaten enthält. Die Weiterleitungsmaschine der CPP hört IMPP-Nachrichten ab, wodurch es mehreren Geldbörsenservern ermöglicht wird, mit mehreren Bezahlungsservern über eine zentrale Instanz zu kommunizieren. Durch das Weiterleiten von Bezahlungstransaktionen durch die CPP hat das Hinzufügen zusätzlicher Teilnehmer keinen Einfluss auf die existierende Installation und vereinfacht das Hinzufügen zusätzlicher Teilnehmer.
Mobile Bezahlungen, Anfragen und Antworten werden zwischen Geldbörsenserver- und Bezahlungsserverinstanzen weitergeleitet. Andere CPP-Komponenten, welche zentralisierte Aufgaben wie den OfferlD-Generator, Suchdienst und FX- Server ausführen, werden durch die Weiterleitungsmaschine in Anspruch genommen, um die Bezahlungsprozesse zu unterstützen. Die Transaktionsprotokolleinträge werden so erzeugt, dass diese den gesetzlichen Erfordernissen entsprechen und gekoppelte (offline mode) Prozesse wie Gebührenabrechnung ermöglichen. Die CPP verarbeitet auch Adresswechselanfragen, Altersprüfanfragen und Anfragen zum Wechsel des Bezahlungsinstruments. Qualitätskennungen werden zusammen mit Anfragen/Antworten übertragen, welche das Qualitätsniveau der zugrundeliegenden Daten angeben.
Die CPP-Weiterleitungsmaschine empfängt externe Benachrichtungen über Makrobezahlungsberechtigungen und vervollständigt die Transaktionsprotokolle und tauscht Benachrichtigungen über alle Statusänderungen zwischen den anderen einbezogenen Parteien aus, um die Transaktionsprotokolle des WS, MS und der Encorus-Prozessorplattform konsistent zu halten.
Mit Mikrobezahlungen wird die Berechtigung zwischen WI und Anbietern von Mikrobezahlungsmitteln durchgeführt. Die Berechtigungen werden deshalb mit den Bezahlungsmeldungsflüssen an den Bezahlungsserver übertragen. Bei einer in Gang befindlichen Bezahlungstransaktion behält die Weiterleitungsmaschine Transaktionsdatensätze (transaction records) bei und speichert alle Informationen über eine Transaktion zusammen mit einer eindeutigen TransaktionsID (tran- sactionlD).
Die Suche nach dem Bezahlungsserver und in eine Transaktion einbezogenen Händler wird auf Basis einer OfferlD (OID) oder RangelD durchgeführt. Durch Ausführen der Suche auf Basis einer OfferlD wird die BasketlD aufgelöst und zusammen mit der OID an den MC übertragen, um den Einkaufskorb (Shopping basket) zu erfragen. Der spezielle Händler bestimmt, ob die OID oder die BasketlD zum Identifizieren des Einkaufskorbs benutzt werden. Durch Ausführen der Suche auf Basis einer RangelD wird die Kombination aus RangelD und Händlerkatalognummer an den MC übertragen, um den Einkaufskorb zu erfragen.
Die Teilnehmerliste enthält alle MSISDNs und Pseudonyme (aliases) der Kunden, welche für mobile Bezahlung eingetragen sind. Für jedes MSISDN/Pseudonym wird die HeimgeldbörsenserverlD (home wallet Server ID) ebenso gespeichert. Die MSISDNs/Pseudonyme, welche nicht eingetragen sind, können bei der Verarbeitung durch die CPP frühzeitig abgewiesen werden.
Die OfferlD identifiziert einen Einkaufskorb. Um die Korbinformationen in einem übergreifenden (cross)-WI/MA-Szenario zu identifizieren wird die OfferlD zentral erzeugt. Die OfferlD kann für die mobilen Bezahlungsszenarios sowohl für Mikro- als auch für Makrobezahlungen benutzt werden. In den meisten Fällen werden OfferlDs über ein mobiles Gerät mit begrenzten Fähigkeiten hinsichtlich Größe des Displays und Benutzbarkeit der Tastatur eingegeben.
Der OfferlD-Generator erzeugt eine OfferlD auf Anfrage und das OfferlD-Reposi- torium speichert erzeugte OfferlDs zusammen mit zusätzlichen Daten für Suchzwecke und verwaltet die OfferlD-Lebensdauer (life time). Nachfolgende Bezahlungstransaktionen können dieselbe OfferlD für Bezahlungstransaktionen (z.B. VM, TV Einkauf (Shopping)) nutzen. Statische OfferlDs können durch die Händler auf Monats- oder Jahresbasis "gemietet" werden. Dynamische OfferlDs kennzeichnen ein temporäres Angebot, weisen eine bestimmte Lebensdauer auf und werden durch einen einzelnen Kunden genutzt. Eine dynamische OfferlD wird automatisch gelöscht, sobald eine Transaktion abgeschlossen oder die maximale Lebensdauer überschritten ist.
Das OfferlD-Repositorium speichert Informationen über eine angefragte OfferlD. Wenn Altersprüfungen, Adresswechsel oder GI-Datentransfer anfragt ist, werden die relevanten Kennungen in dem OfferlD-Repositoriumsdatensatz gesetzt. Das OfferlD-Repositorium überwacht auch die ausgegebenen OfferlDs und setzt einen OfferlD-Status auf "gesperrt" (black-out), sobald die damit verbundene Lebensdauer ausläuft. Das OfferlD-Repositorium unterstützt auch manuelle Löschungsanfragen. Die Suchdienste nutzen das OfferlD-Repositorium, um den damit verknüpften Bezahlungsserver aufzufinden.
Die Händlernegativdatei hindert eingetragene Händler entweder daran, sich für mobile Bezahlung bei irgendeinem Händleraquisiteur einzutragen oder irgendeine Transaktion im eingetragenen Zustand einzuleiten. In der Händlernegativdatei werden die ID, die URL und der Händlername zusammen mit einer Zeitangabe gespeichert.
Die Käufernegativdatei hindert eingetragene Käufer entweder daran, sich für mobile Bezahlung an irgendeinem Geldbörsenserver einzutragen oder irgendeine Transaktion im eingetragenen Zustand einzuleiten. In der Käufernegativdatei werden die ID, der Name, der Vornahme, das Geburtsdatum und die MSISDN zusammen mit einer Zeitangabe gespeichert.
Da internationale Transaktionen durch CPP abgewickelt werden, stellt CPP eine zentrale Auslandswechselkursakquisition (foreign exchange (FX) rate acquisition), eine Kursdifferenzverwaltung (spread management) und einen Währungsumrechnungsdienst zur Verfügung. Die CPP berechnet Beträge in Kundenwährung (wenn diese verschieden von der Händlertransaktionswährung sind). Der FX-Server speichert Auslandswährungswechselkurse und führt Währungsumrechnungen zur Abrechnung von internationalen Mikrobezahlungen und Gebührenabrechnungen.
Der Geldbörsenserver (WS) kommuniziert mit Käufergeräten z.B. über gerätespezifische Gateways wie WAP und SMS-Gateways und speichert käufer- und trans- aktionsbezogene Daten wie MSISDN, Rechnungs- und Versandadresse, Kreditkartennummern. Der Geldbörsenserver stellt Kundenbetreuungsfunktionalitäten zur Verfügung und wickelt die Bezahlungsprotokollverarbeitung ab. Der Geldbörsenserver sendet Berechtigungsanfragen an ein Mikrobezahlungsmittel (μPI) weiter.
Jeder Geldbörsenherausgeber stellt wenigstens ein Mikrobezahlungsmittel bereit, welches entweder durch den Herausgeber betrieben wird oder an dem Geldbör- senserver einer dritten Partei aufgenommen wird. Das μPI kann verschiedenen Typs sein, z.B. ein dediziertes Wertspeicherkontensystem, ein Telco-Vorauszah- lungs(prepaid)konto oder eine Telco-Telefonbörse.
Der Bezahlungsserver PS verarbeitet das IMPP-Protokoll zwischen CPP und Händ- leraquisiteur und verarbeitet ein offenes Bezahlungsprotokoll (OPP (open payment protocol)) in Richtung einer Händlerkomponente. Der PS ist über ein Bezahlungsgateway mit Makrobezahlungsbefugten (z.B. Kreditkartenbezahlungsbefug- ten) verbunden, um Berechtigungsanfragen weiterzuleiten. Die Händlerkomponente (MC (merchant component)) ist in dem Einkaufssystem des Händlers inte- griert, um ein OPP zu ermöglichen.
Üblicherweise und vor der Bezahlungstransaktion greift ein Käufer auf ein Geschäft eines Händlers zu, z.B. über einen spezifischen Einkaufskanal (z.B. WEB, WAP, IVR, TV) oder liest Hinweise und Produktangebote an einem Verkaufsauto- maten. Zum Bestätigen der Bezahlungen nutzt der Käufer sein mobiles Telefon, um mit einem Geldbörsenserver Verbindung aufzunehmen (Zugriffsszenario (pull Szenario)) oder wird durch einen Geldbörsenserver angerufen (Anschubszenario (push szenario)). Die Berechtigung wird durch das Mobiltelefonnetzwerk zur Verfügung gestellt und die Berechtigung zur Bezahlung für irgendeinen Typ eines Bezahlungsmittels (z.B. Mikrobezahlungsmittel, Kreditkarte, Debitkarte) kann durchgeführt werden.
Insbesondere und unter Bezugnahme auf Figur 2 legt ein 3-Domänen-Modell einen Prozess für elektronische Bezahlungen fest. Der Begriff "Herausgeberdomä- ne" bezieht sich auf Herausgeber und Eigentümer von Bankkarten oder anderen Bezahlungsmitteln (z.B. Herausgebern und Kunden) und auf diejenigen, welche im Auftrag der Herausgeber handeln (z.B. der Geldbörsenserver). Der Begriff "Akquisiteurdomäne" betrifft diejenigen, welche Bezahlungen aus einer Herausgeberdomäne akquirieren. Der Begriff "Interoperabilitätsdomäne" betrifft die Schnittstelle zwischen der Herausgeber- und Akquisiteurdomäne zum Ermöglichen von Interoperationen (d.h. Abläufen zwischen der Herausgeberdomäne und der Akquisiteurdomäne) für elektronische Bezahlungen.
Der übliche Bezahlungsfluss wird weiter unten als eine Schrittfolge und mit Bezug auf Figur 2 beschrieben. Der unten beschriebene Bezahlungsfluss basiert auf ei- nem Einkauf, welcher über ein Netzwerk wie einem Weitbereichsnetzwerk (z.B. dem Internet) ausgeführt wurde. Natürlich sind auch andere Bezahlungsflüsse möglich und die weiter unten fortgeführte Beschreibung stellt nur ein Beispiel dar.
Schritt 0. Einkaufen. Ein Kunde blättert (kauft ein) in einem Angebot von Waren/Dienstleistungen eines Händlers. Im Ergebnis wird ein Auftrag in dem Einkaufssystem des Händlers gespeichert.
Schritt 1. Initiieren der Bezahlung. Am Schluss des Einkaufens klickt der Kunde auf einen Verweis (Link) in dem Geschäft, welcher den Kunden an den Geldbörsenserver weiterleitet. Die URL enthält Informationen, welche den Geldbörsenserver in die Lage versetzen, den Kontext der Bezahlung (z.B. Händler-URL und Auftragsidentifikation) zu bestimmen. Der Kunde stellt dem Händler die URL des Geldbörsenservers zur Verfügung (z.B. kann der Kunde die URL aus einer Herun- terzieh(drop-down)-Liste auswählen), so dass der Händler die richtige URL für den Verweis zusammenstellen kann. Demzufolge kann der Geldbörsenserver wenigstens den Händler und den Auftrag identifizieren.
Schritt 2. Berechtigung. Der Kunde loggt sich in den Geldbörsenserver ein. Die Berechtigung wird durch den Geldbörsenserver durchgeführt (welcher in vielen Fällen gleich dem Herausgeber ist). Ist der Kunde einmal berechtigt, behält der Kunde Zugriff auf die Kundendaten.
Schritt 3. Erlangen der Auftragsinformation. Der Geldbörsenserver ruft die Auftragsinformation (Auftragsbeschreibung, Zahlungsbetrag) von dem Händler ab. Der Händler gibt ebenfalls die URL seines Bezahlungsservers und die akzeptierten Bezahlungsarten zurück. Der Geldbörsenserver zeigt dem Kunden die Auftragsdaten an.
Schritt 4. Auswahl des Bezahlungsmitteis. Der Geldbörsenserver stellt, basierend auf der Liste der vom Händler akzeptierten Bezahlungsarten und den gespeicherten Bezahlungsmitteln des Käufers, eine Liste verfügbarer Bezahlungsarten/Mittel dar, aus welcher der Käufer wählen kann. Der Geldbörsenserver ruft die Auf- tragsdetails und die akzeptierten Bezahlungsarten ab. Schritt 5. Prüfen des Bezahlungsmittels. Der Geldbörsenserver tritt zuerst mit dem Herausgeber in Verbindung, um zu überprüfen, ob das ausgewählte Bezahlungsmittel gültig ist. Der Herausgeber kann weitere Daten (neben einer einfa- chen Ja/Nein-Antwort) an diesem Punkt (z.B. bei einem einmaligen Token, welcher speziell für die kommende Bezahlung verwendet wird) zurückgeben.
Schritt 6. Bezahlung. Der Geldbörsenserver sendet im Auftrag des Kunden eine Bezahlungsanfrage an den Bezahlungsserver.
Schritt 7. Überprüfen des Auftrags. Der Bezahlungsserver tritt mit dem Einkaufssystem des Händlers in Verbindung, um zu überprüfen, ob die von dem Geldbörsenserver empfangenen Auftragsdaten authentisch sind. Der Bezahlungsserver empfängt alle Daten, welche zum Verarbeiten der Bezahlung benötigt werden.
Schritt 8. Erfassung. Der Bezahlungsserver leitet die Bezahlungsdaten an den Akquisiteur weiter. Der Erfassungsschritt kann asynchron ausgeführt werden, wenn eine hinausgeschobene Belieferung verwendet wird.
Schritt 9. Ausgleich. Der Akquisiteur tätigt eine physische Bezahlung, d.h. der Akquisiteur führt die Bezahlungsanfrage über ein Geldinstitut in einer nachgestellten (back end) Operation aus. Der Ausgleich kann asynchron (z.B. in Stapeln (batches)) erfolgen. Das Ausgleichsnetzwerk verarbeitet die Transaktion und das Geld wird auf das Konto des Händlers überführt.
Schritt 10. Benachrichtigung. Der Bezahlungsserver benachrichtigt den Händler über den Erfolg der Transaktion. Die Benachrichtigung kann auch asynchron erfolgen.
Schritt 11. Lieferanfrage. Der Geldbörsenserver versorgt den Händler mit der Lieferadresse. Dieser Schritt kann an anderen Punkten der Meldungsfolge durchgeführt werden, z.B. vor der Bezahlung oder später, asynchron.
Viele Meldungen können berechtigungsähnliche Elemente mit sich führen. Z.B. prüft bei einer SET-Erfassungsanfrage (Capture Request) das SET-Gateway die Unterschrift des Karteninhabers. Gegenwärtige Bezahlungssysteme können auch einige dieser Meldungen weglassen oder die Art und Weise, wie bestimmte Informationen verarbeitet werden, kann verschieden sein, z.B. kann die Benachrichtigung durch den Käufer an den Händler zurückgeleitet werden oder in eini- gen Fällen völlig weggelassen werden. Die Schritte können auch miteinander verflochten oder weiter aufgespalten sein.
Protokoll
Das Protokoll umfasst verschiedene Unterprotokolle. Jedes Unterprotokoll verfügt über seinen eigenen festgelegten Umfang mit klaren Grenzen zu anderen Unterprotokollen.
In einer beispielhaften Ausführungsform wird ein Unterprotokoll als das interope- rable mobile Bezahlungsprotokoll (IMPP) bezeichnet und für Meldungen zwischen und über den Geldbörsenserver OpCo und das Bezahlungsserverprotokoll genutzt. Das andere Unterprotokoll ist das offene Bezahlungsprotokoll für den Informationsaustausch zwischen dem Bezahlungsserver und dem Händlersystem.
Das IMPP legt die Kommunikation zwischen den folgenden Komponenten durch die OpCo-Domäne fest.
Geldbörsenserver OpCo Bezahlungsserver Händlersystem
Eine beispielhafte Ausführungsform des IMPP ist in einem in Figur 3 dargestellten Modell beschrieben. Das IMPP führt eine zentrale Instanz zum Meldungsweiterlei- ten und anderer bezahlungsbezogener Verarbeitungen ein, welche hier auch manchmal als die OpCo-Domäne bezeichnet werden. Das OpCo hält die zentralen Angebotsdaten und findet in bestimmten Szenarien den Geldbörsenserver des Kunden während der Bezahlungseinleitung heraus. Weiterhin stellt das OpCo (über die CPP) das Weiterleiten von Bezahlungsmeldungen in beiden Richtungen zwischen einem Geldbörsenserver und einem Bezahlungsserver zur Verfügung. Bezugnehmend auf Figur 3 enthält der Geldbörsenserver Kernkundendaten, welche zur Berechtigung und Bezahlung vorrangig sind, genauso wie eine Transaktionshistorie.
Der Geldbörsenserver wird während der Bezahlungseinleitungsphase angesteuert (triggered) und sendet nachfolgend Bezahlungsmeldungen an den Bezahlungsser^ ver über das OpCo. Der Geldbörsenserver wird durch das OpCo benachrichtigt, wenn sich der Status einer Bezahlungstransaktion geändert hat und kann den Status einer bestimmten Transaktion abfragen, um die Transaktionshistorie zu aktualisieren.
Der Bezahlungsserver hält die Händler-Kerndaten für die Bezahlung und die Transaktionshistorie. Der Bezahlungsserver empfängt auch Bezahlungsmeldungen von dem OpCo und verarbeitet die Meldungen. Insbesondere sendet der Bezahlungsserver Meldungen an die Bezahlungsbefugte auf Seiten des Akquisiteurs und löst Ergebnisbenachrichtigungen an das OpCo und das Händlersystem aus. Der Bezahlungsserver sendet und empfängt die erforderliche Information an/von dem Händlersystem während der verschiedenen Phasen des Bezahlungsprozesses.
Der Begriff "Händlersystem" betrifft ein Einkaufssystem und Bezahlungs- stecker(p!ug-in)-Komponenten, welche auf der lokalen Domäne eines 3D-ModeII- konformen Bezahlungssystems des Händlers bereitgestellt werden. Das Händlersystem sendet und empfängt die erforderlichen Informationen an/von dem Be- zahlungsserver während der verschiedenen Phasen des Bezahlungsprozesses. Das Händlersystem stellt eine lokale technische Indikation des Bezahlungssystems in das Einkaufssystem des Händlers zur Verfügung, oft ergänzt durch einen Einkaufsstecker (Shopping plug-in).
Im weiteren erfolgt eine Beschreibung des Verfahrens oder Protokolls, welches in Verbindung mit den Nachrichten zwischen dem Geldbörsenserver und dem Bezahlungsserver in Verbindung mit einer Transaktion verwendet wird, wie in Figur 3 dargestellt. Schritt 1. Einkaufen. Ein Kunde sucht (kauft ein) Waren/Dienstleistungen und ein Auftrag wird in dem Einkaufssystem des Händlers gespeichert.
Schritt 2 und 3. Initialisieren des Angebotskontextes. Am Ende des Einkaufs klickt der Kunde auf einen Verweis in dem Geschäft, welcher das Senden des Angebotskontextes von dem Einkaufssystem an den Bezahlungsserver auslöst. Die Anfrage wird durch den Bezahlungsserver an das OpCo weitergeleitet. Der Angebotskontext wird gespeichert und die diesbezügliche OfferlD wird an den Bezahlungsserver und an das Händlersystem in der Antwort zurückgesendet. Der Ange- botskontext umfasst Informationen, welche anzeigen, ob eine Alterprüfung durchgeführt werden soll und ob eine Lieferadresse von dem Händler gefordert wird.
Schritt 4. Anzeigen der OfferlD. Der Käufer bekommt entweder die OfferlD ange- zeigt, um die Interaktion über den (verschiedenen) Bezahlungskanal weiterzuführen, oder der Käufer wird an seinen Geldbörsenserver über das OpCo (mit demselben Bezahlungskanal, nicht gezeigt) weitergeleitet. Das Herausfinden der Geldbörsen/Bezahlungsserver-URL wird innerhalb von OpCo und URL durchgeführt, wenn dies erforderlich ist. Die URL ist nicht erforderlich, wenn der Geld- börsenserver die Adresse des Bezahlungsservers nicht braucht. Bei dem IMPP kann der Bezahlungskanal von dem Einkaufskanal verschieden sein. Es wird dem Käufer genügend Information geliefert, um den Auftrag identifizieren zu können und der CPP das Erzeugen eines Bezahlungsaufrufs zu ermöglichen.
Schritt 5. Eingeben der OfferlD. Der Käufer wird gebeten, die von dem Geschäft empfangene OfferlD in seine Geldbörse einzugeben. Der Käufer wird am Geldbörsenserver durch das MSISDN des Mobiltelefons des Käufers in dem Bezahlungskanal identifiziert und berechtigt.
Schritt 6. Bezahlungsaufruf. Der Geldbörsenserver leitet die OfferlD an das OpCo und erhält die Bezahlungsaufrufinformation zurück. Dies umfasst, ob eine Altersprüfung durchgeführt werden soll und ob eine Lieferadresse von dem Händler gefordert wird. Der Käufer wird berechtigt und erhält Zugang zu seinen Daten. Schritt 7. Übertragen des Angebots. Der Geldbörsenserver sucht die Auftragsinformationen (z.B. Auftragsbeschreibung, letztendlicher Zahlungsbetrag) heraus.
Schritt 8. Die Daten werden durch das OpCo an den zugehörigen Bezahlungsser- ver weitergeleitet.
Schritt 9. Der Bezahlungsserver fragt Auftragsdetails von dem Händler ab. Das Händlersystem gibt ebenfalls die akzeptierten Bezahlungsarten zurück. Der Geldbörsenserver zeigt dann dem Kunden die letztendlichen Auftragsdaten an. Der Meldungsaustausch verläuft durch das OpCo, aber nicht direkt zu dem Händler wie in dem 3D-Modell. Der Geldbörsenserver braucht deshalb die Netzwerkadresse des Händlers nicht zu kennen. Der Geldbörsenserver leitet ebenfalls die Lieferadresse an den Händler zum Neuberechnen des letztendlichen Zahlungsbetrags und das Ergebnis einer möglicherweise von dem Händler gewünschten Altersprü- fung weiter. Der Geldbörsenserver empfängt die Auftragsdetails und die akzeptierten Bezahlungsarten. Die zu verwendenden Bezahlungsmittel werden ausgewählt und für gültig erklärt.
Schritt 10. Auswählen des Bezahlungsmitteis. Der Geldbörsenserver stellt, basie- rend auf der Liste der akzeptierten Bezahlungsarten des Händlers und gespeicherter Bezahlungsmittel des Kunden, eine Liste verfügbarer Bezahlungsar- ten/Mittel dar, aus welcher der Kunde wählen kann.
Schritt 11. Vorberechtigung. Der Geldbörsenserver tritt mit der Bezahlungsbefug- ten auf der Seite des Herausgebers in Verbindung, um zu überprüfen, ob die ausgewählten Bezahlungsmittel gültig sind, um Limitprüfungen durchzuführen und um eine Bezahlung im Falle eines Neufirmenschemas, welches zur interoperablen Mikrobezahlung konform ist, vor zu berechtigen.
Schritte 12 und 13. Berechtigen der Bezahlung. Der Geldbörsenserver sendet im Auftrag des Kunden eine Bezahlungsanfrage an das OpCo. Dies kann das Ergebnis einer Vorberechtigung im Falle von schemakonformen Mikrobezahlungen umfassen. Das OpCo leitet die Anfrage an den zugehörigen Bezahlungsserver weiter. Der Bezahlungsserver empfängt alle Daten, welche zur Verarbeitung der Bezah- lung benötigt werden. Schritt 14. Gegenprüfung des Angebots. Der Bezahlungsserver tritt mit dem Einkaufssystem des Händlers in Verbindung, um zu prüfen, ob die von dem Geldbörsenserver empfangenen Auftragsdaten authentisch sind.
Schritt 15. Berechtigung. Der Geldbörsenserver leitet die Bezahlungsdaten im Falle von Makrobezahlungen an die Bezahlungsbefugte auf Seiten des Akquisiteurs weiter oder prüft im Falle von schemakonformen Mikrobezahlungen das Ergebnis der Vorberechtigung. Beide Schritte 11 oder 16 werden sich gegenseitig aus- schließend durchgeführt, um eine Bezahlung durch OpCo zu berechtigen. Das Ausgleichsnetzwerk verarbeitet die Transaktion.
Schritt 16. Abrechnung. Die Bezahlungsbefugte auf Seiten des Akquisiteurs nimmt die physikalische Bezahlung vor, d.h. verarbeitet die Anfrage in den fi- nanztechnischen Endkomponenten (financial back-ends). Das Ausgleichen kann asynchron (z.B. in Stapeln (batches)) ausgeführt werden. Der Geldbörsenserver benachrichtigt den Händler über den Erfolg der Transaktion. Eine derartige Benachrichtigung kann auch asynchron erfolgen. Der Händler weiß deshalb, ob die Bezahlung erfolgreich war und ist in der Lage, mit der Lieferung der Waren zu beginnen.
Schritt 17. Lieferung. Das Ergebnis der Bezahlung wird dem Kunden angezeigt. Ist die laufende Bezahlung abgeschlossen, kann der Kunde die Interaktion mit dem Geschäft fortführen. Für den Kunden ist ein Bezahlungsbeleg typischerweise wichtig, insbesondere um den Zugriff auf den digitalen Inhalt unmittelbar nach der Bezahlung zu beginnen. Die Waren werden in dem Einkaufskanal oder asynchron geliefert. Der Geldbörsenserver empfängt einen Bezahlungsbeleg im Auftrag des Käufers.
Schritt 18 bis 19. Erfassung. Abhängig von dem Bezahlungssystem auf Seiten des Akquisiteurs können zurückgestellte oder aufgeteilte Beträge erfasst werden und die Bezahlung wird (teilweise) zurückerstattet oder ein Guthaben wird durch den Händler asynchron vergeben. Diese Aktion kann durch Händler in den Einkaufssystemen ausgelöst werden und wird an den Bezahlungsserver weitergeleitet. Die Erfassungsanfrage wird durch den Bezahlungsserver an die Bezahlungsbefugte auf Seiten des Akquisiteurs weitergeleitet. Das Geld wird dem Händler verbucht und nach Abrechnung übertragen.
Schritte 20 bis 23. Statusbenachrichtigungen und Anfragestatus.
Unter jetziger Bezugnahme auf Figur 4 verwaltet die OPP den Informationsaustausch zwischen dem Geldbörsenserver, dem Händlersystem und dem Bezahlungsserver. Das IMPP verwaltet die Kommunikation zwischen diesen Komponenten und der OpCo-Domäne. Das OPP legt zusätzliche Meldungen zum Informati- onsaustausch über IMPP fest und das OPP verwaltet den Informationsaustausch über die OpCo-Domäne, welcher von dem speziellen Einkauf und einem Bezahlungskanal oder einer Kombination von beiden abhängt. Das OPP hängt teilweise von dem unterstützten Bezahlungs- und Einkaufsszenario ab. Das OPP legt den Informationsaustausch zwischen den einbezogenen Komponenten über die OpCo- Domäne durch Verwenden des IMPP fest. Das OPP verwaltet nicht die Kommunikation innerhalb der Herausgeber- und der Akquisiteurdomäne. Der OPP-Mel- dungsfluss ist in der "Bezahlungseinleitungs(Payment initiation)"-Phase und der "Nachbezahlungs(Post-Payment)"-Phase des 3D-Modells beschrieben.
Die "Bezahlungseinleitungs"-Phase des Modells beschreibt das Auffinden des Geldbörsenservers und die Weckrufmeldung. Die "Nachbezahlungs"-Phase beschreibt den Benachrichtigungs- und Lieferungsprozess. Das OPP verwaltet nicht die Kommunikation zwischen dem Kunden und dem Händlersystem, da diese Kommunikation durch den Händler oder das Einkaufssystem festgelegt wird. Das OPP verbirgt die Bezahlung, das Einkaufen und Szenario spezifische Daten, so dass das zugrunde liegende IMPP keine Rücksicht auf diese Daten nehmen muss.
Das OPP benutzt das zugrunde liegende Protokoll, um die Meldungen zwischen dem Geldbörsenserver und dem Bezahlungsserver auszutauschen. Das bedeutet, dass der Geldbörsenserver und der Bezahlungsserver keine direkte Netzwerkkommunikation unterstützen. Alle Kommunikation zwischen dem Geldbörsenserver und dem Bezahlungsserver werden von dem gleichen IMPP verwaltet, welches die gesamte Kommunikation zwischen den drei Komponenten Geldbörsenserver, Prozessplattform und Bezahlungsserver verwaltet. Deshalb müssen Meldungspaa- re von dem OPP in zusätzlichen Meldungen gekapselt werden, um diese über das zugrundeliegende Unterprotokoll zu übertragen. Für den Geldbörsenserver (WS Übertragung (WSTransfer)) und den Bezahlungsserver (PS Übertragung (PSTrans- fer)) eingeleiteten Austausch sind zwei neue Meldungspaare notwendig. Die Meldungspaare sind weiter unten beschrieben.
Weckrufanfrage und Antwortmeldung: Die Weckrufanfrage wird durch das Händlersystem abgegeben, um eine Geldbörsenserversuche in bestimmten Bezahlungsszenarien einzuleiten. Diese Anfrage wird an die Prozessorplattform gesendet, welche die Bezahlung durch den entsprechenden Heimgeldbörsenserver (Home Wallet Server) des Kunden einzuleiten. Der Weckrufprozess hängt von der Kombination aus Einkaufs- und Bezahlungskanal ab.
Lieferanfrage und Antwortmeldung: Die Lieferanfrage wird durch den Geldbörsenserver abgegeben, um das Händlersystem über eine abgeschlossene Bezah- lungstransaktion zu informieren. Das Händlersystem kann diese Benachrichtigung nutzen, um den Lieferprozess einzuleiten. Der Lieferprozess hängt von dem Bezahlungs- und Einkaufsszenario ab.
Wiederaufnahme Anfrage und Antwort Meldung: Die Wiederaufnahme Anfrage wird durch den Geldbörsenserver abgegeben, um eine unterbrochene Lieferung von Onlineinhalten abzuschließen.
Das IMPP verwaltet die bezahlungsspezifische Kommunikation zwischen dem Geldbörsenserver, dem Händlersystem der Prozessorplattform und dem Bezah- lungsserver. Das OPP verwaltet den Informationsaustausch über die OpCo-Domäne, welche von einem speziellen Einkaufs- und Bezahlungskanal oder einer Kombination von beiden abhängt. Das IMPP ist unabhängig von dem unterstützten Bezahlungs- und Einkaufsszenario.
Das IMPP führt die folgenden Funktionen durch: Es stellt eine Markenübertragung zwischen Kunde und Händler, Betragsneuberechnung durch das Händlersystem zur Verfügung; es stellt Auftragsinformationsaustausch zur Verfügung; es stellt Altersprüfungsfähigkeiten zur Verfügung; es stellt Adressaustausch mit und ohne Bezahlung zur Verfügung; es stellt einen Erweiterungsmechanismus zum Austau- sehen zusätzlicher Informationen in dem festgelegten Meldungsfluss zur Verfü- gung; es stellt Bezahlungsberechtigungen einschließlich "Soforterfassung(capture now)"-Einrichtungen für Makro- und Mikrobezahlungen zur Verfügung; es stellt eine OfferlD-Verwaltung zur Verfügung; und es stellt einen Erweiterungsmechanismus für den Austausch von zusätzlichen Meldungen über die CPP zur Verfü- gung. Die Integration und Kommunikation zwischen einem Kunden und dem
Geldbörsenserver und zwischen einem Händler und dem Bezahlungsserver ist unabhängig von dem IMPP. Das IMPP nimmt keine Rücksicht auf die Kombination von verschiedenen Einkaufs- und Bezahlungskanälen. Aus der Kombination von verschiedenen Einkaufs- und Bezahlungskanälen resultierende Probleme werden durch den OPP-Teil des Protokollstapels (Stacks) verwaltet. Das IMPP stellt eine Protokollschicht (protocol layer) zur Verfügung, um die globale Kommunikation zwischen Geldbörsenservern und Bezahlungsservern über eine einzelne Prozessorplattform zu verwalten.
Das OPP und IMPP berücksichtigen Bezahlung, Einkauf, Kunde, Händler oder Tel- co-spezifische Erfordernisse. Das IMPP hält einen Mechanismus zum Übertragen von Meldungen aus höheren Protokollschichten über die CPP zur Verfügung. Verschiedene Geldbörsenserver oder Bezahlungsserveranbieter sind in der Lage, die Funktion in eine höhere Protokollschicht ohne direkte Kommunikation zwischen Geldbörsenserver und Bezahlungsserver außerhalb des IMPP auszudehnen. Anbieter von Geldbörsenservern oder Bezahlungsservern implementieren das IMPP für die Kommunikation über die CPP.
Das IMPP bearbeitet Nachrichten zwischen allen einbezogenen Komponenten über die OpCo-Domäne. Es deckt dabei nicht die Kommunikation innerhalb der Herausgeber oder der Akquisiteurdomäne ab. Das IMPP verarbeitet die in der "Auf- tragsaustausch(order exchange)"-Phase und "Bezahlungs"-Phasen eines SD-Bezahlungsphasenmodells beschriebenen Meldungsflüsse.
IMPP-Meldungen sind gemäß verschiedenartiger Bereiche klassifiziert. Insbesondere werden alle Meldungspaare in einem Bezahlungsbereich als OpCo interpretiert. Normalerweise werden diese Meldungen von dem Geldbörsenserver abgegeben, um eine Bezahlungstransaktion auszuführen. Die OpCo empfängt die Meldung und interpretiert ihren Inhalt zum Transaktionsprotokollieren oder zur Ge- bührenverwaltung. Normalerweise werden die Meldungen an den Bezahlungsser- ver zur speziellen Verarbeitung weitergeleitet. Die entsprechende Meldungsantwort wird über die CPP an den Geldbörsenserver gesendet. In manchen speziellen Szenarien nimmt die CPP die eintreffende Anfrage auf und sendet eine Antwort zurück an den Geldbörsenserver. Die CPP interpretiert alle Meldungen innerhalb dieses Bereiches. Andere Bereiche umfassen einen Erweiterungsbereich, einen Benachrichtigungsbereich und einen Angebotsbereich.
Figur 5 stellt IMPP-Meldungen dar und jeder Meldungstyp würde darunter erklärt.
Insbesondere wird die PayPurchase-Anfrage durch den Geldbörsenserver abgege- ben, um einen Einkauf über IMPP einzuleiten. Diese Anfrage wird über die CPP an den Bezahlungsserver gesendet. Die CPP wirkt als Proxy für dieses Meldungspaar.
Die Paylnquire-Anfrage wird durch den Geldbörsenserver gegeben, um eine Anfrage über IMPP einzuleiten. Diese Anfrage wird über die CPP an den Bezahlungs- server gesendet. Die CPP wirkt als Proxy für dieses Meldungspaar.
Die PayStateUpdate-Anfrage wird durch den Bezahlungsserver abgegeben, um den Transaktionsstatus auf dem Geldbörsenserver zu aktualisieren. Diese Anfrage wird über die CPP an den Geldbörsenserver gesendet.
Die WSTransfer-Anfrage wird durch den Geldbörsenserver abgegeben, um eine Übertragung von zusätzlichen Informationen über IMPP einzuleiten. Diese Anfrage wird über die CPP an den Bezahlungsserver gesendet. Die CPP wirkt als ein Proxy für dieses Meldungspaar. Das WSTransfer-Meldungspaar kann zum Über- tragen von Meldungen aus einer höheren Protokollschicht über IMPP genutzt werden. Der Inhalt dieses Meldungspaars wird als anonymes Datum durch die CPP verarbeitet.
Die PSTransfer-Anfrage wird durch den Geldbörsenserver abgegeben, um eine Übertragung von zusätzlichen Informationen über IMPP einzuleiten. Diese Anfrage wird über die CPP an den Bezahlungsserver gesendet. Die CPP wirkt als ein Proxy für dieses Meldungspaar. Dieses PSTransfer-Meldungspaar kann zum Übertragen von Meldungen aus einer höheren Protokollschicht über IMPP genutzt werden. Der Inhalt dieses Meldungspaars wird als anonymes Datum durch die CPP verarbeitet. Die WSNotify-Anfrage wird durch den Geldbörsenserver abgegeben, um die CPP über zusätzliche Informationen zu benachrichtigen. Die CPP verarbeitet die Anfrage und erwidert mit einer entsprechenden Antwort. Zum Beispiel wird diese Anfrage genutzt, um die CPP über die Unterbrechung des Meldungsflusses durch den Kunden zu informieren. Auf diese Art und Weise ist die CPP in der Lage, die Situation innerhalb der CPP, z.B. das Löschen der dynamischen OfferlD in dem Kontext-Repositorium abzuwickeln.
Die PSNotify-Anfrage wird von dem Bezahlungsserver abgegeben, um die CPP über zusätzliche Informationen zu benachrichtigen. Die CPP verarbeitet die Anfrage und erwidert mit einer entsprechenden Antwort. Zum Beispiel wird diese Anfrage genutzt, um die CPP über eine Unterbrechung des Meldungsflusses zu informieren.
Die OfferCreateContext-Anfrage wird von dem Bezahlungsserver abgegeben, um eine neue OfferlD in dem Kontext-Repositorium zu erzeugen. Nach Verarbeitung der Anfrage in dem entsprechenden OfferlD-Server, wird eine Antwortmeldung an den Bezahlungsserver zurückgesendet. Dieses Meldungspaar ist für den Geldbör- senserver nicht sichtbar.
Die OfferDestroyContext-Anfrage wird von dem Bezahlungsserver abgegeben, um einen OfferlD-Eintrag in dem Kontext-Repositorium zu löschen. Nach Verarbeitung der Anfrage in dem entsprechenden OfferlD-Server, wird eine Antwortmel- düng an den Bezahlungsserver zurückgesendet. Dieses Meldungspaar ist für den Geldbörsenserver nicht sichtbar.
Die OfferModifyContext-Anfrage wird von dem Bezahlungsserver gegeben, um einen OfferlD-Eintrag in dem Kontext-Repositorium zu ändern. Nach Verarbeitung der Anfrage in dem entsprechenden OfferlD-Server, wird eine Antwortmeldung an den Bezahlungsserver zurückgesendet. Dieses Meldungspaar ist für den Geldbörsenserver nicht sichtbar.
Figur 6 stellt eine gültige Meldungsfolge für das Protokoll dar. Figur 7 stellt eine OfferlD-Meldungsfolge dar. Die Währungsumrechnung wird auf der Seite des Geldbörsenservers durchgeführt. Figur 8 stellt eine WAP-WAP-Mikrobezahlungsfolge dar. In Figur 8 liegen zwei Umleitungen vor, insbesondere eine Umleitung an die CPP, welche durch den Händler eingeleitet wurde, und eine an den Heimgeldbörsen-Server (home wallet Server), welche durch die CPP eingeleitet wurde. Figur 9 stellt eine WAP-WAP-Adressenübertragung ohne Bezahlungsfolge und Figur 10 eine Verkaufsautomaten-Makrobezahlungsfolge dar. Figur 11 stellt eine statische OfferlD-Erzeugungsfolge dar.
Die OfferlD weist die folgenden Stati auf.
Startstatus (SS (Start State)):
Registrierter Status (RS (Registered State)):
Erzeugter statischer Status (CSS (Created Static State)):
Erzeugter dynamischer Status (CDS (Created Dynamic State)):
Gesperrter Status (DS (Disabled State)):
Die folgenden Aktionen können zum Ändern des OfferlD-Status vorgenommen werden.
Registrieren (R (Register)):
Nicht Registrieren (UR (Unregister)):
Statisches Erzeugen (CS (Create static)):
Dynamisches Erzeugen (CD (Create dynamic)):
Ändern (M (Modify)):
Löschen (D (Destroy)):
Aktivieren (EA (Enable)):
Deaktivieren (DA (Disable)): Die dynamischen Transaktionsmodelle für Makrobezahlung haben gemeinsam, dass der Eigentümer des Transaktionsstatus der Bezahlungsserver ist. In dem in Figur 12 dargestellten Statusmodell werden die Transaktionsstati und Übergänge für eine umgehende Makrobezahlung benutzt, oft als "Verkaufs (Sales)"-Trans- aktionen bezeichnet. Kein gesonderter Schritt zum finanzieren der Bezahlung wird auf Seiten des Händlers/Akquisiteurs durchgeführt.
Das in Figur 13 dargestellte Statusmodell beschreibt die Transaktionsstati und Übergänge, welche für eine Makrobezahlungsgutschrift benutzt werden. Es wird von Händlern verwendet, um eine Gutschrift auf ein Makrobezahlungsmittel auszugeben. Dies wird durch Händler getätigt, um eine Bezahlung zurückzuerstatten, nachdem die eigentliche Transaktion schon abgerechnet wurde.
Das in Figur 14 darstellte Statusmodell beschreibt die Transaktionsstati und Übergänge, welche bei verzögerter Makrobezahlung benutzt werden. Dies wird verwendet, wenn der Händler eine berechtigte Bezahlung mit einiger Verzögerung, z.B. wenn die Waren versandt werden, erfasst. Wenn nur teilweise Versendung möglich ist, kann die teilweise Erfassung einmalig oder fortlaufend angewendet werden. Der Kunde kann den detaillierten Bezahlungsstatus in seiner Geldbörse verfolgen. Eine Statusmaschine wird für die Lebensdauer der anfänglichen Transaktion zur Verfügung gestellt und einer andere Statusmaschine wird für die Lebensdauer von teilweisen Transaktionen zur Verfügung gestellt.
Figur 15 stellt ein Statusmodell für teilweise Makrobezahlung dar. Eine teilweise Makrobezahlungstransaktion hat ihre eigene Lebensdauer und die Geldbörse des Käufers wird über alle Teilbezahlungsrelevanten Ereignisse benachrichtigt.
aufgehoben Notify: WSNotifyReqO Notify: PSNotifyReqO Set: internal triggered
Ackn.: WSNotifyRes() Ackn.: PSNotifyRes()
Die dynamischen Transaktionsmodelle für Mikrobezahlung haben gemeinsam, dass der Eigentümer des Transaktionsstatus der Geldbörsenserver ist, aufgrund der Tatsache, dass das kundenseitige Abrechnungssystem die Bezahlung bis zur Abrechnung aufrecht erhält.
Figur 16 stellt das Statusmodell für die Transaktionsstati und Übergänge dar, welche für eine umgehende Mikrobezahlung, z.B. eine Niedrigwerttransaktion benutzt werden, welche an einem Verkaufsautomaten eingeleitet wurde.
Figur 17 stellt ein Statusmodell für die Transaktionsstati und Übergänge dar, welche bei verzögerten Mikrobezahlungen benutzt werden. Dies wird benutzt, wenn der Händler eine berechtigte schemakonforme Mikrobezahlung nur teilweise oder mehrere Male mit sehr geringen Erfassungsbeträgen ("Sofort(Instant)"-Be- zahlung, z.B. "Bezahlen nach Zeit (pay per time)" oder "Bezahlen nach Umfang (pay per volume)" Geschäfte) erfasst.
Figur 18 stellt ein Statusmodell für Transaktionsstati und Übergänge dar, welches zum Ausführen einer Mikrobezahlungsgutschrift benutzt wird. Dies wird durch Händler genutzt, um eine Gutschrift auf ein Kundenmikrobezahlungsmittel zu übertragen. Die Händler brauchen dies, um eine Bezahlung zurückzuerstatten, nachdem die eigentliche Transaktion schon abgerechnet wurde.
Die IMPP-Meldungsstruktur besteht aus einer Zweischichtstruktur, nämlich einem Meldungsumschlag (message wrapper) und (eine HTTP-Anfrage oder -Antwort) und einer Meldung (einer XML-Einheit (entity)). Eine IMPP-Meldung wird synchron verarbeitet und weist ein XML-Meldungselement (Anfrage/Antwort-Paar) auf, welches in der entsprechenden HTTP-Anfrage und Erwiderung enthalten (wrapped) ist. Dieses Anfrage/Antwort-Paar stellt eine vollständige Protokollumwandlungseinheit (protocol conversation unit) dar. Wenn eine IMPP-Meldung einfach durch eine bestimmte technische Funktion an eine andere Einheit weitergeleitet wird, wird nur der Meldungsumschlag durch die weiterleitende Einheit verarbeitet. Die Meldung selbst kann unverarbeitet bleiben, um zusätzliche Verarbeitung oberhalb von XML-Syntax-Analyse (parsing) und Schreiben (writing) zu vermeiden.
Der Meldungsumschlag ist von dem genutzten Protokoll abhängig, welches
HTTP/1.0 ist. Folglich ist der Transportumschlag (transport wrapper) ein gültiger HTTP/1.0-Anfragekopf/Antwortkopf gemäß RFC822. Das genutzte HTTP-Anfrage- verfahren (verb) ist POST.
Anfrage
Antwort
Figur 19 stellt eine IMPP-Meldungsstruktur dar. Die Anfrage und die Antwort auf eine Meldung sind beide als eine serialisierte XML-Struktur dargestellt. Das XML- Basiselement (root element) <ImppMessage> enthält ein XML 'element only' E- lement <Header> und genau eine Anfrage oder ein Antwort XML 'element only' Element. Das <Header> Element enthält die Subelemente Id (für Meldungs- Idempotenz) und Version.
Dokumenttypvereinbarung Elementdefinition < !ELEMENT ImppMessage (Header, (...))> Elementdefinition <!ELEMENT Header (id, Version)>
Eine generische Beispiel-Meldung ist die folgende: <ImppMessage>
<Header>
</Header> <PayPurchaseRequest>
< !-...-->
</PayPurchaseRequest> </ImppMessage>.
Infolge der Meldungsstruktur kann eine hergestellte Verbindung nach Austausch einer vollständigen Protokollumwandlungseinheit (protocol conversation unit) wiederverwendet werden, um einen TCP connect/accept/close overhead auszuschließen und die Effizienz zu steigern. Das HTTP-keep-alive-Protokoll wird benutzt, um eine Abstimmung zwischen den einbezogenen technischen Funktionen auf Anwendungsebene zu erreichen. Eine schon hergestellte Verbindung kann in derselben Richtung wiederverwendet werden, d.h. innerhalb derselben Client/Server-Rollenzuweisung (role allocation).
Die Anwendungen des Geldbörsenservers und Bezahlungsservers verarbeiten An- erkennung (non-repudiation). Es können entweder entsprechende Attribute in den Protokollelementen oder erweiterte Elemente/Attribute genutzt werden. Das VPN verarbeitet die Verschlüsselung (encryption) jeder Kommunikation zwischen Geldbörsenservern und OpCo wie auch zwischen Bezahlungsservern und OpCo. Das VPN stellt nur Verbindungen zwischen zwei Parteien her, welche eine erfolg- reiche gegenseitige Berechtigung durchgeführt haben. Die Versendung von Anwendungsdaten erfordert die Beendigung des Berechtigungsprozesses.
Das Protokoll legt auch einen Mechanismus zur Versionsabsprache (version nego- tiation) zwischen den technischen Funktionen fest, ist aber unabhängig von den angewendeten konkreten Versionskompatibilitätsregeln. Das Protokoll umfasst das Senden der benutzten Protokollversion in dem Meldungskopf.
Innerhalb einer Protokollmeldungsfolge wird nur eine Version benutzt. Der Versionsabsprachefluß ist symmetrisch und es kommt nicht darauf an, ob der Geldbörsenserver, der Bezahlungsserver oder das OpCo selbst eine Folge einlei- tet. Darüber hinaus wird ein entsprechender Fehlercode festgelegt, um eine Versionsunverträglichkeit anzuzeigen. Wenn das OpCo in Folge einer Versionsunstimmigkeit eine Meldung nicht an den Empfänger weiterleiten kann, wird dies als technischer Fehler behandelt.
Der Versionsabspracheprozess ist in Figur 20 dargestellt und weiter unten beschrieben.
Schritt 1. Eine Bezahlungskomponente sendet eine IMPP-Anfrage an das OpCo unter Verwenden der höchsten IMPP-Version, welche durch den Absender unterstützt wird.
Schritt 2. Das OpCo prüft die Version und verarbeitet das Ergebnis.
Schritt 3. a) Prüfung OK: Die Anfrage wird an den Empfänger weitergeleitet.
b) Prüfung nicht OK: Das OpCo sendet eine Fehlermeldung zurück, welche die durch das OpCo unterstützten IMPP-Versionen enthält.
c) Nochmaliges Senden: Die Bezahlungskomponente sende die IMPP-Anfrage nochmals unter Verwenden der höchsten gemeinsamen Version oder stoppt mit einem Fehler.
Schritt 4. Die Bezahlungskomponente prüft die Version und bearbeitet das Ergebnis.
Schritt 5. a) Prüfung OK: Die Antwort wird an das OpCo zurückgesendet.
b) Prüfung nicht OK: Eine Fehlermeldung wird an das OpCo zurück gesendet, welche die durch den Empfänger unterstützten IMPP- Versionen enthält.
Schritt 6. a) Das OpCo erzeugt einen Mittelwert zwischen eigenen und durch den Empfänger unterstützten Versionen und sendet cisa Fehlermeldung an den Absender zurück, welche diese Information enthält.
b) Das OpCo sendet die normale Antwort an den Absender zurück.
c) Nochmaliges Senden: Die Bezahlungskomponente sendet die IMPP-Anfrage nochmals unter Verwenden der höchsten gemeinsamen Version oder stoppt mit einem Fehler.
Aus der Perspektive eines IMPP-Teilnehmers treten IMPP-Flüsse in Paaren auf. Jede von einem anfragenden Teilnehmer übermittelte Meldung wird von einem antwortendem Teilnehmer erwidert. Der Fehlerfluss (im Unterschied zu anderen Flüssen) wird hinsichtlich des Anfragenden und Antwortenden festgelegt, da die- ser genutzt wird, wenn der Antwortende die eingehende Meldung nicht verlässlich identifizieren kann. Eine Fehler zeigt an, dass eine Antwortender eine Meldung abweist, weil ein Formatfehler vorliegt oder Inhaltsprüfungstests fehlgeschlagen sind. Der Antwortende sendet einen Fehler (eher einen negativen Antwortcode), wenn der Antwortende irgendeinem der Felder der eingehenden Mel- düng nicht trauen kann. Üblicherweise wird ein Fehler genutzt, um dem Absender einer Meldung direkt zu antworten, wenn es nicht möglich ist, den Fehler eindeutig auf einen fehlerhaften Wert eines Feldes einzugrenzen. Die Fehlermeldung wird nicht benutzt, um normale Geschäftsergebnisse wie eine abgelehnte Berechtigung anzuzeigen. Geschäftsergebnisse werden durch explizite Codes in standar- disierten Antwortmeldungen angezeigt.
Fehler in dem IMPP-System können aus einer Anzahl von verschiedenen Quellen resultieren. Zum Beispiel können IMPP-Meldungen grammatikalisch bestimmbar (parseable), aber durch nicht befolgen der Anforderungen des Protokolls fehlge- bildet (malformed) sein, Werte können falsch oder Meldungen können beschädigt sein, üblicherweise als Ergebnis von Übertragungsfehlern.
Hinsichtlich doppelter Meldungen erscheint genug Information im Klartext des Meldungsumschlags, so dass herausgefunden werden kann, ob eine Meldung eine Neuübertragung ist oder nicht. Die Reaktion des Empfängers auf eine doppelte Meldung hängt von der Indempotenz-Eigenschaft (im Detail weiter unten beschrieben) des Meldungstyps, der Anzahl von verdoppelten Meldungen, der Quelle der doppelten Meldungen und von der beobachteten Frequenz zwischen nachfolgenden doppelten Meldungen ab. Wenn ein System Verdacht schöpft, dass es Uberschwemmungs- oder Werbebemüllungsangriffen ausgesetzt ist, können doppelte Meldungen ignoriert werden.
Eine beschädigte Meldung ist eine Meldung, welche nicht grammatikalisch bestimmbar (cannot be parsed) ist. Üblicherweise sollte eine möglicherweise be- schädigte Meldung nicht empfangen werden, weil die Nachrichtentransportmechanismen veranlassen werden, dass beschädigte Daten zurückgesendet werden. Wird eine beschädigte Meldung jedoch empfangen, wird eine entsprechende Fehlermeldung zurückgegeben, welche anzeigt, dass eine beschädigte Meldung empfangen wurde und eine Anfrage/Antwortpaarkennung der Meldung zur Verfügung stellt, wenn diese verfügbar ist. Es wird akzeptiert, die Meldung völlig zu ignorieren, wenn nicht genügend Daten entnommen wurden, um in der Lage zu sein darauf zu antworten. Hinsichtlich fehlgebildeter Meldungen wird eine entsprechende Fehlermeldung von dem AbAbsender zurückgegeben, wenn eine Meldung grammatikalisch bestimmbar ist, aber ansonsten aufgrund von außerhalb eines Bereichs liegenden Werten oder inkonsistenten Optionen falsch ist.
Eine Anwendung erzeugt keine Fehlermeldung als Antwort auf eine andere Fehlermeldung. Alle IMPP-Komponenten senden eine Fehlermeldung, wenn ein auf niedriger Ebene (low-level) liegender Verarbeitungsfehler auf eine IMPP-Antwort- meidung auftritt. Jede Meldung, welche nicht als IMPP-Meldung erkannt wird, wird ignoriert. Die IMPP-Komponenten vermeiden üblicherweise das Senden von Fehlermeldungen auf demselben Kanal wie Anfragemeldungen.
Die folgenden Felder sind für Fehler (error) festgelegt.
ErrorCode: Nummerierter Code, welcher die Fehlerbedingung definiert. ErrorDescription: Eine freie Beschreibung der Fehlerursache. ErrorObjectID: Die Objektkennung einer nicht-unterstützten kritischen Erweiterung, welche den Fehler auslöste. ErrorMessage: Die Meldung, welche den Fehler erzeugte.
Das IMPP-Protokoll basiert auf Anfrage/Antwortpaaren durch das gesamte Protokoll hindurch. Die Fehlermeldung geht nicht konform mit diesem Paradigma, weil diese eine Antwort auf entweder eine Anfrage oder eine Antwort sein kann. Der frühere Fall stellt keine Schwierigkeit dar. In dem späteren Fall jedoch können Schwierigkeiten auftreten, wenn der zugrunde liegende Transport auf einem Anfrage/Antwortparadigma basiert, wie in einem World Wide Web-Browser. In diesem Fall kann die Fehlermeldung als eine Anfragemeldung gesendet werden und das Protokoll wird keine Antwortmeldung (das zugrunde liegende Protokoll kann zeitabgeschaltet (time out) sein) fordert. Für eine als Ergebnis der operativen Beschränkungen eines World Wide Web-Browsers gesendeten Fehlermeldung kann eine Benutzererlaubnis erforderlich sein.
Der HTTP-Meldungskopf enthält einen Statuscode, welcher den Verarbeitungsstatus der entsprechenden Meldungseinheit als Ganzes angibt. Jeder Geschäftsfehler wird unabhängig von dem Meldungsstatus durch die Bestandteile angezeigt. Die folgenden Statuscode sind als eine bestimmte Meldung definiert, welche die 5xx Statuscodebereiche des HTTP-Standards zum Anzeigen von anwendungsspezifischen Fehlern nutzen.
Im Fall eines Statuscodes verschieden von 200, wird der XML-Rumpf der HTTP- Antwort weggelassen. Darüber hinaus werden die anwendungsunabhängigen Statuscodes wie durch HTTP festgelegt für alle HTTP-spezifischen Ausgaben (z.B. 400 Schlechte Anfrage (Bad Request)) verwendet.
Wenn eine Operation beliebig oft ausgeführt werden kann, ohne dass ein Schaden entsteht, wird diese als idempotent bezeichnet. Aus der Perspektive des IMPP ist Idempotenz eine Eigenschaft, wie ein Empfänger auf eine Meldung antwortet. Jede Anfrage im IMPP, welche keine Antwort empfängt, wird wiederge- sendet, weil dem Absender nicht bekannt ist, ob die Anfrage oder Antwort verloren ging. Die übertragene Meldung ist bitweise identisch der ursprünglichen Anfragemeldung. Üblicherweise ist eine doppelte Meldung keine Fehlerbedingung.
Das IMPP-Protokoll arbeitet in Umgebungen, in denen die Meldungsabgabe nicht garantiert ist. Wenn eine IMPP-Anwendung keine Antwort in einer vernünftigen Zeitspanne (festgelegt durch die Anwendung oder möglicherweise in Antwort auf eine Benutzerfrage) empfängt, sendet sie die Meldung erneut. Wenn die empfangene IMPP-Anwendung feststellt, dass sie vorher die gleiche Meldung verarbeitet hat, ruft sie die vorherige Antwort ab und sendet die vorherige Antwort wieder. Wenn der Absender einer Meldung die Antwort nicht empfängt, ist es üblicherweise nicht möglich zu bestimmen, ob die Anfrage oder die Antwort verloren ging. Um diesen Zustand weiter zu komplizieren, kann die ursprüngliche Anfrage schlicht irgendwo in dem Netzwerk verzögert worden sein und dann möglicherweise kurz vor dem Eintreffen der zurückübertragenen Anfrage bearbeitet worden sein. Deshalb ermöglicht das Protokoll dem Absender, die Anfrage mit der Garantie zu wiederholen, dass das Ergebnis ohne Rücksicht darauf, ob die Anfrage oder die Antwort verloren ging, dasselbe sein wird. Nicht alle IMPP-Meldungen erfordern Idempotenz. Das IMPP enthält Meldungen, welche so gestaltet worden, dass sie zu jeder Zeit gesendet werden können, so dass es für einen Empfänger nicht notwendig ist, jede Anfrage zum Feststellen zu speichern, ob ein Duplikat empfangen wurde. Die IMPP-Produkte garantieren Idempotenz des Protokolls durch Überprüfen einer Transaktionskennung und Erzeugen eines Zeitstempels (time- stamp) in dem Meldungskopf. Z.B. lehnt ein Bezahlungsserver Versuche ab, Pay- Authorization-Anfragen eines Geldbörsenservers zu wiederholen. Der Bezahlungs- Server erkennt diese Versuche durch Überprüfen des Meldungskopfs der Pay- Authorization-Anfrage. Wenn eine IMPP-Komponente erkennt, dass sie böswilligen Uberschwemmungs- oder Werbebemüllungsangriffen ausgesetzt ist, welche keine oder mehr idempotente IMPP-Meldungstypen einbezieht, ist es nicht notwendig, auf diese Meldungen in dieser Situation zu antworten.
Die IMPP-Komponente kann jedes Verfahren nutzen, um idempotente Anfragen zu erkennen. Ein mögliches Verfahren besteht darin, den SHA-1-Hash des Meldungskopfs aller Meldungen zu speichern. Wenn ein Duplikat erkannt wird, kann der Hash des Meldungskopfs erzeugt und zum Aufsuchen eines gespeicherten Idem- potenz-Eintrags verwendet werden. Bei dieser Herangehensweise muss die IMPP- Komponente eine vollständige Kopie jeder eintreffenden Anfrage aufbewahren, kann, jedoch eine bitweise identische Antwort erzeugen. Eine bitweise Antwort wird hier als eine neue Antwort mit derselben Information erzeugt. Wenn mehrere Antworten auf eine idempotente Anfrage empfangen werden, kann der Emp- fänger alle solche Antworten nach der ersten ignorieren.
Eine IMPP-Komponente ist nicht zum Beantworten von Meldungen erforderlich, wenn sie erkennt, dass sie böswilligen Uberschwemmungs- oder Werbebemüllungsangriffen ausgesetzt ist, welche mit einem oder mehr IMPP-Meldungstypen einhergehen. Die IMPP-Komponenten können ihre eigenen Kriterien zum Erkennen solcher Angriffe aufbauen.
Im folgenden werden Beschreibung oder ähnliche Szenarien, welche idempotente Meldungsflüsse einschließen, behandelt. Diese Szenarien beschreiben zwei Über- tragungen derselben Anfrage, abhängig jedoch von den Bedingungen zur Zeit des Versagens kann die Anfrage mehrere Male wiederholt werden. Kombinationen von diesen Szenarien sind auch möglich. Verzögerte Anfrage oder Antwort: Eine idempotente Anfrage wird gesendet, doch die Abgabe entweder der Anfrage oder der Antwort wird verzögert, so dass der Empfänger keine rechtzeitige Antwort empfängt. Die Anfrage wird nochmals übertragen, die empfangene IMPP-Komponente verarbeitet die erste Anfrage und überträgt die Antwort zurück, wenn sie die zweite Antwort empfängt. Verlorene Anfragen: Eine idempotente Anfrage wird gesendet, doch die Abgabe der Meldung geschieht aufgrund eines Netzwerkversagens nicht. Die Anfrage wird nochmals übertragen.
Verlorene Antwort: Eine idempotente Anfrage wird gesendet und darauf geantwortet, doch die Abgabe der Antwort geschieht aufgrund eines Netzwerkversagens nicht. Die Anfrage wird nochmals übertragen. Die empfangene IMPP-Komponente verarbeitet die erste Anfrage und überträgt dann die Antwort zurück, wenn sie eine zweite Anfrage empfängt.
Es ist notwendig, einen Mechanismus zur Verfügung zu stellen, welcher IMPP- Bezahlungsmeldungen erweitert. Da in der IMPP-Meldung kein Platz vorgesehen ist, um diese Informationen aufzunehmen, wird eine Protokollerweiterung verwendet. Der zum Erweitern von IMPP-Meldungen verwendete Mechanismus gleicht der Art und Weise, in der X.509-Zertifikate erweitert werden. Insbesondere wird ein Erweiterungsfeld zur Verfügung gestellt, welches eine Folge von Erweiterungsdaten enthält. Die Erweiterungsdaten zeigen den Typ der Erweiterung und die Kritikalität (criticality) der Erweiterung an.
Eine Erweiterung weist drei Komponenten auf. Insbesondere eine Objektkennung, welche die Erweiterung eindeutig identifiziert. Diese Kennung erlaubt IMPP-Komponenten eine Erweiterung zu erkennen und Daten zu verarbeiten. Ein Kritikali- tätskennzeichen zeigt an, ob der Empfänger die Erweiterung zum Verarbeiten der Meldung versteht, welche die Erweiterung enthält. Die Daten stellen die zusätzli- ehe Geschäftsinformation zur Verfügung, welche das Festlegen der Erweiterung notwendig macht. Die Auslegung der Daten wird durch die Organisation festgelegt, welche die Erweiterung erstellt hat.
Das Kritikalitätskennzeichen ist ein boolischer Wert. Eine Erweiterung wird als kritisch eingeschätzt, wenn dieser Wert True ist. Anderenfalls wird die Erweiterung als unkritisch eingeordnet. Der Standardwert (default value) ist False. Wenn eine Erweiterung kritisch ist, erkennen und verarbeiten Empfänger der Meldung die Erweiterung. Wenn eine Erweiterung unkritisch ist, können Empfänger, welche die Erweiterung nicht verarbeiten können, die Daten sicher ignorieren. Ein Satz von Informationsobjekten wurde für jede Datenstruktur erzeugt, welche eine Erweiterung enthalten kann. Diese Sätze legen die Erweiterungen fest, welche in der Datenstruktur zum Verarbeiten erlaubt sind.
IMPP-Anwendungen passen in eine von zwei Kategorien. Insbesondere in eine Anwendung, welche keine Meldungserweiterungen unterstützt und in eine Anwendung, welche einige ausgewählte Sätze von Meldungserweiterungen unterstützt. Eine IMPP-Komponente, welche keine Meldungserweiterungen unterstützt, erkennt das Vorhandensein einer Erweiterung in einer Meldung und überprüft das Kritikalitätskennzeichen. Ist die Erweiterung kritisch, verarbeitet die IMPP-Komponente die Meldung nicht und weist sie mit einem Fehlercode unrecognizedEx- tension zurück. Ist die Erweiterung unkritisch, kann die Anwendung die Daten in der Erweiterung ignorieren und den Rest der Meldung weiterverarbeiten. Eine Anwendung, welche Meldungserweiterungen unterstützt, erkennt das Vorhanden- sein einer Erweiterung in einer Meldung und verarbeitet die Erweiterung wie folgt.
1. Wenn die Anwendung die Objektkennung für diese Meldung unterstützt, werden die Daten in der Erweiterung verarbeitet.
2. Wenn die Anwendung die Objektkennung für diese Meidung nicht unterstützt und die Erweiterung kritisch ist, verarbeitet die Anwendung die Meldung nicht und weist sie mit einem Fehlercode unrecognizedExtension zurück.
3. Wenn die Anwendung die Objektkennung für diese Meldung nicht unterstützt und die Erweiterung unkritisch ist, kann die Anwendung die Daten in der Erweiterung ignorieren und den Rest der Meldung weiterverarbeiten.
Das OpCo ist die letztendliche Entscheidungsinstanz darüber, ob ein gegebenes Datenelement innerhalb einer Meldung verschlüsselt wird. Das OpCo kann die
Nutzung irgendeiner Erweiterung ablehnen, welche Daten enthält, die die Integrität des IMPP beeinträchtigen können. Jede Erweiterung wird durch ihren Erweiterungsnamen, Eigentümernamen und eine eindeutige Erweiterungskennung identifiziert. Eine IMPP-Komponente kann entscheiden, eine kritische Erweiterung zum Übertragen zusätzlicher Informationen in dem normalen IMPP-Meldungsfluss zu benutzen. Wenn die empfangende IMPP-Komponente die Daten ohne die Erweiterung nicht versteht und diese deshalb nicht verarbeiten kann, sollte die Meldung abgelehnt werden.
Hinsichtlich der Transaktionen ist das Transaktionsmanagement verteilt, d.h. ein in eine Transaktion einbezogener Geldbörsenserver und Bezahlungsserver kommunizieren unter Verwendung von IMPP-Meldungen. Beide Server enthalten einen Statusmechanismus, z.B. Warten auf Antworten, Überprüfen von Unterbrechungen (time-out) und Senden von Abfrage- und Wiederherstellungsmeldungen im Fall von Fehlern. Die CPP hält ebenfalls Statusinformationen aufrecht, da IMPP- Meldungen durch die CPP weitergeleitet werden. Der "Eigentümer" einer Transaktion ist die Partei, welche für die primären Statusübergänge während der Lebensdauer einer bestimmten Transaktion verantwortlich ist. Der genutzte Synchronisationsmechanismus hängt von der technischen Eigentümerschaft der Transaktion ab. Es existieren verschiedene mögliche Eigentümerschaften für verschiedene durch IMPP unterstützte Bezahlungsmodelle, wie weiter unten beschrieben ist.
Das IMPP stellt die entsprechenden Meldungen oder Meldungsfolgen zum Unterstützen des Bezahlungsmodells zur Verfügung. Es existieren wenigstens zwei verschiedene Möglichkeiten, um Transaktionen über IMPP zu synchronisieren.
1. Benachrichtigen(Notify)/Bestätigen(Acknowledge): Die Verteilung von Informa- tionen über einen Statusübergang wird durch den Eigentümer der Transaktion durchgeführt. 2. Synchronisieren (Synchronize): Die Verteilung von Informationen über einen Statusübergang wird durch einen entfernten (remote) Teilnehmer der Transaktion ausgelöst (triggered).
Benachrichtigen/Bestätigen ist verfügbar, wenn es in dem entsprechenden Proto- kollfluss unterstützt wird. Wenn verfügbar, wird nur eine Benachrichtigung pro Übergang durchgeführt. Folglich werden unbestätigte Benachrichtigungen durch den Eigentümer nicht berücksichtigt. Die Synchronisation ist für entfernte Teilnehmer verfügbar, um Übergänge in einen finalen Status mehrmals abzufragen. Die Stati und deren Übergänge werden aus der Protokollperspektive genau beschrieben, welche eine Abstraktion von der Implementation in den Bezahlungskomponenten bedeutet. Wenn eine Komponente die "Historie (history)" eines Status benötigt, d.h. den Übergang, welcher zu einem Status führt, kann die Komponente anstatt dessen einen 'zusammengesetzten Status (composite State)' aufrechterhalten. Darüber hinaus legt jede Bezahlungskomponente ihren eigenen Weg fest, um Transaktionen zu löschen, d.h. um eine bestimmte Transaktion aus einem letztendlichen Geschäftsstatus in einen letztendlichen technischen Status zu überführen. Dies wird asynchron durchgeführt und ist nicht durch IMPP-Proto- kollmeldungen gedeckt.
Die Übergangsphasen sind weiter unten beschrieben.
Bezahlunosverarbeitunq
Weiter unten wird eine detaillierte Beschreibung von Prozessen gegeben, welche durch die beispielhafte Ausführungsform der CPP durchgeführt werden. Insbesondere wird die übliche Verarbeitung beschrieben genauso wie die Verarbeitung, welche mit OfferlDs, Negativdateien, Geldumrechnung, Transaktionsprotokollie- ren, Mikrobezahlungsausgleich und -abrechnung und Gebührenmanagement verbunden ist.
Für Mobilbezahlungen werden alle Anfragen und Antworten zwischen Geldbörsenserver und Bezahlungsserverinstanzen weitergeleitet. Andere CPP-Komponenten, welche zentralisierte Aufgaben ausführen, wie der OfferlD-Generator, der Such(look-up)-Dienst und der FX-Server, werden von der Weiterleitungsmaschine benutzt, um den Bezahlungsprozess zu unterstützen. Transaktionsprotokolleinträge werden erzeugt, um rechtliche Erfordernisse zu erfüllen und entkoppel- te(offline)-Modus-Prozesse wie Gebührenrechnungsstellung zu ermöglichen. Ad- ressänderungsanfragen, Altersprüfanfragen und Anfragen zum Wechsel des Be- zahlungsmittels werden zusammen mit regulären Bezahlungsanfragen genauso unterstützt. Qualitätskennzeichen werden zusammen mit diesen Anfragen/Antworten übertragen und zeigen den Qualitätsgrad der zugrundeliegenden Daten an.
Die Weiterleitungsmaschine empfängt externe Benachrichtigungen über Makrobe- zahlungsberechtigungen und -erfassungen, vervollständigt die Transaktionsprotokolle und Austauschbenachrichtigungen hinsichtlich Statuswechseln zwischen den anderen einbezogenen Parteien, um die Transaktionsprotokolle von WS, MS und CPP konsistent zu halten.
Mit den Mikrobezahlungen wird die Berechtigung zwischen WI und dem Anbieter des Mikrobezahlungsmittels durchgeführt. Deshalb werden Berechtigungs-Tokens mit dem Bezahlungsmeldungsfluss an den Bezahlungsserver übertragen. Für ge- rade stattfindende Transaktionen hält die Weiterleitungsmaschine Transaktionsdatensätze aufrecht, in welchen alle Information über eine Transaktion zusammen mit einer eindeutigen TransactionID (TX_ID) gespeichert ist.
In Umleitungsszenarien stellt die Weiterleitungsmaschine eine Umleitungskomponente zur Verfügung, welche 'Umleitungen (redirects)1 verarbeitet, bei denen der Browser des Kunden von der Händler-URL zu ihrer oder seiner Heimgeldbörsen- URL über ein CPP-URL und direkt zurück zu der Händler-URL nach Abschluss der Transaktion umgeleitet wird. Die Umleitungskomponente stellt eine zentrale Um- leitungs-URL zur Verfügung, welche Händler üblicherweise nutzen können, um die OfferlD anzuzeigen. Darüber hinaus kann der Käufer MSISDN/Pseudo- nym/Alias in einer vertrauten Umgebung eingeben, um Anschub- (push) oder Rückfall(fall-back)szenarien (wenn MSISDN nicht erkannt werden kann) zu ermöglichen. Um Vorwärtsszenarien zu unterstützen, leitet die Umleitungskompo- nente das Pseudonym des Käufers an den Geldbörsenserver weiter. Der WS löst dann einen IVR-Ruf (call) oder WAP-Anschub an den Käufer aus. Die Umleitungskomponente sollte nicht für nicht-mobile Kundenberechtigung (Web-Web Szenario) genutzt werden, z.B. mit Pseudonym-PIN, weil die Kundenberechtigung in der Verantwortung des Geldbörsenservers liegt.
Bei WAP-WAP-Szenarien unterstützt die Weiterleitungsmaschine 'Umleitungen (redirects)', bei denen der Browser des Kunden von der Händler-URL zu seiner Heimgeldbörsen-URL über ein OpCo-URL umgeleitet und direkt zurück zu der Händler-URL nach Abschluss der Transaktion umgeleitet wird. Die CPP stellt eine zentrale URL bereit, um die OfferlD anzuzeigen. Deshalb braucht der Händler die Anzeige der OfferlD nicht in den Einkaufsfluss zu integrieren. Darüber hinaus stellt diese URL Eingabefelder für MSISDN/Pseudonym zur Verfügung, um einen Anschub einzuleiten.
Transaktionen zwischen Händlern und Kunden, welche der gleichen Firma angehören, z.B. MNO, werden als "unter uns (on-us)"-Transaktionen bezeichnet, auf welche spezielle Regeln angewendet werden können. Wenn 'unter uns'-Transak- tionen zwischen einem Geldbörsenserver und einem MA-Server bewirkt werden, welche durch dieselbe Firma in einem Land betrieben werden, können diese Transaktionen ohne Weiterleiten durch das OpCo verarbeitet werden. Die CPP identifiziert ein 'unter uns'-Szenario und gibt eine entsprechende Antwort an den WS zurück. Bei Abschluss der Berechtigungsphase wird die CPP durch den PS benachrichtigt, um die OfferlD zu entfernen und die 'unter uns'-Beziehungen zwischen WS- und PS-Instanzen (betrifft beide Varianten) zu speichern. Jede Transaktion durch die CPP wird geprüft, um zu erkennen, ob der Typ der Transaktion 'unter uns' ist, wobei in diesem Fall das 'unter uns'-Kennzeichen innerhalb des Transaktionsdatensatzes gesetzt wird (betrifft beide Varianten). Bei Erkennung einer 'unter uns'-Transaktion wird der eingeleitete Bezahlungsfluss durch Senden der PS-Suchinformation an den WS beendet.
Alle Anfragen, welche ursprünglich von entweder dem Geldbörsenserver oder Bezahlungsserver stammen, werden zusammen mit der ID des entsprechenden Geldbörsenservers oder Bezahlungsservers protokolliert. Das Protokollieren von 'unter uns'-Transaktionen wird so wie das für Schema-Transaktionen getätigt, jedoch wird das 'unter uns'-Kennzeichen gesetzt.
Der Suchdienst führt auf Anfrage Suchen nach dem Geldbörsenserver und Bezahlungsserver aus. Basierend auf einer OfferlD stellt der Suchdienst den entspre- chenden Bezahlungsserver mittels Durchsuchen des OfferlD-Repositoriums fest. In der entgegengesetzten Richtung kann der Heimgeldbörsenserver durch Zugreifen auf die Teilnehmerliste abgerufen werden.
Die Suche nach dem in eine Transaktion eingebundenen PS und Händlers wird basierend auf der OfferlD oder RangelD getätigt. Durch Ausführen der Suche basierend auf einer OfferlD wird die BasketlD aufgelöst und zusammen mit der OID an den MC übertragen, um den Einkaufskorb anzufragen. Der Händler entscheidet dann, ob die OID oder die BasketlD zum Identifizieren des Einkaufskorbs genutzt wird. Durch Ausführen der Suche basierend auf einer RangelD wird die Kombina- tion aus RangelD und Händlerkatalognummer an den MC übertragen, um den Einkaufskorb abzufragen.
Die Teilnehmerliste enthält alle MSISDNs und Pseudonyme des Käufers, welcher für mobile Bezahlung eingetragen ist. Für jedes MSISDN/Pseudonym wird die HeimgeldbörsenserverlD ebenfalls gespeichert. Die MSISDNs/Pseudonyme, wel- ehe nicht eingetragen sind, können in dem Prozess auch frühzeitig durch die CPP abgewiesen werden.
Die Geldbörsenserverinstanzen nutzen Online-Anfragen oder erzeugen eine flache (flat) Datei, welche alle neuen oder geänderten Teilnehmer enthält und übertragen die Datei an das OpCo, um die Teilnehmerliste zu aktualisieren. Pseudonyme werden an dem WS in Übereinstimmung mit den Pseudonym-Erzeugungsregeln (alias generation rules) (3 Ziffern identifizieren das WI, 8 Ziffern als KäuferlD und eine Prüfsummenziffer) erzeugt.
OfferlDs
Die OfferlD-Serverkomponente der CPP umfasst den OfferlD-Generator, welcher eine OfferlD auf Anfrage erzeugt und das OfferlD-Repositorium, welches erzeug- te OfferlDs zusammen mit zusätzlichen Daten für Suchzwecke speichert und deren Lebensdauer verwaltet. Das OfferlD-Nummerierungssystem stellt sicher, abhängig von der Anzahl der zu einer bestimmten Zeit benutzten OfferlDs, dass die Anzahl der genutzten Ziffern variieren kann, um immer die kleinstmögliche Anzahl zur Verfügung zu stellen. Für einige mobile Bezahlungsszenarien ist die Grö- ße der OfferlD überhaupt nicht kritisch (z.B. Bankknoten). Abhängig von der angefragten Lebensdauer stellt die folgende Tabelle die minimale Länge einer OID dar:
< = 1 Stunde kürzest verfügbar (Minimum 4 Ziffern) 1 Stunde - 1 Tag [kürzest verfügbar (Minimum 4 Ziffem)]+2 > 1 Tag [kürzest verfügbar (Minimum 4 Ziffem)]+4 Umleitung 16 Ziffern
Die Länge der OfferlDs (obige Tabelle) ist konfigurierbar. Abhängig von dem Ver- trag mit einem Händler können bestimmte Bereiche von OfferlDs für einen Händler reserviert werden. Der Händler zahlt eine Benutzungsgebühr für den Bereich und kann jede (Katalog-)Nummer nach dem Bereichskennzeichen nutzen, um die ID für sein Angebot abzubilden. Durch Nutzen dieses Mechanismus kann der Händler existierende Katalognummern durch einfaches Aufaddieren seines spezi- fischen Händlerpräfixes (prefix) wiederverwenden. Prüfsummentests ermöglichen es dem Geldbörsenserver umgehend eine OfferlD zu überprüfen und zusätzliche Nutzereingaben anzufragen, ohne mit der CPP kommunizieren zu müssen. Die Wahrscheinlichkeit versehentlich einen anderen aktiven Einkaufskorb durch fehlerhaftes Eingeben einer falschen OfferlD zu identifizieren sollte niedrig genug sein, um das Risiko tolerierbar zu machen. Wenigstens eine einzelne falsche Ziffer, zusätzliche/fehlende Ziffern und verwechselte Ziffern können erkannt werden. Die Prüfsummenziffer ist für RangelDs nicht verfügbar.
OfferlD/RangelD-Struktur
Präfix n Zifferninhalt Prüfsumme Präfix n Ziffern RangelD M Ziffern Händlerinhalt
Der Präfix (nicht notwendigerweise eine ganze Ziffer) führt bestimmte Steuerinformationen mit, bei der es wichtig ist, diese von der OfferlD direkt ohne Zugriff auf das OID-Repositorium abzurufen. Üblicherweise existiert keine HändlerlD, welche mit der OID kodiert ist. Die einzige Ausnahme betrifft RangelDs, bei welchen die OID aus einem Bereichskennzeichen und einer händlerspezifischen Erweiterung besteht.
Bei Installationen in verschiedenen Regionalen wird die CPP_ID in den OfferlD- Präfix kodiert, um eine OID-Weiterleitung zu ermöglichen. Der OfferlD-Generator erzeugt auf Anfragen OfferlDs. Es können statische und dynamische OfferlDs erzeugt werden. OfferlDs werden einmalig ausgegeben. Nachfolgende Bezahlungstransaktionen können dieselbe OfferlD für Bezahlungstransaktionen nutzen (z.B. VM, TV-Einkauf). Statische OfferlDs werden von den Händlern auf monatlicher oder jährlicher Basis 'gemietet (rented)'. Wenn die Mietdauer abläuft, schaltet die OID in den Status 'Sperre (black-out)', aus welchem die OID wieder aktiviert werden kann, wenn der Händler die Mietvereinbarung weiterführt. Der Händler muss die parallele Benutzung der statischen OID handhaben. OfferlDs kennzeichnen ein temporäres Angebot mit einer bestimmten Lebensdauer und werden exklusiv durch einen einzelnen Kunden genutzt. Eine OfferlD wird automatisch gelöscht, sobald eine Transaktion beendet oder die maximale Lebensdauer überschritten wird. Bankknotenszenarien benutzen z.B. eine dynami- sehe OfferlD mit einer verlängerten Lebensdauer. Wenn ein Kunde eine Transaktion nach Eingeben der OfferlD abbricht, wird die OID nicht gelöscht. Alle OfferlDs können jedoch auf Anfrage explizit gelöscht werden.
Hinsichtlich dynamischer OfferlDs wird eine OfferlD durch den Händler auf An- frage nach dynamischen OfferlDs festgelegt. Nach Ablauf der Lebensdauer wird der Status auf 'Sperre (black-out)' gesetzt. Die maximale Lebensdauer wird einen Monat betragen. Während der Sperrdauer können OIDs nicht nochmals ausgegeben werden. Die Sperrdauer ist konfigurierbar und hängt von der Lebensdauer der OID ab:
abgeschlossen 1 Stunde
0 bis 10 Minuten 1 Stunde 10 bis 16 Minuten 6 Stunden
1 Stunde bis 24 Stunden 1 Tag 1 Tag bis 7 Tage 1 Woche
1 Woche minus 4 Wochen 2 Wochen 1 Monat bis 12 Monate 1 Monat
Beim Erfragen einer OID kann der Händler bestimmte Attribute setzen, um den Typ der Anfrage anzuzeigen (Zahlung, Altersprüfung, Adressübertragung, PI- Übertragung von Details). Mit einer Anfrage für eine OID kann der Händler eine Markenliste herausgeben, um Markenübereinstimmung (brand matching) mit PI- Detailübertragungen zu unterstützen. Die Einkaufs-BasketlD kann mit der OfferlD verbunden sein.
Zum Erzeugen statischer OfferlDs wird die OfferlD durch den Händler auf Anfrage nach einer statischen OfferlD festgelegt. Nach Ablauf der Mietdauer wird der OfferlD-Status auf 'Sperre' geschaltet. Die minimale Mietdauer ist 1 Monat. Die Mietdauer beginnt mit dem Erzeugen der OID, nicht mit Aktivierung. Die Anfrage nach einer einzelnen OID kann durch das MC durchgeführt werden (genauso für dynamische OIDs). Weil die Einkaufs-BasketlD mit der Anfrage übertragen wird, ist die statische OID automatisch nach der Anfrage aktiviert. Der Händler kann eine Stapelerzeugung von OfferlDs gemäß dem CPP-Nummerierungsschema erfragen. Diese Anfrage wird durch die Händlerselbstbedienung durchgeführt und nicht direkt durch die Händlerkomponente. Als Folge davon empfängt der Händler eine Datei, welche alle erzeugten OIDs und das Ablaufdatum der Mietdauer enthält.
Mit den RangelDs erhält der Händler die Möglichkeit, existierende Katalognum- mern mit dem mobilen Bezahlungsschema wiederzuverwenden. Auf Anrage nach einer RangelD spezifiziert der Händler die Nummer von UnterlDs, welche er benutzen will. Während der Suche wird der Händler identifiziert. Die Kombination von RangelD und Katalognummer wird an den Händler weitergeleitet, um den Einkaufskorb zu erhalten.
Das OfferlD-Repositorium enthält alle Informationen über erfragte OfferlDs. Wenn Altersprüfungen, Adressaustausch oder PI-Datentransfer gefragt ist, werden die relevanten Kennzeichen (flags) in dem OfferlD-Repositoriumsdatensatz gesetzt. Das OfferlD-Repositorium überwacht die ausgegebenen OfferlDs und setzt Stati auf 'Sperre', sobald eine zugehörige Lebensdauer abläuft. Das OfferlD- Repositorium unterstützt auch das manuelle Löschen von Anfragen. Der Suchdienst benutzt das OfferlD-Repositorium, um zugehörige Bezahlungsserver zu erfragen.
Um die statische OID mit einem anderen Korb zu verbinden oder die Anfragetypen zu verändern unterstützt das OfferlD-Repositorium die Deaktivierung von OIDs. Durch das MC ist die Deaktivierung nur für einzelne OIDs erlaubt. Dieses Merkmal kann auch genutzt werden, wenn ein Artikel vorübergehend nicht erhältlich ist oder der Händler eine verlängerte Sperrdauer haben möchte. Die Miet- dauer wird durch die Deaktivierung nicht verlängert. Wenn mehrere OIDs deaktiviert werden müssen, wird das MSS genutzt.
Das Repositorium unterstützt die Änderung statischer OIDs (d.h. Verknüpfen anderer BasketIDs, Änderungsanfragetypen oder Verlängerung der Mietdauer). Das Repositorium unterstützt die Stapeländerung (batch modification) von statischen OIDs (d.h. Verknüpfung anderer BasketIDs, Änderungsanfragetypen oder Verlängerung der Mietdauer). Diese Anfrage wird durch das MSS durchgeführt.
Eine einzelne OID kann aktiviert werden. Es können auch mehrere OIDs durch das MSS aktiviert werden. Um eine solche Aktivierung vorzunehmen, lädt der Händler eine Liste von BasketIDs zusammen mit allen anderen Anfrageparametern. Nach Erzeugung des OID-Blocks empfängt der Händler eine Zuordnungsdatei (location file).
Das OfferlD-Repositorium löscht automatisch OIDs, wenn die Lebensdauer abläuft oder wenn eine Transaktion beendet ist. Ein Käuferabbruch resultiert nicht in einem Löschen der OID. Das OID-Repositorium erlaubt auch das Löschen von OIDs im einfachen (Single) und Stapel(batch)-Modus. Bei dynamischen OIDs resultiert ein Löschen in einer unmittelbaren Beseitigung, während bei statischen OIDs das Löschen den OID-Status auf 'Sperre (black-out)' setzt.
Durch das MSS kann der Händler eine OID mit dem Status 'Sperre' wieder herstellen. Statische OIDs müssen gesperrt werden, wenn der Mietvertrag abläuft. Während der Sperrdauer ist der Händler in der Lage, die OID durch Erfragen ei- ner Verlängerung der Mietdauer durch das MSS zu reaktivieren.
Neqativdateien
Der Negativdatei-Dienst stellt eine zentrale und gemeinsame (consolidated) Da- tenbasis zur Verfügung, um Händler wie auch Kunden zu sperren. Die Geldbörsenserver- und Bezahlungsserver-Instanzen können auf Basis einer Anfrage gegen die Datenbank prüfen genauso wie ihre lokalen Negativdatei-Verzeichnisse mit dem Negativdatei-Dienst an der Prozessorplattform synchronisieren.
Durch die CPP kann ein einzelner Händler zu der Negativdatei zusammen mit einem Zeiteintrag zugefügt werden. Zusätzlich kann die Negativdatei überprüft werden, um festzustellen, ob ein Datensatz hinsichtlich eines einzelnen Händlers existiert. Ein Händlerakquisiteur kann diese Prüfung von außerhalb auslösen. Zusätzlich kann ein einzelner Händler aus der Negativdatei entfernt werden. Eine Liste von Händlern kann auch in eine Negativdatei importiert werden. Wenn ein Händler schon in der Negativdatei geführt ist, wird der zugehörige Datensatz übersprungen. Händlerdateisätze in der Datei können auch zur Beseitigung- gekennzeichnet werden. Während des Importierens werden diese Händler aus der Negativdatei entfernt. Eine Händlernegativdatei kann auch exportiert werden. Z.B. kann eine Datei heruntergeladen (downloaded) oder an einen Händlerakquisiteur übertragen werden, um eine lokale Negativdatei zu aktualisieren.
Ein einzelner Käufer kann zu der Negativdatei zusammen mit einem Zeiteintrag in dem Datensatz hinzugefügt werden. Die Negativdatei kann überprüft werden, um festzustellen, ob sie einen Datensatz über einen einzelnen Käufer enthält. Ein Geldbörsenausgeber kann diese Prüfung von außerhalb auslösen. Die CPP kann auch jede Transaktion gegen die innere (internal) Negativdatei prüfen. Ein einzelner Käufer kann aus der Negativdatei entfernt werden. Auch kann eine Liste von Käufern in die Negativdatei importiert werden. Wenn ein Käufer schon in der Negativdatei geführt ist, kann der zugehörige Datensatz der Datei übersprungen werden. Käuferdatensätze in der Datei können auch zur Beseitigung gekennzeichnet werden. Während des Imports werden diese Käufer aus der Negativdatei entfernt. Eine Datei, welche alle negativen Dateidatensätze enthält, die nach einer gewissen Zeit erzeugt wurden, kann exportiert werden. Diese Datei kann dann heruntergeladen oder an einen Geldbörsenausgeber übertragen werden, um eine lokale Negativdatei zu aktualisieren.
Alle Änderungsaktionen der Negativdatei werden protokolliert. Die historischen Negativdateidaten werden gespeichert und ein Status (z.B. eingetragen (listed), gesperrt (blocked), inaktiv (inactive), gelöscht (deleted)) wird beibehalten. Nach einer gewissen Periode (d.h. drei Jahren) werden gelöschte Einträge physisch aus den Negativdateidatensätzen entfernt.
Währungsumrechnung
Das System unterstützt drei verschiedene Währungen: Die Währung, welche der Transaktion zugrunde liegt; die Registrierungswährung der Käufer am WI; und die Währung, welche das MA mit der CPP abrechnet. Für internationale Mikrobezahlungen wird der Betrag einer Transaktion von der Transaktionswährung zu der WI-Abrechnungswährung (Binnenwährung des Käufers) vor der Berechtigung des Kunden und Abzug (deduction) von dem SVA umgerechnet. Da beide Währungen dem Kunden angezeigt werden und das SVA basierend auf dem zugrundeliegenden Kurs abgezogen wird, können Währungsrisiken existieren, welche durch zusätzliche Kursaufschläge abgedeckt werden.
Das OpCo beinhaltet ein Währungsrisiko bei Berechtigung einer μPI, wenn der Ausgleich mit dem MA nicht am selben Tag ausgeführt werden kann. In diesen Fällen kann das OpCo eine Aufschlag auf den Währungskurs aufrechnen.
Die Währungsumrechnungstabelle speichert Währungskurse. Ein Datensatz wird für jedes Währungspaar (EUR/GBP) und (GBP/EUR) erzeugt. Die Zeitmarke speichert die Information der letzten Aktualisierung des Datensatzes. Zusätzliche Statusinformationen können in dem 'Status'-Feld (z.B. abgelaufen (expired), gültig (valid)) gespeichert werden. Die Währungsumrechnungstabelle wird auf einer vorbestimmten regelmäßigen Basis durch Kontaktaufnehmen mit einem Umrechnungskursdienstanbieter und Importieren der aktualisierten Umrechnungskurse in die Umrechnungstabellen aktualisiert. Der Zeitstempel und Status werden ebenfalls aktualisiert.
Das Statusfeld der Währungsumrechnungstabelle wird auf 'abgelaufen (expired)1 geschaltet, wenn das Währungspaar eine bestimmte Anzahl von Tagen (d.h. einen Tag, konfigurierbar) aktualisiert wurde. Abgelaufene Währungspaare haben keinen Einfluss auf die Währungsumrechnung.
Die Umrechungstabelle kann in eine Datei exportiert werden, welche durch den Geldbörsenanbieter oder die OpCo-Finanzabteilung heruntergeladen werden kann. Die Kurse umfassen die OpCo-Aufschlag. Eine Beispieltabelle ist unten gezeigt.
Währungskode Händler (ISO)
Währungskode Kunde (ISO)
Format (Dezimalen)
Umrechnungsfaktor
Zeitstempel Status (aktuell (current), abgelaufen (expired)) Hinsichtlich der Aufschlagstabellen werden zusätzliche OpCo-Aufschläge in einer zusätzlichen Tabelle (d.h. einer Aufschlagstabelle) gespeichert. Ein Datensatz wird für jedes Währungspaar (EUR/GBP) und (GBP/EUR) erzeugt. Der Zeitstempel speichert die Information der letzten Aktualisierung des Datensatzes. Zusätzliche Statusinformationen können in dem 'Status'-Feld (z.B. abgelaufen (expired), gültig (valid)) gespeichert werden. Administratoren können Aufschlagsprozente für Währungspaare durch Übertragen einer flachen Datei (flat file) an den FX-Server aktualisieren, welche dann in die Aufschlagstabelle importiert werden. Ein Bei- spiel einer Aufschlagstabelle wird im folgenden gezeigt:
Währungskode Händler (ISO) Währungskode Kunde (ISO) Aufschlagsprozentsatz Aufschlagsbetrag
Üblicherweise wandelt die CPP Beträge basierend auf Umrechnungskursen und CPP-Aufschlag um und überträgt die Beträge in TX-Währung, umgewandelter Währung und Umwandlungskurs. Durch diesen Prozess kann die Umrechnungs- kurssynchronisation weggelassen werden, da der aktuellste Umrechnungskurs benutzt wird. Die Währungsumrechnung geschieht gemäß den Regeln der europäischen Zentralbank (ECB European Central Bank)). Wenn Einheiten nationaler Währung in EUR ausgedrückt werden, umfasst der Betrag sechs Zahlen vor und/oder nach dem Dezimalpunkt. Bei Umrechnung der Währungen in EUR wer- den Zwischenergebnisse auf ein Minimum von 3 Dezimalstellen (nach dem Dezimalpunkt) berechnet. Währungsbeträge, welche in EUR ausgewiesen sind, werden auf den nächsten Eurocent auf- oder abgerundet.
Eine Schnittstelle zu einem Anbieter von internationalen Währungsumrechnungs- kursen (d.h. Reuters, Bloomberg, Bridge oder Telerate) ist eingeführt. Die Finanzabteilung der WIs oder OpCo's kann eine exportierte Umrechnungskursdatei herunterladen.
Es werden Administrationseinrichtungen für OpCo-Administratoren und die Fi- nanz- oder Wertpapierabteilung des OpCo zur Verfügung gestellt. Diese Einrich- tungen umfassen z.B. das Verwalten des Ablaufs zum Holen von Umrechungskur- sen über die festgelegte Schnittstelle zu dem Umrechnungskursanbieter, das Festlegen von Regeln zum Aktualisieren des Status, das Anschauen und manuelle Editieren von Umrechnungskursen, das Anschauen und manuelle Editieren von Umrechnungskursaufschlägen und das Anschauen des Wechselprotokolls und der historischen Daten. Um die umgehende Benachrichtigung des verantwortlichen Administrators sicherzustellen, alarmieren den Administrator bestimmte Ereignisauslöser (event trigger). Z.B. lösen die folgenden Ereignisauslöser Meldungen an den Administrator aus:
Fehler: Import der Währungskurse fehlgeschlagen Fehler: Export der Dateien fehlgeschlagen Warnung: Umrechnungskurs abgelaufen
Warnung: Umrechnung mit abgelaufenem Umrechnungskurs nach Voreinstellung durchgeführt
Der Administrator empfängt Alarme als eine Meldung in der Administrator-GUI. Zusätzlich kann er wählen, ebenfalls Alarme durch E-Mail oder SMS zu empfangen. Der Administrator benutzt die Administrator-Service-GUI, um Zugang zu de- taillierten Fehlerlisten/berichten zu erhalten. Detaillierte Fehlermeldungen werden nicht mit einer Benachrichtigung übertragen.
Darüber hinaus werden alle Änderungen der Währungsumrechnungskurse protokolliert. Historische Daten werden für rechtliche Zwecke gespeichert (10 Jahre). Bei Rücküberstattungen wird der FX aus dem TX-Protokoll festgelegt und nicht aus der Datei für historische Daten. Das Transaktionsprotokoll dient als Basis für Gebührenabrechnung und Streitabwicklungen. Mehrere Protokollebenen werden auf Anfragebasis unterstützt. Z.B.:
Protokollieren aller Ereignisse mit allen Attributen
Protokollieren der Ereignisse nur mit Schlüsselattributen Protokollieren nur der Ereignisse Protokollieren nur der Fehler. Die Protokolldateien werden zur Verarbeitung bis zu drei Monate gespeichert. Danach werden die Transaktionsprotokolle für 10 Jahre archiviert. Bei allen ope- rationalen Prozessen werden gesetzliche Anforderungen befolgt, z.B. das Datenschutzgesetz. Eine NewCo-Datenschutzstrategie sollte festgelegt und für alle NewCo-Teilnehmer verbindlich gemacht werden, um das Käufervertrauen zu steigern.
Mikrobezahlunqsausqleich und -abrechnunq
Der CPP-Ausgleichs- und Abrechnungs-(C8-S)-Dienst verarbeitet durch Händlerakquisiteure eingeleitete Ausgleichsanfragen, sammelt durch das MA abzurechnende und mit dem μPI-Anbieter auszugleichende Beträge. Zusätzliche Abrechnungsdatensätze und Angaben werden erzeugt, um Abrechnungsdetails allen μPI-Anbie- tern (WI und MAs) zur Verfügung zu stellen. Der Finanzmitteltransfer wird an ei- nem Hauptbuchungssystem ausgelöst. Für Händlerakquisiteure unterstützt der Ausgleichs- und Abrechnungsdienst sowohl Einheitswährungsabrechnung wie auch Multiwährungsabrechnung. Bei Multiwährungsabrechnung wird das MA in verschiedenen TX-Währungen abgerechnet. Für jede MA zeigt der Hauptdatendatensatz alle Abrechnungswährungen des MA und ob der MA für Einfach- oder Mul- tiwährungsabrechnungen gewählt wurde, an.
Die Aufgabe des Ausgleichs und der Abrechnung kann in den folgenden Schritten, wie in Figur 23 dargestellt und weiter unten beschrieben, aufgeteilt werden:
1. Vorverarbeitung (Vermittlung und Abstimmung)
2. Ausgleich mit MA (Sammlung hinsichtlich MA)
3. Ausgleich mit μPI-Anbieter (Sammlung hinsichtlich μPI-Anbieter)
4. Buchung (Einleiten der Abrechnung)
5. Abweisungs- und Rückführungsprozess (Fehlerverarbeitung) 6. Streitverarbeitung
7. Täuschungserkennung
8. Verwaltung
Wenn ein Ausgleichsdatensatz durch den Ausgleichs- und Abrechnungsprozess läuft, nimmt er verschiedene Stati wie in Figur 24 dargestellt an. Vorverarbeitung (Vermittlung und Abstimmung) ist ein linearer Prozess. Sammeln hinsichtlich der PIs und MAs können parallel durchgeführt werden. Das Ergebnis des Prozesses ist in einem Abrechnungsbericht (einschließlich Fehlerkodes) und einer 'Sammeltabelle (Aggregation table)' dokumentiert, welche zum Buchen im Hauptbuch ge- nutzt wird.
Der Händlerakquisiteur leitet C- S durch Senden der Erfassungs-/Berechtigungs- Token enthaltenden Ausgleichsdatei an den CPP-C&S-Dienst ein. Gemäß des Ausgleichsablaufs bringt der C8ιS-Dienst die MA-Ausgleichsdatei mit den intern ge- sammelten Transaktionsprotokollen in Einklang. Ein 'Abrechnungsbericht (Settle- ment Report)' wird erzeugt, um den Händler über alle Transaktionen zu informieren, welche abgerechnet werden sowie über alle zurückgewiesenen Transaktionen.
Ein TX-Ausgleichsdatensatz enthält die AkquisiteursID, BezahlungsmittellD, Tran- saktionsID, Beträge und den Verarbeitungsstatus wie unten beschrieben:
MA_ID μPI.ID TX_ID
Berechtigungszeit und -datum
Berechtigungs(Erfassungs)-Token
Erfassungszeit und -datum
Transaktionswährung Betrag (in TX-Währung)
Käuferwährung
Betrag (in Käuferwährung)
FX-Kurs
Kennzeichen 'Ausgleichsdatei empfangen' + Zeitstempel Kennzeichen 'Abstimmung abgeschlossen' + Zeitstempel
Abstimmungsstatus (Akzeptiert/Zurückgewiesen), Fehlerkode
Kennzeichen 'gesammelt hinsichtlich MA' + Zeitstempel
Kennzeichen 'gesammelt hinsichtlich PI' + Zeitstempel
Kennzeichen 'gebucht für MA-Abrechnung' + Zeitstempel Kennzeichen 'gebucht für PI-Abrechnung' + Zeitstempel Kennzeichen 'Bericht an MA' + Zeitstempel Kennzeichen 'Bericht an PI' + Zeitstempel
Transaktionsdaten von den MAs werden zu Gültigkeitsprüfungszwecken mit den zur selben Zeitspanne gehörenden internen CPP-TX-Protokollen verglichen. Datensätze, welche nicht übereinstimmen, werden in einer Fehlerdatei gesammelt. Die Fehlerdatei dient als Basis für Fehlererkennung und die Teile, welcher einer speziellen MA zuzurechnen sind, werden in den Abrechnungsbericht der MA kopiert. Es sind vier Klassen übereinstimmender Ergebnisse möglich.
TX Übereinstimmung
TX Unverträglichkeit: Unverträglichkeit zwischen Daten, welche zu derselben TX in der Abrechnungsdatei und in dem EPP TX-Protokoll gehören.
Überschuss TX: Die Abrechnungsdatei des MA enthält eine Erfassung, welche kein Gegenstück in dem EPP TX-Protokoll hat.
Fehlende TX: Das EPP TX-Protokoll enthält eine Erfassung, welche ein Gegenstück in der Abrechnungsdatei der MA hat. (Der Protokolldatensatz ist mit "fehlendes TX" markiert, wenn eine Erfassung zum Ausgleich nicht innerhalb einer bestimmten Zeit, z.B. einer Woche eingegangen ist; "Abfallsammlung (garbage collection)").
Der Ausgleich mit dem MA-Anbieter erfolgt gemäß dem MA-Ausgleichsablauf. In Einklang gebrachte Transaktionsdatensätze der Vorverarbeitungsprozedur werden hinsichtlich jedes Händlerakquisiteurs gesammelt. Der Sammelprozess führt zu einem MA-Abrechnungsbericht und stellt die Basis für die MA-Abrechnung bereit (Sammeltabelle (aggregation table)).
Erfolgreich in Einklang gebrachte Transaktionen werden hinsichtlich jeder MA und jeder Abrechnungs(Transaktions)währung gesammelt. Die Sammeltabelle spei- chert Beträge, welche über eine bestimmte Abrechnungsperiode gesammelt wurden. Das Format der Sammeltabelle wird im folgenden gezeigt:
MA_ID
Beginn der Abrechnungsperiode (Datum und Zeit) Ende der Abrechnungsperiode (Datum und Zeit) Tabellenerzeugungszeitstempel Abrechnungswährung
Gesamtanzahl von gesammelten Transaktionen Absoluter Abrechnungsbetrag (in TX-Währung) μPI_ID 1
Anzahl der Transaktionen für μPI 1 Abrechnungsbetrag für μPI 1 μPI_ID 2
Anzahl der Transaktionen für μPI 2 Abrechnungsbetrag für μPI 2
Kennzeichen 'gebucht für MA-Abrechnung' + Zeitstempel Kennzeichen 'berichtet an MA+ Zeitstempel
Bei jeder Abrechnungswährung wird eine getrennte Sammeltabelle errechnet. Die Sammeltabelle stellt die Basis für das Buchen (Anleitung der Abrechnung) dar und ein Teil des Abrechnungsberichts wird an das MA gesendet. Der Abrechnungsbericht enthält Ergebnisse der Abstimmungs- und Sammlungsschritte (einschließlich Fehlermeldungen) hinsichtlich eines speziellen Händlerakquisiteurs. Gemäß dem Berichtsablauf wird der Abrechnungsbericht in dem entsprechenden MA-Verzeichnis gespeichert (voraussichtlich täglich).
Das Ausgleichen mit dem μPI-Anbieter geschieht gemäß dem PI-Ausgleichsablauf.
In Einklang gebrachte Transaktionsdatensätze aus der Vorverarbeitungsprozedur werden hinsichtlich jedes Bezahlungsmittel-Anbieters gesammelt. Der Sammel- prozess führt zu PI-Abrechnungsberichten und stellt die Basis für die PI-
Abrechnung (Sammeltabelle) zur Verfügung. In Einklang gebrachte Datensätze werden hinsichtlich jedes PI gesammelt. Die Sammeltabelle speichert Beträge, welche über eine bestimmte Abrechnungsperiode gesammelt wurden.
μPI_ID
Beginn der Abrechnungsperiode (Datum und Zeit)
Ende der Abrechnungsperiode (Datum und Zeit)
Tabellenerzeugungszeitstempel Gesamtanzahl gesammelter Transaktionen Gesamtabrechnungsbetrag (in TX-Währung) Kennzeichen 'gebucht für PI-Abrechnung' + Zeitstempel Kennzeichen 'berichtet an PI' + Zeitstempel
Die Sammeltabelle stellt die Basis für das Buchen (Einleitung der Abrechnung) dar und ein Teil des Abrechnungsberichts wird an den PI-Anbieter gesendet. Der Abrechnungsbericht enthält Ergebnisse der Abstimmungs- und Sammelschritte (einschließlich Fehlermeldungen) hinsichtlich eines Bezahlungsmittel-Anbieters. Gemäß dem Berichtsablauf wird der Abrechnungsbericht in dem entsprechenden Pl-Verzeichnis gespeichert (voraussichtlich täglich). Der CPP-C&S-Dienst löst das G/L-System dahingehend aus, die physischen Finanzmittelübertragungen an den MA und von dem μPI-Anbieter einzuleiten. Das OpCo rechnet Bruttobeträge mit dem PI-Anbieter ab (Autobezahlung). Gebühren werden getrennt abgerechnet. Die CPP blättert zur PI-Buchung durch die Pl-Sammeltabelle und erzeugt eine fla- ehe Datei (flat file) mit Buchungsdatensätzen (z.B. direkte Debitanfragen) zur Stapeleingabe an ein G/L-System (z.B. SAP FI) und setzt das Kennzeichen für die zugehörigen Protokolldatensätze und die Sammeltabelle. Bei dem MA buchen blättert die CPP durch die MA-Sammeltabelle und erzeugt eine flache Datei mit Buchungsdatensätzen zur Stapeleingabe an ein G/L-System (z.B. SAP FI) und setzt das Kennzeichen für die zugehörigen Protokolldatensätze und die Sammeltabelle. In dem Fall, indem MA eine Multiwährungsabrechnung wünscht, wird ein getrennter Bezahlungslauf für jede Abrechnungswährung eingeleitet.
Das G/L druckt Rechnungen und Anweisungen und leitet Finanzmittelübertragun- gen ein. Die Finanzmittelübertragung kann einem anderen Ablauf folgen als das Buchen, z.B. abhängig von dem abzurechnenden Wert. Der Abstimmungsschritt kennzeichnet fehlerhafte Transaktionen, welche in einer Fehler-TX-Datei gespeichert werden. Es wird versucht, Fehler manuell zu berichtigen. Ergebnisse dieses Fehlerberichtigungsschritts (z.B. 'berichtigt (corrected)', 'zurückgewiesen (rejee- ted)1) werden in den entsprechenden MA-Abrechnungsbericht aufgenommen. Abgewiesene Datensätze werden mit Fehlerkodes gekennzeichnet.
Um Insidertäuschungen zu erkennen, werden Berichte erzeugt, um die korrekte Verarbeitung von abrechnungsbezogenen Daten zu verfolgen und verdächtiges Verhalten zu erkennen (z.B. da*s Löschen von Sammeltabellen, manuelle Buchun- gen, Protokolldateimanipulation). In einem späteren Stadium können intelligente Täuschungserkennungsalgorithmen angewendet werden, um Negativdateien zu aktualisieren, z.B. Benutzerprofilüberprüfungen: Erkennen von ungewöhnlichem Benutzerverhalten, verdächtige Anstiege im Umsatz eines Benutzers, Bezahlungs- ortüberprüfungen: Überprüfen, ob Bezahlungen von weit entfernten Orten innerhalb einer kurzen Zeit ausgingen.
Ein Ablaufmechanismus löst die Vermittlung, die Abstimmung und MA- und μPI- Ausgleich aus. Der Buchungsschritt kann, abhängig von einer Schwelle für einen Minimalabrechnungsbetrag, für jeden MA oder μPI geplant werden. Der Buchungsablauf und die Schwelle für den Minimalabrechnungsbetrag sind in dem Hauptdatendatensatz gespeichert. Der Administrator überwacht des korrekte Ablaufen und löst manuell Verarbeitungsschritte aus, wenn dies notwendig ist.
Alle mobilen Bezahlungstransaktionen werden durch die CPP weitergeleitet, was einen Protokolleintrag in der Protokolldatei zur Folge hat. Diese Protokolldatei stellt die Basis für das Erzeugen von Transaktionsgebührenrechnungen und -berichten dar. Die resultierenden Rechnungsberichte werden dann in einem Kontenverwaltungssystem gebucht, um die Abrechnung einzuleiten. Verschiedene Ereig- nisse wie z.B. eine OfferlD-Anfrage, Berechtigung an der PI oder eine Erfassung werden mit verschiedenen Gebühren belastet. Der Händlerakquisiteur belastet den Händler mit einer mobilen Händlerdienstleistungsgebühr (mobile MSC). Die mobile MSC abzüglich einer MA-Gebühr wird durch die CPP beansprucht und weiter unter den Anteilseignern verteilt. Die Figur 25 stellt die Gebührenverteilung dar.
Ein Stapelprozess (z.B. täglich, wöchentlich, monatlich) wird für die Rechnungsstellung von Transaktionsgebühren durchgeführt, da die Anzahl von Transaktionen sehr hoch sein kann, d.h. im Bereich von mehreren Millionen pro Tag. Die Aufgabe der Gebührenverarbeitung kann in die folgenden Schritte aufgespalten werden, wie in Figur 26 dargestellt.
1. Vermittlung
2. Bewertung 3. Rechnungsstellung 4. Berichten (Exportieren von Dateien, welche Rechnungsdetails enthalten)
5. Buchen (Einleiten von Abrechnungen, Ausgabe von Anweisungen/Rechnungsdarstellung)
6. Abweisungs- und Rückgabeprozesse (Fehlerbehandlung) 7. Streitbehandlung
8. Täuschungserkennung
9. Verwaltung
Bei jedem Schritt werden Daten in einem besonderen Bestand gehalten und mit in "vollständige (piain)", "vermittelt (mediated)", "bewertet (rated)" oder "verrechnet (billed)" bezeichnet. Der Bewertungskatalog enthält Ereignisdefinitionen und Preisgestaltung-/-bewertungsinformationen. Im Berechnungskatalog werden Regeln für spezielle Gebühren (z.B. monatliche Beitragsgebühren) und Abschläge gespeichert. Gespeicherte Prozeduren legen Bearbeitungs- und Rechnungsperio- den fest und lösen die verschiedenen Verarbeitungsschritte aus. Das Rechnungs- detail-Repositorium enthält die verrechneten Ereignisse und stellt die Basis für detaillierte Berichte wie EPA (elektronische Bezahlungsanweisung (electronic payment advice)) dar. Rechnungen werden an das G/L gesendet, um die Abrechnung einzuleiten (Zahlungslauf).
Ein Vermittlungsmodul verfolgt die Protokolldateien, welche von verschiedenen Protokolldateiquellen empfangen werden. Die Hauptquelle besteht aus den täglichen Protokolldateien von dem Weiterleitungsmodul der Prozessorplattform. Andere Quellen umfassen Daten, welche noch nicht verarbeitet werden konnten, z.B. berichtigte Datensätze aus den abgewiesenen und rückgegebenen Prozessen. Die Daten werden gefiltert und möglicherweise neu formatiert.
Der Begriff "Bewertung (rating)" bedeutet, jedem Ereignis einen Preis zuzuordnen. Eine Bewertungstabelle wird zum Festlegen der Preise für jede Ereignisklas- se genutzt. Die Bewertungstabelle wird erzeugt, bevor der Bewertungsprozess gestartet wird und bleibt unverändert während wenigstens einer Rechnungsperiode. Für jeden Rechnungs- oder Anweisungsempfänger kann eine individuelle Bewertungstabelle genutzt werden, abhängig von den individuellen Geschäftsvereinbarungen zwischen OpCo, NewCo, den MAs, PI-Anbietern und den WIs.
Die Gebührenstruktur ist so gestaltet, dass sie allgemein ausreichen, um alle Gebühren abzudecken, welche üblicherweise in der Transaktionsrechnungsstellung auftreten. Die Transaktionspreisgestaltung kann von der tatsächlichen Anzahl von Transaktionen und dem durchschnittlichen Wert der Händler- oder Händlerakqui- siteurszahlungstransaktionen abhängen. Ein allgemeiner Ansatz, um solch eine Gebührenstruktur abzudecken, besteht in einer Preistabelle in Matrixform.
Parameter, welche die Preistabelle bestimmen, sind:
Ereignistyp (OfferlD-Anfrage, Adressprüfung, Erfassung, etc.) Bezahlungskanal (WAP, IVR, SMS)
Einkaufskanal (Web, WAP, IVR, TV, Verkaufsautomat, etc.) Bezahlungsinstrument (μPI, Visa, MasterCard, Direktdebit, etc.) Regionalklasse (Kunde und Händler in derselben/in verschiedenen Regionen): unter uns (Interner Operator (intra-operator)), Zuhause (domestic (national)), innerregional (z.B. America, EMEA, ASPA), überregional Risikoklasse des Handels/Händlers
Die Abrechnungswährung (eine getrennte Preistabelle für jede Währung kann verwendet werden, wenn ein MA für Multiwährungsabrechnung gewählt wurde).
Ereignisse, welche bewertet werden, umfassen:
Statische/dynamische OfferlD-Erzeugung (allocateOfferlD, initOfferlD)
Informationsanfragen (adressREQ, agecheckREQ, PIDetailREQ) Bezahlungsberechtigung (AuthorizePaymentRequest)
Mikrobezahlungserfassung
Mikrobezahlungserstattung
Mikrobezahlungsgutschrift
IMPP-Erweiterungsmeldungen (volumenbezogen, z.B. pro Meldung oder pro Kilo- byte) Andere zentrale Dienste (tbd.) (Bezahlungseinleitung, d.h. PayPurchase Anfrage) (Währungsumrechnung) (WS und PS Suche) (Fehlermeldungen)
Der Rechnungsstellungsprozess sammelt alle bewerteten Ereignisse hinsichtlich eines Kontos (empfangbar oder bezahlbar) in einem einzelnen Rechnungsstel- lungsdatensatz. Wiederkehrende Teilnahmegebühren oder spezielle Gebühren werden aufaddiert und Abschläge abgezogen. Spezielle Gebühren und Abschläge können für jeden Anweisungsempfänger variieren. Die bewerteten Ereignisse werden durch Rechnung zusammengestellt (empfangbare Abrechnungen/bezahlbare Abrechnungen) und die Gebühren werden gesammelt. Ein mehrere Untergebühren enthaltendes bewertetes Ereignis ist Teil von mehreren Rechnungen. Ab- schlage oder andere Gebühren (z.B. Teilnahmegebühren) werden zu jeder Rechnung hinzuaddiert. Die Rechnungen enthalten den zu rechnenden gesammelten Betrag (gutgeschrieben oder eingezogen).
Die Rechnungsdetailberichte enthalten die Datensätze, welche zum Berechnen ei- ner Rechnung für einen besonderen Empfänger verwendet werden. Die Dateien der Rechnungsdetailberichte werden dem Teilnehmer auf Anfrage zugesendet. Die Rechnungsanweisungen enthalten gesammelte Positionen in einer Rechnung. Das Formatieren und Ausgeben von Anweisungen unterliegt dem Hauptbuchungssystem.
Das Buchen leitet den Gebühreneinzug und die Verteilung über das Hauptbuchungssystem ein. Rechnungen werden "gebucht (booked)" gekennzeichnet, sobald das Buchen eingeleitet wurde. Am Ende des Rechnungsstellungszyklus werden alle Rechnungen an das Hauptbuch übertragen (Bezahlungslauf).
Sobald Rechnungsdetails "ausgegeben (delivered)" oder Rechnungen mit "gebucht (booked)" gekennzeichnet sind, werden die Daten in einem Massenspeicher archiviert. Archivierte Transaktionsprotokolle und Rechnungsdateien stellen die Basis für das Beilegen von Streitfällen dar. Die CPP stellt eine Zugriffsschnittstel- le zu den protokollierten Transaktionsdetails und Rechnungsdetails für die streit- verwaltende Behörde zur Verfügung, z.B. ein Kundenbetreuungszentrum. Streitfälle betreffend Gebühreneinzug und -Verteilung (Finanzmittelübertragungen) werden durch nachgelagerte Dienste (back office) verwaltet. Täuschungserken- nungsberichte sollten auch deshalb erzeugt werden, um das korrekte Verarbeiten von rechnungsbezogenen Daten zu verfolgen und verdächtiges Verhalten (z.B. das Löschen von Rechnungsdateien, manuelle Buchungen, Protokolldateimanipulationen) aufzufinden.
Die Wertpapierabteilung verwendet ein Hauptbuchungs(G/L)-System, um Bu- chungen zum Gebühreneinzug und -Verteilung und Mikrobezahlungsabrechnungen zu verwalten. Der Ausgleichs- und Abrechnungsdienst und die Gebührenrechnungsmaschine leiten Buchungen am G/L-System ein. Buchungen sind an Empfangskunden und Bezahlungskunden des OpCo, NewCo, alle WIs, PI-Anbieter und MAs möglich. Wiederkehrende Buchungen werden für jeden Mikrobezahlungsab- rechnungszyklus und für jede Rechnungsstellungsperiode (täglich, wöchentlich oder monatlich) getätigt. Für jede Buchung (Mikrobuchungsabrechnung oder Gebührenrechnungsstellung) wird eine Anweisung gedruckt und jeden Empfänger versendet. Physische Finanzmittelübertragungen an/vom MA, an/vom WI und an NewCo-Bankkonten werden eingeleitet. Die Mikrobezahlungsabrechnung mit MAs sollte nicht erfolgen, bevor die Bezahlung von den μPIs empfangen wurde. Unregelmäßigkeiten im Finanzmittelfluss werden verfolgt und berichtet, und Aufrufe werden automatisch erzeugt, wenn Finanzmittelübertragungen verspätet sind. Der G/L-Operator kann Berichte über Bargeldfluss und ausstehende Bargeldübertragungen (für die Bargeldverwaltung) anfragen. Rückübertragungen können im Fall inkorrekter Buchungen z.B. durch inkorrekte Gebührenrechnungen manuell eingeleitet werden.
Alle operationalen Tätigkeiten werden protokolliert (um eine unabhängige Rechnungsprüfung und Täuschungserkennung möglich zu machen). Informationen über Anteilseigner (Händlerakquisiteure, Geldbörsenausgeber, Bezahlungsmittelanbieter, NewCo und OpCo) werden zentral in der CPP gespeichert. Verschiedene Komponenten fragen Daten an, um ihre Verarbeitungsaufgaben durchzuführen. Der Administrator erzeugt und ändert Hauptdateneinträge und ändert den Status der Daten (aktiv/inaktiv). MA Hauptdaten Name
Verbindungsdaten (Adresse, Telefon, E-Mail, etc.) ID Bezahlungsserveradresse (URL) Interne G/L-Buchungskontonummer Bankkontonummer
Rechnungsstellungs- und Abrechnungsabläufe (möglicherweise mehrere) Rechnungswährungen Status (registriert, aktiv, inaktiv, gelöscht)
WI Hauptdaten
Name
Verbindungsdaten (Adresse, Telefon, E-Mail, etc.) ID
Geldbörsenserveradresse (URL)
Interne G/L-Buchungskontonummer
Bankkontonummer
Rechnungsstellungs- und Abrechnungsabläufe Abrechnungswährung
Status (registriert, aktiv, inaktiv, gelöscht)
PI-Anbieter-Hauptdaten
Name Verbindungsdaten (Adresse, Telefon, E-Mail, etc.)
ID
Serveradresse (URL)
Interne G/L-Buchungskontonummer
Bankkontonummer Rechnungsstellungs- und Abrechnungsabläufe
Abrechnungswährung
Status (registriert, aktiv, inaktiv, gelöscht)
NewCo-Hauptdaten Name Verbindungsdaten (Adresse, Telefon, E-Mail, etc.) Interne G/L-Buchungskontonummer Bankkontennummer
Rechnungsstellungs- und Abrechnungsabläufe (möglicherweise mehrere) Abrechnungswährungen Status (registriert, aktiv, inaktiv, gelöscht)
OpCo-Hauptdaten
Name Verbindungsdaten (Adresse, Telefon, E-Mail, etc.)
Interne G/L-Buchungskontonummer
Bankkontonummer
Rechnungsstellungs- und Abrechnungsabläufe
(möglicherweise mehrere) Abrechnungswährungen Status (registriert, aktiv, inaktiv, gelöscht)
Der Administrationsdienst kapselt die mannigfaltigen Administrationseinrichtungen der verschiedenen Komponenten, stellt ein einzelnes Einschreiben (single- sign-on) für den Administrationsnutzer und Protokolle aller Benutzeraktivitäten zur Verfügung. Die folgenden Administrationsaufgaben werden zentral durchgeführt, da sie für alle CPP-Komponenten gültig sind.
Softwareaktualisierungen, System neustarts, Hardware- und Netzwerk- Einrichtung
Die Festlegung von Rollen und Rechten, Installationen von Benutzern (Administratoren, Operatoren), Zuweisung von Rollen zu Benutzern
Der Sicherheitsverwalter (security manager) verfügt exklusiven Zugang zu Sicherheits- und Systemprotokollen, um die Systemoperationen zu überprüfen und Insidertäuschungen zu erkennen
Der Hauptdatenadministrator erzeugt und ändert Hauptdateneinträge und ändert den Status der Anteilseigner (z.B. aktiv/inaktiv), Die Kundenbetreuungsrolle weist diese Zugriffsrechte auf die Hauptdaten, Transaktionsprotokolle, Rechnungsstellungsdetails und Abwicklungsberichte zu.
Die Kunden- und Händlergültigkeitsprüfung während des Registrierungsprozesses wird zentral durchgeführt. Für jeden Kunden sendet das WS eine Prüfanfrage an die CPP. Die CPP führt die Gültigkeitsprüfung durch Überprüfen von Informationen wie Name, Adresse, Alter durch. Nach Beendigung wird das Prüfungsergebnis an das WS zusammen mit einem Qualitätskennzeichen gesendet, welches den für die Gültigkeitsprüfung benutzten Dienst anzeigt (dies kann auf Vereinbarungen zwischen CPP und WI/MA basieren).
In Fig. 28 sind schematisch die verschiedenen Schichten eines interoperablen Mobile-Payment-Protokolls IMPP gezeigt, welches zwischen einem Händler-Server (Merchant Server) und einem Kunden-Server (Wallet Server) auf einer Verarbeitungsplattform (Processing Platform) abläuft. Grundsätzlich hat das Protokoll eine Kern- bzw. Basisschicht (IMPP Core Layer) und eine Erweiterungsschicht (IMPP Extension Layer), wobei zur ersteren der eigentliche Zahlungsverkehrsbereich (Payment ränge), der Kontext-Identifikator-Bereich (OfferlD ränge) und der Be- nachrichtungsbereich (Notification ränge) gehören. Die Erweiterungsschicht umfasst optionale Anfragen und Antworten zwischen den Kunden- und Händler-Serverinstanzen. Sie ermöglicht auch eine kommunikative Anbindung von dritten Kunden-Servern. Die Kommunikation zwischen Abnehmer und Kunden-Server einerseits sowie Anbieter und Händler-Server andererseits liegt außerhalb dieses Protokolls.
Die Ablaufdiagramme und Verfahrensschritt-Listen der Figuren 29A bis 29C, 30A bis 30C, 31A bis 31C, 34A bis 34C und 36A bis 36C für wesentliche Typen von Transaktionen bzw. Bezahlvorgängen sind selbsterklärend.
Dies gilt auch für die in Fig. 32A und 32B sowie 33A und 33B dargestellten Abläufe bei der Erzeugung und der Löschung bzw. Zerstörung einer statischen OfferlD. Hierzu wird insbesondere auch auf die weiter oben gegebene allgemeine Erläuterung zur Handhabung des Kontext-Identifikators hingewiesen. Die in Fig. 35A und 35B dargestellten Schritte und Aspekte eines Clearing-Ablaufes sind davon abhängig, ob ein sogenannter Merchant Acquirer involviert ist o- der nicht. Sie folgen den organisatorischen Geflogenheiten etablierter Clearing- Prozeduren im herkömmlichen Geldverkehr.
Die Figuren 37 bis 40 sind durch ihre Beschriftung im wesentlichen selbsterklärend, so dass eine zusätzliche verbale Beschreibung nicht erforderlich ist. Hierbei gelten folgende Abkürzungen:
EPP Encorus Processing Platform (Systemverwaltungsserver)
FX Foreign Exchange (Währungsumrechnung)
MA Merchant Acquirer (ein Dienstanbieter)
OpCo Systembetreiber
PI Payment Instrument PS Payment Server (bei Transaktionsserver)
P2P Person-to-Person
SVA Stored value account (Guthabenkonto)
Telco Telekommunikationsbetreiber
TX Übertragung WI Wallet Issuer (ein Dienstanbieter)
WS Wallet Server (ein Transaktionsserver)
Obwohl die Erfindung im Umfang verschiedener Ausführungsformen beschrieben wurde, wird der Fachmann erkennen, dass die Erfindung unter Abänderungen, innerhalb des Sinns und Umfangs der Ansprüche, umgesetzt werden kann.

Claims

Patentansprüche
1. Verfahren zur Ausführung einer Transaktion auf einem System, das mindestens eine Zentralprozessorplattform, mindestens einen Geldbörsenser- ver und mindestens einen Bezahlungsserver aufweist, wobei die Zentralprozessorplattform eine Weiterleitungsmaschine, die per Kommunikationsverbindung mit dem Geldbörsenserver und dem Bezahlungsserver gekoppelt ist, aufweist und das Verfahren diese Schritte aufweist: Empfangen einer Transaktionsanfrage am Bezahlungsserver oder am Geld- börsenserver,
Weiterleiten der Anfrage vom Bezahlungsserver oder vom Geldbörsenserver an die Zentralprozessorplattform und
Betrieb der Zentralprozessorplattform, um die Transaktion durchzuführen.
2. Verfahren nach Anspruch 1, wobei die Transaktionsanfrage am Bezahlungsserver oder am Geldbörsenserver von wenigstens entweder einem mobilen Gerät oder einem nicht-mobilen Gerät empfangen wird.
3. Verfahren nach Anspruch 1 oder 2, wobei Kommunikationen zwischen der Zentralprozessorplattform und wenigstens entweder dem Bezahlungsserver oder dem Geldbörsenserver entsprechend einem Protokoll erfolgen.
4. Verfahren nach Anspruch 3, wobei das Protokoll ein interoperables mobiles Bezahlungsprotokoll aufweist.
5. Verfahren nach Anspruch 4, wobei das interoperable mobile Bezahlungsprotokoll in Zusammenhang mit der Durchführung wenigstens entweder einer direkten Makrobezahlung, Makrobezahlungsgutschrift, verzögerten Makrobezahlung, teilweisen Makrobezahlung, direkten Mikrobezahlung, verzögerten Mikrobezahlung oder Mikrobezahlungsgutschrift verwendet wird.
6. Verfahren nach einem der vorangehenden Ansprüche, wobei die Zentralprozessorplattform wenigstens entweder eine Währungsumrechnung, oder eine Bezahlungsabrechnung und einen Bezahlungsausgleich, oder eine Ge- bührenbearbeitung und Rechnungsstellung, oder eine Geldmittelverteilung durchführt.
7. Verfahren nach einem der vorangehenden Ansprüche, wobei der Geld- börsenserver wenigstens entweder Berechtigungsdaten, Bezahlungsdaten oder Transaktionsverlaufsdaten aufweist.
8. Verfahren nach einem der vorangehenden Ansprüche, wobei der Bezahlungsserver wenigstens entweder Händlerdaten oder Transaktionsverlaufs- daten aufweist.
9. Datenübertragungsverfahren zur Übermittlung von zahlungsverkehrsrelevanten Informationen zur Bezahlung einer von einem Anbieter an einen Abnehmer verkauften Ware oder Dienstleistung unter Zugriff auf ein bei einem Kontenverwalter elektronisch verwaltetes Abnehmerkonto unter Nutzung eines Telekommunikationsnetzes, insbesondere Mobilfunknetzes, an das der Abnehmer mit einem Telekommunikations-Endgerät angeschlossen ist, insbesondere zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t, dass von dem Anbieter eine Anfrage nach einem eindeutigen Kontext-Identifikator zur temporären oder permanenten, transaktionsübergreifenden Kennzeichnung einer von ihm angebotenen Ware oder Dienstleistung, ins- besondere einer Mehrzahl von Waren und/oder Dienstleistungen, an einen
Systemverwaltungsserver gerichtet, von dem Systemverwaltungsserver ein Kontext-Identifikator oder eine Bestätigung eines extern erzeugten Kontext-Identifikators generiert und dem anfragenden Anbieter zugesandt, der Kontext-Identifikator an den Abnehmer übermittelt und von dem Abnehmer über das Telekommunikationsnetz in Zuordnung zu dem Kontext-Identifikator Autorisierungsdaten zur Autorisierung der Bezahlung an den Kontenverwalter übermittelt werden.
10. Datenübertragungsverfahren nach Anspruch 9, d a d u rc h g eken n ze i ch n et, dass mit der Generierung des Kontext-Identifikators keine Gültigkeitsdauer festgelegt wird, so dass er potentiell unbegrenzt gültig ist.
11. Datenübertragungsverfahren nach Anspruch 9, d a d u rc h g eken n ze i ch n et, dass mit der Generierung des Kontext-Identifikators eine Gültigkeitsdauer definiert und er bei deren Ablauf automatisch ungültig gemacht wird.
12. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 11, d a d u rc h g e ken nze i ch n et, dass zum Ungültigmachen des Kontext-Identifikators bei Ablauf der Gültigkeitsdauer oder auf Anforderung des Anbieters ein Eliminierungssignal an den Anbieter gesandt wird.
13. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 12, d a d u rc h g e ken nzei ch n et, dass die Übermittlung des Kontext-Identifikators an potentielle Abnehmer als invariante optische Anzeige, insbesondere Beschriftung auf einem Schaufensterdisplay oder Ausgabeautomaten oder Aufdruck auf einem Prospekt oder Katalog oder dergleichen, erfolgt.
14. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 12, d a d u rc h g e ken nze i ch n et, dass die Übermittlung des Kontext-Identifikators an potentielle Abnehmer als variable optische Anzeige auf einer elektrooptischen Anzeigeeinrichtung oder durch Sprachausgabe oder ein akustisches Signal erfolgt.
15. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 14, d a d u rc h g e ken nze i ch n et, dass der Kontext-Identifikator in einem Broadcast-Verfahren außerhalb des Telekommunikationsnetzes, insbesondere durch Rundfunk- oder Fernsehübertragung oder Versand bzw. Verteilung von Druckschriften oder E-Mail- Broadcast, während der Gültigkeitsdauer an eine Vielzahl potentieller Abnehmer übermittelt wird.
16. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 14, d a d u rch g e ken n zei ch n et, dass der Kontext-Identifikator, insbesondere in einem Broadcast-Verfahren, in einer Kurznachricht oder per WAP über das Telekommunikationsnetz an das Telekommunikations-Endgerät des Abnehmers übermittelt und dort angezeigt wird.
17. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 16, da d u rch g e ken n zeichn e , dass die Schritte der Anfrage nach einem Kontext-Identifikator durch den Anbieter und der Zusendung eines solchen an den Anbieter als im wesentlichen automatisierte Datenübertragungen zwischen dem Systemverwaltungsserver und einem Händler-Server oder Anbieter-Datenendgerät über ein Daten- und/oder Telekommunikationsnetz, insbesondere das Internet, ablaufen.
18. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 17, d a d u rch g e ken nze i ch n et, dass nach dem Schritt der Übermittlung des Kontext-Identifikators an den Abnehmer der Kontext-Identifikator durch den Abnehmer über das Telekommunikati- onsnetz an einen Kunden-Server des Netzbetreibers oder eines Dienstanbieters im Telekommunikationsnetz übermittelt, durch den Kunden-Server, Dienstserver oder Händler-Server eine Anfragenachricht zur Einholung eines verbindlichen Angebots an den Anbieter gesandt, durch den Anbieter ein Angebotsdatensatz an den Kunden-Server übersandt und der Angebotsdatensatz vom Kunden-Server an das Telekommunikations- Endgerät des potentiellen Abnehmers übermittelt und dort im Rahmen einer Menüführung zur Bestätigung der Transaktion angezeigt wird.
19. Datenübertragungsverfahren nach Anspruch 18, d a d u rc h g eke n nze i ch n et, dass die Datenübertragung in den Schritten der Anfrage nach einem verbindlichen Angebot und der Übersendung der Angebotsdaten über den System- Verwaltungsserver ausgeführt wird, welcher insbesondere Such- und Routing-Funktionen zwischen Netzbetreiber bzw. Dienstanbieter und Anbieter ausführt.
20. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 19, d a d u rc h g e ken n ze i c h n et, dass der Kontext-Identifikator vollständig extern erzeugt und im Rahmen der Anfrage durch den Anbieter zur Bestätigung an den Systemverwaltungsserver übermittelt wird.
21. Datenübertragungsverfahren nach einem der Ansprüche 9 bis 19, d a d u rch geken nzeic h n et, dass der Kontext-Identifikator einen ersten und einen zweiten Abschnitt aufweist, wobei der erste Abschnitt ein durch den Systemverwaltungsserver generierter oder verwalteter Anbieter-Identifikator und der zweite Ab- schnitt ein durch den Anbieter generierter oder verwalteter Waren- oder
Warengruppen-Identifikator ist und das Verfahren eine Übermittlung des zweiten Abschnitts an den Systemverwaltungsserver, die Verknüpfung von erstem und zweitem Abschnitt im Systemverwaltungsserver und die Zusendung oder Bestätigung des gesamten Kontext-Identifikators an den Ab- nehmer bzw. diesem gegenüber umfasst.
22. Datenübertragungsverfahren nach einem der Ansprüche 18 bis 21, d a d u rch g e ken nze i c h n et, dass der Kontext-Identfikator in oder an einem Telekommunikationsendgerät, insbesondere durch eine mit diesem verbundene Kamera oder einen Scanner, des Abnehmers aus einem optischen oder akustischen Signal in ein elektrisches Signal umgewandelt wird.
23. Anordnung zur Durchführung des Verfahrens nach einem der vorangehen- den Ansprüche, mit einem Systemverwaltungsserver, der zur Generierung und Übersendung des Kontext-Identifikators im Ansprechen auf eine Anfrage ausgebildet ist, einem mit dem Systemverwaltungsserver über ein Daten- und/oder Telekommunikationsnetz, insbesondere das Internet, verbundenen Anbieter- Endgerät zur Eingabe und Übersendung der Anfrage nach einem Kontext-
Identifikator und zur Ausgabe eines übersandten Kontext-Identifikators, Anzeigemitteln zur Anzeige des Kontext-Identifikators für den oder die Abnehmer und einem Telekommunikations-Endgerät, insbesondere Mobilfunk-Endgerät, zum Anschluss des Abnehmers an ein Telekommunikationsnetz zum Zugriff auf sein Abnehmerkonto.
24. Anordnung nach Anspruch 23, g e ke n n ze ic h net d u rch einen Kunden-Server, der eine Verbindung zwischen dem Telekommunikations-Endgerät des Abnehmers und dem Anbieter-Endgerät zur Übermittlung eines verbindlichen Angebotes, insbesondere über den Systemverwaltungsserver, herstellt.
25. Anordnung nach Anspruch 23 oder 24, d a d u rc h ge ken n zei c h n et, dass die Anzeigemittel als Druckschrift oder Beschriftung eines Trägers ausgebildet sind.
26. Anordnung nach Anspruch 23 oder 24, d a d u rc h g e ken n zeic h n et, dass die Anzeigemittel als elektrooptische Anzeigeeinrichtung, insbesondere als
Display eine Telekommunikations- oder Datenendgerätes, ausgebildet sind.
27. Anordnung nach Anspruch 23 oder 24, d a d u rc h ge ken n zei ch n et, dass die Anzeigemittel als Sprachausgabe- oder akustische Signalgebereinrichtung ausgebildet sind.
28. Anordnung nach Anspruch 23 oder 24, d a d u rc h g eke n nzei ch n et, dass die Anzeigemittel als Fernseh- oder Rundfunkempfänger ausgebildet sind.
29. Anordnung nach einem der Ansprüche 23 bis 28, d a d u rc h g eke n nze i c h n et, dass dem Telekommunikations-Endgerät des Abnehmers eine Kamera oder ein Scanner zur selbsttätigen Erfassung eines optisch angezeigten Kontext- Identifikators zugeordnet ist oder das es zur Auswertung eines einen Kon- text-Identifikator repräsentierenden akustischen Signals ausgebildet ist.
30. Anordnung nach einem der Ansprüche 23 bis 29, d a d u rc h g e ke n nzei ch n et, dass der Systemverwaltungsserver eine Codeerzeugereinheit zur Generierung eines Kontext-Identifikators zur temporären oder permanenten, transakti- onsübergreifenden eindeutigen Kennzeichnung von durch die Anbieter angebotenen Waren oder Dienstleistungen, insbesondere jeweils einer Mehrzahl von Waren und/oder Dienstleistungen, im Ansprechen auf eine empfangene Anfrage und eine Codesendeeinrichtung zur Übersendung des ge- nerierten Kontext-Identifikators direkt oder mittelbar an das anfragende
Anbieter-Endgerät aufweist.
31. Anordnung nach Anspruch 30, d a d u rch g eke n nzei ch n et, dass der Systemverwaltungsserver der Codeerzeugereinheit zugeordnete Zeitgebermittel und Zeitdauer-Speichermittel zur Zuordnung und Speicherung einer Gültigkeitsdauer zu jedem Kontext-Identifikator sowie eine mit den Zeitgeber- und Zeit-Speichermitteln verbundene Zeitdauer-Vergleichereinheit zur Überwachung des Ablaufes einer festgelegten Gültigkeitsdauer und zur Ausgabe eines Eliminierungssignals zum Ungültigmachen des Kontext-Identifikators bei Ablauf aufweist.
32. Anordnung nach einem der Ansprüche 23 bis 31, d a d u rc h g eke n nzei ch n et, dass dem Systemverwaltungsserver ein Datenhaltungssystem zur Speicherung und Verwaltung aller gültigen Kontext-Identifikatoren und von diesen im System zugeordneten Informationen, insbesondere zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge, zugeordnet ist.
33. Datenübertragungsanordnung zur Übermittlung von zahlungsverkehrsrelevanten Informationen zur Bezahlung von durch Anbieter an Abnehmer verkauften Waren oder Dienstleistungen unter Zugriff auf bei mindestens einem Kontenverwalter elektronisch verwalteten Abnehmerkonten, mit mindestens einem Telekommunikationsnetz, insbesondere Mobilfunknetz, an das die Abnehmer jeweils mit einem Telekommunikations-Endgerät angeschlossen sind, mit dem Telekommunikationsnetz verbundenen oder verbindbaren Anbieter-Endgeräten, mindestens einem Kontenverwaltungsserver zur Verwaltung der Abnehmerkonten, mindestens einem Kunden-Server des Betreibers des Telekommunikationsnetzes oder eines Kunden-Dienstanbieters, wobei der Kunden-Server zur Verwaltung von Identifizierungsdaten der Abnehmer sowie zur Ausführung einer Datenkommunikation mit den Anbieter-Endgeräten sowie dem oder jedem Kontenverwaltungsserver ausgebildet ist, und einem Systemverwaltungsserver, der über eine bidirektionale Datenverbindung direkt mit dem oder jedem Kunden-Server sowie mit den Anbieter- Endgeräten oder mindestens einem zwischengeschalteten Händler-Server eines Händler-Dienstanbieters verbunden oder verbindbar ist und Speichermittel zur Speicherung von Identifizierungs- und Adressdaten der Anbieter-Endgeräte oder des oder jedes Händler-Servers sowie Datenverkehrsleitmittel zum Routing von Datenübertragungsvorgängen zwischen dem oder jedem Kunden-Server und den Anbieter-Endgerä- ten bzw. dem oder jedem Händler-Server aufweist.
34. Datenübertragungsanordnung nach Anspruch 33, d a d u r c h g e k e n n z e i c h n e t, dass der Systemverwaltungsserver mit einer Mehrzahl von Kunden-Servern in mehreren Telekommunikationsnetzen, insbesondere Mobilfunknetzen, im wesentlichen dauerhaft verbunden ist.
35. Datenübertragungsanordnung nach Anspruch 33, d a d u rc h g e ke n nze i ch n et, dass der Systemverwaltungsserver und/oder der Händler-Server in einem Telekommunikationsnetz, insbesondere Mobilfunknetz, angeordnet ist und eine Funktionseinheit mit dem Kunden-Server bildet.
36. Datenübertragungsanordnung nach einem der Ansprüche 33 bis 35, d a d u rc h g e ke n nze ich n et, dass der Systemverwaltungsserver mit einer Mehrzahl von Händler-Servern verbindbar ist, wobei jeder Händler-Server mit einer Mehrzahl von Anbieter- Endgeräten verbunden oder verbindbar ist und einen Händler-Speicher zur Speicherung von Identifizierungs- und Adressdaten der angeschlossenen
Anbieter aufweist.
37. Datenübertragungsanordnung nach einem der Ansprüche 33 bis 36, d a d u rc h g e ke n nze ich n et, dass der Systemverwaltungsserver eine Codeerzeugereinheit zur Generierung eines Kontext-Identifikators zur temporären oder permanenten, transakti- onsübergreifenden eindeutigen Kennzeichnung von durch die Anbieter angebotenen Waren oder Dienstleistungen, insbesondere jeweils einer Mehrzahl von Waren und/oder Dienstleistungen, im Ansprechen auf eine emp- fangene Anfrage und eine Codesendeeinrichtung zur Übersendung des generierten Kontext-Identifikators direkt oder mittelbar an das anfragende Anbieter-Endgerät aufweist.
38. Datenübertragungsanordnung nach Anspruch 37, d a d u rc h g e ke n nze ich n e , dass der Systemverwaltungsserver der Codeerzeugereinheit zugeordnete Zeitgebermittel und Zeitdauer-Speichermittel zur Zuordnung und Speicherung einer Gültigkeitsdauer zu jedem Kontext-Identifikator sowie eine mit den Zeitgeber- und Zeitdauer-Speichermitteln verbundene Zeitdauer-Verglei- chereinheit zur Überwachung des Ablaufes einer festgelegten Gültigkeits- dauer und zur Ausgabe eines Eliminierungssignals zum Ungültigmachen des Kontext-Identifikators bei Ablauf aufweist.
39. Datenübertragungsanordnung nach einem der Ansprüche 33 bis 38, d ad u rch g eken nzeich net, dass der oder mindestens ein Kontenverwaltungsserver dem oder einem Telekommunikationsnetz direkt zugeordnet ist und mit dem Systemverwaltungsserver und/oder mit dem Kunden-Server zur Ausführung einer Bezahlung, insbesondere unter Zugriff auf ein Prepaid-Guthaben, zusammen- wirkt.
40. Datenübertragungsanordnung nach einem der Ansprüche 33 bis 38, d a d u rc h g eke n nzei ch n et, dass der oder mindestens ein Kontenverwaltungsserver außerhalb des netzinter- nen Steuerungsbereiches des oder jedes Telekommunikationsnetzes angeordnet und insbesondere direkt mit dem Telekommunikations-Endgerät des Abnehmers verbindbar ist.
41. Datenübertragungsanordnung nach einem der Ansprüche 33 bis 40, d a d u rc h g e ke n nzeic h n et, dass der Systemverwaltungsserver einen Ablaufprogrammspeicher zur Speicherung mindestens eines Transaktions-Ablaufprogrammes der Datenkommunikation zwischen dem oder jedem Kunden-Server und den Anbieter-Endgeräten bzw. dem oder jedem Händler-Server aufweist.
42. Datenübertragungsanordnung nach einem der Ansprüche 33 bis 41, d a d u rc h g e ke n nzei ch n et, dass dem Systemverwaltungsserver ein Datenhaltungssystem zur Speicherung und Verwaltung aller gültigen Kontext-Identifikatoren und von diesen im System zugeordneten Informationen, insbesondere zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge, zugeordnet ist.
43. Datenübertragungsverfahren zur Übermittlung von zahlungsverkehrsrele- vanten Informationen zur Bezahlung von durch Anbieter an Abnehmer ver- kauften Waren oder Dienstleistungen unter Zugriff auf bei mindestens einem Kontenverwalter elektronisch verwalteten Abnehmerkonten, über mindestens ein Telekommunikationsnetz, insbesondere Mobilfunknetz, an das die Abnehmer jeweils mit einem Telekommunikations-Endgerät angeschlos- sen sind, insbesondere zum Betrieb einer Datenübertragungsanordnung nach einem der Ansprüche 33 bis 42, d a d u rc h g e ken nze ic h n et, dass durch einen Systemverwaltungsserver Datenverbindungen zwischen min- destens einem Kunden-Server und einer Mehrzahl von Anbieter-Endgeräten oder mindestens einem zwischengeschalteten Händler-Server aufgrund von in einer Datenbasis des Systemverwaltungsserver gespeicherten Identifizierungs- und Adressdaten der Anbieter-Endgeräte oder des oder jedes Händler-Servers und des oder jedes Kunden-Servers, insbesondere mehrere Datenverbindungen parallel zueinander, aufgebaut und in einem
Transaktions-Ablaufprogramm gespeicherte Datenkommunikationsschritte zwischen diesen gesteuert werden.
44. Datenübertragungsverfahren nach Anspruch 43, d a d u rc h g e ke n n ze i ch n et, dass von dem Anbieter eine Anfrage nach einem eindeutigen Kontext-Identifikator zur temporären oder permanenten, transaktionsübergreifenden Kennzeichnung einer von ihm angebotenen Ware oder Dienstleistung, insbesondere einer Mehrzahl von Waren und/oder Dienstleistungen, an einen Systemverwaltungsserver gerichtet, von dem Systemverwaltungsserver ein Kontext-Identifikator oder eine Bestätigung eines extern erzeugten Kontext-Identifikators generiert und dem anfragenden Anbieter zugesandt, der Kontext-Identifikator an den Abnehmer übermittelt und von dem Abnehmer über das Telekommunikationsnetz in Zuordnung zu dem Kontext-Identifikator Autorisierungsdaten zur Autorisierung der Bezahlung an den Kontenverwalter übermittelt werden.
45. Datenübertragungsverfahren nach Anspruch 43 oder 44, d a d u rc h g e ken n ze i ch n et, dass der Kontext-Identifikator in einem Broadcast-Verfahren außerhalb des Telekommunikationsnetzes, insbesondere durch Rundfunk- oder Fernsehübertragung oder Versand bzw. Verteilung von Druckschriften oder E-Mail- Broadcast, während der Gültigkeitsdauer an eine Vielzahl potentieller Ab- nehmer übermittelt wird.
46. Datenübertragungsverfahren nach Anspruch 43 oder 44, d a d u rch g ekennzeich net, dass der Kontext-Identifikator, insbesondere in einem Broadcast-Verfahren, in einer Kurznachricht oder per WAP an das Telekommunikations-Endgerät des Anbieters übermittelt und dort angezeigt wird.
47. Datenübertragungsverfahren nach einem der Ansprüche 43 bis 46, d a d u rc h g e ke n nzei ch n et, dass die Schritte der Anfrage nach einem Kontext-Identifikator durch den Anbieter und der Zusendung eines solchen an den Anbieter als im wesentlichen automatisierte Datenübertragungen zwischen dem Systemverwaltungsserver und einem Händler-Server oder Anbieter-Datenendgerät über ein Daten- und/oder Telekommunikationsnetz, insbesondere das Internet, ablau- fen.
48. Datenübertragungsverfahren nach einem der Ansprüche 43 bis 47, d a d u rch g e ke n nzeic h n et, dass, insbesondere bei Transaktionen mit einem über einer vorbestimmten Schwelle liegenden Geldwert, nach dem Schritt der Übermittlung des Kontext-Identifikators an den Abnehmer der Kontext-Identifikator durch den Abnehmer über das Telekommunikationsnetz an einen Kunden-Server des Netzbetreibers oder eines Dienstan- bieters im Telekommunikationsnetz übermittelt, durch den Kunden-Server eine Anfragenachricht zur Einholung eines verbindlichen Angebots an den Anbieter gesandt, durch den Anbieter ein Angebotsdatensatz an den Kunden-Server übersandt und der Angebotsdatensatz vom Kunden-Server an das Telekommunikations- Endgerät des potentiellen Abnehmers übermittelt und dort im Rahmen einer Menüführung zur Bestätigung der Transaktion angezeigt wird.
49. Datenübertragungsverfahren nach Anspruch 48, d a d u rc h g e ken nzei c h n et, dass durch den Kunden-Server an den Abnehmer eine Aufforderung zur Übermittlung des Kontext-Identifikators und zugehöriger Zahlungsinformationen gesandt wird.
50. Datenübertragungsverfahren nach Anspruch 48 oder 49, d a d u rch g e ke n n zei ch n et, dass sich ein Schritt der Übermittlung einer Zahlungsbestätigung durch den Abnehmer über sein Telekommunikations-Endgerät direkt oder mittelbar an den Kontenverwaltungsserver anschließt.
51. Datenübertragungsverfahren nach Anspruch 50, d a d u rch geken nzeich net, dass der Empfang der Zahlungsbestätigung am Kontenverwaltungsserver die e- lektronische Abbuchung oder Reservierung eines Prepaid-Teilguthabens triggert.
52. Datenübertragungsverfahren nach Anspruch 50, d a d u rch g e ke n n zei ch n et, dass der Empfang des Zahlungsbestätigungssignals beim Kontenverwaltungsser- ver eine bankenübliche elektronische Clearing-Prozedur zwischen dem Kontenverwaltungsserver des Abnehmers und einem Kontenverwaltungsserver sowie dem Anbieter-Endgerät des die Transaktion ausführenden Anbieters oder dem Händler-Server des diesem zugeordneten Händler-Dienstanbieters startet.
53. Datenübertragungsverfahren nach Anspruch 52, d a d u rch g e ken n ze i c h n et, dass die Clearing-Prozedur außerhalb der Datenübertragungsanordnung nach einem der Ansprüche 1 bis 10 abläuft.
54. Datenübertragungsverfahren zur Übermittlung von zahlungsverkehrsrelevanten Informationen zur Ausführung einer Zahlung eines Zahlers an einen Zahlungsempfänger unter Zugriff auf ein durch einen ersten Kontenverwaltungsserver elektronisch verwaltetes Zahlerkonto unter Nutzung eines Te- lekommunikationsnetzes, insbesondere Mobilfunknetzes, an das der Zahler mit einem Telekommunikations-Endgerät angeschlossen ist, insbesondere zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 8, wobei - von dem Telekommunikations-Endgerät des Zahlers eine Verbindung mit einem ersten Transaktionsserver eines Systembetreibers oder Dienstanbieters aufgebaut und ein erster Zahlungsanweisungs-Da'tensatz, der mindestens eine Betragsinformation und eine Adressinformation des Zahlungsempfängers umfasst, an den ersten Transaktionsserver übermittelt wird, - durch den ersten Transaktionsserver aus der Adressinformation ein Kon- tenidentifikator eines durch den ersten oder einen weiteren Kontenverwaltungsserver elektronisch verwalteten Zahlungsempfängerkontos ermittelt wird und - durch den ersten Transaktionsserver eine Gutschrift auf das Zahlungs- empfängerkonto durch Übermittlung eines zweiten Zahlungsanweisungs-
Datensatzes, der mindestens die Betragsinformation und den Konteniden- tifikator des Zahlungsempfängerkontos umfasst, an den Kontenverwaltungsserver des Zahlungsempfängerkontos ausgelöst wird.
55. Datenübertragungsverfahren zur Übermittlung von zahlungsverkehrsrelevanten Informationen zur Ausführung einer Zahlung eines Zahlers an einen Zahlungsempfänger unter Zugriff auf ein durch einen ersten Kontenverwaltungsserver elektronisch verwaltetes Zahlerkonto unter Nutzung eines Datennetzes, insbesondere des Internet, an das der Zahler mit einem Daten- endgerät angeschlossen ist, sowie eines Telekommunikationsnetzes, insbesondere Mobilfunknetzes, an das der Zahler mit einem Telekommunikations-Endgerät angeschlossen ist, insbesondere zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 8, wobei - von dem Datenendgerät des Zahlers eine Verbindung mit einem ersten Transaktionsserver eines Systembetreibers oder Dienstanbieters aufgebaut und ein erster Zahlungsanweisungs-Datensatz, der mindestens eine Betragsinformation und eine Adressinformation des Zahlungsempfängers um- fasst, an den ersten Transaktionsserver übermittelt wird,
- durch den ersten Transaktionsserver eine Verbindung zu dem Telekommunikations-Endgerät des Zahlers aufgebaut und ein Daten- oder Sprachkommunikationsvorgang zur Authentisierung des Zahlers über das Telekommunikationsnetz initiiert wird, - im Ansprechen auf eine erfolgreiche Authentisierung durch den ersten
Transaktionsserver aus der Adressinformation ein Kontenidentifikator eines durch den ersten oder einen weiteren Kontenverwaltungsserver elektronisch verwalteten Zahlungsempfängerkontos ermittelt wird und
- durch den ersten Transaktionsserver die Zahlung auf das Zahlungsemp- fängerkonto durch Übermittlung eines zweiten Zahlungsanweisungs-Datensatzes, der mindestens die Betragsinformation und den Kontenidentifikator des Zahlungsempfängerkontos umfasst, an den Kontenverwaltungsserver des Zahlungsempfängerkontos ausgelöst wird.
56. Datenübertragungsverfahren nach Anspruch 54 oder 55, d a d u r c h g e k e n n z e i c h n e t, dass
- durch den ersten Transaktionsserver aus der Adressinformation eine Serveradresse eines zweiten Kontenverwaltungsservers ermittelt wird, durch den das Zahlungsempfängerkonto elektronisch verwaltet wird, - durch den ersten Transaktionsserver eine Anfrage nach einem Kontenidentifikator des Zahlungsempfängerkontos, unter Übermittlung der Adressinformation des Zahlungsempfängers, an den zweiten Kontenverwaltungsserver gesandt wird und
- durch den zweiten Kontenverwaltungsserver der Kontenidentifikator des Zahlungsempfängerkontos ermittelt und an den ersten Transaktionsserver gesandt wird.
57. Datenübertragungsverfahren zur Übermittlung von zahlungsverkehrsrelevanten Informationen zur Ausführung einer Zahlung eines Zahlers an einen Zahlungsempfänger unter Zugriff auf ein durch einen ersten Kontenverwal- tungsserver elektronisch verwaltetes Zahlerkonto unter Nutzung eines Telekommunikationsnetzes, insbesondere Mobilfunknetzes, an das der Zahler mit einem Telekommunikations-Endgerät angeschlossen ist, insbesondere zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 8, wobei
- von dem Telekommunikations-Endgerät des Zahlers eine Verbindung mit einem ersten Transaktionsserver eines Systembetreibers oder Dienstanbieters aufgebaut und ein erster Zahlungsanweisungs-Datensatz, der mindes- tens eine Betragsinformation und eine Adressinformation des Zahlungsempfängers umfasst, an den ersten Transaktionsserver übermittelt wird,
- der erste Zahlungsanweisungs-Datensatz durch den ersten Transaktionsserver an einen anhand eines Teiles der Adressinformation des Zahlungsempfängers festgestellten zweiten Transaktionsserver übermittelt wird, - durch den zweiten Transaktionsserver aus der Adressinformation ein Kontenidentifikator eines durch den ersten oder einen weiteren Kontenverwaltungsserver elektronisch verwalteten Zahlungsempfängerkontos ermittelt wird und
- durch den zweiten Transaktionsserver eine Gutschrift auf das Zahlungs- empfängerkonto durch Übermittlung eines zweiten Zahlungsanweisungs- Datensatzes, der mindestens die Betragsinformation und den Kontenidentifikator des Zahlungsempfängerkontos umfasst, an den Kontenverwaltungsserver des Zahlungsempfängerkontos ausgelöst wird.
58. Datenübertragungsverfahren zur Übermittlung von zahlungsverkehrsrelevanten Informationen zur Ausführung einer Zahlung eines Zahlers an einen Zahlungsempfänger unter Zugriff auf ein durch einen ersten Kontenverwaltungsserver elektronisch verwaltetes Zahlerkonto unter Nutzung eines Datennetzes, insbesondere des Internet, an das der Zahler mit einem Daten- endgerät angeschlossen ist, sowie eines Telekommunikationsnetzes, insbesondere Mobilfunknetzes, an das der Zahler mit einem Telekommunikations-Endgerät angeschlossen ist, insbesondere zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 8, wobei - von dem Datenendgerät des Zahlers eine Verbindung mit dem ersten Transaktionsserver eines Systembetreibers oder Diensteanbieters aufgebaut und ein erster Zahlungsanweisungs-Datensatz, der mindestens eine Betragsinformation und eine Adressinformation des Zahlungsempfängers umfasst, an den ersten Transaktionsserver übermittelt wird,
- durch den ersten Transaktionsserver eine Verbindung zu dem Telekommunikations-Endgerät des Zahlers aufgebaut und ein Daten- oder Sprachkommunikationsvorgang zur Authentisierung des Zahlers über das Telekommunikationsnetz initiiert wird, - im Ansprechen auf eine erfolgreiche Authentisierung durch den ersten
Transaktionsserver der erste Zahlungsanweisungs-Datensatz durch den ersten Transaktionsserver an einen anhand eines Teiles der Adressinformation des Zahlungsempfängers festgestellten zweiten Transaktionsserver übermittelt wird, - durch den zweiten Transaktionsserver aus der Adressinformation ein Kontenidentifikator eines durch den ersten oder einen weiteren Kontenverwaltungsserver elektronisch verwalteten Zahlungsempfängerkontos ermittelt wird und
- durch den zweiten Transaktionsserver eine Gutschrift auf das Zahlungs- empfängerkonto durch Übermittlung eines zweiten Zahlungsanweisungs- Datensatzes, der mindestens die Betragsinformation und den Kontenidentifikator des Zahlungsempfängerkontos umfasst, an den Kontenverwaltungsserver des Zahlungsempfängerkontos ausgelöst wird.
59. Datenübertragungsverfahren nach Anspruch 57 oder 58, d a d u r c h g e k e n n z e i c h n e t, dass
- durch den zweiten Transaktionsserver aus der Adressinformation eine Serveradresse eines zweiten Kontenverwaltungsservers ermittelt wird, durch den das Zahlungsempfängerkonto elektronisch verwaltet wird, - durch den zweiten Transaktionsserver eine Anfrage nach einem Kontenidentifikator des Zahlungsempfängerkontos, unter Übermittlung der Adressinformation des Zahlungsempfängers, an den zweiten Kontenverwaltungsserver gesandt wird und
- durch den zweiten Kontenverwaltungsserver der Kontenidentifikator des Zahlungsempfängerkontos ermittelt und an den zweiten Transaktionsserver gesandt wird.
60. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 56, d a d u rc h g e ken n ze i ch n et, dass durch den ersten oder zweiten Transaktionsserver der erste oder zweite Zahlungsanweisungs-Datensatz nach Ermittlung des Kontenidentifikators des Zahlungsempfängers vor Auslösung der Zahlung zusammen mit einer Bestätigungsaufforderung an das Telekommunikations-Endgerät des Zah- lers übermittelt und die Zahlung erst im Ansprechen auf den Empfang eines Bestätigungssignals vom Telekommunikations-Endgerät des Zahlers ausgelöst wird.
61. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 60, d a d u rc h geken nzei ch n et, dass der erste Zahlungsanweisungs-Datensatz einen ersten Währungscode und der zweite Zahlungsanweisungs-Datensatz einen zweiten, vom ersten verschiedenen Währungscode umfasst und bei der Erstellung des zweiten Zahlungsanweisungs-Datensatzes eine Umrechnung aus der Betragsinformati- on des ersten Zahlungsanweisungs-Datensatzes in eine Betragsinformation des zweiten Zahlungsanweisungs-Datensatzes aufgrund eines vorgespeicherten Umtauschverhältnisses ausgeführt wird.
62. Datenübertragungsverfahren nach Anspruch 61, d a d u rch g eke n n zei ch n et, dass die Umrechnung der Betragsinformation bei dem ersten oder zweiten Kontenverwaltungsserver unter Nutzung eines vom Transaktionsserver des Systembetreibers aus übermittelten Umtauschverhältnisses ausgeführt wird.
63. Datenübertragungsverfahren nach Anspruch 61, d a d u rc h g e ken nze i c h n et, dass die Umrechnung der Betragsinformation durch den Transaktionsserver aufgrund eines in einer zugeordneten Datenbasis gespeicherten Umtauschver- hältnisses ausgeführt wird.
64. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 63, d a d u rc h g e ke n nze i ch n et, dass der erste und/oder zweite Zahlungsanweisungs-Datensatz eine die Zahlung betreffende Textinformation umfasst, die insbesondere bei beiden Zahlungsanweisungs-Datensätzen im wesentlichen identisch ist.
65. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 64, d a d u rc h geken nzeich n et, dass die Datenübermittlungen von dem und zu dem Telekommunikations-Endgerät des Zahlers für eine Zahlung sämtlich per Kurznachricht gemäß SMS, Datenfile-Übertragung gemäß WAP oder über IVR-Sprachkommunikation ausgeführt werden.
66. Datenübertragungsverfahren nach Anspruch 65, d a d u rc h g e ke n nzei ch n et, dass eine Zahlung eines unterhalb eines vorbestimmten Schwellwertes liegenden Betrages durch die Übermittlung eines ersten Zahlungsanweisungs-Datensatzes per SMS ohne Rückbestätigung-Datenübertragung an das Telekom- munikations-Endgerät initiiert wird.
67. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 66, d a d u rc h g e ke n nze i ch n et, dass durch den ersten Kontenverwaltungsserver eine Autorisierungsprüfung des Zahlers und/oder durch den zweiten Kontenverwaltungsserver eine Autorisierungsprüfung des Zahlungsempfängers aufgrund von jeweils gespeicherten Nutzerdaten ausgeführt wird.
68. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 67, d a d u rc h g e ke n nze i ch n et, dass durch den ersten oder zweiten Transaktionsserver eine Autorisierungsprüfung des Zahlers und/oder Zahlungsempfängers aufgrund von gespeicherten Nutzerdaten ausgeführt wird.
69. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 68, d a d u rch g e ke n n ze i c h n et, dass die Adressinformation des Zahlungsempfängers im ersten Zahlungsanweisungs-Datensatz als MSISDN, Netzadresse eines IP-Netzes, Alias oder Kon- toidentifikator ausgebildet ist.
70. Datenübertragungsverfahren nach einem der Ansprüche 54 bis 69, d a d u rch g eke n n zeich n et, dass für jede Gutschrift durch den ersten oder zweiten Transaktionsserver eine Abwicklungs-Betragsinformation generiert und dem zweiten Zahlungsanweisungs-Datensatz zusammen mit einer vorbestimmten Kennzeichnung darüber hinzugefügt wird, ob das Zahlerkonto oder Zahlungsempfängerkonto oder beide anteilig hiermit zu belasten sind.
71. Datenübertragungsverfahren nach einem der Ansprüche 61 bis 70, d ad u rch g eke n nzeich n et, dass bei der Umrechnung der Betragsinformation des ersten Zahlungsanweisungs-Datensatzes in diejenige des zweiten Zahlungsanweisungs-Datensatzes eine, insbesondere in einer zugeordneten Datenbasis des Transakti- onsservers oder Systemverwaltungs-Server gespeicherte, Spread-Informa- tion eingerechnet wird.
72. Datenübertragungsanordnung zur Übermittlung von zahlungsverkehrsrelevanten Informationen zur Ausführung einer Zahlung eines Zahlers an einen Zahlungsempfänger unter Zugriff auf ein elektronisch verwaltetes Zahlerkonto mit mindestens einem Telekommunikationsnetz, insbesondere Mobilfunknetz, an das der Zahler mit einem Telekommunikations-Endgerät angeschlossen ist, einem ersten Kontenverwaltungsserver zur Verwaltung des Zahlerkontos, der optional über das Telekommunikationsnetz mit dem Telekommunikations-Endgerät verbindbar ist, einem ersten Transaktionsserver des Betreibers des Telekommunikationsnetzes oder eines Dienstanbieters, wobei der erste Transaktionsserver ins- besondere über das Telekommunikationsnetz mit dem Telekommunikations-Endgerät verbindbar ist, einem zweiten Kontenverwaltungsserver zur Verwaltung eines Zahlungsempfängerkontos, der direkt oder mittelbar mit dem ersten Transaktions- Server verbindbar ist und mit dem ersten Kontenverwaltungsserver identisch sein kann, wobei der erste Transaktionsserver zur Umwandlung eines ersten Zahlungsanweisungs-Datensatzes, der mindestens eine Betragsinformation und eine Adressinformation des Zahlungsempfängers umfasst, in einen zweiten Zahlungsanweisungs-Datensatz, der mindestens die Betragsinformation und einen Kontenidentifikator des Zahlungsempfängerkontos umfasst, ausgebildet ist.
Datenübertragungsanordnung zur Übermittlung von zahlungsverkehrsrele- vanten Informationen zur Ausführung einer Zahlung eines Zahlers an einen
Zahlungsempfänger unter Zugriff auf ein elektronisch verwaltetes Zahlerkonto mit mindestens einem Telekommunikationsnetz, insbesondere Mobilfunknetz, an das der Zahler mit einem Telekommunikations-Endgerät angeschlossen ist, einem ersten Kontenverwaltungsserver zur Verwaltung des Zahlerkontos, der optional über das Telekommunikationsnetz mit dem Telekommunikations-Endgerät verbindbar ist, einem ersten Transaktionsserver des Betreibers des Telekommunikations- netzes oder eines Dienstanbieters, wobei der erste Transaktionsserver insbesondere über das Telekommunikationsnetz mit dem Telekommunikations-Endgerät verbindbar ist, einem zweiten Kontenverwaltungsserver zur Verwaltung eines Zahlungsempfängerkontos, der mittelbar mit dem ersten Transaktionsserver ver- bindbar ist und mit dem ersten Kontenverwaltungsserver identisch sein kann, einem zweiten Transaktionsserver, der mit dem ersten Transaktionsserver und dem zweiten Kontenverwaltungsserver verbindbar und zur Umwandlung eines ersten Zahlungsanweisungs-Datensatzes, der mindestens eine Betragsinformation und eine Adressinformation des Zahlungsempfängers umfasst, in einen zweiten Zahlungsanweisungs-Datensatz, der mindestens die Betragsinformation und einen Kontenidentifikator des Zahlungsempfängerkontos umfasst, ausgebildet ist.
74. Datenübertragungsanordnung nach Anspruch 72 oder 73, g eke n nzeich net d u rch ein Datenendgerät, über das der Zahler mit einem Datennetz, insbesondere dem Internet angeschlossen ist und das mit dem ersten Transaktionsserver verbindbar ist.
75. Datenübertragungsanordnung nach einem der Ansprüche 72 bis 74, d a d u rc h g e ken nze i ch n et, dass ein Systemverwaltungsserver mit einer Mehrzahl von ersten und/oder zweiten Transaktionsservern in mehreren Telekommunikationsnetzen, insbe- sondere Mobilfunknetzen, im wesentlichen dauerhaft verbunden ist.
76. Datenübertragungsanordnung nach Anspruch 75, d a d u rc h g eken n ze i ch n et, dass der Systemverwaltungsserver in einem Telekommunikationsnetz, insbeson- dere Mobilfunknetz, angeordnet ist und eine Funktionseinheit mit einem
Transaktionsserver bildet.
77. Datenübertragungsanordnung nach einem der Ansprüche 72 bis 76, d a d u rc h g e ke n nze ic h n et, dass der oder mindestens ein Kontenverwaltungsserver dem oder einem Telekommunikationsnetz direkt zugeordnet ist und mit dem Systemverwaltungsserver und/oder mit dem Transaktionsserver zur Ausführung einer Zahlung, insbesondere unter Zugriff auf ein Prepaid-Guthaben, zusammenwirkt.
78. Datenübertragungsanordnung nach einem der Ansprüche 72 bis 77, d a d u rc h g eken n zeic h n et, dass der oder mindestens ein Kontenverwaltungsserver außerhalb des netzinternen Steuerungsbereiches des oder jedes Telekommunikationsnetzes ange- ordnet und insbesondere direkt mit dem Telekommunikations-Endgerät des Zahlers verbindbar ist.
79. Datenübertragungsanordnung nach einem der Ansprüche 72 bis 78, d a d u rc h g e ke n n ze ic h n et, dass der Systemverwaltungsserver einen Ablaufprogrammspeicher zur Speicherung mindestens eines Transaktions-Ablaufprogrammes der Datenkommunikation zwischen dem Telekommunikations-Endgerät eines Zahlers und dem Kontenverwaltungsserver bzw. dem Transaktionsserver oder den Transaktionsservern aufweist.
80. Datenübertragungsanordnung nach einem der Ansprüche 72 bis 79, d ad u rch geken nzeich n et, dass dem Systemverwaltungsserver ein Datenhaltungssystem zur Speicherung und Verwaltung aller gültigen Nutzerdaten und, insbesondere von zahlungsverkehrsrelevanten Daten und Kennzeichnungen stattgefundener Datenübertragungsvorgänge zugeordnet ist.
EP02791681A 2001-11-14 2002-11-14 Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge Ceased EP1446778A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP02791681A EP1446778A2 (de) 2001-11-14 2002-11-14 Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge

Applications Claiming Priority (12)

Application Number Priority Date Filing Date Title
EP01127042 2001-11-14
EP01127042 2001-11-14
EP02005762 2002-03-13
EP02005763A EP1313074A3 (de) 2001-11-14 2002-03-13 Datenübertragungsanordnung mit Systemverwaltungsserver und Verfahren zu deren Betrieb
EP02005763 2002-03-13
EP02005762A EP1313073A3 (de) 2001-11-14 2002-03-13 Datenübertragungsverfahren und -anordnung mit Kontext-Identifikator
EP02010457A EP1361551A1 (de) 2002-05-08 2002-05-08 Datenübertragungsverfahren und -anordnung, insbesondere für privaten Zahlungsverkehr
EP02010457 2002-05-08
US38961702P 2002-06-17 2002-06-17
US389617P 2002-06-17
EP02791681A EP1446778A2 (de) 2001-11-14 2002-11-14 Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge
PCT/EP2002/012782 WO2003042938A2 (de) 2001-11-14 2002-11-14 Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge

Publications (1)

Publication Number Publication Date
EP1446778A2 true EP1446778A2 (de) 2004-08-18

Family

ID=56290355

Family Applications (1)

Application Number Title Priority Date Filing Date
EP02791681A Ceased EP1446778A2 (de) 2001-11-14 2002-11-14 Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge

Country Status (4)

Country Link
US (1) US20050256802A1 (de)
EP (1) EP1446778A2 (de)
AU (1) AU2002358013A1 (de)
WO (1) WO2003042938A2 (de)

Families Citing this family (168)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070055582A1 (en) 1996-11-12 2007-03-08 Hahn-Carlson Dean W Transaction processing with core and distributor processor implementations
US20080172314A1 (en) 1996-11-12 2008-07-17 Hahn-Carlson Dean W Financial institution-based transaction processing system and approach
US8396811B1 (en) 1999-02-26 2013-03-12 Syncada Llc Validation approach for auditing a vendor-based transaction
US8392285B2 (en) 1996-11-12 2013-03-05 Syncada Llc Multi-supplier transaction and payment programmed processing approach with at least one supplier
CA2358528C (en) 1998-12-23 2015-04-14 The Chase Manhattan Bank System and method for integrating trading operations including the generation, processing and tracking of trade documents
US7720762B1 (en) 2002-10-03 2010-05-18 Gofigure Payments, Llc System and method for electronically processing commercial transactions based upon threshold amount
US8793160B2 (en) 1999-12-07 2014-07-29 Steve Sorem System and method for processing transactions
US7146338B2 (en) 2001-06-28 2006-12-05 Checkfree Services Corporation Inter-network financial service
US7831467B1 (en) * 2000-10-17 2010-11-09 Jpmorgan Chase Bank, N.A. Method and system for retaining customer loyalty
US9948644B2 (en) 2001-03-26 2018-04-17 Salesforce.Com, Inc. Routing messages between applications
US7788399B2 (en) 2001-03-26 2010-08-31 Salesforce.Com, Inc. System and method for mapping of services
US7689711B2 (en) 2001-03-26 2010-03-30 Salesforce.Com, Inc. System and method for routing messages between applications
US8849716B1 (en) 2001-04-20 2014-09-30 Jpmorgan Chase Bank, N.A. System and method for preventing identity theft or misuse by restricting access
US7689506B2 (en) 2001-06-07 2010-03-30 Jpmorgan Chase Bank, N.A. System and method for rapid updating of credit information
US7266839B2 (en) 2001-07-12 2007-09-04 J P Morgan Chase Bank System and method for providing discriminated content to network users
US8020754B2 (en) 2001-08-13 2011-09-20 Jpmorgan Chase Bank, N.A. System and method for funding a collective account by use of an electronic tag
US7987501B2 (en) 2001-12-04 2011-07-26 Jpmorgan Chase Bank, N.A. System and method for single session sign-on
US7693783B2 (en) 2002-06-12 2010-04-06 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8645266B2 (en) * 2002-06-12 2014-02-04 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US20040122736A1 (en) 2002-10-11 2004-06-24 Bank One, Delaware, N.A. System and method for granting promotional rewards to credit account holders
US8301493B2 (en) 2002-11-05 2012-10-30 Jpmorgan Chase Bank, N.A. System and method for providing incentives to consumers to share information
US10535049B2 (en) * 2003-03-21 2020-01-14 Paypal, Inc. Payment transactions via substantially instant communication system
US8306907B2 (en) 2003-05-30 2012-11-06 Jpmorgan Chase Bank N.A. System and method for offering risk-based interest rates in a credit instrument
US8175908B1 (en) 2003-09-04 2012-05-08 Jpmorgan Chase Bank, N.A. Systems and methods for constructing and utilizing a merchant database derived from customer purchase transactions data
KR100584001B1 (ko) * 2004-03-30 2006-05-26 와이더댄 주식회사 가상 발신번호를 이용한 모바일 소액결제 서비스 시스템및 방법
EP1782255A4 (de) 2004-06-09 2009-04-29 Us Bancorp Licensing Inc Transaktionsverarbeitung mit kern- und verteilerprozessorimplementierungen
US8762238B2 (en) 2004-06-09 2014-06-24 Syncada Llc Recurring transaction processing system and approach
EP1782256A4 (de) 2004-06-09 2009-05-06 Us Bancorp Licensing Inc Auftragsressourcen-erfüllungs- und -verwaltungssystem und ansatz
US7925551B2 (en) * 2004-06-09 2011-04-12 Syncada Llc Automated transaction processing system and approach
US7574386B2 (en) 2004-06-09 2009-08-11 U.S. Bank National Association Transaction accounting auditing approach and system therefor
US10600059B2 (en) * 2004-07-29 2020-03-24 Amdocs Development Limited Component based customer care management
US8417633B1 (en) * 2004-11-08 2013-04-09 Rockstar Consortium Us Lp Enabling improved protection of consumer information in electronic transactions
US10134202B2 (en) * 2004-11-17 2018-11-20 Paypal, Inc. Automatic address validation
US20060229998A1 (en) 2005-03-31 2006-10-12 Mark Harrison Payment via financial service provider using network-based device
WO2006125223A2 (en) * 2005-05-18 2006-11-23 Lehman Brothers Inc. Methods and systems for providing interest rate simulation displays
US7401731B1 (en) 2005-05-27 2008-07-22 Jpmorgan Chase Bank, Na Method and system for implementing a card product with multiple customized relationships
US7774402B2 (en) 2005-06-29 2010-08-10 Visa U.S.A. Adaptive gateway for switching transactions and data on unreliable networks using context-based rules
CN101218340B (zh) * 2005-07-08 2012-02-15 森下仁丹株式会社 双歧杆菌属的微生物生产的多糖
US7925578B1 (en) 2005-08-26 2011-04-12 Jpmorgan Chase Bank, N.A. Systems and methods for performing scoring optimization
US20140089120A1 (en) * 2005-10-06 2014-03-27 C-Sam, Inc. Aggregating multiple transaction protocols for transacting between a plurality of distinct payment acquiring devices and a transaction acquirer
US20130332343A1 (en) 2005-10-06 2013-12-12 C-Sam, Inc. Multi-tiered, secure mobile transactions ecosystem enabling platform comprising a personalization tier, a service tier, and an enabling tier
JP2007286697A (ja) * 2006-04-12 2007-11-01 Mastercard Internatl Japan Inc 支払い処理支援装置及び支払い処理支援方法
US20070288322A1 (en) 2006-05-23 2007-12-13 Toshiba Tec Kabushiki Kaisha Portable terminal and its programs, settlement apparatus, and merchandising information providing apparatus
US7788174B1 (en) 2006-07-13 2010-08-31 Gofigure Payments, Llc Method for facilitating a value exchange in a mobile payments network
US7783541B1 (en) * 2006-07-13 2010-08-24 Gofigure Payments, Llc System and method for allocating fees associated with an electronic transaction
EP2074577A4 (de) * 2006-09-05 2010-12-22 Mobibucks Inc Zahlungssysteme und -verfahren
US8909553B2 (en) * 2006-09-06 2014-12-09 Transaction Wireless, Inc. Payment card terminal for mobile phones
US8712884B2 (en) 2006-10-06 2014-04-29 Syncada Llc Transaction finance processing system and approach
EP2103019A4 (de) 2007-01-09 2012-07-11 Visa Usa Inc Kontaktfreie transaktion
CA2578893A1 (en) * 2007-02-15 2008-08-15 Ibm Canada Limited - Ibm Canada Limitee System and method for processing payment options
US20080208688A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Methods and systems for handling of mobile discount certificates using mobile devices
US10102518B2 (en) * 2007-02-22 2018-10-16 First Data Corporation Enrollment and registration of a device in a mobile commerce system
US20080208741A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Account information lookup systems and methods in mobile commerce
US20080207234A1 (en) 2007-02-22 2008-08-28 First Data Corporation Marketing messages in mobile commerce
US20080208742A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Provisioning of a device for mobile commerce
US20080208762A1 (en) * 2007-02-22 2008-08-28 First Data Corporation Payments using a mobile commerce device
US8566239B2 (en) 2007-02-22 2013-10-22 First Data Corporation Mobile commerce systems and methods
JP4287887B2 (ja) * 2007-03-05 2009-07-01 東芝テック株式会社 ショッピングシステム及びこのシステムに用いられる携帯端末，決済端末，サーバ並びにプログラム
US8935187B2 (en) 2007-03-07 2015-01-13 Playspan, Inc. Distributed payment system and method
US8548908B2 (en) * 2007-04-11 2013-10-01 First Data Corporation Mobile commerce infrastructure systems and methods
US20080288400A1 (en) 2007-04-27 2008-11-20 Cashedge, Inc. Centralized Payment Method and System for Online and Offline Transactions
US9342823B2 (en) * 2007-06-18 2016-05-17 Lemon, Inc. Payment clearing network for electronic financial transactions and related personal financial transaction device
US8660966B2 (en) 2007-08-31 2014-02-25 Microsoft Corporation Payment system and method
US20090070256A1 (en) * 2007-09-04 2009-03-12 Skycash Sp. Z O.O. Systems and methods for payment
US8751394B2 (en) * 2007-11-28 2014-06-10 Sybase 365, Inc. System and method for enhanced transaction security
JP5214228B2 (ja) * 2007-11-30 2013-06-19 株式会社日立製作所 コンテンツ配信システム
US8622308B1 (en) 2007-12-31 2014-01-07 Jpmorgan Chase Bank, N.A. System and method for processing transactions using a multi-account transactions device
US8751337B2 (en) 2008-01-25 2014-06-10 Syncada Llc Inventory-based payment processing system and approach
US20090201817A1 (en) * 2008-02-08 2009-08-13 International Business Machines Corporation Method of optimizing a flow of value in a network
US8554652B1 (en) 2008-02-21 2013-10-08 Jpmorgan Chase Bank, N.A. System and method for providing borrowing schemes
US8762210B2 (en) 2008-06-03 2014-06-24 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
WO2009149164A2 (en) * 2008-06-03 2009-12-10 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US10157375B2 (en) * 2008-06-03 2018-12-18 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US8090650B2 (en) 2008-07-24 2012-01-03 At&T Intellectual Property I, L.P. Secure payment service and system for interactive voice response (IVR) systems
US20100063926A1 (en) * 2008-09-09 2010-03-11 Damon Charles Hougland Payment application framework
US9639852B2 (en) * 2008-09-24 2017-05-02 Paypal, Inc. GUI-based wallet program for online transactions
US20100125546A1 (en) * 2008-11-19 2010-05-20 Melyssa Barrett System and method using superkeys and subkeys
US20100131347A1 (en) * 2008-11-24 2010-05-27 Research In Motion Limited Electronic payment system using mobile wireless communications device and associated methods
US8364587B2 (en) * 2009-01-28 2013-01-29 First Data Corporation Systems and methods for financial account access for a mobile device via a gateway
US9230259B1 (en) 2009-03-20 2016-01-05 Jpmorgan Chase Bank, N.A. Systems and methods for mobile ordering and payment
US20100274678A1 (en) * 2009-04-22 2010-10-28 Gofigure Payments, Llc Systems, methods and devices for facilitating mobile payments
US9235831B2 (en) 2009-04-22 2016-01-12 Gofigure Payments, Llc Mobile payment systems and methods
US9137494B2 (en) * 2009-07-22 2015-09-15 At&T Intellectual Property I, L.P. Systems and methods to order a content item deliverable via a television service
US9064246B1 (en) * 2009-10-13 2015-06-23 Sprint Communications Company L.P. Payment service and platform authentication integration
US20110093387A1 (en) * 2009-10-16 2011-04-21 Zack Fuerstenberg System and method for non-credit card billers to accept credit card payments
US9195980B2 (en) * 2009-10-30 2015-11-24 Nokia Technologies Oy Method and apparatus for recovery during authentication
US20110218880A1 (en) * 2010-03-03 2011-09-08 Ayman Hammad Systems and methods using mobile device in payment transaction
US8554631B1 (en) 2010-07-02 2013-10-08 Jpmorgan Chase Bank, N.A. Method and system for determining point of sale authorization
RU2732585C2 (ru) 2010-07-09 2020-09-22 Виза Интернэшнл Сервис Ассосиэйшн Шлюзовой уровень абстракции
US20120239556A1 (en) * 2010-10-20 2012-09-20 Magruder Andrew M Latency payment settlement apparatuses, methods and systems
USD774529S1 (en) 2010-11-04 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
US20120116957A1 (en) * 2010-11-04 2012-05-10 Bank Of America Corporation System and method for populating a list of transaction participants
US8306868B2 (en) * 2010-12-19 2012-11-06 Bhaskar Arcot Sivanathan Method for accepting payment information on the web using an interactive voice response system
WO2012112822A2 (en) 2011-02-16 2012-08-23 Visa International Service Association Snap mobile payment apparatuses, methods and systems
US10586227B2 (en) 2011-02-16 2020-03-10 Visa International Service Association Snap mobile payment apparatuses, methods and systems
USD774526S1 (en) 2011-02-21 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
USD774527S1 (en) 2011-02-21 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
USD774528S1 (en) 2011-02-21 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
US10223691B2 (en) 2011-02-22 2019-03-05 Visa International Service Association Universal electronic payment apparatuses, methods and systems
US8447693B2 (en) * 2011-04-13 2013-05-21 Citicorp Credit Services, Inc. Methods and systems for routing payment transactions
US9582598B2 (en) 2011-07-05 2017-02-28 Visa International Service Association Hybrid applications utilizing distributed models and views apparatuses, methods and systems
US10121129B2 (en) 2011-07-05 2018-11-06 Visa International Service Association Electronic wallet checkout platform apparatuses, methods and systems
US9355393B2 (en) 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
WO2013012671A1 (en) * 2011-07-15 2013-01-24 Mastercard International, Inc. Methods and systems for payments assurance
US9710807B2 (en) 2011-08-18 2017-07-18 Visa International Service Association Third-party value added wallet features and interfaces apparatuses, methods and systems
US10825001B2 (en) 2011-08-18 2020-11-03 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US10242358B2 (en) 2011-08-18 2019-03-26 Visa International Service Association Remote decoupled application persistent state apparatuses, methods and systems
US9508072B2 (en) * 2011-08-26 2016-11-29 Paypal, Inc. Secure payment instruction system
US20130073458A1 (en) * 2011-09-19 2013-03-21 Cardinalcommerce Corporation Open wallet for electronic transactions
US10223730B2 (en) 2011-09-23 2019-03-05 Visa International Service Association E-wallet store injection search apparatuses, methods and systems
IN2014KN00998A (de) 2011-10-12 2015-09-04 C Sam Inc
US20130124364A1 (en) * 2011-11-13 2013-05-16 Millind Mittal System and method of electronic payment using payee provided transaction identification codes
AU2013214801B2 (en) 2012-02-02 2018-06-21 Visa International Service Association Multi-source, multi-dimensional, cross-entity, multimedia database platform apparatuses, methods and systems
US9026460B2 (en) * 2012-06-28 2015-05-05 Bank Of America Corporation Automatic activation of mobile payment mechanisms based on identified mobile payment types accepted by a merchant
US20140012738A1 (en) * 2012-07-09 2014-01-09 Bennett Woo Methods and systems for measuring accuracy in fraudulent transaction identification
US9846861B2 (en) * 2012-07-25 2017-12-19 Visa International Service Association Upstream and downstream data conversion
USD770478S1 (en) 2012-09-07 2016-11-01 Bank Of America Corporation Communication device with graphical user interface
EP2717207A1 (de) * 2012-10-05 2014-04-09 Alcatel Lucent Cloud-basiertes Bezahlverfahren
CN102930431B (zh) * 2012-10-29 2016-01-27 东莞宇龙通信科技有限公司 支付服务器和支付通道标识方法
CN102968720B (zh) * 2012-11-07 2016-08-03 东莞宇龙通信科技有限公司 支付服务器、终端和支付通道隔离方法
CN102968719B (zh) * 2012-11-07 2016-12-21 东莞宇龙通信科技有限公司 支付服务器、终端和支付通道接入方法
GB2509895A (en) * 2012-11-22 2014-07-23 Visa Europe Ltd Activation and Use of a Digital Wallet via Online Banking
CN103903126B (zh) * 2012-12-26 2018-03-23 中国移动通信集团江苏有限公司 资金快速到账的方法、系统及电信系统、第三方支付系统
US10108995B2 (en) * 2013-05-07 2018-10-23 Excalibur Ip, Llc Online and offline collaboration associated with shopping and purchasing
US9058626B1 (en) 2013-11-13 2015-06-16 Jpmorgan Chase Bank, N.A. System and method for financial services device usage
US10664833B2 (en) * 2014-03-05 2020-05-26 Mastercard International Incorporated Transactions utilizing multiple digital wallets
US10096027B2 (en) * 2014-03-12 2018-10-09 The Toronto-Dominion Bank System and method for authorizing a debit transaction without user authentication
WO2016005937A2 (en) * 2014-07-09 2016-01-14 Vineet Katial A method and system for processing invoices for a user
WO2016042398A1 (en) * 2014-09-15 2016-03-24 Aesthetic Integration Limited System and method for modeling and verifying financial trading platforms
US11551198B2 (en) * 2015-01-28 2023-01-10 Swoop Ip Holdings Llc Email-based e-commerce with near field communication
US10163083B2 (en) 2015-04-13 2018-12-25 Bank Of America Corporation Account activity management system
US20170132630A1 (en) * 2015-11-11 2017-05-11 Bank Of America Corporation Block chain alias for person-to-person payments
US11295293B2 (en) 2016-01-07 2022-04-05 Worldpay, Llc Point of interaction device emulation for payment transaction simulation
US9825931B2 (en) 2016-01-26 2017-11-21 Bank Of America Corporation System for tracking and validation of an entity in a process data network
US10116667B2 (en) * 2016-01-26 2018-10-30 Bank Of America Corporation System for conversion of an instrument from a non-secured instrument to a secured instrument in a process data network
WO2017136418A1 (en) 2016-02-01 2017-08-10 Visa International Service Association Systems and methods for code display and use
US10142347B2 (en) 2016-02-10 2018-11-27 Bank Of America Corporation System for centralized control of secure access to process data network
US10438209B2 (en) 2016-02-10 2019-10-08 Bank Of America Corporation System for secure routing of data to various networks from a process data network
US10129238B2 (en) 2016-02-10 2018-11-13 Bank Of America Corporation System for control of secure access and communication with different process data networks with separate security features
US11374935B2 (en) 2016-02-11 2022-06-28 Bank Of America Corporation Block chain alias person-to-person resource allocation
US10762504B2 (en) 2016-02-22 2020-09-01 Bank Of America Corporation System for external secure access to process data network
US10178105B2 (en) * 2016-02-22 2019-01-08 Bank Of America Corporation System for providing levels of security access to a process data network
US10140470B2 (en) 2016-02-22 2018-11-27 Bank Of America Corporation System for external validation of distributed resource status
US10026118B2 (en) 2016-02-22 2018-07-17 Bank Of America Corporation System for allowing external validation of data in a process data network
US10440101B2 (en) 2016-02-22 2019-10-08 Bank Of America Corporation System for external validation of private-to-public transition protocols
US10135870B2 (en) * 2016-02-22 2018-11-20 Bank Of America Corporation System for external validation of secure process transactions
US10496989B2 (en) 2016-02-22 2019-12-03 Bank Of America Corporation System to enable contactless access to a transaction terminal using a process data network
US10679215B2 (en) 2016-02-22 2020-06-09 Bank Of America Corporation System for control of device identity and usage in a process data network
US10318938B2 (en) 2016-02-22 2019-06-11 Bank Of America Corporation System for routing of process authorization and settlement to a user in process data network based on specified parameters
US10475030B2 (en) 2016-02-22 2019-11-12 Bank Of America Corporation System for implementing a distributed ledger across multiple network nodes
US10142312B2 (en) 2016-02-22 2018-11-27 Bank Of America Corporation System for establishing secure access for users in a process data network
US10636033B2 (en) 2016-02-22 2020-04-28 Bank Of America Corporation System for routing of process authorizations and settlement to a user in a process data network
US10607285B2 (en) 2016-02-22 2020-03-31 Bank Of America Corporation System for managing serializability of resource transfers in a process data network
US10387878B2 (en) 2016-02-22 2019-08-20 Bank Of America Corporation System for tracking transfer of resources in a process data network
CN107305673A (zh) 2016-04-18 2017-10-31 阿里巴巴集团控股有限公司 一种订单处理方法和装置
RU2716042C1 (ru) 2016-07-15 2020-03-05 Кардиналкоммерс Корпорейшн Мост между аутентификацией и авторизацией с использованием расширенных сообщений
SG10201606192YA (en) * 2016-07-27 2018-02-27 Mastercard Asia Pacific Pte Ltd A System And Method For Making Payment Within A Digital Messaging Environment
US10402796B2 (en) 2016-08-29 2019-09-03 Bank Of America Corporation Application life-cycle transition record recreation system
US11631077B2 (en) 2017-01-17 2023-04-18 HashLynx Inc. System for facilitating secure electronic communications between entities and processing resource transfers
US11321681B2 (en) 2017-02-06 2022-05-03 Northern Trust Corporation Systems and methods for issuing and tracking digital tokens within distributed network nodes
US11341488B2 (en) 2017-02-06 2022-05-24 Northern Trust Corporation Systems and methods for issuing and tracking digital tokens within distributed network nodes
US20190087823A1 (en) * 2017-09-20 2019-03-21 Mastercard International Incorporated Cashless transaction processing methods and apparatus
US10929545B2 (en) 2018-07-31 2021-02-23 Bank Of America Corporation System for providing access to data stored in a distributed trust computing network
SG11202104548SA (en) * 2018-11-06 2021-05-28 Visa Int Service Ass Systems and methods for managing a transaction state object
WO2020188581A1 (en) * 2019-03-20 2020-09-24 Telefonaktiebolaget Lm Ericsson (Publ) Payment transaction handling in a radio communication network
ES2902462A1 (es) * 2020-09-28 2022-03-28 Bankinter Sa Método para autorizar una tercera transacción basada en la autenticación de transacciones de pago instrumentales y no instrumentales por internet
US12014365B2 (en) 2020-10-30 2024-06-18 National Automated Clearing House Association System and method for business payment information directory services
CN112651795B (zh) * 2020-12-11 2023-11-17 深圳市智莱科技股份有限公司 自动售卖机的出货方法、自动售卖机和可读存储介质

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5289371A (en) * 1992-09-11 1994-02-22 Memorylink, Inc. System and method for routing data and communications
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
JP3367675B2 (ja) * 1993-12-16 2003-01-14 オープン マーケット インコーポレイテッド オープンネットワーク販売システム及び取引トランザクションのリアルタイムでの承認を行う方法
US5822737A (en) * 1996-02-05 1998-10-13 Ogram; Mark E. Financial transaction system
US6754636B1 (en) * 1996-09-04 2004-06-22 Walker Digital, Llc Purchasing systems and methods wherein a buyer takes possession at a retailer of a product purchased using a communication network
EP0848361B1 (de) * 1996-12-13 1999-08-25 Telefonaktiebolaget L M Ericsson (Publ) Verfahren und System zur Durchführung von Geldtransaktionen
US6868391B1 (en) * 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
ATE442746T1 (de) * 1998-09-10 2009-09-15 Swisscom Ag Verfahren zum kaufen von waren oder dienstleistungen mit einem mobiltelefon
DE19903363C2 (de) * 1999-01-28 2002-05-29 Mueller Judex Donald Verfahren und System zur Durchführung von bargeldlosen Finanztransaktionen
FR2790162B1 (fr) * 1999-02-19 2001-04-13 France Telecom Procede de telepaiement et systeme pour la mise en oeuvre de ce procede
EP1065634A1 (de) * 1999-07-02 2001-01-03 Mic Systems System und Verfahren zur Durchführung gesicherter elektronischer Transaktionen über ein offenes Kommunikationsnetwerk
DE19946539B4 (de) * 1999-09-28 2010-04-29 T-Mobile Deutschland Gmbh Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk
DE60032863D1 (de) * 1999-11-30 2007-02-22 Citibank Na System und Verfahren zur Durchführung einer elektronischen Transaktion mit einer elektronischen Geldbörse mittels eines Transaktionproxys
FR2801995B1 (fr) * 1999-12-07 2005-09-09 Bruno Duval Procede et systeme de gestion d'une transaction securisee a travers un reseau de communication
US7366703B2 (en) * 2000-01-05 2008-04-29 American Express Travel Related Services Company, Inc. Smartcard internet authorization system
GB2364482B (en) * 2000-06-30 2002-10-09 Motorola Inc Server-based electronic wallet system
US7428507B2 (en) * 2001-06-29 2008-09-23 Hewlett-Packard Development Company, L.P. System and arrangement for processing payments for purchases through a payment server

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO03042938A3 *

Also Published As

Publication number Publication date
AU2002358013A1 (en) 2003-05-26
WO2003042938A3 (de) 2003-12-04
WO2003042938A2 (de) 2003-05-22
US20050256802A1 (en) 2005-11-17

Similar Documents

Publication Publication Date Title
EP1446778A2 (de) Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge
US7110980B2 (en) System and method for facilitating electronic transfer of funds
DE69610719T2 (de) System und verfahren für treuhandvermittler gebrauchende geschäfliche zahlungen
DE19652294C2 (de) Elektronisches Übertragungssystem und Verfahren
US7565326B2 (en) Dialect independent multi-dimensional integrator using a normalized language platform and secure controlled access
DE69534982T2 (de) Computer-zahlungssystem zum kaufen von informationsprodukten mittels elektronischem transfer auf dem internet
EP1178444A1 (de) Elektronischer Zahlungsverkehr mit SMS
DE102008035391A1 (de) Verfahren zur Authentifizierung
DE19946539B4 (de) Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk
US20060074802A1 (en) Electronic payment system with rejection option
EP1180751A1 (de) Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher
RU2423020C1 (ru) Система предоставления услуг абонентам мобильных телефонов (варианты)
WO2004006198A1 (de) Verfahren zur elektronischen bezahlung einer ware oder dienstleistung unter nutzung eines mobilfunknetzes und anordnung zu dessen durchführung
DE60000576T2 (de) Verfahren zum einführen von handelsdienstleistungen
DE10061560A1 (de) Verfahren zur automatischen Abwicklung von Zahlungsvorgängen im Electronic Commerce sowie zugehörige Vorrichtung
CN115545946A (zh) 一种融资管理系统及方法
EP1411483A2 (de) Verfahren zum vorbereiten eines bezahlvorganges in einem Kommunikationsnetz
DE69730435T2 (de) System, verfahren und hergestellter gegenstand für die architektur virtueller verkaufspunkte mit mehreren eingangspunkten
EP1193658A1 (de) Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher
EP1315131B1 (de) Verfahren zum Ermöglichen eines Geldausgleichs zwischen Zahlungssystemen in Kommunikationsnetzen
CN115545903B (zh) 信贷管理系统及方法
EP1310928A1 (de) Verfahren zum Ermöglichen und Durchführen einer Geldzahlung unter Nutzung eines Kommunikationsnetzes
US20170076287A1 (en) Electronic payment system with option to accept or reject a proffered payment
WO2001081875A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken
US20040073494A1 (en) Commercial transaction system

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

AK Designated contracting states

Kind code of ref document: A2

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

AX Request for extension of the european patent

Extension state: AL LT LV MK RO SI

RIN1 Information on inventor provided before grant (corrected)

Inventor name: KOEHNTOPP, FRANK

Inventor name: MOST, LYSANN

Inventor name: WEBER, MICHAEL

Inventor name: BLUMERT, OVE

Inventor name: ZIMMERMANN, HOLGER

Inventor name: MAENNLE, MANFRED

Inventor name: BIECHELE, BERND

Inventor name: HACKETT, DAMIAN

Inventor name: SCHULZE, ANDREAS

Inventor name: BOUCEKA, DENIS

Inventor name: KRUPPA, STEPHAN

Inventor name: MARRA, ANDREAS

Inventor name: OFFER, GERO

Inventor name: AMMERMANN, DIRK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: KOEHNTOPP, FRANK

Inventor name: MOST, LYSANN

Inventor name: WEBER, MICHAEL

Inventor name: BLUMERT, OVE

Inventor name: ZIMMERMANN, HOLGER

Inventor name: MAENNLE, MANFRED

Inventor name: BIECHELE, BERND

Inventor name: HACKETT, DAMIAN

Inventor name: SCHULZE, ANDREAS

Inventor name: BOUCEKA, DENIS

Inventor name: KRUPPA, STEPHAN

Inventor name: MARRA, ANDREAS

Inventor name: OFFER, GERO

Inventor name: AMMERMANN, DIRK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: KOEHNTOPP, FRANK

Inventor name: MOST, LYSANN

Inventor name: WEBER, MICHAEL

Inventor name: BLUMERT, OVE

Inventor name: ZIMMERMANN, HOLGER

Inventor name: MAENNLE, MANFRED

Inventor name: BIECHELE, BERND

Inventor name: HACKETT, DAMIAN

Inventor name: SCHULZE, ANDREAS

Inventor name: BOUCEKA, DENIS

Inventor name: KRUPPA, STEPHAN

Inventor name: MARRA, ANDREAS

Inventor name: OFFER, GERO

Inventor name: AMMERMANN, DIRK

RIN1 Information on inventor provided before grant (corrected)

Inventor name: KOEHNTOPP, FRANK

Inventor name: MOST, LYSANN

Inventor name: WEBER, MICHAEL

Inventor name: BLUMERT, OVE

Inventor name: ZIMMERMANN, HOLGER

Inventor name: MAENNLE, MANFRED

Inventor name: BIECHELE, BERND

Inventor name: HACKETT, DAMIAN

Inventor name: SCHULZE, ANDREAS

Inventor name: BOUCEKA, DENIS

Inventor name: KRUPPA, STEPHAN

Inventor name: MARRA, ANDREAS

Inventor name: OFFER, GERO

Inventor name: AMMERMANN, DIRK

17Q First examination report despatched

Effective date: 20061109

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20110410