WO2004081892A2 - Verfahren und system zum initiieren und/oder durchführen einer mit mindestens zwei korrespondierenden willenserklärungen in beziehung stehenden transaktion - Google Patents

Verfahren und system zum initiieren und/oder durchführen einer mit mindestens zwei korrespondierenden willenserklärungen in beziehung stehenden transaktion Download PDF

Info

Publication number
WO2004081892A2
WO2004081892A2 PCT/EP2004/002520 EP2004002520W WO2004081892A2 WO 2004081892 A2 WO2004081892 A2 WO 2004081892A2 EP 2004002520 W EP2004002520 W EP 2004002520W WO 2004081892 A2 WO2004081892 A2 WO 2004081892A2
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
data
payment
instance
entity
Prior art date
Application number
PCT/EP2004/002520
Other languages
English (en)
French (fr)
Other versions
WO2004081892A3 (de
Inventor
Christian Hogl
Original Assignee
Christian Hogl
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Christian Hogl filed Critical Christian Hogl
Priority to JP2006504645A priority Critical patent/JP2006524938A/ja
Priority to AU2004219478A priority patent/AU2004219478A1/en
Priority to EP04719443A priority patent/EP1602088A2/de
Priority to US10/548,492 priority patent/US7702581B2/en
Priority to CA002518448A priority patent/CA2518448A1/en
Publication of WO2004081892A2 publication Critical patent/WO2004081892A2/de
Publication of WO2004081892A3 publication Critical patent/WO2004081892A3/de
Priority to US12/728,544 priority patent/US8065232B2/en
Priority to US13/285,201 priority patent/US8566238B2/en
Priority to US13/941,807 priority patent/US8831990B2/en
Priority to US14/476,780 priority patent/US20140372292A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • 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/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
    • G06Q20/405—Establishing or using transaction specific rules
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G06Q20/1085—Remote banking, e.g. home banking involving automatic teller machines [ATMs]
    • 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/223—Payment schemes or models based on the use of peer-to-peer 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/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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/383—Anonymous user system
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0213—Consumer transaction fees
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • 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
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G06Q50/265—Personal security, identity or safety

Definitions

  • the present invention relates to a method and a system for initiating and / or executing a transaction related to at least two corresponding declarations of intent, in particular a payment transaction, between at least two transaction parties via a settlement instance, in which at least one of the transaction parties uses a landline telephone or a mobile phone or a Mobile communication device used to transmit data.
  • Payment transactions are the primary area of application of the present invention due to their frequency and economic importance.
  • Standard-compatible processes of type A refer to those methods which can be used within the entire current "installed base” of mobile telephones (ie with all or the majority of the mobile telephones / SIM module chip cards which are widespread according to the prior art), without the need for an exchange or technical modification of the mobile phones or the SIM module chip cards.
  • Force-looking type B processes refers to processes that can only be used with special mobile phones or SIM modules (generally newer types), which are only available on the market in small numbers or only in the future will come.
  • the data exchange of at least one transaction party usually takes place via protocols or processes such as WAP (Wireless Application Protocol) or i-Mode (predominantly used in Japan) as well as locally on the mobile phones or the SIM module.
  • WAP Wireless Application Protocol
  • i-Mode randominantly used in Japan
  • Java or SIM application toolkit applications designed for chip cards with data being exchanged, for example, via GPRS (GSM Packet Radio Service).
  • GSM Packet Radio Service GSM Packet Radio Service
  • Another disadvantage of the forward-looking type B method is that it can generally only be used in mobile radio networks with a certain standard (such as GSM) and not with simple landline telephones.
  • the data exchange of at least one transaction party generally takes place via a standing telephone connection with voice announcements (for example through an IVR system (Interactive Voice Response)) and DTMF tone transmission (Dual Tone Multi Frequency) or via SMS (Short Message System).
  • voice announcements for example through an IVR system (Interactive Voice Response)
  • DTMF tone transmission Dual Tone Multi Frequency
  • SMS Short Message System
  • these procedures involve the transmission of the complete mobile phone number (ANI or MSISDN) or a unique alias from the payer or recipient to the recipient or payer, and the transmission of a permanently valid PIN code from the payer to a processing authority Authorization and, if applicable, the transmission of once-valid TAN codes as authorization or proof of payment from the processing authority to the payer and from the payer to the recipient.
  • ANI or MSISDN complete mobile phone number
  • MSISDN mobile phone number
  • TAN codes a permanently valid PIN code from the payer to a processing authority
  • Paybox method is known as the second embodiment of DE 19903822. This procedure should be briefly described as an example of a standard-compatible type A procedure:
  • the payer (hereinafter referred to as Z) first transmits his mobile phone number (ANI or MSISDN) or an alias clearly assigned to the mobile phone number to the recipient (E).
  • E then implicitly transmits his own cell phone number to the processing authority (AI) by calling his cell phone and explicitly the cell phone number of Z, as well as the amount to be paid, via DTMF tone transmission.
  • the telephone connection from E to AI remains until the last step).
  • the settlement authority checks whether Z is an approved participant and whether Z's creditworthiness is sufficient to pay the amount.
  • the AI then initiates a call to the cell phone number from Z. Z accepts the call.
  • An AI voice computer generates an acoustic announcement of the payment information (recipient, payment amount).
  • Z enters a PIN code via DTMF tone transmission.
  • the AI sends an acoustic confirmation of the payment to E via the still existing telephone connection.
  • the main disadvantage of the Paybox process is the high telecommunication costs and the long processing time.
  • the call from E to the AI and the transmission of the data takes about 30 seconds.
  • Calling the AI to Z afterwards including announcing the payment information and querying the authorization PIN, also takes about the same length of time.
  • the second call the first call remains connected.
  • telecommunications costs for 90 seconds of mobile phone connections arise. Provided that the processing takes place via a free phone number and the operator of the AI bears the telecommunication costs, according to the state of the art this will result in costs of approx
  • the transaction takes a total of approx. 75 seconds.
  • the time restriction also exists when using an alternative transmission method such as SMS.
  • the delivery speed of an SMS is not secured and is often more than 30 seconds, in some cases significantly longer.
  • certain future-dependent type B processes e.g. use of the WAP protocol - the duration of the connection establishment, navigation and data entry are too long for use in time-critical mobile commerce scenarios.
  • Another disadvantage of the above-mentioned standard-compatible type A methods is the fact that, as a rule, the full cell phone number of the payer or of the recipient must be disclosed to the recipient or payer.
  • the use of a call number alias (such as in the paybox procedure) provides partial anonymity with regard to the subscriber's actual mobile phone number, but a fundamentally clear identity of a transaction party is known to the other transaction party.
  • Another disadvantage of using the complete mobile phone number or the call number alias is its length (usually 12 digits) and the associated longer input and transmission time and the probability of incorrect entries.
  • Another disadvantage of the aforementioned standard-compatible type A procedures is the low level of evidence or the risk of disputability for the payer, recipient and operator of the processing authority.
  • One way of increasing this security of evidence is to involve a "Trusted Third Party", ie an additional party recognized by the payer, recipient and operator of the settlement authority.
  • the telecommunications provider in particular can be considered as such an additional party.
  • Another disadvantage of the aforementioned standard-compatible type A processes is that an error about the authorized amount is easily possible. This risk arises from the fact that the amount is usually only actively stated by one of the transaction parties and only passively confirmed by the other transaction party, e.g. after being shown on the mobile phone display or after an acoustic announcement of the amount.
  • DE 19946 539 A1 discloses a method for billing Internet transactions via mobile radio.
  • the assignment of merchant and customer in a payment gateway is established via a temporary IP address of the customer's mobile phone. This IP address is transferred from the customer as well as from the merchant to the payment gateway.
  • a disadvantage of this method is that the temporary IP address of the mobile radio subscriber has to be compared to his MSISDN via an MSISDN IP database, which makes the use of the method more difficult or impossible for a payment gateway provider independent of the mobile radio operator.
  • Another disadvantage of this method is that the customer must have a WAP-compatible mobile radio device, so it is disadvantageously a "future-dependent method of type B" (see above).
  • this method has the disadvantage that a relatively large data record, namely the temporary IP address of a mobile subscriber, has to be transmitted for the assignment of retailers and customers Assignment of the IP addresses arriving at the payment gateway is complex, since a very large number of IP addresses may have to be compared for this.
  • EP 1 081 919 A1 discloses a method for authorizing the payment of goods offered on the Inlernet.
  • the assignment of customer and provider takes place in an authorization comparator by means of a transaction code that has been generated by the provider and transmitted to the customer.
  • this has the disadvantage that handling transaction codes, which can be changed for both transaction parties in each transaction, is inherently complex.
  • the total triple transmission of the transaction code (from the provider to the authorization comparator, from the provider to the customer and from the customer to the authorization comparator) is very susceptible to errors.
  • At least two of the transaction parties transmit data to the processing instance, the transmission of the data taking place within a limited time window (time interval).
  • the initiation of the data transmission of these transaction parties is carried out actively by the transaction parties and not by the processing authority, the data transmitted during the initiation containing features that enable the declarations of intent to be assigned to one another.
  • the feature of the initiation of the data transmission by the transaction parties means that before the first transmission of transaction-relevant data from the transaction parties to the settlement entity, no transaction-relevant data is transmitted from the settlement entity to the transaction parties.
  • An instance is understood in the sense of the present invention in particular to mean a technical device, such as. B. a data processing device.
  • Application programs which automatically carry out the steps of the method can be stored on this device.
  • the settlement authority is also referred to below as a computer system.
  • Fixed-line telephones, mobile telephones and / or communication devices are provided on the part of the transaction parties for data transmission.
  • data which correspond to the declaration of intent are entered into these devices.
  • the remaining data which e.g. B. identify the transaction parties, can be stored in the devices and automatically transferred to the settlement authority.
  • the method according to the invention serves to initiate and / or carry out a transaction which is related to at least two corresponding declarations of intent.
  • the declarations of intent can be aimed in particular at the conclusion of a contract.
  • the transaction to be initiated or carried out in this case is then the execution of the contract.
  • a separate conventional credit card payment may be the subject of the declaration of intent and / or the conclusion of the contract.
  • the data is transmitted simultaneously or within a limited time window (time interval).
  • time interval time window
  • a sequential data transfer is usually carried out, for a payment transaction, for example, first from the payer to the recipient, then from the recipient to the processing authority, then from the processing authority to the payer, then from the payer to the processing authority and from there to the recipient again.
  • the simultaneous or timely and actively initiated data transmission from the transaction parties towards the processing instance also means that only a few characteristic data have to be transmitted in order to enable the declarations of intent and thus the transaction parties to be assigned to one another. Because the narrow time window limits the size of the pool of transactions that can be assigned to each other. The reduced amount of data on the one hand further simplifies and speeds up processing, and on the other hand enables the anonymity of the transaction parties with one another.
  • the simultaneous or timely data transmission further increases security against deniability, since in contrast to methods in which a transaction can be initiated or triggered by one party, the active and simultaneous participation of two transaction parties is required. This also increases the security against accidental triggering or accidental double triggering of a transaction.
  • the time interval for the transmission of the data depends on the transaction and the devices used for this as well as the number of data arriving at the processing instance per unit of time.
  • the duration of the time interval can be, for example, 5 minutes, but is preferably less. If the transaction is initiated via two mobile phones, the time interval is e.g. B. in a range between 10 sec. And 30 sec, preferably 20 sec.
  • the data is advantageously transmitted to at least one of the transaction parties by initiating a telephone call to the processing instance.
  • Initiation of a telephone call is understood here on the one hand to mean that the data transfer originates from the transaction parties and not from the processing authority.
  • various data such as the identifier of the caller and the identifier of the called party, as well as additional features such as suffix digits, can be transmitted.
  • a paid connection is usually only made when the call is from the called party is accepted. When the call is initiated, it can be accepted, but this is not absolutely necessary.
  • the transmission of at least part of the data transmitted by at least one of the transaction parties takes place by means of the telephone number sequence chosen for processing a telephone call.
  • the sequence of telephone numbers is preferably so short that it can be completely transmitted by the switching centers and / or transmission systems.
  • the implicit transmission of the relevant data as part of the phone number has the advantage of security, speed and ease of use.
  • the triggering of a payment transaction is in fact as simple as dialing a telephone number, while the security functions implemented in mobile phones, which prevent unintentional or unauthorized dialing, also protect the payment function.
  • this configuration has the advantage that the individual connection proof of the telecommunication provider can serve as proof of payment and document and that the payment transaction can be very easily integrated into the billing systems of the telecommunication provider.
  • Another advantage of data transmission as part of the phone number is that - in contrast to DTMF tone transmission - visual control (before sending the data) is possible via the display of the mobile phone. Furthermore, this type of transmission is much less prone to errors than DTMF tones, which often lead to problems with poor radio connections. Nevertheless, any other transmission methods are conceivable for the transmission of data both from the transaction parties to the settlement entity and from the settlement entity to the transaction parties, the scope of this invention including these. These transmission methods can be used in whole or in part as an alternative or in addition to the methods described above.
  • the amount, a PIN, a customer number, a payment allocation reference code or other information can be transmitted via one or more alternative methods.
  • the data transmitted by one transaction party are just sufficient to enable identification of this transaction party, but not sufficient to enable identification of the other transaction party.
  • the data transmitted by the transaction parties to the processing instance are related to one another in accordance with a specific rule.
  • party A only discloses to party B only the last n digits of its mobile number, ie. h only part of the number.
  • Party B now transmits its own mobile phone number and the said n digits to the processing entity, at the same time party A only transmits its own mobile phone number to the processing entity. Due to the narrow time window, the pool of transactions to be assigned to one another is so small that the n digits are sufficient for the assignment.
  • n digits that party B transmits are not sufficient to identify party A; furthermore, the n digits are related to party A's mobile phone number according to a certain rule).
  • the procedure can also work in such a way that both parties A and B disclose to each other, for example, the last n or m digits of their respective cell phone numbers.
  • party A In the Paybox procedure explained above, which does not work with simultaneous transmission, party A must disclose to party B the complete mobile phone number or a unique alias in order to enable unique addressing.
  • the transaction parties are clearly identified vis-à-vis the settlement authority, which opens up the basic possibility of mediating between them in the event of a dispute and with the consent of the transaction parties or establishing a connection between them.
  • the data transmitted by the transaction parties to the processing instance contain the essential part of the contents of the respective declarations of intent and / or a digital print (digest, hash value) of the contents of the respective declarations of intent and / or a clear one Reference to the content of the respective declarations of intent, if applicable, recorded elsewhere.
  • a checking entity which comprises or can be connected to the processing instance, checks whether an assignment of the transaction parties is possible on the basis of the transmitted data. In the case of a payment transaction, this also checks whether the respective declarations of intent correspond.
  • the data transmission from the transaction parties to the settlement island is carried out via mobile telephones, and information about the locations of the mobile telephones is also transmitted during the data transmission.
  • This information is used as an additional assignment criterion.
  • This training is advantageous in application scenarios in which there is spatial proximity between the payer and the recipient.
  • information about the location of the transaction parties can be used as an additional criterion in order to facilitate an assignment of the transaction parties via the data records in the transaction pool.
  • location dependent services describes methods in which the location information can be transmitted and evaluated by mobile phone users.
  • the processing agency can request the input of additional features, e.g. through an IVR (Interactive Voice Response) system, ask the payer to enter the last four digits of the recipient's cell phone number.
  • IVR Interactive Voice Response
  • a transaction entity which can be comprised by or connected to the settlement entity.
  • This transaction instance checks whether it is possible to carry out the payment transaction. If the check is positive, the transaction is carried out.
  • the transaction to be initiated or carried out further includes at least the documentation of the conclusion of the contract, i.e. z. B. saving the data related to the transaction.
  • a telephone connection is established between the two transaction parties (provided that both transaction parties use a landline telephone or mobile phone). This variant is particularly useful if e.g. a payment transaction for a telephone consultation or the like is carried out and the service is provided directly via the telephone connection established. In the event that e.g.
  • a payment transaction is to take place using the mobile phones, the procedure has to be modified in such a way that the payment amount and the last four digits of the payer's mobile phone number are transmitted via DTMF tones within the connection sent by the transaction parties.
  • the DTMF tones could be filtered out by the switching system and forwarded to the settlement entity, or a temporary low-tone connection between the transaction parties and the settlement entity could be initiated.
  • a signaling entity which can be comprised by the processing entity or can be connected to it. If the test body fails the test, it passes it to both Parties an error message. This can be done, for example, by accepting the calls and making an acoustic announcement.
  • the signaling triggered by the signaling entity or via the data transmitted by the signaling entity can in particular allow the transaction parties to draw conclusions as to the status of the execution of transactions by the transaction entity (and the result of the checking entity).
  • the signaling entity transmits data to at least one of the transaction parties after the transaction has been carried out, which signals that the transaction has been carried out.
  • This signaling is advantageously implemented as follows:
  • both calls can be accepted by the processing center as soon as a final status is reached (i.e. an error has occurred or all preparatory check steps have been completed before the payment is made). If there is an error, there is a short announcement with the reason for the error (e.g. "Single amount limit exceeded” or "No corresponding payee is present") and the hang-up entity immediately hangs up. If the payment can be carried out, a longer announcement is made (eg "Payment of EUR 23.50 is now”), followed by an acoustic signal and then an optional account balance announcement.
  • This configuration has the following advantage: Unsuccessful transactions always lead to Connection times of, for example, 5 seconds or shorter, only successful transactions lead to connection times of, for example, 10 seconds or longer.
  • Embodiments of the method are also possible, in which the signaling generally takes place in that the signaling instance initiates a call back to at least one of the transaction parties.
  • This variant has the advantage that documents for the transactions carried out are also recorded in the individual connection records of the operator of the signaling instance or processing instance.
  • This variant using a callback can in turn be designed in such a way that time intervals of different lengths lie between the transition of different call setup signals and / or call release signals. For example, the callback can take place after 10 seconds for a successful transaction, after 20 seconds for an unsuccessful transaction, or the callback can take place immediately in both cases, and in the case of a successful transaction, a longer announcement (before hanging up by the signaling or processing authority) than in the case of an unsuccessful transaction.
  • ANI special caller number
  • the variant can advantageously be designed using a callback and, if necessary, using a special caller number such that the callbacks originating from the processing entity are only signaled in the telecommunications devices of the transaction parties, but are not accepted by them.
  • the advantage of this configuration is that theoretically no telecommunication costs arise at all.
  • the transmission of the acoustic signal or the signaling described above is carried out exactly synchronously to both transaction parties and additionally in particular exactly at the moment when the actual payment process takes place logically (expressed in IT terminology: the moment in which the transaction is committed, which is the actual payment transaction).
  • IT terminology the moment in which the transaction is committed, which is the actual payment transaction.
  • connection duration of a successful transaction is longer than that of an unsuccessful transaction has the advantage that hanging up a transaction partner prematurely means that the transaction is terminated and the "commit" of the actual payment transaction is not carried out
  • the above-described effect on the individual connection records is ruled out by hanging up early (such manipulation would be possible if long connection times were an indicator of unsuccessful and short connection times an indicator of successful transactions.)
  • the signaling is carried out by the call by lifting the settlement instance is accepted or is not accepted by signaling a dial tone or a busy signal or another signal is signaled or that there are different time intervals between the transition of different call setup signals and / or call reduction signals.
  • the method could work in such a way that, in the case of a successful transaction, a three-digit dial tone signal is generated before a busy signal occurs, whereas in the case of an unsuccessful transaction, a busy signal already occurs after a dial tone signal.
  • a three-digit dial tone signal is generated before a busy signal occurs, whereas in the case of an unsuccessful transaction, a busy signal already occurs after a dial tone signal.
  • the method could also work, for example, in such a way that the signaling alternatively to or combined with dial tone or busy signals via other toll-free announcements, e.g. "No connection under this number” or special new toll-free announcements to be introduced.
  • the probability of complaints and the general risk of misuse can be reduced in all accounting variants by combining information about past transactions with the signaling of the transaction success to the transaction parties. This means, for example, that after each transaction a brief announcement of the credit of the "Stored Value Account” or the sum of the individual transactions aggregated since the last settlement can be made. In addition, security is increased by announcing the date and amount of the last previous transaction ,
  • the transmission of the data and / or signaling could be wholly or partly by multi-frequency tones ( ⁇ TMF) and / or IVR systems (Interative Voice Response) and / or via speech recognition systems and / or by voice and / or via SMS text messages and / or via the USSD protocol (Unstructured Supplementary Services Data) and / or via the WAP protocol (Wireless Application Protocol) and / or via the GPRS protocol (GSM Packet Radio Service) of the GSM standard and / or a comparable protocol of another mobile radio standard and / or using the i-mode protocol and / or using a Java and / or SIM application toolkit application and / or using the Use of a Bluetooth interface and / or an infrared interface.
  • ⁇ TMF multi-frequency tones
  • IVR systems Interative Voice Response
  • speech recognition systems and / or by voice and / or via SMS text messages and / or via the USSD protocol (Unstructured Supplementary Services Data) and / or via the WAP protocol (Wire
  • a disadvantage of using DTMF tones, IVR systems, speech recognition systems, voice and SMS messages is the longer processing time compared to data transmission as part of the number of a telephone call.
  • Disadvantages of using the USSD protocol are the inconsistent implementation of status messages in various end devices and the fact that USSD (in the USSD Stage 2 variant) is not used by all mobile network operators is supported as well as the fact that an implementation by a provider independent of the mobile network operator is not easily possible.
  • a disadvantage of the use of WAP, GPRS, i-Mode, Java, SIM application toolkit and similar processes is that - provided there is no end device exchange and, if necessary, a change in the mobile network operator or a change in tariff - it is based on the status technology can only be used by a relatively small or very small number of mobile phone users.
  • cüi ⁇ can transmit the data and / or signaling in whole or in part via a computer network and / or via the Internet and / or by email and / or by calling up a web service and / or by using the HTTP and / or XML protocol and / or using a Bluetooth interface and / or an infrared interface and / or a wireless LAN and / or using a digital or analog modem and / or using another transfer procedure.
  • the method according to the invention relates in particular to payment transactions.
  • the declarations of intent are generally directed at least to the execution of a payment transaction relating to monetary or value units.
  • Value units can e.g. or in particular bonus points in discount systems, "status miles" or the like.
  • bonus points or the like can also be booked in parallel with payment transactions relating to monetary units.
  • the transaction consists at least in initiating or carrying out a payment transaction relating to money or value units.
  • the transaction entity then processes The transaction transaction can be further processed by the transaction instance by means of authentication and / or aggregation and / or forwarded to other processing instances online or offline at the same time or with a delay.
  • individual transactions can be collected on the part of the payer or recipient and will only be debited or credited to a bank account or credit card as a total monthly amount. In this case, the collective orders will be sent to banks or Credit card companies forwarded as further processing instances. Alternatively, individual transactions (especially for larger amounts) can also be forwarded to credit card companies for online authorization.
  • the transmitted data in the case of a payment transaction, contain the amount of money or value units to be paid.
  • the probability of errors is reduced and the reliability of detection is increased.
  • the amount is usually only activated by one of the transaction parties specified and only passively confirmed by the other transaction party, for example after being shown on the mobile phone display or after an acoustic announcement of the amount. This makes it easy to make a mistake about the authorized amount. For example, with the Paybox method it can occur that the amount announced only acoustically is not understandable or is incorrectly understandable due to a bad radio connection or loud ambient noise.
  • a payment assignment reference code is additionally transmitted, which enables or facilitates the clear assignment of the transaction parties.
  • the payment amount could not be transmitted in plain text, but rather as an encrypted sequence of digits and / or a check digit or check digit sequence could be added.
  • the payment amount is determined by actively entering the amount and not by passive confirmation of a displayed or announced amount. This advantageously leads to a reduction in the probability of error.
  • additional features to be queried which enable the transaction to be recorded or sub-grouped separately, e.g. with an announcement such as "Press 1 for a private payment, 2 for a business payment".
  • additional authorization features can also be queried using other methods, e.g. biometric procedures such as voice comparisons (voice sampling) are carried out.
  • Criteria can automatically transfer small amounts directly against a “Stored Value
  • a different type of signaling and confirmation of the transaction depending on the amount. For example, in the case of higher amounts after the transaction has been completed, an SMS will be sent to confirm.
  • the transaction parties comprise a payer or a telephone of the payer and a payee or a telephone of the payee.
  • the steps are carried out so that: a) the payer initiates a telephone call to the processing entity, the telephone number dialed in this case containing a sequence of digits which corresponds to the payment amount, b) the payee transmits data to the processing entity simultaneously or promptly when the payer calls, which contain the payment amount, c) a reviewing body checks whether the data transmitted by the payer and the payee can be clearly assigned to each other and at least the payment amounts contained match, d) a transaction instance checks whether the transmitted data can be used to identify and / or legitimize the payer and The recipient of the payment is possible and / or whether the processing of the payment transaction is possible e1) if the checking authority and the transaction instance are positive, the transaction instance carries out or initiates further processing, - the call of the payer is accepted by a signaling authority and, if applicable,
  • the steps are carried out so that: a) the data of the payee to the processing institution is also carried out by the fact that the payee initiates a telephone call to the processing institution, the telephone number dialed in this case containing a sequence of digits which corresponds to the The amount of the payment corresponds to b1) in the event of a positive test of the test authority and transaction authority after the
  • the confirmation signal is transmitted to the payee by also calling the payee from the
  • the settlement instance or the transaction instance are advantageously included or operated by a telecommunications provider.
  • One advantage of the above-described configuration of the method is that the payment processes can be very easily integrated into the billing systems of the telephone or mobile radio providers. The processing of the payment transactions advantageously takes place together with the billing of the telecommunication services.
  • the method according to the invention also has the advantage that an individual connection proof of the telephone or mobile telephone bill of the telecommunications provider can serve directly as proof of payment and proof without further modification. This leads to a reduction in costs, since there is no need to create and send a separate invoice. An entry for an outgoing call to telephone number "0800-55555-2350-4567" of 11 seconds in length could therefore serve as proof of a received payment in the amount of EUR 23.50.
  • Advantageous in the property according to the invention that is, both transaction parties make a call to the processing authority initiate is that a document exists for each of the transaction parties. Please note that calls to free numbers that begin with 0800, for example, are usually not recorded in the caller's individual connection record.
  • an announcement or other signaling and / or a PIN query or another query to confirm the transaction is carried out before the transaction is carried out.
  • the feedback of the signaling entity about the transaction carried out can preferably be secured against misuse by the fact that a clear booking reference code or a cryptographically signed confirmation message, e.g. is sent by email or SMS.
  • the method could e.g. can also be implemented in such a way that the call is accepted by the processing instance by lifting off only in the event of a successful transaction and a dial tone and / or busy signal is signaled in the event of an unsuccessful transaction.
  • This variant would have the advantage that transactions generally (and only) lead to entries in itemized records if they are successful.
  • the signaling instance could advantageously be called back to one or all of the transaction parties combined with an acoustic announcement of the cause of the error.
  • the cause of the error can e.g. be sent by SMS.
  • the system according to the invention for initiating and / or executing a transaction related to at least two corresponding declarations of intent, in particular a payment transaction comprises a first communication device that is assigned to a first transaction party, a second communication device that is assigned to a second transaction party, and a settlement administration with which data can be received from the communication devices.
  • the settlement body includes a review body or is linked to a review body. It can be used to check whether an assignment of the transaction parties is possible on the basis of data transmitted by the communication devices within a limited time window.
  • a computer system for initiating and / or executing a payment transaction is provided.
  • the computer system relates in particular to an embodiment of the processing entity mentioned above.
  • the computer system includes an input for receiving data from a first and a second communication device, the data containing features that allow an assignment of two corresponding declarations of intent.
  • a transaction pool memory is connected to the input, which temporarily stores incoming data within a time interval.
  • a test instance is connected to the transaction pool memory, with which the data stored in the transaction pool memory can be analyzed in such a way that at least identifiers of the first and second communication devices and an amount to be paid can be obtained and whether an assignment of the transaction parties can be checked on the basis of the transmitted data is possible and whether the respective declarations of intent correspond.
  • a transaction instance is connected to the verifier, with which, if the verification is positive, the data obtained in the verifier can be converted into payment instruction data. Finally, an exit is connected to the transaction instance, via which the payment instruction data can be transmitted to a payment processing instance.
  • a signaling instance is connected to the transaction instance and the output, with which, depending on the checking of the checking entity and / or on the transmission of the payment instruction data, signaling about the initiation and / or execution of the payment transaction to at least one communication device or are transferable to other recipients.
  • the transaction instance can also comprise an account management instance or be directly connected to an account management instance. If the billing e.g. Via a "Stored Value Account", i.e. a prepaid credit takes place, the "Settlement", i.e. the execution of the payment process can be carried out particularly efficiently, quickly and risk-free, since no communication connection to an external processing entity is necessary, no extensive transaction histories have to be managed and a credit, collection and charge-back risk is excluded.
  • the communication devices are, in particular, a landline telephone and / or a cell phone.
  • the invention comprises a computer program with program code means to carry out all the steps of the above-mentioned embodiments of the method according to the invention when the program is executed on a computer.
  • the invention encompasses a computer program product with program code means, which are stored on a computer-readable data carrier, for the various To implement configurations of the above-mentioned method when the program product is executed on a computer.
  • FIG. 1 shows a graph to explain the first exemplary embodiment of the method according to the invention
  • the transaction parties comprise a payer 1 (or a communication device of the payer) and a payee 2 (or a communication device of the payee).
  • the payer 1 initiates a telephone call 5 to the processing instance 3.
  • the telephone number dialed in this case contains a sequence of digits 7 which corresponds to the payment amount.
  • the payee 2 transmits data to the processing instance 3 which contain the payment amount 7.
  • the time interval is in a range between 10 sec. And 30 sec. B. 20 sec.
  • the payee 2 transmits a payment assignment reference code 8 to the processing instance 3, which is formed according to a certain rule from the number 12 of the payer 1 (e.g.
  • a test authority 9 checks whether the data transmitted by payer 1 and payee 2 can be clearly assigned to one another and at least the payment amounts 7 contained match.
  • a transaction instance 10 checks whether an identification and / or legitimation of the payer 1 and the payee 2 is possible on the basis of the transmitted data and / or whether the processing of the payment process is possible.
  • the transaction instance 10 checks in the next step whether it is possible to carry out the payment. This depends in particular on the amount and the creditworthiness of the payer. If, for example, the current payment amount or an aggregate sum of payment amounts exceeds a limit (which depends, for example, on the creditworthiness of the payer), the transaction entity 10 can reject the execution or further processing of the payment transaction or carry out an additional legitimation check by requesting a further authorization feature (e.g.
  • the transaction entity 10 can request a further confirmation (also, for example, by simply pressing a button and transmitting a DTMF tone) before the execution of the transaction under certain conditions, for example from a certain amount. Furthermore, it is also possible, for example, that under certain conditions, such as, for example, from a certain amount before the transaction is carried out, the amount is explicitly announced again and the confirmation is then requested.
  • test entity 9 and the transaction entity 10 test positive, the transaction entity 10 carries out the further processing of the payment or initiates (or initiates) the payment.
  • the call from the payer 1 is accepted by the signaling instance 11 and, if necessary, an acoustic announcement is made, which shows that the payment has been made.
  • a confirmation signal about the payment made is transmitted to the payee 2.
  • the call of the payer 1 will not be accepted by the processing instance 3 or will be accepted with a delay and / or an acoustic announcement will be made, which indicates that the payment has not been made.
  • the transmission of the data of the payee 2 to the processing instance 3 also takes place in that the payee makes a telephone call 6 to the
  • Call 6 of the payee is accepted by the signaling instance 11 and, if necessary, an acoustic announcement is made, which shows that the payment has been made.
  • Payee 2 is not accepted or accepted with a delay and / or an acoustic announcement is made, from which it follows that the payment has not been made.
  • the execution of a payment transaction is to be explained using a detailed example:
  • Party A (1) with a mobile phone with the mobile phone number 0171-1234567 (12) would like to give party B (2) with a mobile phone with the mobile phone number 0171-9876543 (13) an amount of EUR 23.50 (7) numbers.
  • party A gives party B the last four digits of its mobile number (8), ie “4567” with (4).
  • A dials the number 0800-55555-2350 with its mobile phone (5).
  • B dials almost the same line on his mobile phone to 0800-55555-2350-4567 (6). If the payment is successful, the calls are accepted and A and B receive a short acoustic announcement "Payment has been made".
  • the method can also be designed in such a way that the payer does not disclose the last four digits of his mobile phone number to the payee and the payee transmits these - as part of the phone number - to the processing authority, but vice versa, i.e. that the payee discloses the last four digits of his mobile phone number to the payer and that the payer transmits these - as part of the phone number - to the processing authority.
  • Both variants can also be combined, i.e. the payer and the payee disclose the last two digits of their respective mobile phone numbers to each other and transmit the two digits received from the other party - as part of the phone number - to the processing authority.
  • Settlement instance 3 can be reached on the head number 0800-55555.
  • the incoming calls are registered by the processing instance 3.
  • the mobile phone numbers 12 and 13 of the callers (MSISDN or ANI) are automatically transmitted.
  • the significant portions "2350" (7) and "23504567” (T and 8 ') are extracted from the dialed numbers (DNIS).
  • the transaction records are assigned to a transaction pool Transactions discontinued.
  • the data records are deleted again from the transaction pool for which no other data record to be assigned was / is found within the time interval, that is to say for example within 20 seconds.
  • the checking entity 9 which includes the processing instance 3 or can be connected to it, checks whether an assignment of the transaction parties 1 and 2 is possible on the basis of the transmitted data. In the current example of the payment transaction, this also results in a check as to whether the respective declarations of intent correspond. This is done by comparing the data records in the transaction pool to match the “amount” and “short transmitter identifier” fields (7 and 8 versus 7 'and 8'). Since the quasi-simultaneity, as an additional criterion, means that the transaction pool is always very small, even with a high transaction load, it is very likely that an assignment based on the criteria "amount” and "short transmitter identifier" is possible.
  • the processing entity 3 will request the entry of additional characteristics, e.g. ask payer 1 via an IVR system (Interactive Voice Response) to also enter the last four digits of the recipient's mobile phone number.
  • IVR system Interactive Voice Response
  • the mobile phone numbers of the callers (MSISDN or ANI) are transmitted automatically, which simplifies the process and provides protection against misuse.
  • This transmission can e.g. can be achieved through a special circuit of the telecommunications provider on the part of the processing authority, which makes it possible to also display those caller numbers whose display is normally suppressed. This has the advantage that even callers with standard phone number suppression can use the system in individual cases without changing the display mode.
  • the method can also be designed in such a way that when calling mobile phones with suppressed caller ID, e.g.
  • An IVR system queries identification features (e.g. the mobile phone number in conjunction with a PIN or a free customer number that is not corrected for a mobile phone number).
  • identification features e.g. the mobile phone number in conjunction with a PIN or a free customer number that is not corrected for a mobile phone number.
  • the provider's computer system transmits an identifier of one's own identity 13, the amount T and the last four digits 8 'of the cell phone number 12 of the payer.
  • the return signaling from the signaling instance 11 to the computer system of the provider can in turn take place via an HTTP response or the return value of the web service.
  • the data transmission between the computer system and the processing entity 3 or signaling entity 11 is advantageously additionally secured by cryptographic methods.
  • a third exemplary embodiment for the execution and documentation of a contract conclusion, combined with the execution of a payment transaction, is described below.
  • the third embodiment works analogously to the e-commerce scenario of the second embodiment described above. It concerns a payment transaction on the Internet in which a payer makes a payment to, for example, a provider of goods or services. In addition to the pure payment from the payer to the provider, a purchase or service contract between provider and payer should also be concluded and documented in this example. In the following, the payer is therefore referred to as the payer / buyer.
  • a digital impression is formed from the content of the contract, e.g. via a hash algorithm like MD5.
  • the digital impression can e.g. also consist of a checksum or checksum or contain part of the credit card number or the so-called CVC code additionally assigned to the credit card number.
  • the digital impression is advantageously limited to a relatively short, e.g. six-digit sequence of digits (e.g. "141516") reduced. This six-digit sequence of digits is displayed to the payer / buyer on the website and / or sent to the payer / buyer by e-mail, for example.
  • the content of the contract can also be saved and recorded permanently, for example by sending an email to the payer / buyer with the terms of the contract, which contains a reference number of the contract in the email.
  • the reference number can also consist, for example, of a six-digit sequence of digits (for example “949596”) and advantageously also include the date, time or other data.
  • the payer / buyer now also transmits the reference number to the processing instance (in addition to the amount), for example by adding six numbers to the dialed number ("0800-55555-2350”), ie " 0800-55555-2350-949596 "dials.
  • the digital impression can also be transmitted, for example as part of the phone number, by dialing "0800-55555-2350-141516".
  • both the digital impression and the reference number can be transmitted.
  • the transmission of the payment amount can also be dispensed with.
  • the payment-specific part of the described method can also be omitted and the method can only be used for the implementation and / or documentation of the conclusion of the contract.
  • the payment can be made via a conventional credit card and the credit card payment including the credit card data can be part of the concluded contract. All or part of all data can also be transmitted via DTMF tones or via SMS or another method.
  • a high level of documentation and proof of the contract concluded is achieved through the process designs shown. Because the data transfer of the digital impression (digest) and / or the reference number takes place parallel to the Internet via the user's mobile phone, the data as a whole is protected against manipulation on the Internet.
  • the above-described document function of the individual connection verification of the telecommunications provider can be used.
  • the billing functionality can be implemented, for example, simply by the call, via which the payment transaction is carried out, being rated directly with the amount contained in the telephone number, provided the connection duration was, for example, longer than 10 seconds.
  • a connection to the phone number 0800-55555-2350, for example 11 seconds long, would then be charged with an amount of EUR 23.50, a connection to the phone number 0800-55555-2350-4567, for example 11 seconds in length with a credit amount of EUR 23.50.
  • This functionality could be implemented with minimal software updates in the accounting systems. Only a few additional technical devices or interfaces would have to be created. The process advantageously works symmetrically for both payers and receivers - in contrast to conventional processes, in which different systems and interfaces are used on the receiver side than on payment soap.
  • a fourth exemplary embodiment is explained below with reference to FIG. 3.
  • This exemplary embodiment relates to an implementation variant which is particularly suitable for use in POS (point-of-sale) cash register systems which, as a rule, instead of an Internet connection, only via landline telephone connections for the communication of credit card terminals or comparable devices an authorization center.
  • the customer informs the cashier of the last four digits 8 of his cell phone number 12. This is entered by the cashier in a cash register or a credit card terminal 16 or a comparable device (hereinafter referred to as "terminal") and transferred from the terminal to a connected or integrated landline or mobile radio modem which initiates a telephone call to the processing authority and dialing "0800-55555-2350-4567" as the telephone number in the first exemplary embodiment. If the method variant of the first exemplary embodiment described above is used, in which a minimum duration of the connection is indicative of a successful transaction, it is sufficient for the terminal to decide whether the payment was successful, in principle only checking whether the modem connection is longer than the minimum duration duration.
  • the processing of the method can be greatly accelerated compared to protocols in which a time-consuming modem protocol connection is established. This also leads to a reduction in telecommunications costs.
  • a more detailed feedback from the processing authority to the cash register system in the event of an error is generally not necessary, since the payer or customer in turn receives acoustic feedback about the cause of the error.
  • the payer and recipient receive an incoming call from the signaling entity, the special caller number “0800-55555-2350” being generated by the signaling entity as the caller number (ANI), provided that the payment has been made, or “0800 - 55555-0000 "if payment cannot be made. From the caller number shown on the display, payers and recipients can see whether the payment was successful or not.
  • the entry advantageously remains stored in the caller list of the mobile telephone, which enables it to be checked again later. The faster and safer short transmission time is advantageous compared to signaling by sending an SMS.
  • a telephone connection is established between the two transaction parties (provided that both transaction parties use a landline telephone or a mobile phone).
  • This variant is particularly useful if e.g. a payment transaction for a telephone consultation or the like is carried out and the service is provided directly via the telephone connection established.
  • the procedure described in the first example could be modified so that the payment amount and the last four digits of the payer's mobile phone number are transmitted via DTMF tones which are sent within the connection by the transaction parties.
  • the DTMF tones could be filtered out by the switching system and forwarded to the settlement entity, or a temporary telephone connection between the transaction parties and the settlement entity could be initiated.
  • the mobile telephones 1 and 2 of a payer and a payee send the telephone calls 5 and 6 to the computer system promptly.
  • the phone numbers used for the selection contain the amount 7 or T for the payment transaction.
  • a telephone number also contains a reference 8 'to the telephone number of the other.
  • the computer system is integrated, for example, in a system of the telecommunications provider. It has an input 18 which contains the dialed telephone numbers of can record incoming calls without having to answer calls 5 and 6 immediately. The input 18 forwards this data into a transaction pool memory 19.
  • a test entity 9 is connected to the transaction pool memory 19.
  • the latter checks whether another data record of the transaction pool memory 19 can be assigned to this data record. For this purpose, it extracts from a call at least the identifier of the caller who made the call, and from the dialing number the amount to be paid and, if appropriate, the payment assignment reference code 8 '.
  • the test instinct 9 checks whether the identifiers of the telephones via which the calls 5 and 6 have been made are stored in a database of the computer system. This enables the computer system to establish a connection to registered users and their data for the payment transaction. For example, the account details or credit card numbers can be determined for the users.
  • the test entity 9 checks whether the declarations of intent contained in the calls correspond.
  • the checking unit 9 checks whether the payment assignment reference code 8 ′ actually corresponds to the last 4 digits of the telephone number of the other call 5. If all checks are positive, the checking entity 9 transmits the data to the transaction entity 10 connected to it and the data records are removed from the transaction pool memory 19.
  • the transaction pool memory 19 thus comprises a database in which incoming calls are stored in a timely manner and which can be used to check whether new data records can be assigned to one another.
  • the transaction entity 10 can convert this data into payment instruction data 21. These are, for example, instructions for direct debit from a payer's account and, in parallel, transferring a certain amount to a payee's account.
  • the transaction entity 10 transmits the payment instruction data 21, for example, via an internet connection to the bank of the processing entity or the banks of the payer and the payee.
  • an output 20 is provided in the computer system.
  • Signaling entity 11 may be connected. In the event that payment instruction data 21 have been transmitted, the signaling entity 11 sends signaling 22 via the
  • the signaling 22 can also be sent to other recipients, for example stored email addresses of the payer and the payee.
  • the signaling instance 11 can also send signaling signals 22 about a transaction that has not taken place.
  • the signaling 22 can be sent even if the test of the test entity 9 was positive. The signaling 22 can take place as explained with reference to the first exemplary embodiments.
  • the payer and the payee only have to make two entries:
  • the payer provides the payee with part of his telephone number.
  • the latter starts a payment application on his mobile phone 2 and enters this part 8 of the telephone number into his mobile phone 2.
  • the payer also starts the payment transaction application on his mobile phone 1.
  • Both parties then enter the amount to be paid 7 or T in the application of the mobile phones 1, 2 and essentially simultaneously press a key to start the payment transaction.
  • the applications on mobile phones 1 and 2 then automatically generate telephone numbers 5 and 6 and send them to the computer system.
  • the computer system then initiates the payment transaction by transmitting payment instruction data 21 to the payer's bank.
  • the payment transaction is also documented by the computer system.

Abstract

Die vorliegende Erfindung betrifft ein Verfahren und ein System zum Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion, insbesondere einer Zahlungstransaktion, zwischen mindestens zwei Transaktionsparteien über eine Abwicklungsinstanz (3), bei dem mindestens eine der Transaktionsparteien ein Festnetztelefon oder Mobiltelefon (1, 2) oder ein mobiles Kommunikationsgerät zur Übermittlung von Daten benutzt. Das Verfahren ist dadurch gekennzeichnet, dass mindestens zwei der Transaktionsparteien Daten an die Abwicklungsinstanz übermitteln, wobei die Übermittlung der Daten innerhalb eines begrenzten Zeitfensters erfolgt, und dass die Initiierung der Datenübermittlung dieser Transaktionsparteien aktiv durch die Transaktionsparteien und nicht durch die Abwicklungsinstanz (3) erfolgt, wobei die bei der Initiierung übertragenen Daten Merkmale enthalten, die die Zuordnung der Willenserklärungen untereinander ermöglichen.

Description

Verfahren und System zum Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion
Die vorliegende Erfindung betrifft ein Verfahren und ein System zum Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion, insbesondere einer Zahlungstransaktion, zwischen mindestens zwei Transaktionsparteien über eine Abwicklungsinstanz, bei dem mindestens eine der Transaktionsparteien ein Festnetztelefon oder Mobiltelefon oder ein mobiles Kommunikationsgerät zur Übermittlung von Daten benutzt. Zahlungstransaktionen stellen aufgrund ihrer Häufigkeit und wirtschaftlichen Bedeutung das hauptsächliche Anwendungsgebiet der vorliegenden Erfindung dar.
Es sind eine Vielzahl von Verfahren zur Durchführung von Zahlungstransaktionen mit Hilfe von Mobiltelefonen bekannt. Die Vorteile dieser Verfahren sind z.B. in der DE19903822 beschrieben. Diese Verfahren sind in der Regel so ausgestaltet, dass die Transaktionsparteien mit einer Abwicklungsinstanz und ggf. untereinander Daten austauschen.
Hierbei ist zu unterscheiden zwischen zwei Verfahrenstypen, die im folgenden als „standardkompatible Verfahren des Typs A" und „zukunftsabhängige Verfahren des Typs B" bezeichnet werden sollen. „Standardkompatible Verfahren des Typs A" bezieht sich auf solche Verfahren, die innerhalb der gesamten gegenwärtigen „Installed Base" von Mobiltelefonen einsetzbar sind (d.h. mit allen oder dem überwiegenden Teil der nach dem Stand der Technik verbreiteten Mobiltelefone/SIM-Modul-Chipkarten), ohne dass ein Austausch oder technische Modifikationen der Mobiltelefone oder der SIM-Modul-Chipkarten nötig wird. „Zukunftsabhängige Verfahren des Typs B" bezieht sich auf solche Verfahren, die nur mit speziellen Mobiltelefonen oder SIM-Modulen (in der Regel neueren Typs) eingesetzt werden können, welche erst in geringer Stückzahl auf dem Markt verbreitet sind oder erst in Zukunft auf den Markt kommen werden.
Bei den zukunftsabhängigen Verfahren des Typs B geschieht der Datenaustausch zumindest einer Transaktionspartei in der Regel über Protokolle bzw. Verfahren wie WAP (Wireless Application Protocol) oder i-Mode (überwiegend in Japan verbreitet) sowie über lokal auf den Mobiltelefonen oder den SIM-Modul-Chipkarten ausgeführten Java- oder SIM-Application- Toolkit-Applikationen, wobei der Datenaustausch z.B. über GPRS (GSM Packet Radio Service) geschieht. Nachteilig an den zukunftsabhängigen Verfahren des Typs B ist, dass sie von der Verbreitung und dem Erfolg der zugrunde liegenden technologischen Basis abhängig sind. Ein Betreiber, der ein solches Verfahren einführen möchte, steht vor der Wahl, sich auf eine sehr kleine potentielle Nutzerbasis zu stützen oder potentielle Nutzer (z.B. durch Subventionen) dazu zu bewegen, sich neue Mobiltelefon-Endgeräte anzuschaffen. Dies stellt eine sehr große Hürde für die Einführung eines solchen Verfahrens dar.
Weiterhin nachteilig an den zukunftsabhängigen Verfahren des Typs B ist, dass sie in der Regel nur in Mobilfunk-Netzen mit einem bestimmten Standard (wie z.B. GSM) sowie nicht mit einfachen Festnet∑telefonen einsetzbar sind. Bei den standardkompatiblen Verfahren des Typs A geschieht der Datenaustausch zumindest einer Transaktionspartei in der Regel über eine stehende Telefonverbindung mit Sprachansagen (z.B. durch ein IVR-System (Interactive Voice Response)) und DTMF-Ton- Übermittlung (Dual Tone Multi Frequency) oder per SMS (Short Message System). In der Regel erfolgt bei diesen Verfahren die Übermittlung der vollständigen Mobiltelefon-Nummer (ANI bzw. MSISDN) oder eines eindeutigen Alias vom Zahler bzw. Empänger an den Empfänger bzw. Zahler, die Übermittlung eines dauerhaft gültigen PIN-Codes vom Zahler an eine Abwicklungsinstanz zur Autorisierung und ggf. die Übermittlung von einmal gültigen TAN-Codes als Autorisisierungs- oder Zahlungsnachweis von der Abwicklungsinstanz zum Zahler und vom Zahler zum Empfänger. Eines dieser Verfahren, das sogenannte Paybox-Verfahren, ist als zweites Ausführungsbeispiel der DE 19903822 bekannt. Dieses Verfahren soll beispielhaft als Vertreter eines standardkompatiblen Verfahren des Typs A kurz dargestellt werden:
Der Zahler (im folgenden Z genannt) übermittelt zunächst mündlich seine Mobiltelefon- Nummer (ANI bzw. MSISDN) oder einen der Mobiltelefon-Nummer eindeutig zugeordneten Alias an den Empfänger (E). Daraufhin übermittelt E an die Abwicklungsinstanz (AI) über einen Anruf seines Mobiltelefons implizit seine eigene Mobiltelefon-Nummer und explizit per DTMF-Ton-Übermittlung die Mobiltelefon-Nummer von Z, sowie den zu zahlenden Betrag. (Die Telefonverbindung von E zur AI bleibt dabei bis zum letzten Schritt bestehen). Die Abwicklungsinstanz prüft daraufhin, ob Z ein zugelassener Teilnehmer ist und ob die Bonität- von Z zur Zahlung des Betrages ausreicht. Daraufhin initiiert die AI einen Anruf auf die Mobiltelefon-Nummer von Z. Z nimmt den Anruf an. Ein Sprachcomputer der AI erzeugt eine akustische Ansage der Zahlungsinformationen (Empfänger, Zahlungsbetrag). Zur Bestätigung und Autorisierung der Zahlung gibt Z per DTMF-Ton-Übermittlung einen PIN- Code ein. Nach erfolgreicher Autorisierung übermittelt die AI an E über die noch bestehende Telefonverbindung akustisch eine Bestätigung der Zahlung. Nachteilig an dem Paybox-Verfahren sind vor allem die hohen Telekommunikationskosten und die lange Abwicklungsdauer.
Im Paybox-Verfahren dauert der Anruf von E an die AI und die Übermittlung der Daten ca. 30 Sekunden. Etwa gleich lange dauert auch der danach erfolgende Anruf der AI an Z inklusive Ansage der Zahlungsinformationen und Abfrage der Autorisierungs-PIN. Während des zweiten Anrufs bleibt die Verbindung des ersten Anrufs bestehen. Insgesamt entstehen so Telekommunikationskosten für 90 Sekunden Mobiltelefon-Verbindungen. Sofern die Abwicklung über eine kostenfreie Rufnummer erfolgt und der Betreiber der AI die Telekommunikationskosten trägt, entstehen ihm nach dem Stand der Technik dadurch Kosten von ca. 30 Euro-Cent
Dadurch ist die Anwendung des Paybox-Verfahrens für kleinpreisige Zahlungstransaktionen in der Regel nicht wirtschaftlich.
Im Paybox-Verfahren dauert die Abwicklung der Transaktion insgesamt ca. 75 Sekunden.
Dadurch ist die Anwendung dieses Verfahrens in allen zeitkritischen Mobile-Commerce- Einsatzszenarien wie z.B. bei Zahlungen an Kassen im Einzelhandel sehr problematisch.
Die am Beispiel des Paybox-Verfahrens veranschaulichten Nachteile gelten in ähnlicher Form für viele andere standardkompatible Verfahren des Typs A.
So bleibt z.B. die Zeitrestriktion auch bei Einsatz eines alternativen Übertragungsverfahrens wie SMS bestehen. So ist z.B. die Zustellgeschwindigkeit einer SMS nicht gesichert und beträgt oft mehr als 30 Sekunden, im Einzelfall deutlich länger. Hinzu kommt (je nach Verfahren) die Zeit für die Eingabe und das Versenden einer SMS. (Gleiches gilt auch bei bestimmten zukunftsabhängigen Verfahren des Typs B, z.B. Einsatz des WAP-Protokolls - die Dauer von Verbindungsaufbau, Navigation und Dateneingabe sind zu lang für einen Einsatz in zeitkritischen Mobile-Commerce-Szenarien). Weiterhin nachteilig an den genannten standardkompatiblen Verfahren des Typs A ist die Tatsache, dass in der Regel die vollständige Mobiltelefon-Nummer des Zahlers bzw. des Empfängers gegenüber dem Empfänger bzw. Zahler offen gelegt werden müssen. Dadurch ist keine Anonymität der Transaktionsparteien untereinander gegeben. Durch Einsatz eines Rufnummem-Alias (wie z.B. im Paybox-Verfahren) ist zwar eine teilweise Anonymität hinsichtlich der tatsächlichen Mobiltelefon-Nummer des Teilnehmers gegeben, dennoch ist eine prinzipiell eindeutige Identität einer Transaktionspartei der anderen Transaktionspartei bekannt.
Weiterhin nachteilig an der Verwendung der vollständigen Mobiltelefon-Nummer oder des Rufnummem-Alias ist deren Länge (in der Regel 12 Stellen) und die damit verbundene längere Eingabe- und Übertragungsdauer sowie die Wahrscheinlichkeit von Fehleingaben. Weiterhin nachteilig an den genannten standardkompatiblen Verfahren des Typs A ist die geringe Beweissicherheit bzw. das Risiko der Abstreitbarkeit für Zahler, Empfänger und Betreiber der Abwicklungsinstanz. Eine Möglichkeit zur Erhöhung dieser Beweissicherheit besteht in der Einschaltung einer „Trusted Third Party", d.h. einer von Zahler, Empfänger und Betreiber der Abwicklungsinstanz anenerkannten zusätzlichen Partei. Als eine solche zusätzliche Partei kommt insbesondere der Telekommunikations-Provider in Frage. Jedoch darf der Inhalt der innerhalb einer stehenden Telefon- oder WAP-Datenverbindung übertragenen Daten vom Telekommunikations-Provider aufgrund rechtlicher Bestimmungen in der Regel nicht protokolliert werden, ebenso wenig der Inhalt von versendeten SMS. Protokolliert werden daher in der Regel lediglich die Rufnummern der Kommunikationspartner, der Zeitpunkt und die Dauer der Kommunikation sowie die Menge der übertragenen Daten. Die Tatsache, dass eine Transaktion abgewickelt wurde, lässt sich so zwar grundsätzlich relativ gut beweisen. Sollte jedoch ein Streit über die Höhe des autorisierten Betrages entstehen, ist die Nachweisbarkeit problematisch. Aus diesem Grunde ist es bei Verfahren wie Paybox in der Regel notwendig, zur Reduzierung der Irrtumswahrscheinlichkeit und Vermeidung späterer Reklamationen z.B. eine SMS zur Bestätigung zu verschicken, wodurch weitere Kosten entstehen.
Weiterhin nachteilig an den genannten standardkompatiblen Verfahren des Typs A ist, dass ein Irrtum über den autorisierten Betrag leicht möglich ist. Dieses Risiko ergibt sich dadurch, dass der Betrag in der Regel nur von einer der Transaktionsparteien aktiv angegeben und von der anderen Transaktionspartei nur passiv bestätigt wird, z.B. nach Anzeige auf dem Mobiltelefon-Display oder nach einer akustischen Ansage der Betragshöhe.
Aus der DE 19946 539 A1 ist ein Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk bekannt. Die Zuordnung von Händler und Kunden in einem Payment-Gateway wird bei diesem Verfahren über eine temporäre IP-Adresse des Mobiltelefons des Kunden hergestellt. Diese IP-Adresse wird nämlich sowohl vom Kunden als auch vom Händler an den Payment-Gateway übertragen. Nachteilhaft an diesem Verfahren ist, dass ein Abgleich der temporären IP-Adresse des Mobilfunkteilnehmers zu seiner MSISDN über eine MSISDN- IP-Datenbank erfolgen muss, was den Einsatz des Verfahrens für einen mobilfunkbetreiberunabhängigen Payment-Gateway-Anbieter erschwert oder unmöglich macht. Weiterhin nachteilig an diesem Verfahren ist, dass der Kunde über ein WAP-fähiges Mobilfunkgerät verfügen muss, es sich somit nachteilhafterweise um ein „zukunflsabhängiges Verfahren des Typs B" (s.o.) handelt. Zusätzlich ist der Aufbau einer WAP-Internetverbindung sehr zeitaufwendig und das Verfahren somit für die meisten Bezahlszenarien nicht geeignet. Im Übrigen besitzt dieses Verfahren den Nachteil, dass ein relativ großer Datensatz, nämlich die temporäre IP-Adresse eines Mobilfunkteilnehmers, für die Zuordnung von Händler und Kunden übertragen werden muss. Schließlich ist die durchzuführende Zuordnung der bei dem Payment-Gateway eingehenden IP-Adressen aufwändig, da hierfür ggf. eine sehr große Anzahl an IP-Adressen verglichen werden muss.
Aus der EP 1 081 919 A1 ist schließlich ein Verfahren zur Autorisierung zur Bezahlung von im Inlernet angebotenen Waren bekannt. Hier erfolgt die Zuordnung von Kunde und Anbieter in einem Aulorisierungskomparator mittels eines Transaktionscodes, der vom Anbieter erzeugt und an den Kunden übertragen worden ist. Hiermit ergibt sich jedoch der Nachteil, dass der Umgang mit Transaktioncodes, die für beide Transaktionsparteien bei jeder Transaktion veränderlich sind, prinzipbedingt komplex ist. Daraus resultiert, dass die insgesamt dreifache Übermittlung des Transaktionscodes (vom Anbieter zum Autorisierungskomparator, vom Anbieter zum Kunden und vom Kunden weiter zum Autorisierungskomparator) sehr fehleranfällig ist. Zur Absicherung gegen einen Transaktionscode-Irrtum (und versehentlichem „Treffen" einer anderen offenen Transaktion), aber auch zur Absicherung gegen einen generellen Irrtum z.B. über den autorisierten Betrag ist daher eine nochmalige Rückfrage vom Autorisierungskomparator zum Kunden notwendig (siehe Spalte 8 Zeile 47-55 der Druckschrift), bevor die Transaktion durchgeführt werden kann. Dies verlangsamt und verteuert das Verfahren erheblich, so dass fast alle Nachteile des o.a. Paybox-Verfahrens auch für dieses Verfahren gelten. Ferner ist das Generieren eines zuverlässig eindeutigen Transaktionscodes so aufwändig, dass hierfür praktikablerweise ein spezieller Algorithmus im händlerseitigen Endgerät erforderlich ist, was eine Beschränkung auf z.B. java-fähige Mobiltelefone mit sich bringt. Auch hier handelt es sich somit nachteilhafterweise um ein „zukunftsabhängiges Verfahren des Typs B" (s.o). Schließlich ergibt sich auch hier der Nachteil, dass ein relativ großer Datensatz für die Zuordnung von Händler und Kunden übertragen werden muss und die durchzuführende Prüfung aufwändig ist, da ggf. eine sehr große Anzahl an Transaktionscodes verglichen werden muss.
Aufgabe der vorliegenden Erfindung ist es daher, ein Verfahren und ein System zum Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion, insbesondere einer Zahlungstransaktion, zwischen mindestens zwei Transaktionsparteien über eine Abwicklungsinstanz bereitzustellen, bei dem mindestens eine der Transaktionsparteien ein Festnetztelefon oder Mobiltelefon oder ein mobiles Kommunikationsgerät zur Übermittlung von Daten benutzt, welches die vorstehend beschriebenen Probleme löst. Dies bedeutet insbesondere, dass das Verfahren und das System mit allen oder dem überwiegenden Teil der nach dem Stand der Technik verbreiteten Mobiltelefone/SIM-Modul-Chipkarten, in Mobilfunk-Netzen mit unterschiedlichen Standards sowie mit einfachen Festnetzlelefonen einsetzbar sein soll, und ferner eine kurze Abwicklungsdauer, geringe Transaktionskosten, die Anonymität der Transaktionsparteien untereinander, eine niedrige Fehlerwahrscheinlichkeit sowie eine hohe Nachweissicherheit bereitstellen soll.
Diese Aufgabe wird durch das Verfahren nach Anspruch 1 und ein System nach Anspruch 26 bzw. 27 gelöst, wobei sich vorteilhafte Ausgestaltungen aus den Unteransprüchen ergeben.
Bei dem erfindungsgemäßen Verfahren übermitteln mindestens zwei der Transaktionsparteien Daten an die Abwicklungsinstanz, wobei die Übermittlung der Daten innerhalb eines begrenzten Zeitfensters (Zeitintervalls) erfolgt. Die Initiierung der Datenübermittlung dieser Transaktionsparteien erfolgt aktiv durch die Transaktionsparteien und nicht durch die Abwicklungsinstanz, wobei die bei der Initiierung übertragenen Daten Merkmale enthalten, die die Zuordnung der Willenserklärungen untereinander ermöglichen.
Das Merkmal der Initiierung der Datenübermittlung durch die Transaktionsparteien bedeutet, dass vor der erstmaligen Übermittlung von transaktionsrelevanten Daten von den Transaktionsparteien zur Abwicklungsinstanz keine Übermittlung von transaktionsrelevanten Daten von der Abwicklungsinstanz zu den Transaktionsparteien erfolgt.
Unter einer Instanz wird im Sinne der vorliegenden Erfindung insbesondere eine technische Einrichtung verstanden, wie z. B. eine Datenverarbeitungseinrichtung. Auf dieser Einrichtung können Anwendungsprogramme gespeichert sein, welche automatisch die Schritte des Verfahrens ausführen. Die Abwicklungsinstanz wird im Folgenden auch Computersystem genannt. Auf Seiten der Transaktionsparteien sind zur Datenübermittlung Festnetztelefone, Mobiltelefone und/oder Kommunikationsgeräte vorgesehen. Um das erfindungsgemäße Verfahren durchzuführen, reicht es aus, dass in diese Geräte Daten eingegeben werden, welche der Willenserklärung entsprechen. Bei einer Zahlungstransaktion reicht es beispielsweise aus, wenn der zu zahlende Betrag eingegeben wird. Die restlichen Daten, welche z. B. die Transaktionsparteien identifizieren, können in den Geräten gespeichert sein und automatisch an die Abwicklungsinstanz übertragen werden.
Allgemein dient das erfindungsgemäße Verfahren dem Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion. Die Willenserklärungen können insbesondere auf den Abschluss eines Vertrages gerichtet sein. Die in diesem Fall zu initiierende oder durchzuführende Transaktion ist dann die Durchführung des Vertragsabschlusses. Z. B. kann eine separat erfolgende herkömmliche Kreditkartenzahlung Gegenstand der Willenserklärung und/oder des Vertragsabschlusses sein.
Die Übermittlung der Daten erfolgt simultan oder innerhalb eines begrenzten Zeitfensters (Zeitintervalls). Durch die simultane und in Richtung von den Transaktionsparteien zur Abwicklungsinstanz erfolgende Datenübertragung werden Abwicklungsdauer und Transaktionskosten reduziert. Bei herkömmlichen Verfahren wie z.B. Paybox erfolgt in der Regel eine sequentielle Datenübertragung, bei einer Zahlungstransaktion z.B. erst vom Zahler zum Empfänger, dann vom Empfänger zur Abwicklungsinstanz, dann von der Abwicklungsinstanz zum Zahler, dann vom Zahler wieder zur Abwicklungsinstanz und von dieser wieder zum Empfänger.
Durch die simultane bzw. zeitnahe und aktiv von den Transaktionsparteien in Richtung zur Abwicklungsinstanz initiierte Datenübertragung wird ferner bewirkt, dass nur wenig Merkmals-Daten übermittelt werden müssen, um eine Zuordnung der Willenserklärungen und damit der Transaktionsparteien untereinander zu ermöglichen. Denn das schmale Zeitfenster beschränkt die Größe des Pools der einander zuzuordnenden Transaktionen. Durch die reduzierte Datenmenge wird einerseits eine weitere Vereinfachung und Beschleunigung der Abwicklung erreicht, andererseits die Anonymität der Transaktionsparteien untereinander ermöglicht. Durch die simultane bzw. zeitnahe Datenübertragung wird weiterhin eine Erhöhung der Sicherheit gegen Abstreitbarkeit erreicht, da im Gegensatz zu Verfahren, bei denen eine Transaktion alleine von einer Partei initiiert oder ausgelöst werden kann, die aktive und zeitgleiche Mitwirkung von zwei Transaktionsparteien erforderlich ist. Ebenso wird hierdurch eine höhere Sicherheit gegen versehentliche Auslösung oder versehentlich doppelt erfolgende Auslösung einer Transaktion erreicht.
Das Zeitintervall für die Übermittlung der Daten hängt von der Transaktion und den hierfür benutzten Geräten sowie der Anzahl der bei der Abwicklungsinstanz eintreffenden Daten pro Zeiteinheit ab. Die Dauer des Zeitintervalls kann beispielsweise 5 Minuten sein, bevorzugt ist sie aber geringer. Falls die Transaktion über zwei Mobiltelefone initiiert wird, ist das Zeitintervall z. B. in einem Bereich zwischen 10 sec. und 30 sec, bevorzugt 20 sec.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens erfolgt vorteilhafterweise die Datenübermittlung mindestens einer der Transaktionsparteien durch die Initiierung eines Telefonanrufs zur Abwicklungsinstanz. Unter Initiierung eines Telefonanrufs wird hier zum einen verstanden, dass die Datenübermittlung von den Transaktionsparteien ausgeht und nicht von der Abwicklungsinstanz. Zum anderen wird hierunter das Anwählen der Abwicklungsinslanz verstanden, ohne dass die Abwicklungsinstan∑ den Anruf annehmen muss. Bei einem solchen Anwählen können bereits verschiedene Daten, wie beispielsweise die Kennung des Anrufers und die Kennung des Angerufenen sowie Zusatzmerkmale wie Nachwahlziffern übermitteln werden. Eine kostenpflichtige Verbindung wird normalerweise erst dann hergestellt, wenn der Anruf von dem Angerufenen angenommen wird. Bei der Initiierung des Anrufs kann dieser angenommen werden, dies ist jedoch nicht unbedingt erforderlich.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens erfolgt die Übermittlung mindestens eines Teils der von mindestens einer der Transaktionsparteien übermittelten Daten durch die beim Aufbau eines Telefonanrufs zur Abwicklungsinstan∑ gewählte Telefonnummem-Ziffemfolge. Dabei ist vorzugsweise die Telefonnummern-Ziffernfolge so kurz, dass sie von den Vermittlungsstellen und/oder Übermittlungssystemen vollständig übertragen werden kann. Die implizite Übermittlung der relevanten Daten als Teil der Rufnummer hat einerseits den Vorteil von Sicherheit, Schnelligkeit und Einfachheit in der Bedienung. Die Auslosung eines Zahlungsvorganges ist nämlich so einfach wie das Wählen einer Telefonnummer, wobei gleichzeitig die in Mobiltelefonen implementierten Sicherheits-Funktionen, die ein unbeabsichtigtes oder unbefugtes Wählen verhindern, auch die Zahlungsfunktion schützen. Andererseits hat diese Ausgestaltung den Vorteil, dass der Einzelverbindungsnachweis des Telekommunikation s- Providers als Zahlungsnachweis und Beleg dienen kann sowie dass eine sehr einfache Integration der Zahlungstransaktion in die Abrechnungssysteme des Telekommunikations- Providers möglich ist. Ein weiterer Vorteil der Datenübermittlung als Teil der Rufnummer besteht darin, dass - im Unterschied zur DTMF-Ton-Übermittlung - eine visuelle Kontrolle (vor dem Versand der Daten) über das Display des Mobiltelefons möglich ist. Weiterhin ist diese Art der Übertragung wesentlich weniger fehleranfällig als DTMF-Töne, die bei schlechten Funkverbindungen häufig zu Problemen führen. Gleichwohl sind sowohl für die Übermittlung von Daten sowohl von den Transaktionsparteien zur Abwicklungsinstanz als auch von der Abwicklungsinstanz zu den Transaktionsparteien beliebige andere Übertragungsmethoden denkbar, wobei der Umfang dieser Erfindung diese mit einschließt. Diese Übertragungsmethoden können dabei ganz oder teilweise alternativ oder ergänzend zu den oben beschriebenen Methoden angewendet werden. Beispielsweise kann im Falle einer Zahlungstransaktion die Übermittlung des Betrages, einer PIN, einer Kundennummer, eines Zahlungszuordnungs-Referenzcodes oder einer anderen Information über ein oder mehrere alternative Verfahren erfolgen. Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens sind die von einer Transaktionspartei übermittelten Daten gerade hinreichend, um eine Identifikation dieser Transaktionspartei zu ermöglichen, aber nicht hinreichend, um eine Identifikation der anderen Transaktionspartei zu ermöglichen.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens stehen die von den Transaktionsparteien an die Abwicklungsinstanz übermittelten Daten zueinander nach einer bestimmten Vorschrift in Beziehung. Bei dem erfindungsgemäßen Verfahren genügt es, wenn Partei A gegenüber Partei B beispielsweise nur die letzten n Ziffern seiner Mobiltelefon-Nummer offen legt, d. h nur einen Teil der Rufnummer. Partei B übermittelt nun die eigene Mobiltelefon-Nummer und die besagten n Ziffern an die Abwicklungsinstanz, Zeitgleich übermittelt Partei A nur die eigene Mobiltelefon-Nummer an die Abwicklungsinstanz. Durch das schmale Zeitfenster ist der Pool der einander zuzuordnenden Transaktionen so klein, dass die n Ziffern zur Zuordnung ausreichen. (Die n Ziffern, die Partei B übermittelt, sind nicht hinreichend, um Partei A zu identifizieren; femer stehen die n Ziffern zur Mobillelefon-Nummer von Partei A nach einer bestimmten Vorschrift in Beziehung) Alternativ kann das Verfahren auch so funktionieren, dass beide Parteien A und B einander z.B. die letzten n bzw. m Ziffern ihrer jeweiligen Mobiltelefon-Nummern offen legen. Im oben erläuterten Paybox-Verfahren, das nicht mit simultaner Übermittlung arbeitet, ist muss Partei A gegenüber Partei B die vollständige Mobiltelefon-Nummer oder einen eindeutigen Alias offen legen, um eine eindeutige Adressierung zu ermöglichen. Durch diese Merkmale wird die Anonymität der Transaktionsparteien untereinander unter Beibehaltung der Zuordenbarkeit sichergestellt. Gegenüber der Abwicklungsinstanz sind die Transaktionsparteien jedoch eindeutig identifiziert, was die prinzipielle Möglichkeit eröffnet, z.B. im Streitfall und mit Einwilligung der Transaktionsparteien zwischen diesen zu vermitteln oder eine Verbindung zwischen ihnen herzustellen. Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens enthalten die von den Transaktionsparteien an die Abwicklungsinstanz übermittelten Daten den wesentlichen Teil der Inhalte der jeweiligen Willenserklärungen und/oder oder einen digitalen Abdruck (Digest, Hash-Wert) der Inhalte der jeweiligen Willenserklärungen und/oder eine eindeutige Referenz auf ggf. an anderer Stelle erfasste Inhalte der jeweiligen Willenserklärungen.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens prüft eine Prüfinstanz, die von der Abwicklungsinstanz umfasst oder mit dieser verbunden sein kann, ob eine Zuordnung der Transaktionsparteien anhand der übermittelten Daten möglich ist. Bei einer Zahlungstransaktion ergibt sich daraus auch die Prüfung, ob die jeweiligen Willenserklärungen korrespondieren.
Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens wird die Datenübermittlung von den Transaktionsparteien an die Abwicklungsinslan∑ über Mobiltelefone durchgeführt und bei der Datenübermittlung werden Informationen über die Aufenthaltsorte der Mobiltelefone mit übermittelt. Diese Informationen werden als zusätzliches Zuordnungskriterium verwendet. Diese Weiterbildung ist in Anwendungs-Szenarien vorteilhaft, bei denen eine räumliche Nähe zwischen Zahler und Empfänger besteht. Die Information über den Aufenthaltsort der Transaktionsparteien kann in diesem Fall als zusätzliches Kriterium herangezogen werden, um eine Zuordnung der Transaktionsparteien über die Datensätze im Transaktions-Pool zu erleichtern. Unter dem Begriff „Location Dependent Services" sind Verfahren bekannt, bei denen die Ortsinformation von Mobiltelefon-Nutzern übertragen und ausgewertet werden kann.
Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens kann die Abwicklungsinstan∑ in den seltenen Fällen, in denen eine eindeutige Zuordnung deshalb nicht möglich ist, weil mehrere Datensätze mit übereinstimmenden Kriterien im Transaktions- Pool vorliegen, die Eingabe zusätzlicher Merkmale anfordern, z.B. den Zahler über ein IVR- System (Interactive Voice Response) darum bitten, auch die letzten vier Ziffern der Mobiltelefon-Nummer des Empfängers einzugeben.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens existiert eine Transaktionsinstanz, die von der Abwicklungsinstanz umfasst oder mit dieser verbunden sein kann. Diese Transaktionsinstanz prüft, ob eine Durchführung des Zahlungsvorgangs möglich ist. Bei positiver Prüfung wird die Transaktion durchgeführt.
Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens beinhaltet die zu initiierende oder durchzuführende Transaktion ferner mindestens die Dokumentation des Vertragsabschlusses, d.h. z. B. das Speichern der mit der Transaktion in Verbindung stehenden Daten. Ferner sind ebenso Ausgestaltungen des Verfahrens möglich, bei denen zwischen beiden Transaktionsparteien eine Telefonverbindung hergestellt wird (sofern beide Transaktionsparteien ein Festnetztelefon oder Mobiltelefon verwenden). Diese Variante ist insbesondere dann sinnvoll, wenn z.B. eine Zahlungstransaktion für eine telefonische Beratung o.a. erfolgt und die Dienstleistung gleich über die hergestellte Telefonverbindung erbracht wird. Hierfür könnte für den Fall, dass z.B. innerhalb einer bestehenden Mobil- Telefonverbindung zwischen den Transaktionsparteien eine Zahlungstransaktion unter Nutzung der Mobiltelefone erfolgen soll, das Verfahren so abgewandelt sein, dass die Übermittlung des Zahlbetrages und der letzten vier Ziffern der Mobiltelefon-Nummer des Zahlers über DTMF-Töne erfolgt, die innerhalb der Verbindung von den Transaktionsparteien gesendet werden. In diesem Fall könnten die DTMF-Töne vom Vermittlungssystem ausgefiltert und an die Abwicklungsinstanz weitergeleitet werden oder es könnte eine temporäre Teiefon-Verbindung der Transaktionsparteien mit der Abwicklungsinstanz initiiert werden.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens existiert eine Signalisierungsinstanz, die von der Abwicklungsinstanz umfasst oder mit dieser verbunden sein kann. Bei nicht erfolgreicher Prüfung der Prüfinstanz gibt diese an beide Parteien eine Fehlermeldung aus. Dies kann z.B. durch Annahme der Anrufe und eine akustische Ansage erfolgen. Die von der Signalisierungsinstanz ausgelöste Signalisierung bzw. über die von der Signalisierungsinstanz übermittelten Daten können für die Transaktionsparteien insbesondere Rückschlüsse auf den Status der Durchführung von Transaktionen durch die Transaktionsinstan∑ (sowie auf das Ergebnis der Prüfinstanz) zulassen.
Allgemein übermittelt die Signalisierungsinstanz nach der Durchführung der Transaktion zumindest einer der Transaktionsparteien Daten, die signalisieren, dass die Transaktion durchgeführt worden ist. Diese Signalisierung ist vorteilhafterweise wie folgt realisiert:
Nach Eingang der beiden Anrufe in der Abwicklungsinstan∑ werden zunächst alle Prüfungsund Verarbeitungsschritte durch die Prüfinstanz und die Transaktionsinstanz durchgeführt. Während dieser Zeit werden die Anrufe von der Abwicklungsinstanz noch nicht angenommen, d.h. den Transaktionsparteien wird zunächst ein Freizeichen signalisiert, wodurch vorteilhafterweise die Telekommunikationskosten reduziert werden.
Des Weiteren können beide Anrufe von der Abwicklungsinstahz angenommen werden, sobald ein abschließender Status erreicht ist (d.h. ein Fehler vorliegt oder alle vorbereitenden Prüfschritte vor Durchführung der Zahlung erledigt sind). Wenn ein Fehler vorliegt, erfolgt eine kurze Ansage mit dem Fehlergrund (z.B. „Einzelbetrags-Limit überschritten" oder „Kein korrespondierender Zahlungsempfänger vorliegend") und unmittelbar danach ein Auflegen durch die Abwicklungsinstanz. Wenn die Zahlung durchgeführt werden kann, erfolgt eine längere Ansage (z.B. „Zahlung von EUR 23,50 erfolgt jetzt"), gefolgt von einem akustischen Signal und danach einer optionalen Kontostand- Ansage. Diese Ausgestaltung hat folgenden Vorteil: Nicht erfolgreiche Transaktionen führen immer zu Verbindungsdauern von z.B. 5 Sekunden oder kürzer, ausschließlich erfolgreiche Transaktionen führen zu Verbindungsdauern von z.B. 10 Sekunden oder länger.
Femer sind Ausgestaltungen des Verfahrens möglich, bei denen die Signalisierung generell dadurch erfolgt, dass von der Signalisierungsinstanz ein Rückruf an mindestens eine der Transaktionsparteien initiiert wird. Diese Variante hat den Vorteil, dass auch in den Einzelverbindungsnachweisen des Betreibers der Signalisierungsinstanz bzw. Abwicklungsinstanz Belege für die durchgeführten Transaktionen erfasst werden. Diese Variante unter Nutzung eines Rückrufs kann wiederum so ausgestaltet sein, dass unterschiedlich lange Zeitintervalle zwischen dem Übergang verschiedener Rufaufbau- Signale und/oder Rufabbau-Signale liegen. So kann z.B. der Rückruf bei einer erfolgreichen Transaktion nach 10 Sekunden, bei einer nicht erfolgreichen Transaktion nach 20 Sekunden erfolgen, oder der Rückruf kann in beiden Fällen sofort erfolgen, und im Falle einer erfolgreichen Transaktion eine längere Ansage (vor dem Auflegen durch die Signalisierungsinstanz bzw. Abwicklungsinstanz) erfolgen als im Falle, einer nicht erfolgreichen Transaktion.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens ist es ebenso möglich, die Variante unter Nutzung eines Rückrufs weiterhin so zu gestalten, dass die Signalisierung dadurch erfolgt, dass bei dem von der Abwicklungsinstanz initiierten Rückruf von der Abwicklungsinstanz eine spezielle Anrufer-Rufnummer (ANI) generiert und übergeben wird, wobei aus dieser ANI Rückschlüsse auf das Ergebnis der Prüfinstanz und/oder auf den Status der Durchführung von Transaktionen durch die Transaktionsinstanz möglich sind.
Ferner kann vorteilhafterweise die Variante unter Nutzung eines Rückrufs und ggf. Nutzung einer speziellen Anrufer-Rufnummer so ausgestaltet sein, dass die von der Abwicklungsinstanz ausgehenden Rückrufe in den Telekommunikationsgeräten der Transaktionsparteien nur signalisiert, aber von diesen nicht angenommen werden. Vorteilhaft an dieser Ausgestaltung ist, dass theoretisch Überhaupt keine Telekommunikationskosten entstehen.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens erfolgt die Aussendung des oben beschriebenen akustischen Signals bzw. der Signalisierungen exakt synchron an beide Transaktionsparteien und zusätzlich insbesondere genau in dem Moment, in dem der eigentliche Zahlungsvorgang logisch erfolgt (in Informatik- Fachsprache ausgedrückt: in dem Moment, in dem das „Commit" der Transaktion erfolgt, die den eigentlichen Zahlungsvorgang darstellt). Hierdurch wird die Wahrscheinlichkeit von Szenarien verringert, in denen an eine oder alle der Transaktionsparteien keine eindeutige Signalisierung über den Erfolg oder den Status der Transaktion erfolgen kann. (Solche Szenarien können z.B. eintreten, wenn die Telekommunikationsverbindung während der Durchführung der Transaktion abbricht.)
Die Ausgestaltung, dass die Verbindungsdauer einer erfolgreichen Transaktion länger ist als die einer nicht erfolgreichen Transaktion hat den Vorteil, dass vorzeitiges Auflegen eines Transaktionspartners dazu führt, dass die Transaktion abgebrochen und das „Commit" des eigentlichen Zahlungsvorgangs nicht ausgeführt wird. Dadurch wird eine Manipulation des oben beschriebenen Effektes auf die Einzelverbindungsnachweise durch vorzeitiges Auflegen ausgeschlossen (Eine solche Manipulation wäre möglich, wenn lange Verbindungsdauern ein Kennzeichen für nicht erfolgreiche und kurze Verbindungsdauern ein Kennzeichen für erfolgreiche Transaktionen wären.) Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens erfolgt die Signalisierung dadurch, dass der Anruf durch Abheben der Abwicklungsinstanz angenommen wird oder unter Signalisierung eines Freizeichens nicht angenommen wird oder ein Besetzt-Signal oder ein anderes Signal signalisiert wird oder dass unterschiedlich lange Zeitintervalle zwischen dem Übergang verschiedener Rufaufbau-Signale und/oder Rufabbau-Signale liegen. Beispielsweise könnte das Verfahren so funktionieren, dass im Falle einer erfolgreichen Transaktion ein dreimaliges Freizeichen-Signal erzeugt wird, bevor ein Besetzt-Signal auftritt, wohingegen im Fall einer nicht erfolgreichen Transaktion bereits nach einem Freizeichen-Signal ein Besetzt-Signal auftritt. Vorteilhaft an dieser Ausgestaltung ist, dass theoretisch überhaupt keine Telekommunikationskosten entstehen.
Ferner könnte das Verfahren beispielsweise auch so arbeiten, dass die Signalisierung alternativ zu oder kombiniert mit Freizeichen- oder Besetzt-Signalen über andere gebührenfreie Ansagen wie z.B. „Kein Anschluss unter dieser Nummer" oder spezielle neu einzuführende gebührenfreie Ansagen erfolgt.
Des Weiteren kann bei dem erfindungsgemäßen Verfahren in allen Abrechnungsvarianten die Wahrscheinlichkeit von Reklamationen sowie das generelle Missbrauchsrisiko reduziert werden, indem kombiniert mit einer Signalisierung über den Transaktionserfolg Informationen über zurückliegende Transaktionen an die Transaktionsparteien übermittelt werden. Dies bedeutet z.B., dass nach jeder Transaktion eine kurze Ansage der des Guthabens des „Stored Value Accounts" bzw. die Summe der seit der letzten Abrechnung aggregierten Einzeltransaktionen erfolgen kann. Zusätzlich erhöht wird die Sicherheit, indem Datum und Betrag der letzten zurückliegenden Transaktion angesagt wird.
Für den Fall, dass beide Transaktionsparteien ein Telefon bzw. Mobiltelefon verwenden, könnte die Übermittlung der Daten und/oder Signalisierungen ganz oder teilweise durch Mehrfrequenz-Töne (ÖTMF) und/oder IVR-Systeme (Interative Voice Response) und/oder über Spracherkennungssysteme und/oder durch Sprache und/oder über SMS- Kurzmitteilungen und/oder über das USSD-Protokoll (Unstructured Supplementary Services Data) und/oder über das WAP-Protokoll (Wireless Application Protocol) und/oder über das GPRS-Protokoll (GSM Packet Radio Service) des GSM-Standards und/oder ein vergleichbares Protokoll eines anderen Mobilfunk-Standards und/oder über das i-Mode- Protokoll und/oder unter Nutzung einer Java- und/oder SIM-Application-Toolkit-Anwendung und/oder über die Nutzung einer Bluetooth-Schnittstelle und/oder einer Infrarot-Schnittstelle erfolgen. Nachteilig an der Verwendung von DTMF-Tönen, IVR-Systemen, Spracherkennungssystemen, Sprache und SMS-Mitteilungen ist die längere Abwicklungsdauer im Vergleich zur Datenübermittlung als Teil der Rufnummer eines Telefonanrufes. Nachteilig an der Verwendung des USSD-Protokolls ist die nicht einheitliche Implementierung von Statusmeldungen in verschiedenen Endgeräten und die Tatsache, dass USSD (in der Variante USSD Stage 2) nicht von allen Mobilfunk-Netzbetreibern unterstützt wird sowie die Tatsache, dass eine Implementierung durch einen vom Mobilfunk- Netzbetreiber unabhängigen Anbieter nicht ohne weiteres möglich ist. Nachteilig an der Verwendung von WAP, GPRS, i-Mode, Java, SIM-Application-Toolkit und ähnlichen Verfahren ist, dass sie - sofern kein Endgeräte-Austausch und ggf. Wechsel des Mobilfunk- Netzbetreibers oder Wechsel des Tarifs erfolgt - nach dem Stand der Technik nur von einem relativ kleinen oder sehr kleinen Teil der Mobilfunk-Nutzer verwendet werden können.
Falls nur eine der Transaktionsparteien ein Telefon bzw. Mobiltelefon verwendet, kann cüiβ Übermittlung der Daten und/oder Signalisierungen ganz oder teilweise über ein Computemetzwerk und/oder über das Internet und/oder per E-Mail und/oder über den Aufruf eines Webservice und/oder mittels Verwendung des HTTP- und/oder des XML-Prokolls und/oder über die Nutzung einer Bluetooth-Schnittstelle und/oder einer Infrarot-Schnittstelle und/oder eines Wireless LAN und/oder über ein digitales oder analoges Modem und/oder die Nutzung eines sonstigen Übertragungsverfahrens erfolgen.
Das erfindungsgemäße Verfahren betrifft insbesondere Zahlungstransaktionen. Dabei sind die Willenserklärungen allgemein mindestens auf die Durchführung eines Zahlungsvorgangs betreffend Geld- oder Werteinheiten gerichtet. Werteinheiten können z.B. oder insbesondere Bonuspunkte in Rabattsystemen, „Statusmeilen" oder ähnliches sein. Vorteilhafterweise können zusammen mit Zahlungstransaktionen betreffend Geldeinheiten auch parallel Bonuspunkte o.a. verbucht werden. Die Transaktion besteht in diesen Fällen mindestens in der Veranlassung oder Durchführung eines Zahlungsvorgangs betreffend Geld oder Werteinheiten. Die Transaktionsinstanz verarbeitet dann Zahlungsvorgänge betreffend Geld oder Werteinheiten. Die Weiterverarbeitung der Zahlungstransaktion durch die Transaktionsinstanz kann durch Legitimationsprüfung und/oder Aggregation und/oder eine zeitgleich oder zeitverzögert, online oder offline erfolgende Weiterleitung an andere Verarbeitungsinstanzen erfolgen. Beispielsweise können auf Seiten des Zahlers bzw. Empfängers einzelne Transaktionen gesammelt und nur als Gesamtbetrag monatlich einem Bankkonto oder einer Kreditkarte belastet bzw. gutgeschrieben werden. Die Sammel- Aufträge werden in diesem Fall an Banken oder Kreditkartenunternehmen als weitere Verarbeitungsinstanzen weitergeleitet. Alternativ können einzelne Transaktionen (insbesondere bei höheren Beträgen) auch zeitgleich zur Online-Autorisierung an Kreditkartenunternehmen weitergeleitet werden.
Gemäß einer bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens enthalten im Falle einer Zahlungstransaktion die übermittelten Daten den zu zahlenden Betrag an Geld oder Werteinheiten. Durch die doppelte Übermittlung der relevanten Daten wird die Fehlerwahrscheinlichkeit gesenkt und die Nachweissicherheit erhöht. Bei herkömmlichen Verfahren wird der Betrag in der Regel nur von einer der Transaktionsparteien aktiv angegeben und von der anderen Transaktionspartei nur passiv bestätigt, z.B. nach Anzeige auf dem Mobiltelefon-Display oder nach einer akustischen Ansage der Betragshöhe. Dadurch ist ein Irrtum über den autorisierten Betrag leicht möglich. So kann es z.B. bei dem Paybox-Verfahren auftreten, dass der nur akustisch angesagte Betrag aufgrund einer schlechten Funkverbindung oder lauter Umgebungsgeräusche nicht oder falsch verständlich ist. Weiterhin wird durch das Teilen einer gemeinsamen Information in Form der Betragshöhe und die doppelte aktive Angabe dieses Betrages eine Bezeugungswirkung durch beide Transaktionsparteien erreicht. Damit wird eine zusätzliche Erhöhung der Sicherheit gegen Abstreitbarkeit erreicht. Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens wird zusätzlich ein Zahlungszuordnungs-Referenzcode übertragen, der die eindeutige Zuordnung der Transaktionsparteien ermöglicht oder erleichtert.
Gemäß einer bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens könnte der Zahlbetrag nicht im Klartext, sondern als verschlüsselte Ziffernfolge übermittelt und/oder um eine Prüfziffer oder Prüfziffernfolge ergänzt werden.
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens erfolgt die Festlegung des Zahlbetrages durch eine aktive Eingabe des Betrages und nicht durch passive Bestätigung eines angezeigten oder angesagten Betrages. Dies führt vorteilhafterweise zu einer Reduktion der Irrtumswahrscheinlichkeit. Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens ist es auch möglich, dass Zusatzmerkmale abgefragt werden, die eine buchhalterisch getrennte Erfassung oder Untergruppierung der getätigten Transaktion ermöglichen, z.B. durch eine Ansage wie „Drücken Sie 1 für eine private Zahlung, 2 für eine geschäftliche Zahlung".
Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens ist es weiterhin möglich, dass für den Fall, dass mehrere Nutzer über ein Mobil- oder Festnetztelefon Transaktionen ausführen, Merkmale abgefragt werden, die die Zuordnung der Transaktion zu nutzerspezifischen Unterkonten ermöglichen, z.B. durch Eingabe verschiedener PINs für verschiedene Nutzer.
Anstelle von PINs kann die Abfrage von zusätzlichen Autorisierungsmerkmalen auch über andere Verfahren, z.B. biometrische Verfahren wie Stimmvergleiche (Voice-Sampling) erfolgen.
Außerdem kann generell eine Unterscheidung der Weiterverarbeitung nach bestimmten
Kriterien erfolgen. Z.B. können automatisch kleine Beträge direkt gegen einen „Stored Value
Account" abgerechnet, mittlere Beträge aggregiert und zeitversetzt gegen ein Bankkonto abgerechnet und höhere Beträge online bei einem Kreditkartenunternehmen autorisiert werden. Hierbei kann auch eine je nach Modus unterschiedliche Form der Speicherung und Verwaltung der Transaktions-Historie realisiert werden. So können z.B. Transaktionen mit niedrigen Beträgen für den Fall von Reklamationen nur kurzzeitig oder gar nicht und solche mit höheren Beträgen über längere Zeiträume gespeichert werden. Weiterhin ist es möglich, dem Nutzer für einzelne Transaktion individuell die Entscheidungsmöglichkeit über den Abrechnungsmodus ∑u geben, z.B. durch eine IVR-basierte Abfrage („Drücken Sie 1 , um diese Zahlung per Kreditkarte abzurechnen, 2, um sie per Bankeinzug abzurechnen").
Gemäß einer weiteren bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens kann z.B. eine je nach Betragshöhe unterschiedliche Art der Signalisierung und Bestätigung der Transaktion erfolgen. So könnte z.B. bei höheren Beträgen nach erfolgter Transaktion zusätzlich eine SMS zur Bestätigung verschickt werden.
Gemäß einem bevorzugten Ausführungsbeispiel des erfindungsgemäßen Verfahrens umfassen die Transaktionsparteien einen Zahler bzw. ein Telefon des Zahlers und einen Zahlungsempfänger bzw. ein Telefon des Zahlungsempfängers. Es werden die Schritte durchgeführt, dass: a) der Zahler einen Telefonanruf an die Abwicklungsinstanz initiiert, wobei die dabei gewählte Telefonnummer eine Ziffernfolge enthält, die dem Zahlbetrag entspricht, b) der Zahlungsempfänger simultan oder zeitnah zum Anruf des Zahlers Daten an die Abwicklungsinstanz übermittelt, die den Zahlbetrag enthalten, c) eine Prüfinstanz prüft, ob die von Zahler und Zahlungsempfänger übermittelten Daten einander eindeutig zuordenbar sind und mindestens die enthaltenen Zahlbeträge übereinstimmen, d) eine Transaktionsinstanz prüft, ob anhand der übermittelten Daten eine Identifikation und/oder Legitimation von Zahler und Zahlungsempfänger möglich ist und/oder ob die Verarbeitung des Zahlungsvorgangs möglich ist e1) bei positiver Prüfung von Prüfinstanz und Transaktionsinstanz die Transaktionsinstanz die Weiterverarbeitung durchführt oder veranlasst, - der Anruf des Zahlers von einer Signalisierungsinstanz angenommen wird und ggf. eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung erfolgt ist, ein Bestätigungssignal über die erfolgte Zahlung an den Zahlungsempfänger übermittelt wird, e2) für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, der Anruf des Zahlers von der Abwicklungsinstanz nicht angenommen wird oder verzögert angenommen wird und/oder eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung nicht erfolgt ist. Gemäß einer Weiterbildung des erfindungsgemäßen Verfahrens werden die Schritte durchgeführt, dass: a) auch die Übermittlung der Daten des Zahlungsempfängers an die Abwicklungsinstan∑ dadurch erfolgt, dass der Zahlungsempfänger einen Telefonanruf an die Abwicklungsinslanz initiiert, wobei die dabei gewählte Telefonnummer eine Ziffernfolge enthält, die dem Zahlbetrag entspricht, b1 ) bei positiver Prüfung von Prüfinstanz und Transaktionsinstanz nach erfolgter
Zahlung das Bestätigungssignal an den Zahlungsempfänger dadurch übermittelt wird, dass auch der Anruf des Zahlungsempfängers von der
Signalisierungsinstanz angenommen wird und ggf. eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung erfolgt ist, b2) für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, auch der Anruf des Zahlungsempfängers nicht angenommen wird oder verzögert angenommen wird und/oder eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung nicht erfolgt ist. Die Abwicklungsinstanz oder die Transaktionsinstanz werden vorteilhafterweise von einem Telekommunikations-Provider umfasst oder betrieben. Ein Vorteil der oben dargestellten Ausgestaltung des Verfahrens besteht nämlich darin, dass eine sehr einfache Integration der Zahlungsvorgänge in die Abrechnungssysteme der Telefon- oder Mobilfunk-Provider möglich ist. Vorteilhafterweise geschieht die Verarbeitung der Zahlungstransaktionen zusammen mit der Abrechnung der Telekommunikationsdienstleistungen.
Bei dem erfindungsgemäßen Verfahren ergibt sich ferner der Vorteil, dass ein Einzelverbindungsnachweis der Telefon- oder Mobiltelefon-Rechnung des Telekommunikationsproviders ohne weitere Modifikation direkt als Zahlungsnachweis und Beleg dienen kann. Dies führt zu einer Kostensenkung, da auf die Erstellung und Zusendung einer separaten Abrechnung verzichtet werden kann. Ein Eintrag über einen ausgehenden Anruf an Rufnummer „0800-55555-2350-4567" von 11 Sekunden Länge könnte demnach als ein Nachweis über eine empfangene Zahlung i.H.v. EUR 23,50 dienen. Vorteilhaft an der erfindungsgemäßen Eigenschaft, derzufolge beide Transaktionsparteien einen Anruf zur Abwicklungsinstanz initiieren, ist, dass für jede der Transaktionsparteien ein Beleg existiert. Hierbei ist zu beachten, dass Anrufe zu kostenlosen Rufnummern, die z.B. mit 0800 beginnen, im Regelfall nicht im Einzelverbindungsnachweis des Anrufers erfasst werden. In diesem Fall müsste die Abwicklung über eine alternative Zugangsnummer erfolgen. Andererseits erfolgt die Abrechnung von Anrufen zu kostenlosen Rufnummern in der Regel über die angerufene Partei, in diesem Fall also über den Betreiber der Abwicklungsinstaπz, so dass die betreffenden Anrufe hier auf dem Einzelverbindungsnachweis der Abwicklungsinstanz erfasst würden. Hierdurch erfüllt der Einzelverbindungsnachweis des Telekommunikations-Providers ebenfalls die Funktion eines Zahlungsnachweises und Belegs, allerdings nicht für die Transaktionsparteien, sondern für den Betreiber der Abwicklungsinstanz.
Gemäß einer weiteren bevorzugten Ausgestaltung des erlϊndungsgemäßen Verfahrens erfolgt bei Überschreiten eines bestimmten Betrages oder unter anderen bestimmten Bedingungen vor Durchführung der Transaktion eine Ansage oder andere Signalisierung und/oder eine PIN-Abfrage oder eine andere Abfrage zur Bestätigung der Transaktion. Die Rückmeldung der Signalisierungsinstanz über die durchgeführte Transaktion kann vorzugsweise dadurch gegen Missbrauch gesichert werden, dass ein eindeutiger Buchungs- Referenz-Code oder eine kryptographisch signierte Bestätigungsnachricht, z.B. per E-Mail oder per SMS übermittelt wird.
Das Verfahren könnte weiterhin z.B. auch so realisiert werden, dass ausschließlich im Falle einer erfolgreichen Transaktion der Anruf von der Abwicklungsinstanz durch Abheben angenommen und bei nicht erfolgreicher Transaktion ein Freizeichen- und/oder Besetzt- Signal signalisiert wird. Diese Variante hätte den Vorteil, dass Transaktionen generell dann (und nur dann) zu Einträgen in Einzelverbindungsnachweisen führen, wenn sie erfolgreich sind. In dieser Variante könnte vorteilhafterweise bei nicht erfolgreichen Transaktionen ein Rückruf der Signalisierungsinstanz an eine oder alle der Transaktionsparteien erfolgen verbunden mit einer akustischen Ansage der Fehlerursache. Alternativ kann die Fehlerursache auch z.B. per SMS übermittelt werden.
Das erfindungsgemäße System zum Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion, insbesondere einer Zahlungstransaktion, umfasst ein erstes Kommunikationsgerät, das einer ersten Transaktionspartei zugeordnet ist, ein zweites Kommunikationsgerät, das einer zweiten Transaktionspartei zugeordnet ist, und eine Abwicklungsinslanz, mit der Daten von den Kommunikationsgeräten empfangbar sind. Die Abwicklungsinstanz umfasst eine Prüfinstanz oder ist mit einer Prüfinstanz verbunden. Mit ihr ist prüfbar, ob eine Zuordnung der Transaktionsparteien anhand von jeweils von den Kommunikationsgeräten innerhalb eines begrenzten Zeitfensters übermittelten Daten möglich ist. Schließlich wird erfindungsgemäß ein Computersystem zum Initiieren und/oder Durchführen einer Zahlungstransaktion bereitgestellt. Das Computersystem betrifft insbesondere eine Ausgestaltung der oben genannten Abwicklungsinstanz. Das Computersystem umfasst einen Eingang zum Empfang von Daten eines ersten und eines zweiten Kommunikationsgeräts, wobei die Daten Merkmale enthalten, die eine Zuordnung von zwei korrespondierenden Willenserklärungen erlauben. Mit dem Eingang ist ein Transaktionspool- Speicher verbunden, der innerhalb eines Zeitintervalls eingehende Daten zwischenspeichert. Mit dem Transaktionspool-Speicher ist eine Prüfungsinstanz verbunden, mit welcher die in dem Transaktionspool-Speicher gespeicherten Daten so analysierbar sind, dass zumindest Kennungen des ersten und zweiten Kommunikationsgeräts und ein zu zahlender Betrag gewinnbar sind und prüfbar ist, ob eine Zuordnung der Transaktionsparteien anhand der jeweils übermittelten Daten möglich ist und ob die jeweiligen Willenserklärungen korrespondieren. Mit der Prüfinstanz ist eine Transaktionsinslanz verbunden, mit welcher bei positiver Prüfung die in der Prüfinstanz gewonnen Daten in Zahlungsanweisungsdaten umsetzbar sind. Schließlich ist mit der Transaktionsinstanz ein Ausgang verbunden, über den die Zahlungsanweisungsdaten an eine Zahlungsabwicklungsinstanz übermittelbar sind.
Gemäß einer bevorzugten Weiterbildung des erfindungsgemäßen Computersystems ist mit der Transaktionsinstanz und dem Ausgang eine Signalisierungsinstanz verbunden, mit welcher in Abhängigkeit von der Prüfung der Prüfinstanz und/oder von der Übermittlung der Zahlungsanweisungsdaten Signalisierungen über die Initiierung und/oder Durchführung der Zahlungstransaktion an zumindest ein Kommunikationsgerät oder an andere Empfänger übertragbar sind.
Des Weiteren kann die Transaktionsinstanz auch eine Kontoführungsinstanz umfassen oder direkt mit einer Kontoführungsinstanz verbunden sein. Wenn die Abrechnung z.B. über einen „Stored Value Account", d.h. ein vorausbezahltes Guthaben erfolgt, kann das „Settlement", d.h. die Durchführung des Zahlungsvorgangs, besonders rationell, schnell und risikolos durchgeführt werden, da keine Kommunikationsverbindung zu einer externen Verarbeitungsinstanz notwendig ist, keine umfangreichen Transaktionshistorien verwaltet werden müssen und ein Kredit-, Inkasso- und Charge-Back-Risiko ausgeschlossen wird. Die Kommunikationsgeräte sind insbesondere ein Festnetztelefon und/oder ein Mobiltelefon.
Im Übrigen umfasst die Erfindung ein Computerprogramm mit Programmcode-Mitteln, um alle Schritte der oben genannten Ausgestaltungen des erfindungsgemäßen Verfahrens durchzuführen, wenn das Programm auf einem Computer ausgeführt wird. Schließlich umfasst die Erfindung ein Computerprogrammprodukt mit Programmcode-Mitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um die verschiedenen Ausgestaltungen des oben angegebenen Verfahrens durchzuführen, wenn das Programmprodukt auf einem Computer ausgeführt wird.
Im Folgenden werden Ausführungsbeispiele des erfindungsgemäßen Verfahrens unter Bezugnahme auf die Zeichnungen dargestellt Fig. 1 zeigt eine Graphik zur Erläuterung des ersten Ausführungsbeispiels des erfindungsgemäßen Verfahrens,
Fig. 2 zeigt eine Graphik zur Erläuterung des zweiten Ausführungsbeispiels des erfindungsgemäßen Verfahrens,
Fig. 3 zeigt eine Graphik zur Erläuterung des vierten Ausführungsbeispiels des erfindungsgemäßen Verfahrens,
Fig. 4 zeigt eine Graphik zur Erläuterung eines Ausführungsbeispiels des erfindungsgemäßen Systems,
Mit Bezug zu Figur 1 wird das erste Ausführungsbeispiel erläutert: Die Transaktionsparteien umfassen einen Zahler 1 (bzw. ein Kommunikationsgerät des Zahlers) und einen Zahlungsempfänger 2 (bzw. ein Kommunikationsgerät des Zahlungsempfängers). Der Zahler 1 initiiert einen Telefonanruf 5 an die Abwicklungsinstanz 3. Die dabei gewählte Telefonnummer enthält eine Ziffernfolge 7, die dem Zahlbetrag entspricht. Simultan oder zeitnah zum Anruf des Zahlers übermittelt der Zahlungsempfänger 2 Daten an die Abwicklungsinstanz 3, die den Zahlbetrag 7 enthalten. Das Zeitintervall liegt in einem Bereich zwischen 10 sec. und 30 sec, es ist z. B. 20 sec. Zusätzlich übermittelt der Zahlungsempfänger 2 einen Zahlungszuordnungs-Referenzcode 8 an die Abwicklungsinstanz 3, der nach einer bestimmten Vorschrift aus der Rufnummer 12 des Zahlers 1 gebildet wird (z.B. aus den letzten vier Ziffern der Rufnummer des Zahlers besteht). Eine Prüfinstanz 9 prüft, ob die von Zahler 1 und Zahlungsempfänger 2 übermittelten Daten einander eindeutig zuordenbar sind und mindestens die enthaltenen Zahlbeträge 7 übereinstimmen. Eine Transaktionsinstanz 10 prüft, ob anhand der übermittelten Daten eine Identifikation und/oder Legitimation von Zahler 1 und Zahlungsempfänger 2 möglich ist und/oder ob die Verarbeitung des Zahlungsvorgangs möglich ist.
Hierzu wird zunächst überprüft, ob die Teilnehmer-Nummern im System registriert und für die Zahlungsfunktion zugelassen sind. Bei nicht erfolgreicher Prüfung gibt die Signalisierungsinstanz 11 an die jeweiligen Parteien eine entsprechende Fehlermeldung aus. Dies kann z.B. durch Annahme der Anrufe und eine akustische Ansage erfolgen. Bei erfolgreicher Prüfung prüft im nächsten Schritt die Transaktionsinstanz 10, ob eine Durchführung der Zahlung möglich ist. Dies hängt insbesondere von der Betragshöhe und der Bonität des Zahlers ab. Wenn z.B. der aktuelle Zahlbetrag oder eine aggregierte Summe von Zahlbeträgen ein Limit (das z.B. von der Bonität des Zahlers abhängt) überschreitet, kann die Transaktionsinstanz 10 die Durchführung bzw. Weiterverarbeitung der Zahlungstransaktion ablehnen oder eine zusätzliche Legitimationsprüfung durch Anforderung eines weiteren Autorisierungsmerkmals durchführen (z.B. Eingabe einer PIN über ein IVR- Interface). Generell kann die Transaktionsinstanz 10 vor der Durchführung der Transaktion unter bestimmten Bedingungen, z.B. ab einer gewissen Betragshöhe, noch eine weitere Bestätigung (auch z.B. durch einfaches Drücken einer Taste und Übermittlung eines DTMF- Tones) anfordern. Weiterhin ist z.B. auch möglich, dass unter bestimmten Bedingungen wie z.B. ab einer gewissen Betragshöhe vor Durchführung der Transaktion der Betrag nochmals explizit angesagt wird und danach die Bestätigung abgefragt wird.
Bei positiver Prüfung von Prüfinstanz 9 und Transaktionsinstanz 10 führt die Transaktionsinstanz 10 die Weiterverarbeitung der Zahlung durch oder veranlasst (bzw. initiiert) diese. Der Anruf des Zahlers 1 wird von der Signalisierungsinstanz 11 angenommen und ggf. erfolgt eine akustische Ansage, aus der hervorgeht, dass die Zahlung erfolgt ist. An den Zahlungsempfänger 2 wird ein Bestätigungssignal über die erfolgte Zahlung übermittelt.
Für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, wird der Anruf des Zahlers 1 von der Abwicklungsinstanz 3 nicht angenommen oder verzögert angenommen und/oder es erfolgt eine akustische Ansage, aus der hervorgeht, dass die Zahlung nicht erfolgt ist.
Eine weitere Ausgestaltung dieses ersten Ausführungsbeispiels sieht wie folgt aus:
Auch die Übermittlung der Daten des Zahlungsempfängers 2 an die Abwicklungsinstanz 3 erfolgt dadurch, dass der Zahlungsempfänger einen Telefonanruf 6 an die
Abwicklungsinstanz 3 initiiert. Die dabei gewählte Telefonnummer enthält ebenfalls eine
Ziffernfolge 7', die dem Zahlbetrag entspricht, sowie den Zahlungszuordnungs-Referenzcode als Ziffernfolge 8', also z.B. die letzten vier Ziffern 8 der Rufnummer 12 des Zahlers 1. Bei positiver Prüfung von Prüfinstanz 9 und Transaktionsinstanz 10 nach erfolgter Zahlung wird das Bestätigungssignal auch an den Zahlungsempfänger 2 dadurch übermittelt, dass der
Anruf 6 des Zahlungsempfängers von der Signalisierungsinstanz 11 angenommen wird und ggf. eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung erfolgt ist. Für den
Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, wird auch der Anruf des
Zahlungsempfängers 2 nicht angenommen oder verzögert angenommen wird und/oder es erfolgt eine akustische Ansage, aus der hervorgeht, dass die Zahlung nicht erfolgt ist Im Folgenden soll die Durchführung einer Zahlungstransaktion an einem detaillierten Beispiel erläutert werden:
Partei A (1) mit einem Mobiltelefon mit der Mobiltelefon-Nummer 0171-1234567 (12) möchte an Partei B (2) mit einem Mobiltelefon mit der Mobiltelefon-Nummer 0171-9876543 (13) einen Betrag von EUR 23,50 (7) zahlen. Hierzu teilt Partei A der Partei B die letzten vier Ziffern seiner Mobiltelefon-Nummer (8), also „4567" mit (4). A wählt mit seinem Mobiltelefon die Nummer 0800-55555-2350 an (5). Quasi-zeilgleich wählt B mit seinem Mobiltelefon die Nummer 0800-55555-2350-4567 (6) an. Wenn die Zahlung erfolgreich durchgeführt ist, werden die Anrufe angenommen und A und B erhalten eine kurze akustische Ansage „Zahlung erfolgt".
Das Verfahren kann auch so ausgestaltet sein, dass nicht der Zahler dem Zahlungsempfänger die letzten vier Ziffern seiner Mobiltelefon-Nummer offen legt und der Zahlungsempfänger diese - als Teil der Rufnummer - an die Abwicklungsinstanz übermittelt, sondern umgekehrt, d.h. dass der Zahlungsempfänger dem Zahler die letzten vier Ziffern seiner Mobiltelefon-Nummer offen legt und der Zahler diese - als Teil der Rufnummer - an die Abwicklungsinstanz übermittelt.
Beide Varianten können auch kombiniert werden, d.h. der Zahler und Zahlungsempfänger legen einander die letzten zwei Ziffern ihrer jeweiligen Mobiltelefon-Nummern offen und übermitteln jeweils die von der anderen Partei erhaltenen zwei Ziffern - als Teil der Rufnummer - an die Abwicklungsinstanz.
Dies könnte wie folgt aussehen: A legt B die Ziffern „67" offen, B legt A die Ziffern „43" offen. A wählt „0800-55555-2350-43", B wählt „0800-66666-2350-67". In diesem Fall ist die Anwahl einer unterschiedlichen Kopf-Rufnummer „0800-55555" ggü. „0800-66666" durch die Transaktionsparteien notwendig, um Zahler vom Empfänger zu unterscheiden. Ansonsten funktioniert das Verfahren analog.
Detailliert arbeiten die Abwicklungsinstanz sowie weitere Instanzen wie folgt:
Die Abwicklungsinstanz 3 ist unter der Kopf-Rufnummer 0800-55555 erreichbar. Zunächst werden die eingehenden Anrufe durch die Abwicklungsinstanz 3 registriert. Vorteilhafterweise werden dabei die Mobiltelefon-Nummern 12 und 13 der Anrufer (MSISDN bzw. ANI) automatisch übermittelt. Aus den gewählten Rufnummern (DNIS) werden die signifikanten Anteile „2350" (7) bzw. „23504567" (T und 8') extrahiert. Daraus leitet die Abwicklungsinstanz die Transaktions-Dalensätze (Teilnehmer-Nummer=0171 -1234567; Funktion=Senden; Betrag=23.50; Sender-Kurzkennung=4567) sowie (Teilnehmer- Nummer=01 1-9876543, Funktion=Empfangen; Betrag=23.50; Sender-Kurzkennung= 4567) ab. Die Transaktions-Datensätze werden in einen Transaktions-Pool zuzuordnender Transaktionen eingestellt. Es werden die Datensätze wieder aus dem Transaktions-Pool gelöscht, zu denen innerhalb des Zeitintervalls, d. h. beispielsweise innerhalb von 20 sec, kein zuzuordnender anderer Datensatz gefunden wurde/wird.
Die Prüflnstanz 9, die von der Abwicklungsinstanz 3 umfasst oder mit dieser verbunden sein kann, prüft, ob eine Zuordnung der Transaktionsparteien 1 und 2 anhand der übermittelten Daten möglich ist. Im aktuellen Beispiel der Zahlungstransaktion ergibt sich daraus auch die Prüfung, ob die jeweiligen Willenserklärungen korrespondieren. Dies geschieht durch einen Vergleich der Datensätze im Transaktions-Pool auf Übereinstimmung der Felder „Betrag" und „Sender-Kurzkennung" (7 und 8 gegen 7' und 8'). Da die Quasi-Simultanität als Zusatzkriterium bewirkt, dass der Transaktions-Pool stets sehr klein ist, ist auch bei einer hohen Transaktionslast sehr wahrscheinlich, dass eine Zuordnung allein anhand der Kriterien „Betrag" und „Sender-Kurzkennung" möglich ist.
Die Abwicklungsinstanz 3 wird in den seltenen Fällen, in denen eine eindeutige Zuordnung deshalb nicht möglich ist, weil mehrere Datensätze mit übereinstimmenden Kriterien im Transaktions-Pool vorliegen, die Eingabe zusätzlicher Merkmale anfordern, z.B. den Zahler 1 über ein IVR-System (Interactive Voice Response) darum bitten, auch die letzten vier Ziffern der Mobiltelefon-Nummer des Empfängers einzugeben.
In dem oben dargestellten ersten Ausführungsbeispiele wurde davon ausgegangen, dass die Mobiltelefon-Nummern der Anrufer (MSISDN bzw. ANI) automatisch übermittelt werden, was die Abwicklung vereinfacht und einen Schutz gegen Missbrauch bewirkt. Diese Übermittlung kann z.B. durch eine spezielle Schaltung des Telekommunikations-Providers auf Seiten der Abwicklungsinstanz erreicht werden, die es ermöglicht, auch solche Anrufer-Nummern anzuzeigen, deren Anzeige normalerweise unterdrückt ist. Dies hat den Vorteil, dass auch Anrufer mit standardmäßiger Rufnummern-Unterdrückung das System ohne Umstellung des Anzeigemodus im Einzelfall nutzen können.
Alternativ kann das Verfahren auch so ausgestaltet werden, dass bei Anrufen von Mobiltelefonen mit unterdrückter Rufnummernanzeige z.B. durch ein IVR-System die Abfrage von Identifizierungsmerkmalen (z.B. der Mobiltelefon-Nummer in Verbindung mit einer PIN oder einer nicht zu einer Mobiltelefon-Nummer korreiierten freien Kundennummer) erfolgt. Die Ausgestaltung freier Kundennummern, die nicht mit einer Mobiltelefon-Nummer verknüpft sind, bietet für die Nutzer des Systems eine Möglichkeit zur Erreichung zusätzlicher Anonymität auch gegenüber der Abwicklungsinstanz.
Im folgenden wird ein zweites Ausführungsbeispiel in einem E-Commerce-Szenario mit
Bezug zu Figur 2 beschrieben, bei dem eine Zahlungstransaktion über das Internet erfolgt, bei der ein Zahler eine Zahlung an z.B. einen Anbieter von Waren oder Dienstleistungen durchführt. Der Zahler mit der Mobiltelefon-Nummer 0171-1234567 gibt auf der Internet-Seite 14 des Anbieters, auf der auch der Zahlbetrag, z.B. EUR 23,50 angezeigt ist, die letzten vier Ziffern 8 seiner Mobiltelefonnummer, also „4567" ein und wählt gleichzeitig an seinem Mobiltelefon 1 die Nummer „0800-55555-2350". Die weitere Abwicklung des Verfahrens geschieht im Prinzip analog zu dem oben dargestellten ersten Ausführungsbeispiel, mit dem Unterschied, dass die Datenübertragung von dem Computersyslem des Anbieters zu der Abwicklungsinstanz 3 z.B. über einen HTTP-Request 15 oder den Aufruf eines Webservice geschieht. Hierbei übermittelt das Computersystem des Anbieters eine Kennung der eigenen Identität 13, den Betrag T sowie die letzten vier Ziffern 8' der Mobiltelefonnummer 12 des Zahlers. Die Rücksignalisierung von der Signalisierungsinstanz 11 zum Computersystem des Anbieters kann wiederum über eine HTTP-Response oder den Rückgabewert des Webservice geschehen. Vorteilhafterweise wird die Datenübertragung zwischen Computersystem und Abwicklungsinstanz 3 bzw. Signalisierungsinstanz 11 durch kryptographische Verfahren zusätzlich gesichert. Im Folgenden wird ein drittes Ausführungsbeispiel für die Durchführung und Dokumentation eines Vertragsabschlusses, kombiniert mit der Durchführung einer Zahlungstransaktion, beschrieben. Prinzipiell funktioniert das dritte Ausführungsbeispiel analog zum oben beschriebenen E-Commerce-Szenario des zweiten Ausführungsbeispiel. Es betrifft eine Zahlungstransaktion im Internet, bei der ein Zahler eine Zahlung an z.B. einen Anbieter von Waren oder Dienstleistungen durchführt. Zusätzlich zur reinen Zahlung vom Zahler an den Anbieter soll in diesem Beispiel jedoch auch ein Kauf- oder Dienstleistungsvertrag zwischen Anbieter und Zahler abgeschlossen und dokumentiert werden. Im Folgenden wird der Zahler daher als Zahler/Käufer bezeichnet.
Dazu wird von dem Inhalt des Vertrages ein digitaler Abdruck (Digest) gebildet, z.B. über einen Hash-Algorithmus wie MD5. Der digitale Abdruck kann z.B. auch aus einer Quersumme oder Checksumme bestehen oder einem Teil der Kreditkartennummer oder den der Kreditkartennummer ergänzend zugeordneten sogenannten CVC-Code enthalten. Der digitale Abdruck wird dabei vorteilhafterweise auf eine relativ kurze, z.B. sechsstellige Ziffernfolge (z.B. „141516") reduziert. Diese sechsstellige Ziffernfolge wird dem Zahler/Käufer auf der Internet-Seite angezeigt und/oder z.B. per E-Mail an den Zahler/Käufer geschickt.
Zusätzlich und/oder alternativ kann der Inhalt des Vertrages auch gespeichert und dauerhaft erfasst werden, indem z.B. an den Zahler/Käufer eine E-Mail mit den Vertragsbedingungen geschickt wird, wobei in der E-Mail eine Referenznummer des Vertrages enthalten ist. Die Referenznummer kann z.B. auch aus einer sechsstelligen Ziffernfolge bestehen (z.B. „949596") und vorteilhafterweise noch Datum, Uhrzeit oder andere Daten mit einschließen. Abweichend vom oben beschriebenen E-Commerce-Szenario übermittelt der Zahler/Käufer nun (zusätzlich zum Betrag) auch die Referenznummer zur Abwicklungsinstanz, z.B. indem er die gewählte Rufnummer („0800-55555-2350") um die besagten sechs Ziffern erweitert, also „0800-55555-2350-949596" wählt. Alternativ kann auch der digitale Abdruck übermittelt werden, z.B. als Teil der Rufnummer, indem „0800-55555-2350-141516" gewählt wird.
Alternativ können auch sowohl der digitale Abdruck als auch die Referenznummer übermittelt werden.
Alternativ kann auch auf die Übermittlung des Zahlbetrages verzichtet werden. Alternativ kann auch der ∑ahlungsspezifische Teil des beschriebenen Verfahrens ausgelassen und das Verfahren nur für die Durchführung und/oder Dokumentation des Vertragsabschlusses genutzt werden. So kann beispielsweise die Zahlung über eine herkömmliche Kreditkarte erfolgen und die Kreditkartenzahlung inklusive der Kreditkartendaten Teil des abgeschlossenen Vertrages sein. Alle Daten können ganz oder teilweise auch per DTMF-Töne oder per SMS oder ein anderes Verfahren übertragen werden.
Durch die dargestellten Verfahrensausgestaltungen wird eine hohe Dokumentations- und Nachweissicherheit über den abgeschlossenen Vertrag erreicht. Dadurch, dass die Datenübermittlung des digitalen Abdrucks (Digests) und/oder der Referenznummer parallel zum Internet über das Mobiltelefon des Benutzers erfolgt, werden die Daten insgesamt gegen Manipulation im Internet geschützt.
Zusätzlich kommen die nach dem Stand der Technik bekannten systemimmanenten Sicherheitsvorteile der Nutzung von Mobiltelefonen für E-Commerce- und/oder M- Commerce-Transaktionen zum Tragen (Besitz bzw. physischer Zugriff auf das Mobiltelefon, Sicherung durch SIM-Karten-PIN und/oder Geräte-PIN).
Weiterhin kann (sofern die Übermittlung der Daten als Teil der Rufnummer erfolgt), die oben beschriebene Beleg-Funktion der Einzelverbindungsnachweis des Telekommunikations- Providers ausgenutzt werden.
Bei dem Verfahren kann eine Implementierung der Abrechnungsfunktionalität z.B. einfach dadurch erfolgen, dass der Anruf, über den die Zahlungstransaktion ausgeführt wird, direkt mit dem in der Telefonnummer enthaltenen Betrag tarifiert wird, sofern die Verbindungsdauer z.B. länger als 10 Sekunden war. Eine Verbindung zur Rufnummer 0800-55555-2350 von z.B. 11 Sekunden Länge würde dann mit einem Betrag von EUR 23,50 in Rechnung gestellt, eine Verbindung zur Rufnummer 0800-55555-2350-4567 von z.B. 11 Sekunden Länge mit einem Gutschriftsbetrag von EUR 23,50 abgerechnet. Diese Funktionalität wäre mit minimalen Software-Updates in den Abrechnungssystemen implementierbar. Es müssten nur wenige weitergehende technische Vorrichtungen oder Schnittstellen geschaffen werden. Vorteilhafterweise funktioniert das Verfahren für Zahler wie Empfänger symmetrisch - im Unterschied zu herkömmlichen Verfahren, bei denen auf Empfängerseite andere Systeme und Schnittstellen zum Einsatz kommen als auf Zahlerseife.
Im Folgenden wird ein viertes Ausführungsbeispiel mit Bezug zu Figur 3 erläutert. Dieses Ausführungsbeispiel betrifft eine Implementierungvariante, welche insbesondere zur Anwendung in POS-(point-of-sale)-Kassensystemen geeignet ist, die in der Regel anstelle eines Internet-Anschlusses nur über Festnetz-Telefonanschlüsse ∑ur Kommunikation von Kreditkarten-Terminals oder vergleichbaren Geräten mit einer Autorisierungs∑entrale verfügen.
Der Kunde teilt dem Kassierer die letzten vier Ziffern 8 seiner Mobiltelefon-Nummer 12 mit. Diese wird vom Kassierer in eine Kasse oder ein Kreditkarten-Terminal 16 oder ein vergleichbares Gerät (im folgenden „Terminal" genannt) eingegeben und von dem Terminal an ein verbundenes oder integriertes Festnetz- oder Mobilfunk-Modem übergeben, das einen Telefonanruf zur Abwicklungsinstanz initiiert und dabei wie im ersten Ausführungsbeispiel als Telefonnummer die „0800-55555-2350-4567" wählt. Sofern die oben beschriebene Verfahrensvariante des ersten Ausführungsbeispiels zum Einsatz kommt, bei der eine Mindestdauer der Verbindung Kennzeichen für eine erfolgreiche Transaktion ist, genügt für das Terminal zur Entscheidung, ob die Zahlung erfolgreich war, prinzipiell allein die Prüfung, ob die Modemverbindung länger als die Mindestdauer bestand. Dadurch kann die Abwicklung des Verfahrens gegenüber Protokollen, bei denen ein zeitaufwendiger Modemprotokoll-Verbindungsaufbau erfolgt, stark beschleunigt werden. Dies führt auch zu einer Reduktion der Telekommunikationskosten. Eine detailliertere Rückmeldung der Abwicklungsinstanz an das Kassensystem im Fehlerfall ist in der Regel nicht nötig, da der Zahler bzw. Kunde seinerseits eine akustische Rückmeldung über eine Fehlerursache erhält.
Im Folgenden werden Varianten, die in Verbindung mit den obigen Ausführungsbeispielen umgesetzt werden können, beschrieben: Wie oben bereits beschrieben, ist das Verfahren in den Fällen, in denen die Datenübermittlung an die Abwicklungsinstanz 3 über Telefonanrufe erfolgt, so ausgestaltet, dass ein Teil der Verarbeitungsschritte bereits abgewickelt wird, bevor der Anruf von der Abwicklungsinstanz angenommen wird und ferner so, dass die Verbindungsdauer einer erfolgreichen Transaktion sich von der einer nicht erfolgreichen Transaktion unterscheidet. Schließlich könnte das oben dargestellte erste Beispiel wie folgt abgewandelt werden: statt der Signalisierung eines Freizeichens während der Abwicklung der Transaktion werden die Anrufe von Zahler und Empfänger direkt nach dem Eingang bei der Abwicklungsinstanz von dieser durch eine spezielle Signalisierungsnachricht an die Vermittlungsstelle abgelehnt, wodurch bei Zahler und Empfänger z.B. ein Besetzt-Signal ertönt. Wenige Sekunden später erhalten Zahler und Empfänger einen eingehenden Anruf von der Signalisierungsinstanz, wobei von der Signalisierungsinstanz als Anrufer-Nummer (ANI) die spezielle Anrufer- Rufnummer „0800-55555-2350" generiert wird, sofern die Zahlung erfolgt ist, bzw. „0800- 55555-0000", wenn die Zahlung nicht durchgeführt werden kann. Aus der im Display angezeigten Anrufer-Nummer können Zahler und Empfänger so ersehen, ob die Zahlung erfolgreich war oder nicht. Vorteilhafterweise bleibt der Eintrag weiterhin in der Anruferliste des Mobiltelefons gespeichert, was ein späteres nochmaliges Überprüfen ermöglicht. Vorteilhaft gegenüber einer Signalisierung durch Versand einer SMS ist die schnellere und gesichert kurze Übertragungsdauer.
Ferner sind Ausgestaltungen des Verfahrens möglich, bei denen zwischen beiden Transaktionsparteien eine Telefonverbindung hergestellt wird (sofern beide Transaktionsparteien ein Festnetztelefon oder Mobiltelefon verwenden). Diese Variante ist insbesondere dann sinnvoll, wenn z.B. eine Zahlungstransaktion für eine telefonische Beratung o.a. erfolgt und die Dienstleistung gleich über die hergestellte Telefonverbindung erbracht wird.
Für den Fall, dass z.B. innerhalb einer bestehenden Mobil-Telefonverbindung zwischen den Transaktionsparteien eine Zahlungstransaktion unter Nutzung der Mobiltelefone erfolgen soll, könnte das im ersten Beispiel beschriebene Verfahren so abgewandelt sein, dass die Übermittlung des Zahlbetrages und der letzten vier Ziffern der Mobiltelefon-Nummer des Zahlers über DTMF-Töne erfolgt, die innerhalb der Verbindung von den Transaktionsparteien gesendet werden. In diesem Fall könnten die DTMF-Töne vom Vermittlungssystem ausgefiltert und an die Abwicklungsinstanz weitergeleitet werden oder es könnte eine temporäre Telefon-Verbindung der Transaktionsparteien mit der Abwicklungsinstanz initiiert werden.
Im Folgenden wird ein Ausführungsbeispiel des Computersystems bzw. der Abwicklungsinstanz mit Bezug zu Figur 4 beschrieben: Wie bereits im ersten Ausführungsbeispiel erläutert, senden die Mobiltelefone 1 und 2 eines Zahlers und eines Zahlungsempfängers zeitnah die Telefonanrufe 5 und 6 an das Computersystem. Die bei der Anwahl verwendeten Telefonnummern enthalten einerseits den Betrag 7 bzw. T für die Zahlungstransaktion. Femer enthält eine Telefonnummer eine Referenz 8' auf die Telefonnummer des anderen. Das Computersystem ist beispielsweise in ein System des Telekommunikationsproviders integriert. Es weist einen Eingang 18 auf, der die gewählten Telefonnummern von eingehenden Anrufen aufnehmen kann, ohne dass die Anrufe 5 und 6 gleich angenommen werden müssen. Der Eingang 18 leitet diese Daten in einen Transaktions-Pool-Speicher 19 weiter. Mit dem Transaktions-Pool-Speicher 19 ist eine Prüfinstanz 9 verbunden. Diese prüft beim Eingang eines Datensatzes, ob diesem Datensatz ein anderer Datensatz des Transaktions-Pool-Speichers 19 zugeordnet werden kann. Hierzu extrahiert sie aus einem Anruf zumindest die Kennung des Anrufers, der den Anruf getätigt hat, und aus der Anwahlnummer den zu zahlenden Betrag sowie ggf. den Zahlungszuordnungs- Referenzcode 8'. Nun prüft die Prüfinstan∑ 9, ob die Kennungen der Telefone, über die die Anrufe 5 und 6 getätigt worden sind, in einer Datenbank des Computersystems gespeichert sind. Hierüber kann dass Computersystem eine Verbindung zu registrierten Nutzem und deren Daten für die Zahlungstransaktion gewinnen. Beispielsweise können für die Nutzer die Kontoverbindungsdaten oder die Kreditkartennummern ermittelt werden. Des Weiteren prüft die Prüfinstanz 9, ob die in den Anrufen enthaltenen Willenserklärungen korrespondieren. Im vorliegenden Beispiel prüft die Prüfeinheit 9, ob der Zahlungszuordnungsreferenzcode 8' tatsächlich den letzten 4 Ziffern der Telefonnummer des anderen Anrufs 5 entspricht. Falls alle Prüfungen positiv sind, übermittelt die Prüfinstanz 9 die Daten an die mit ihr verbundene Transaktionsinstanz 10 und die Datensätze werden aus dem Transaktions-Pool-Speicher 19 entfernt.
Falls zu einem eingehenden Datensatz kein anderer Datensatz in dem Transaktions-Pool- Speicher 19 gefunden wird, der diesem zugeordnet werden kann, werden alle Datensätze in dem Transaktions-Pool-Speicher 19 gelöscht, die länger als das vorgegebene Zeitintervall in dem Transaktions-Pool-Speicher 19 enthalten sind. Der Transaktions-Pool-Speicher 19 umfasst somit eine Datenbank, in der jeweils zeitnah eingehende Anrufe abgespeichert sind und durch die bei neu eingehenden Datensätzen geprüft werden kann, ob Datensätze einander zugeordnet werden können.
Die Transaktionsinstanz 10 kann diese Daten in Zahlungsanweisungsdaten 21 umwandeln. Dies sind beispielsweise Anweisungen über einen Lastschrifteinzug von einem Konto des Zahlenden, sowie parallel über eine Überweisung eines bestimmten Betrages auf ein Konto des Zahlungsempfängers. Die Transaktionsinstanz 10 übermittelt die Zahlungsanweisungsdaten 21 in diesem Fall beispielsweise über eine Internetverbindung an die Bank der Abwicklungsinstanz bzw. die Banken des Zahlenden und des Zahlungsempfängers. Hierfür ist in dem Computersystem ein Ausgang 20 vorgesehen.
Des Weiteren kann mit der Transaktionsinstanz 10 und dem Ausgang 20 eine
Signalisierungsinstanz 11 verbunden sein. Für den Fall, dass Zahlungsanweisungsdaten 21 übermittelt worden sind, sendet die Signalisierungsinstanz 11 Signalisierungen 22 über die
Initiierung der Zahlungstransaktion an das Telefon 1 des Zahlers und/oder an das Telefon 2 des Zahlungsempfängers. Ferner können die Signalisierungen 22 auch an andere Empfänger, beispielsweise gespeicherte E-Mail-Adressen des Zahlers und des Zahlungsempfängers gesandt werden. Schließlich kann die Signalisierungsinstanz 11 auch Signalisierungeri 22 über eine nicht erfolgte Transaktion versenden. Außerdem können die Signalisierungen 22 auch schon dann versandt werden, wenn die Prüfung der Prüfinstanz 9 positiv war. Die Signalisierungen 22 können wie mit Bezug zu den ersten Ausführungsbeispielen erläutert erfolgen.
Für die Zahlungstransaktion mit dem Computersystem sind auf Seiten des Zahlenden und des Zahlungsempfängers somit nur zwei Eingaben durchzuführen: Der Zahlende teilt dem Zahlungsempfänger einen Teil seiner Telefonnummer mit. Dieser startet eine Zahlungsanwendung auf seinem Mobiltelefon 2 und gibt diesen Teil 8 der Telefonnummer in sein Mobiltelefon 2 ein. Danach startet auch der Zahlende die Zahlungstransaktionsanwendung auf seinem Mobiltelefon 1. Beide Parteien geben dann den zu zahlenden Betrag 7 bzw. T in der Anwendung der Mobiltelefone 1, 2 ein und drücken im Wesentlichen simultan eine Taste für den Start der Zahlungstransaktion. Daraufhin erzeugen die Anwendungen auf den Mobiltelefonen 1 und 2 automatisch die Telefonnummer 5 und 6 und senden sie an das Computersystem. Das Computersystem initiiert daraufhin die Zahlungstransaktion durch die Übermittlung von Zahlungsanweisungsdaten 21 an die Bank des Zahlenden. Ferner wird die Zahlungstransaktion von dem Computersystem dokumentiert.

Claims

Patentansprüche
1.) Verfahren zum Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion, insbesondere einer Zahlungstransaktion, zwischen mindestens zwei Transaktionsparteien über eine Abwicklungsinstanz, bei dem mindestens eine der
Transaktionsparteien ein Festnetztelefon oder Mobiltelefon (1, 2) oder ein mobiles Kommunikationsgerät zur Übermittlung von Daten benut∑t, dadurch gekennzeichnet, a) dass mindestens zwei der Transaktionsparteien Daten an die Abwicklungsinstanz übermitteln, wobei die Übermittlung der Daten innerhalb eines begrenzten Zeitfensters erfolgt, und b) dass die Initiierung der Datenübermittlung dieser Transaktionsparteien aktiv durch die Transaktionsparteien und nicht durch die Abwicklungsinstanz (3) erfolgt, wobei die bei der Initiierung übertragenen Daten Merkmale enthalten, die die Zuordnung der Willenserklärungen untereinander ermöglichen.
2.) Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Datenübermittlung mindestens einer der Transaktionsparteien durch die Initiierung eines Telefonanrufs zur Abwicklungsinstanz (3) erfolgt.
3.) Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Übermittlung mindestens eines Teils der von mindestens einer der Transaktionsparteien übermittelten Daten durch die beim Aufbau eines Telefonanrufs zur Abwicklungsinstanz (3) gewählte Telefonnummern-Ziffernfolge erfolgt.
4.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine Kombination von zwei Transaktionsparteien existiert, für die gilt, dass die von einer Transaktionspartei übermittelten Daten (5, 6) hinreichend sind, um eine eindeutige Identifikation dieser Transaktionspartei zu ermöglichen, aber nicht hinreichend sind, um eine Identifikation der anderen Transaktionspartei zu ermöglichen.
5.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die von mindestens zwei der Transaktionsparteien an die Abwicklungsinstanz (3) übermittelten Daten (5, 6) zueinander nach einer bestimmten Vorschrift in Beziehung stehen.
6.) Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Abwicklungsinstanz (3) eine Prüfinstanz (9) umfasst oder mit einer Prüfinstanz (9) verbunden ist, die nach der Datenübermittlung prüft, ob eine Zuordnung der Transaktionsparteien anhand der jeweils übermittelten Daten (5, 6) möglich ist.
7.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Datenübermittlung von den Transaktionsparteien an die Abwicklungsinstanz (3) über Mobiltelefone (1 , 2) durchgeführt wird, dass bei der Datenübermittlung Informationen über die Aufenthaltsorte der Mobiltelefone mit übermittelt werden und dass diese Informationen als zusätzliches Zuordnungskriterium verwendet werden.
8.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Abwicklungsinstanz (3) eine Transaktionsinstanz (10) umfasst oder mit einer Transaktionsinstanz (10) verbunden ist, die nach einer positiven Prüfung durch die Prüfinstanz (9) die den Daten (5, 6) zugeordnete Transaktion durchführt.
9.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass beide Transaktionsparteien ein Festnetztelefon oder Mobiltelefon (1 , 2) verwenden und dass zwischen beiden Transaktionsparteien eine Telefonverbindung hergestellt wird.
10.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Abwicklungsinstanz (3) eine Signalisierungsinstanz (11) umfasst oder mit einer Signalisierungsinstanz (11) verbunden ist, die Signalisierungen auslöst und/oder Daten an die Transaktionsparteien oder an andere Empfänger übermittelt.
11.) Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Signalisierung dadurch erfolgt, dass von der Abwicklungsinstanz (3) ein Rückruf an mindestens eine der Transaktionsparteien initiiert wird.
12.) Verfahren nach Anspruch 11 , dadurch gekennzeichnet, dass die Signalisierung dadurch erfolgt, dass bei dem von der Abwicklungsinstanz (3) initiierten Rückruf von der Abwicklungsinstanz (3) eine spezielle Anrufer-Rufnummer (ANI) generiert und übergeben wird, wobei aus dieser ANI Rückschlüsse auf das Ergebnis der Prüfinstanz (9) und/oder auf den Status der Durchführung von Transaktionen durch die Transaktionsinstanz (10) möglich sind.
13.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die erfolgreiche Durchführung der Transaktion oder ein anderer Status den Transaktionsparteien synchron durch ein akustisches Signal signalisiert wird
14.) Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass die Signalisierung dadurch erfolgt, dass der Anruf a) durch Abheben der Abwicklungsinstanz angenommen wird b) oder unter Signalisierung eines Freizeichens nicht angenommen wird c) oder ein Besetzt-Signal oder ein anderes Signal signalisiert wird d) oder dass unterschiedlich lange Zeitintervalle zwischen dem Übergang verschiedener Rufaufbau-Signale und/oder Rufabbau-Signale liegen.
15.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass im Falle einer erfolgreichen Durchführung der Transaktion zwischen Annahme und Beendigung des Anrufs ein längeres oder kürzeres Zeitintervall liegt als im Falle einer nicht erfolgreichen Durchführung der Transaktion
16.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Willenserklärungen mindestens auf die Durchführung eines Zahlungsvorgangs betreffend Geld- oder Werteinheiten gerichtet sind.
17.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Transaktion mindestens in der Veranlassung oder Durchführung eines
Zahlungsvorgangs betreffend Geld oder Werteinheiten besteht.
18.) Verfahren nach Ansprüche 17, dadurch gekennzeichnet, dass die übermittelten Daten (5, 6) beider Transaktionsparteien den zu zahlenden Betrag an Geld oder Werteinheiten enthalten.
19.) Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zusätzlich ein Zuordnungs-Referenzcode (8') übertragen wird, der die eindeutige Zuordnung der Transaktionsparteien ermöglicht oder erleichtert.
20.) Verfahren nach Anspruch 19, dadurch gekennzeichnet, dass der Zuordnungs-Referenzcode aus einem Teil der Ziffern der Rufnummer (ANI) mindestens einer anderen Transaktionspartei besteht, die ein Festnetztelefon oder Mobiltelefon oder ein mobiles Kommunikationsgerät zur Übermittlung der Daten benutzt, oder über eine bestimmte Vorschrift aus dieser Rufnummer gebildet wird.
21.) Verfahren nach einem der Ansprüche 17 bis 20, dadurch gekennzeichnet, dass die Festlegung des Zahlbetrages durch eine aktive Eingabe des Betrages (7, T) und nicht durch passive Bestätigung eines angezeigten oder angesagten Betrages erfolgt.
22.) Verfahren nach einem der vorhergehenden Ansprüche, wobei die Transaktionsparteien einen Zahler und einen Zahlungsempfänger umfassen, dadurch gekennzeichnet, dass a) der Zahler einen Telefonanruf (5) an die Abwicklungsinstanz (3) initiiert, wobei die dabei gewählte Telefonnummer eine Ziffernfolge (7) enthält, die dem Zahlbetrag entspricht, b) der Zahlungsempfänger simultan oder zeitnah zum Anruf (5) des Zahlers Daten (6) an die Abwicklungsinstanz übermittelt, die den Zahlbetrag (7') enthalten, c) eine Prüfinstanz 9 prüft, ob die von Zahler und Zahlungsempfänger übermittelten Daten (5, 6) einander eindeutig zuordenbar sind und mindestens die enthaltenen Zahlbeträge (7, 7') übereinstimmen, d) eine Transaktionsinstanz (10) prüft, ob anhand der übermittelten Daten (5, 6) eine Identifikation und/oder Legitimation von Zahler und Zahlungsempfänger möglich ist und/oder ob die Verarbeitung des Zahlungsvorgangs möglich ist e1 ) bei positiver Prüfung von Prüfinstan∑ (9) und Transaktionsinstanz (10) die Transaktionsinstanz (10) die Weiterverarbeitung durchführt oder veranlasst, - der Anruf des Zahlers von einer Signalisierungsinstanz (11) angenommen wird, ein Bestätigungssignal über die erfolgte Zahlung an den Zahlungsempfänger übermittelt wird, e2) für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, der Anruf des Zahlers von der Abwicklungsinstanz (3) nicht angenommen wird oder verzögert angenommen wird und/oder eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung nicht erfolgt ist.
23.) Verfahren nach Anspruch 22, dadurch gekennzeichnet, dass a) auch die Übermittlung der Daten des Zahlungsempfängers an die
Abwicklungsinstanz (3) dadurch erfolgt, dass der Zahlungsempfänger einen
Telefonanruf (6) an die Abwicklungsinstanz (3) initiiert, wobei die dabei gewählte Telefonnummer eine Ziffernfolge ( ) enthält, die dem Zahlbetrag entspricht, b1) bei positiver Prüfung von Prüfinstan∑ (9) und Transaktionsinstan∑ (10) nach erfolgter Zahlung das Bestätigungssignal an den Zahlungsempfänger dadurch übermittelt wird, dass auch der Anruf des Zahlungsempfängers von der Signalisierungsinstanz (11 ) angenommen wird, b2) für den Fall, dass eine der vorangegangenen Prüfungen negativ ausfällt, auch der Anruf des Zahlungsempfängers nicht angenommen wird oder verzögert angenommen wird und/oder eine akustische Ansage erfolgt, aus der hervorgeht, dass die Zahlung nicht erfolgt ist.
24.) Verfahren nach einem der Ansprüche 8 bis 23, dadurch gekennzeichnet, dass Prüfungs- und/oder Verarbeitungsschritte bereits ausgeführt werden, bevor der Anruf durch Abheben der Abwicklungsinstanz angenommen wird.
25.) Verfahren nach einem der Ansprüche 8 bis 23, dadurch gekennzeichnet, dass der Anruf nur im Falle einer erfolgreichen Durchführung der Transaktion durch Abheben der Abwicklungsinstanz angenommen wird.
26.) System zum Initiieren und/oder Durchführen einer mit mindestens zwei korrespondierenden Willenserklärungen in Beziehung stehenden Transaktion, insbesondere einer Zahlungstransaktion, mit einem ersten Kommunikationsgerät (1 ), das einer ersten Transaktionspartei zugeordnet ist, einem zweiten Kommunikationsgerät (2), das einer zweiten Transaktionspartei zugeordnet ist, und einer Abwicklungsinstanz (3), mit der Daten von den Kommunikationsgeräten (1, 2) empfangbar sind, dadurch gekennzeichnet, dass die Abwicklungsinstanz (3) eine Prüfinstanz (9) umfasst oder mit einer Prüfinstanz (9) verbunden ist, mit der prüfbar ist, ob eine Zuordnung der Transaktionsparteien anhand von jeweils von den Kommunikationsgeräten (1 , 2) innerhalb eines begrenzten Zeitfensters übermittelten
Daten möglich ist.
27.) Computersystem zum Initiieren und/oder Durchführen einer Zahlungstransaktion mit einem Eingang (18) zum Empfang von Daten (5, 6) eines ersten und eines zweiten Kommunikationsgeräts (1 , 2), wobei die Daten (5, 6) Merkmale (7, 7', 8') enthalten, d ie eine Zuordnung von zwei korrespondierenden Willenserklärungen ermöglichen, gekennzeichnet durch: einen mit dem Eingang (18) verbundenen Transaktions-Pool-Speicher (19), der 5 innerhalb eines Zeitintervalls eingehende Daten zwischenspeichert, eine mit dem Transaktions-Pool-Speicher (19) verbundene Prüfinstanz (9), mit welcher die in dem Transaktions-Pool-Speicher (19) gespeicherten Daten so analysierbar sind, dass zumindest Kennungen des ersten und zweiten Kommunikationsgeräts (1 , 2) und ein ∑u zahlender Betrag gewinnbar sind und prüfbar ist, ob eine Zuordnung der o Transaktionsparteien anhand der jeweils übermittelten Daten (5, 6) möglich ist und ob die jeweiligen Willenserklärungen korrespondieren, eine mit der Prüfinstanz (9) verbundene Transaktionsinstanz (10), mit welcher bei positiver Prüfung die in der Prüfinstanz (9) gewonnenen Daten in Zahlungsanweisungsdaten (21) umsetzbar sind, und 5 einem mit der Transaktionsinstanz (10) verbundenen Ausgang (20), über den die
Zahlungsanweisungsdaten (21) an eine Zahlungsabwicklungsinstanz übermittelbar sind.
28.) Computersystem nach Anspruch 27, gekennzeichnet durch eine mit der Transaktionsinstanz (10) und dem Ausgang (20) verbundene Signalisierungsinstanz 0 (11), mit welcher in Abhängigkeit von der Übermittlung der Zahlungsanweisungsdaten
(21 ) und/oder von der Prüfung der Prüfinstanz (9) Signalisierungen (22) über die Initiierung der Zahlungstransaktion und/oder das Ergebnis der Prüfung an zumindest ein Kommunikationsgerät oder an andere Empfänger übertragbar sind.
29.) Computersystem nach Anspruch 27 oder 28, dadurch gekennzeichnet, dass die 5 Kommunikationsgeräte (1 , 2) ein Festnetztelefon und/oder Mobiltelefon sind.
30.) Computerprogramm mit Programmcode-Mitteln, um alle Schritte von jedem beliebigen der Ansprüche 1 bis 25 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.
31.) Computerprogrammprodukt mit Programmcode-Mitteln die auf einem 0 computerlesbaren Datenträger gespeichert sind, um das Verfahren nach jedem beliebigen der Ansprüche 1 bis 25 durchzuführen, wenn das Programmprodukt auf einem Computer ausgeführt wird.
PCT/EP2004/002520 2003-03-11 2004-03-11 Verfahren und system zum initiieren und/oder durchführen einer mit mindestens zwei korrespondierenden willenserklärungen in beziehung stehenden transaktion WO2004081892A2 (de)

Priority Applications (9)

Application Number Priority Date Filing Date Title
JP2006504645A JP2006524938A (ja) 2003-03-11 2004-03-11 少なくとも２つの対応する意思表示に関連づけられたトランザクションを開始および／または実行する方法およびシステム
AU2004219478A AU2004219478A1 (en) 2003-03-11 2004-03-11 Method and system for initiating and/or carrying out a transaction that is associated with at least two professed intentions
EP04719443A EP1602088A2 (de) 2003-03-11 2004-03-11 Verfahren und system zum initiieren und/oder durchführen einer mit mindestens zwei korrespondierenden willenserklärungen in beziehung stehenden transaktion
US10/548,492 US7702581B2 (en) 2003-03-11 2004-03-11 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
CA002518448A CA2518448A1 (en) 2003-03-11 2004-03-11 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
US12/728,544 US8065232B2 (en) 2003-03-11 2010-03-22 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
US13/285,201 US8566238B2 (en) 2003-03-11 2011-10-31 Method for a payment transaction associated with two corresponding declarations of intent
US13/941,807 US8831990B2 (en) 2003-03-11 2013-07-15 Method and system for a payment transaction associated with a declaration of intent
US14/476,780 US20140372292A1 (en) 2003-03-11 2014-09-04 Method and system for a payment transaction associated with a declaration of intent

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10310527.1 2003-03-11
DE10310527A DE10310527B4 (de) 2003-03-11 2003-03-11 Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10/548,492 A-371-Of-International US7702581B2 (en) 2003-03-11 2004-03-11 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
US12/728,544 Continuation US8065232B2 (en) 2003-03-11 2010-03-22 Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent

Publications (2)

Publication Number Publication Date
WO2004081892A2 true WO2004081892A2 (de) 2004-09-23
WO2004081892A3 WO2004081892A3 (de) 2004-10-28

Family

ID=32892028

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/002520 WO2004081892A2 (de) 2003-03-11 2004-03-11 Verfahren und system zum initiieren und/oder durchführen einer mit mindestens zwei korrespondierenden willenserklärungen in beziehung stehenden transaktion

Country Status (8)

Country Link
US (5) US7702581B2 (de)
EP (1) EP1602088A2 (de)
JP (1) JP2006524938A (de)
CN (1) CN1788292A (de)
AU (1) AU2004219478A1 (de)
CA (1) CA2518448A1 (de)
DE (1) DE10310527B4 (de)
WO (1) WO2004081892A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7702581B2 (en) * 2003-03-11 2010-04-20 Christian Hogl Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7353382B2 (en) 2002-08-08 2008-04-01 Fujitsu Limited Security framework and protocol for universal pervasive transactions
US7801826B2 (en) 2002-08-08 2010-09-21 Fujitsu Limited Framework and system for purchasing of goods and services
US7822688B2 (en) 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
US7784684B2 (en) * 2002-08-08 2010-08-31 Fujitsu Limited Wireless computer wallet for physical point of sale (POS) transactions
US7341180B2 (en) * 2004-01-29 2008-03-11 Alpha Network Co., Ltd. Card settlement system
US20080281737A1 (en) * 2004-02-05 2008-11-13 Veritas Mobile Solutions Pte. Ltd. System and Method for Authenticating the Identity of a User
US7877605B2 (en) 2004-02-06 2011-01-25 Fujitsu Limited Opinion registering application for a universal pervasive transaction framework
US10862994B1 (en) * 2006-11-15 2020-12-08 Conviva Inc. Facilitating client decisions
US7734463B1 (en) * 2004-10-13 2010-06-08 Intervoice Limited Partnership System and method for automated voice inflection for numbers
US8874725B1 (en) 2006-11-15 2014-10-28 Conviva Inc. Monitoring the performance of a content player
US20080126258A1 (en) * 2006-11-27 2008-05-29 Qualcomm Incorporated Authentication of e-commerce transactions using a wireless telecommunications device
US7848980B2 (en) * 2006-12-26 2010-12-07 Visa U.S.A. Inc. Mobile payment system and method using alias
FR2919742B1 (fr) * 2007-08-01 2010-10-22 Phoum Lib Procede technique de securisation permettant de certifier les actions utilisateur lors de transactions sur terminaux mobiles
US9177313B1 (en) * 2007-10-18 2015-11-03 Jpmorgan Chase Bank, N.A. System and method for issuing, circulating and trading financial instruments with smart features
US8249985B2 (en) * 2007-11-29 2012-08-21 Bank Of America Corporation Sub-account mechanism
US8813182B2 (en) * 2008-01-30 2014-08-19 Ebay Inc. Near field communication activation and authorization
WO2010086879A1 (en) * 2009-01-16 2010-08-05 Mchek India Payment Systems Pvt. Ltd. A system and method for carrying out a financial transaction
US20110022522A1 (en) * 2009-06-04 2011-01-27 Alan Sege Method and system for providing real-time access to mobile commerce purchase confirmation evidence
US9203913B1 (en) * 2009-07-20 2015-12-01 Conviva Inc. Monitoring the performance of a content player
CN101996451B (zh) * 2009-08-14 2012-07-25 中国工商银行股份有限公司 银行自助设备系统的测试方法及服务器
US20110046969A1 (en) * 2009-08-24 2011-02-24 Mark Carlson Alias hierarchy and data structure
CN102511051B (zh) * 2009-09-24 2016-07-27 日本电信电话株式会社 电子结算方法
US20110076941A1 (en) * 2009-09-30 2011-03-31 Ebay Inc. Near field communication and network data/product transfer
US8781393B2 (en) 2009-09-30 2014-07-15 Ebay Inc. Network updates of time and location
US20110195748A1 (en) * 2010-02-09 2011-08-11 Jonathan Main Enhanced security feature for payment-enabled mobile telephone
US9665864B2 (en) * 2010-05-21 2017-05-30 Intel Corporation Method and device for conducting trusted remote payment transactions
US8995630B1 (en) 2010-08-01 2015-03-31 Tulsa Holdings, Llc Telephony and applications communication in a non-mobile telephone system
USD774529S1 (en) 2010-11-04 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
US9836780B2 (en) 2010-11-19 2017-12-05 Mastercard International Incorporated Method and system for consumer transactions using voice or human based gesture actions
US9836737B2 (en) * 2010-11-19 2017-12-05 Mastercard International Incorporated Method and system for distribution of advertisements to mobile devices prompted by aural sound stimulus
US9384499B2 (en) 2010-11-19 2016-07-05 Mastercard International Incorporated Method and system for indirect control of a website
US10043209B2 (en) 2010-11-19 2018-08-07 Mastercard International Incorporated Method and system for consumer transactions using voice or human based gesture actions
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
USD774526S1 (en) 2011-02-21 2016-12-20 Bank Of America Corporation Display screen with graphical user interface for funds transfer
CA2831080A1 (en) * 2011-04-07 2013-07-18 Fotec Group Llc Broker-mediated payment systems and methods
US8725586B2 (en) * 2011-08-17 2014-05-13 Douglas Levin Accounting system and management methods of transaction classifications that is simple, accurate and self-adapting
DE102011087959A1 (de) * 2011-12-08 2013-06-13 Ford Global Technologies, Llc Verfahren und Vorrichtung zur Abwicklung einer straßennutzungsabhängigen Finanztransaktion sowie Computerprogrammprodukt
US10127540B2 (en) 2011-12-19 2018-11-13 Paypal, Inc. System and method for facilitating electronic financial transactions during a phone call
CN103457913B (zh) * 2012-05-30 2017-10-13 阿里巴巴集团控股有限公司 数据处理方法、通信终端、服务器及系统
US10182096B1 (en) 2012-09-05 2019-01-15 Conviva Inc. Virtual resource locator
US9246965B1 (en) 2012-09-05 2016-01-26 Conviva Inc. Source assignment based on network partitioning
USD770478S1 (en) 2012-09-07 2016-11-01 Bank Of America Corporation Communication device with graphical user interface
US8959032B2 (en) 2012-10-10 2015-02-17 Quisk, Inc. Self-authenticating peer to peer transaction
US20150095239A1 (en) * 2013-09-30 2015-04-02 Fiserv , Inc. Card account identifiers associated with conditions for temporary use
CN105338480B (zh) * 2014-06-24 2020-01-24 创新先进技术有限公司 基于lbs的用户匹配方法、消息客户端、服务器及系统
US10178043B1 (en) 2014-12-08 2019-01-08 Conviva Inc. Dynamic bitrate range selection in the cloud for optimized video streaming
US10305955B1 (en) 2014-12-08 2019-05-28 Conviva Inc. Streaming decision in the cloud
GB2535433A (en) * 2014-12-12 2016-08-24 Aeriandi Ltd Method and apparatus for call correlation
DE102015118999A1 (de) * 2015-11-05 2017-05-11 Deutsche Post Ag Vorzeitige Auslösung des Bezahlprozesses für Nachnahme-Sendungen
US10762788B2 (en) 2017-08-01 2020-09-01 Swoppz, LLC Method and system for requesting and granting priority between vehicles
JP7030043B2 (ja) * 2018-11-27 2022-03-04 本田技研工業株式会社 対価を伴う優先的な通行を行うための情報処理装置、情報処理装置の制御方法、通信装置、通信装置の制御方法、およびプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19903822A1 (de) * 1999-02-02 2000-08-10 Mathias Entenmann Verfahren zur Durchführung bargeldloser Zahlungen und System zur Durchführung des Verfahrens
DE10008280C1 (de) * 2000-02-23 2001-06-13 Wire Card Ag Verfahren und System zur automatischen Abwicklung von bargeldlosen Kaufvorgängen
DE10039569C1 (de) * 2000-08-09 2001-12-06 Mannesmann Ag Verfahren zur Bezahlung an beliebigen Verkaufs- bzw. Dienstleistungsstellen mit Mobiltelefon
US6464134B1 (en) * 1999-12-10 2002-10-15 Terri Page System and method for verifying the authenticity of a check and authorizing payment thereof

Family Cites Families (101)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4960981A (en) * 1989-01-17 1990-10-02 Moneyfax, Inc. Method of and system for electronic funds transfer via facsimile machines
US5122950A (en) * 1989-11-02 1992-06-16 Moneyfax, Inc. Method of and system for electronic funds transfer via facsimile machines
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US5557518A (en) * 1994-04-28 1996-09-17 Citibank, N.A. Trusted agents for open electronic commerce
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5583759A (en) * 1993-11-22 1996-12-10 Huntington Bancshares, Inc. Mechanism for expediting the deposit, transport and submission of checks into the payment system
US6996542B1 (en) * 1994-06-03 2006-02-07 Midwest Payment Systems System and method for paying bills and other obligations including selective payor and payee controls
US5608778A (en) * 1994-09-22 1997-03-04 Lucent Technologies Inc. Cellular telephone as an authenticated transaction controller
US5577100A (en) * 1995-01-30 1996-11-19 Telemac Cellular Corporation Mobile phone with internal accounting
US7069451B1 (en) * 1995-02-13 2006-06-27 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
CA2683230C (en) * 1995-02-13 2013-08-27 Intertrust Technologies Corporation Systems and methods for secure transaction management and electronic rights protection
US6424249B1 (en) * 1995-05-08 2002-07-23 Image Data, Llc Positive identity verification system and method including biometric user authentication
FI102860B (fi) * 1995-11-07 1999-02-26 Nokia Telecommunications Oy Menetelmä ja järjestelmä elektronisen maksutapahtuman suorittamiseksi
US5991749A (en) * 1996-09-11 1999-11-23 Morrill, Jr.; Paul H. Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities
JP3660101B2 (ja) * 1996-11-14 2005-06-15 松下電器産業株式会社 パーソナル電子決済システム
US6199761B1 (en) * 1996-12-09 2001-03-13 Drexler Technology Corporation Validation method for electronic cash cards and digital identity cards utilizing optical data storage
GB2321751B (en) * 1997-04-22 1999-02-10 Searchspace Limited A monitoring system and method
PT992025E (pt) * 1997-06-27 2002-12-31 Swisscom Mobile Ag Processo de transaccao com um elemento de identificacao portatil
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
DE19905054A1 (de) 1999-02-08 2000-08-17 Siemens Ag Verfahren und Anordnung zur Administration eines Zahlungsvorgangs über ein Telekommunikationsnetz
EP1617389A3 (de) * 1999-02-18 2006-09-27 Matsushita Electric Industrial Co., Ltd. Servergerät und Terminal von einem Nutzer zum Gebrauch in einem Gebrauchssystem für elektronische Vermögenswerte
KR100314210B1 (ko) * 1999-02-23 2001-11-17 김용훈 이동통신단말기를 이용한 물품대금 결제방법
US6873691B1 (en) * 1999-04-06 2005-03-29 Bellsouth Intellectual Property Corporation Methods and systems for using the public switched telephone network to conduct a transaction between customer accounts
CA2367452A1 (en) * 1999-04-27 2000-11-02 I3E Holdings, Llc Remote ordering system
US6289323B1 (en) * 1999-06-18 2001-09-11 United States Postal Service System and method for completing monetary transactions by presentment of postage value to a postal authority
DE19928341C2 (de) * 1999-06-21 2002-06-20 Inb Vision Ag Verfahren zur dreidimensionalen optischen Vermessung von Objektoberflächen
DE19934981A1 (de) 1999-07-26 2001-02-01 Alcatel Sa Verfahren zur Abgabe einer Ware oder zum Erbringen einer Dienstleistung unter Einsatz eines Mobilfunk-Endgeräts, Mobilfunk-Endgerät zur Durchführung des Verfahrens und Einrichtung zur Abgabe einer Ware oder zum Erbringen einer Dienstleistung
DE59914198D1 (de) * 1999-09-06 2007-03-29 Gebit Ges Fuer Edv Beratung Un Verfahren zur Autorisierung in Datenübertragungssystemen zur Bezahlung von über das Internet angebotenen Waren und/oder Dienstleistungen
DE19946537A1 (de) * 1999-09-28 2001-04-05 Deutsche Telekom Mobil Verfahren zur Abrechnung von Internet-Dienstleistungen über Mobilfunk
DE19946539B4 (de) * 1999-09-28 2010-04-29 T-Mobile Deutschland Gmbh Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk
US7127427B1 (en) * 1999-10-05 2006-10-24 Andrew Casper Secure transaction processing system and method
WO2001031594A1 (de) * 1999-10-25 2001-05-03 Swisscom Mobile Ag Zahlungstransaktionsverfahren und zahlungstransaktionssystem
US7124101B1 (en) * 1999-11-22 2006-10-17 Accenture Llp Asset tracking in a network-based supply chain environment
US8571975B1 (en) * 1999-11-24 2013-10-29 Jpmorgan Chase Bank, N.A. System and method for sending money via E-mail over the internet
EP1107198B1 (de) * 1999-11-30 2007-01-10 Citibank, Na System und Verfahren zur Durchführung einer elektronischen Transaktion mit einer elektronischen Geldbörse mittels eines Transaktionproxys
IL150220A0 (en) * 1999-12-17 2002-12-01 World Theatre Inc Centralized telephone order and distribution system
AU780943B2 (en) * 1999-12-30 2005-04-28 International Business Machines Corporation Method of payment by means of an electronic communication device
US7366695B1 (en) * 2000-02-29 2008-04-29 First Data Corporation Electronic purchase method and funds transfer system
EP1260077B1 (de) 2000-02-29 2005-04-13 Swisscom Mobile AG Verfahren zur transaktionsbestaetigung, authentifizierungsserver und wap-server
KR100366060B1 (ko) * 2000-03-16 2002-12-28 주식회사 하렉스인포텍 광지불송수신장치 및 이를 이용한 광결제시스템
US20010037284A1 (en) * 2000-03-27 2001-11-01 Finkelstein Ephraim Brian Negotiated right exchange system and method
US20010037308A1 (en) * 2000-03-28 2001-11-01 Mark Kotlarsky Fully secure identification and transmission system
JP2001290874A (ja) * 2000-04-07 2001-10-19 Nec Corp 入金管理方法およびシステム
JP2001306966A (ja) * 2000-04-19 2001-11-02 Nikon Gijutsu Kobo:Kk 電子商取引方法
US7363265B2 (en) * 2000-04-20 2008-04-22 Innovative Payment Systems, Llc Method and system for ubiquitous enablement of electronic currency
US6917853B2 (en) * 2000-05-23 2005-07-12 Munroe Chirnomas Method and apparatus for controlling rented or leased or loaned equipment
JP2001331561A (ja) * 2000-05-24 2001-11-30 Nippon Denki Information Technology Kk 端末機取扱システム
ATE282863T1 (de) * 2000-05-26 2004-12-15 Christian Hoeffle System, verfahren und programm zur zahlung in einem telekommunikationsnetz
US7890433B2 (en) * 2000-06-30 2011-02-15 Tara Chand Singhal Private and secure payment system
DE10040799A1 (de) * 2000-08-21 2002-04-25 Siemens Ag Verfahren für sichere Transaktionen im Zusammenhang mit elektronischem Handel
EP1182625A1 (de) * 2000-08-25 2002-02-27 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Einleitung einer elektronischen Zahlungstransaktion
US7415442B1 (en) * 2000-09-26 2008-08-19 Integrated Technological Systems, Inc. Integrated technology money transfer system
US20020152179A1 (en) * 2000-10-27 2002-10-17 Achiezer Racov Remote payment method and system
JP3581094B2 (ja) * 2000-10-31 2004-10-27 株式会社プロトコーポレーション 残価予測システム及びその方法、並びにコンピュータ上で動作する残価予測プログラムを記録した記録媒体
GB0027922D0 (en) * 2000-11-15 2001-01-03 Haidar Mahmoud N Y Electronic payment and associated systems
US20020073027A1 (en) * 2000-12-11 2002-06-13 Hui Helen Shan-Shan Mobile payment system
WO2002050788A2 (en) * 2000-12-18 2002-06-27 in medias res Gesellschaft für Kommunikationstechnologien mbH Accounting method and accounting machine
GB2372615A (en) * 2000-12-27 2002-08-28 Robert Joseph Gerard Macnamee Telephone based payment system
EP1231578A3 (de) * 2001-02-01 2004-03-10 Siemens Aktiengesellschaft Verfahren und Anordnung zur Durchführung einer bargeldlosen Zahlungsaktion
WO2002071353A1 (de) * 2001-03-01 2002-09-12 Peter Ligezinski Vorrichtung und verfahren zum bargeldlosen bezahlen
US20040128244A1 (en) * 2001-03-26 2004-07-01 Makoto Dojo Charging device, charging method, transaction supporting device, and transaction supporting method
US20020143638A1 (en) * 2001-03-28 2002-10-03 August Katherine G. System and method for conducting wireless customer/vendor transactions
US7165052B2 (en) * 2001-03-31 2007-01-16 First Data Corporation Payment service method and system
US7117183B2 (en) * 2001-03-31 2006-10-03 First Data Coroporation Airline ticket payment and reservation system and methods
US7096205B2 (en) * 2001-03-31 2006-08-22 First Data Corporation Systems and methods for enrolling consumers in goods and services
US7184989B2 (en) * 2001-03-31 2007-02-27 First Data Corporation Staged transactions systems and methods
US20020143655A1 (en) * 2001-04-02 2002-10-03 Stephen Elston Remote ordering system for mobile commerce
US20040030645A1 (en) * 2001-04-16 2004-02-12 Stephen Monaghan Method and system for performing a transaction utilising a thin payment network (mvent)
US7752136B2 (en) * 2001-05-18 2010-07-06 Meadow William D Check authorization system and method
CN1529878A (zh) * 2001-07-19 2004-09-15 W3��Ѷ���ż���˽�����޹�˾ 移动电子资金转帐系统和方法
EP1282087A1 (de) * 2001-08-02 2003-02-05 Alcatel Verfahren zur Durchführung von Transaktionen von elektronischen Geldbeträgen zwischen Teilnehmerendgeräten eines Kommunikationsnetzes, Transaktionsserver und Programmmodul hierfür
ATE452390T1 (de) * 2001-08-03 2010-01-15 Ericsson Telefon Ab L M Verfahren und vorrichtungen für bezahlungen zwischen endgeräten
US7103576B2 (en) * 2001-09-21 2006-09-05 First Usa Bank, Na System for providing cardless payment
US20030074209A1 (en) * 2001-10-15 2003-04-17 Tobin Christopher M. User device with service finding and purchasing functionality
DE10151213B4 (de) * 2001-10-15 2006-03-16 Siemens Ag Verfahren zum Genehmigen von Zahlungen in einem Kommunikationsnetz
US7337229B2 (en) * 2001-11-08 2008-02-26 Telefonktiebolaget Lm Ericsson (Publ) Method and apparatus for authorizing internet transactions using the public land mobile network (PLMN)
AU2002351573A1 (en) * 2001-12-12 2003-07-09 Paradata Systems Inc. Global integrated payment system
US20030130942A1 (en) * 2002-01-08 2003-07-10 Bottomline Technologies (De) Inc. Automated invoice receipt and management system with automated loading systems
JP4076954B2 (ja) * 2002-01-28 2008-04-16 富士通株式会社 取引方法及びそれを実行するための取引システム
HU224788B1 (hu) * 2002-02-07 2006-02-28 Enigma Software Rt Architektúra kiterjedt ügyfélkörben végrehajtható bankkártyás fizetési tranzakciók egyszerûsített hardverigényû lebonyolításához, tranzakciós terminálegység, bõvített funkciós SIM kártya, valamint eljárások megszemélyesítésre és tranzakciók lebonyolítására
US8909557B2 (en) * 2002-02-28 2014-12-09 Mastercard International Incorporated Authentication arrangement and method for use with financial transaction
US20020107007A1 (en) * 2002-03-27 2002-08-08 Howard Gerson Method for wireless telephony payment and an apparatus therefor
EP1367516A1 (de) * 2002-05-29 2003-12-03 SubClearing AS System, Methode und Mittel für elektronische Transaktionen
DE10229477A1 (de) * 2002-07-01 2004-01-29 Siemens Ag Bezahlsystem für bargeldlosen Zahlungsverkehr
US7822688B2 (en) * 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
DE10249612A1 (de) * 2002-10-18 2004-05-06 Siemens Ag Verfahren zum Vorbereiten eines Bezahlvorganges in einem Kommunikationsnetz
US20040083170A1 (en) * 2002-10-23 2004-04-29 Bam Ajay R. System and method of integrating loyalty/reward programs with payment identification systems
US7360694B2 (en) * 2003-01-23 2008-04-22 Mastercard International Incorporated System and method for secure telephone and computer transactions using voice authentication
DE10310527B4 (de) * 2003-03-11 2008-11-20 Christian Hogl Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion
US20050209964A1 (en) * 2003-07-25 2005-09-22 Allen Robert M Method of Providing Secure Payment and Transaction Reconciliation
US20050031051A1 (en) * 2003-08-04 2005-02-10 Lowell Rosen Multiple access holographic communications apparatus and methods
WO2005059690A2 (en) * 2003-12-12 2005-06-30 Michael Stockton Method and system configured for facilitating management of international trade receivables transactions
CA2503740A1 (en) * 2005-03-11 2006-09-11 Dushyant Sharma Electronic payment system for financial institutions and companies to receive online payments
CA2647636A1 (en) * 2006-03-30 2008-03-06 Obopay Inc. Mobile person-to-person payment system
US20070265984A1 (en) * 2006-04-24 2007-11-15 Prakash Santhana Financial transaction using mobile devices
US9911114B2 (en) * 2006-07-06 2018-03-06 Qualcomm Incorporated Methods and systems for making a payment via a stored value card in a mobile environment
US7606766B2 (en) * 2006-12-21 2009-10-20 American Express Travel Related Services Company, Inc. Computer system and computer-implemented method for selecting invoice settlement options
US7630937B1 (en) * 2008-04-30 2009-12-08 Intuit Inc. Method and system for processing a financial transaction
US8069115B2 (en) * 2008-06-25 2011-11-29 Douglas Schoenberg Method and system to process payment
DE202012100620U1 (de) 2011-11-22 2012-06-13 Square, Inc. System zur Bearbeitung von kartenlosen Bezahlungstransaktionen

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19903822A1 (de) * 1999-02-02 2000-08-10 Mathias Entenmann Verfahren zur Durchführung bargeldloser Zahlungen und System zur Durchführung des Verfahrens
US6464134B1 (en) * 1999-12-10 2002-10-15 Terri Page System and method for verifying the authenticity of a check and authorizing payment thereof
DE10008280C1 (de) * 2000-02-23 2001-06-13 Wire Card Ag Verfahren und System zur automatischen Abwicklung von bargeldlosen Kaufvorgängen
DE10039569C1 (de) * 2000-08-09 2001-12-06 Mannesmann Ag Verfahren zur Bezahlung an beliebigen Verkaufs- bzw. Dienstleistungsstellen mit Mobiltelefon

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MANHART K: "BEZAHLEN PER HANDY" FUNKSCHAU, FRANZIS-VERLAG K.G. MUNCHEN, DE, Bd. 73, Nr. 15, 7. Juli 2000 (2000-07-07), Seiten 40-42, XP001101071 ISSN: 0016-2841 *
NILS DIEZMANN: "Sicherheit und Zahlung per Handy " INTERNET ARTICLE, [Online] XP002288728 Gefunden im Internet: <URL:http://www.firstsurf.com/diez0151_t.htm> [gefunden am 2001-12-17] *
See also references of EP1602088A2 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7702581B2 (en) * 2003-03-11 2010-04-20 Christian Hogl Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
US8065232B2 (en) 2003-03-11 2011-11-22 Christian Hogl Method and system for initiating and/or conducting a transaction that is associated with at least two corresponding declarations of intent
US8566238B2 (en) 2003-03-11 2013-10-22 Christian Hogl Method for a payment transaction associated with two corresponding declarations of intent
US8831990B2 (en) 2003-03-11 2014-09-09 Christian Hogl Method and system for a payment transaction associated with a declaration of intent

Also Published As

Publication number Publication date
US20140372292A1 (en) 2014-12-18
US20130304650A1 (en) 2013-11-14
CA2518448A1 (en) 2004-09-23
CN1788292A (zh) 2006-06-14
DE10310527B4 (de) 2008-11-20
US8566238B2 (en) 2013-10-22
US20100174651A1 (en) 2010-07-08
US20120047067A1 (en) 2012-02-23
JP2006524938A (ja) 2006-11-02
DE10310527A1 (de) 2004-09-23
WO2004081892A3 (de) 2004-10-28
US20070055632A1 (en) 2007-03-08
US8065232B2 (en) 2011-11-22
US8831990B2 (en) 2014-09-09
AU2004219478A1 (en) 2004-09-23
US7702581B2 (en) 2010-04-20
EP1602088A2 (de) 2005-12-07

Similar Documents

Publication Publication Date Title
DE10310527B4 (de) Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion
DE69723333T2 (de) Vorausbezahlungsverfahren für Telefonkommunikationsnutzung
DE102008035391A1 (de) Verfahren zur Authentifizierung
WO2009003605A9 (de) Virtuelle prepaid- oder kreditkarte und verfahren und system zur bereitstellung einer solchen und zum elektronischen zahlungsverkehr
DE102008011192A1 (de) Verfahren und Diensterechner sowie System zur Transaktion eines Geldbetrages
WO2002011082A9 (de) Elektronischer zahlungsverkehr mit sms
WO2001062016A2 (de) Verfahren zum feststellen der authentizität eines dienste-nutzers und vorrichtung zum durchführen des verfahrens
EP1249996B1 (de) Verfahren zum Abrechnen von Leistungen in einem Kommunikationsnetz
DE10213072A1 (de) Verfahren zum Betrieb eines einem Mobilfunknetz zugeordneten Abrechnungssystems zur Abrechnung einer kostenpflichtigen Benutzung von Daten und Datenübertragungsnetz
EP1665184A1 (de) Verfahren zur abwicklung einer elektronischen transaktion
EP1302917A2 (de) Verfahren und Anordnung zur elektronischen Bezahlung einer Ware oder Dienstleistung, insbesondere einer Applikation in einem Datennetz
DE19738707C2 (de) Verfahren zur Zuordnung einer für begrenzte Zeiteinheiten zur Telekommunikation in einem Telekommunikationsnetz berechtigenden Temporär-Zugangsberechtigung
EP1158471B1 (de) System, Verfahren und Programm zur Zahlung in einem Telekommunikationsnetz
DE10223282B3 (de) Verfahren, Computerprogramm und Computersystem für einen prepaid Telekommunikationsdienst
EP1034685B1 (de) Verfahren zur authorisierung eines endgeräteanschlusses eines telekommunikationsnetzes
DE10133884A1 (de) Verfahren und System zur Abwicklung bargeldloser Zahlungen
WO2004070492A2 (de) Kontrolle von kreditkarten-transaktionen
EP1274971A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken
DE10210792B4 (de) Verfahren und System zur Freischaltung eines kostenpflichtigen Mobilfunk- oder Online-Dienstes
EP1457939A1 (de) Verfahren zur Übertragung von Zahlungsdienstinformationen
DE10149160A1 (de) Kontroll-Server zur Unterstützung der Vergebührung von Diensten
DE60018768T2 (de) Prüfung der gültigkeit des betriebs während kommunikation zwischen zwei endgeräten eines digitalen netz
DE19742997A1 (de) Verfahren zur Autorisierung eines Endgeräteanschlusses eines Telekommunikationsnetzes

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006504645

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2518448

Country of ref document: CA

Ref document number: 2004219478

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2197/CHENP/2005

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 2004719443

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2004219478

Country of ref document: AU

Date of ref document: 20040311

Kind code of ref document: A

WWP Wipo information: published in national office

Ref document number: 2004219478

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 20048128086

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2004719443

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007055632

Country of ref document: US

Ref document number: 10548492

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10548492

Country of ref document: US