WO2015052198A1 - Verfahren für den ortsunabhängigen handel mit produkten (mobile commerce) unter abwicklung der zahlung über ein tragbares telekommunikationsgerät (mobile payment) - Google Patents

Verfahren für den ortsunabhängigen handel mit produkten (mobile commerce) unter abwicklung der zahlung über ein tragbares telekommunikationsgerät (mobile payment) Download PDF

Info

Publication number
WO2015052198A1
WO2015052198A1 PCT/EP2014/071464 EP2014071464W WO2015052198A1 WO 2015052198 A1 WO2015052198 A1 WO 2015052198A1 EP 2014071464 W EP2014071464 W EP 2014071464W WO 2015052198 A1 WO2015052198 A1 WO 2015052198A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
management server
customer
merchant
payment system
Prior art date
Application number
PCT/EP2014/071464
Other languages
English (en)
French (fr)
Inventor
Bruno KERKMANN
Original Assignee
Afc Rechenzentrum Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Afc Rechenzentrum Gmbh filed Critical Afc Rechenzentrum Gmbh
Priority to DE112014004631.0T priority Critical patent/DE112014004631A5/de
Publication of WO2015052198A1 publication Critical patent/WO2015052198A1/de

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/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network 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/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/327—Short range or proximity payments by means of 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/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/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

Definitions

  • portable telecommunications devices such as mobile phones, smartphones, PDAs and tablets have an integrated camera.
  • APPs allow this camera function to be used like a scanner, e.g. Read in barcodes or QR codes.
  • smartphones can read data from NFC chips (Near Field Communication) via special equipment contactless.
  • NFC chips Near Field Communication
  • portable telecommunication devices covers for the present invention presented method all mobile devices that can transmit data via a telecommunication connection. These devices can be equipped with special features via special applications called APPs.
  • Payment systems are also being integrated into portable telecommunications equipment via APPs developed specifically for the operating systems of these devices. These APPs include either a single payment system or a (cyber) wallet.
  • a wallet or cyberwallet is an application (APP) for a portable telecommunications device in which several different payment options can be managed centrally. A wallet is thus a counterpart to a wallet.
  • APP application
  • To make it easier to use and speed up access to payment options, all data needed to complete a payment or shipping process is stored with the wallet operator.
  • the wallets are therefore usually equipped with a security feature that works independently of the security system of the portable telecommunications device.
  • the scan function can be integrated into a wallet via the camera of the portable telecommunication device. Clearing means payment processing.
  • each merchant maintains his inventories via a merchandise management system, which enables at least a daily updated overview of inventories with manual data entry of goods receipts and outgoing goods. If the sales outlets are connected to the merchandise management system via telecommunications connection, the current inventory can even be determined at any time.
  • the latter systems also allow just-in-time goods traffic in conjunction with automated ordering systems.
  • Methods which establish via portable telecommunication devices by means of a mobile radio connection via QR code or NFC technology connection to a Web shop, in order to handle purchases or sales.
  • Some webshop systems are connected directly to merchandise management systems of the retailers and thus allow an indication or the evaluation of the available stock levels.
  • Another problem is the payment process. Although many web shops accept the same payment methods, the customer must re-enter the payment authorization for security reasons for each purchase. This constellation can not and must not be the future of mobile commerce. All internet-based shop systems can not offer a true mobile commerce shopping experience, even if they have been adapted to mobile commerce and the payment of products via a portable telecommunication device is basically possible. Although products can be depicted and described in terms of their properties, certain minimum data volumes are required that have to be retransmitted and loaded on the Internet each time the customer calls. In addition, if no direct access to a particular product is offered via an Internet address, customers must navigate to the product in the Internet shop or app. Depending on the length of the Internet address, the customer must type a lot or, depending on the nesting depth, make at least two, but usually even more navigation steps, until he can select the desired product.
  • the data required for payment processing and shipping ie the entry of customer, billing or shipping data or access to customer accounts in the shop system, must also be made.
  • These inputs are often cumbersome because there is only a small keyboard available and the input of data often has to be in masks sized for use on the Internet.
  • Mobile commerce needs its own way of offering and selling products for its breakthrough. While the shops on the Internet can offer an ever more complete shopping experience due to better and better data bandwidths, mobile commerce has to make do as on-the-go purchases with as little data as possible to achieve the same processing speed and thus the same shopping experience everywhere.
  • the product presentation must be able to reach the customer more directly and spontaneously. Not the customer should search the product on the Internet, but the product should be able to find the customer, and in a way that poses as little hurdles to the customer, if he wants to buy the product or service largely spontaneously.
  • the mediated shopping experience should always be perceived by the customer as good and safe.
  • the amount of data should be reduced as much as possible to a necessary minimum.
  • the invention is further based on the object that the e-commerce method with mobile payment should also allow the immediate use of product presentations with text and image, which are classically regularly outside the mobile telecommunications device in the form of e.g. Stickers, flyers, advertisements, posters, screen presentations, window displays etc. take place.
  • product presentations with text and image which are classically regularly outside the mobile telecommunications device in the form of e.g. Stickers, flyers, advertisements, posters, screen presentations, window displays etc. take place.
  • the customer should be able to directly initiate a purchase process with his mobile telecommunication device, without having to make a detour via an online store of a retailer and possibly still required or previously registered or having to accept a search on the Internet.
  • the amount of data used in the procedure must be as low as possible because UMTS or WLAN connections are not available everywhere. Only The connection via EDGE works almost all over Germany, but is limited to a maximum of 260 kbit / s. Sometimes only GPRS with a maximum of 20 kbit / s is available. The slow data connections that are also available in rural areas, on highways or in buildings must be sufficient for a true mobile commerce process and enable a purchase within a few seconds.
  • a shopping cart function is intended to solve the quota problem, i.
  • Each customer request for a purchase should first be subjected to a quota check against the existing or expected stock.
  • the merchandise is to be temporarily reserved by the merchant and temporarily stored for each customer in an individual shopping cart under an anonymous shopping cart ID.
  • This shopping cart should only be associated with a special customer via the personal customer data if the payment has already been reported as guaranteed from the clearing procedure. This avoids that a trader receives customer data, if in the end no sale is actually concluded.
  • Settlement should be transaction safe for the buyer and the seller, i. appropriate abort and rollback routines for all possible hardware failures, communication faults or operator errors should be integrated in the process.
  • the invention provides that the data relevant for the purchase of the product, ie each product or Service, coded in a QR code or NFC chip under a one-to-one PID (Point-of-Sale-ID) and represented by this PID.
  • This PID preferably comprises a merchant ID and the item number identifying the product.
  • the PID can be present in particular as a QR code, barcode, NFC chip or a comparable optical or electronic scannable by a mobile telecommunication device coding in the product presentation.
  • the QR code can be scanned optically and the NFC chip electronically into the wallet or the payment system app in the portable telecommunication device.
  • These codings, in particular the QR codes or NFC chips can be understood as the actual point of sale.
  • the cost of a QR code or barcode is minimal and the cost of an NFC chip is only slightly higher.
  • the process can also be used cost-effectively nationwide. Investments are limited to an economically justifiable measure for a nationwide application and thus also interesting for nationally active dealers.
  • the buyer or the wallet or the payment system has all the purchase-relevant information.
  • the method can be used wherever a QR code can be mapped or an NFC chip can be attached.
  • Any modern portable telecommunications device such as a smartphone, tablet, etc., can scan QR codes into a wallet or payment system app via the integrated camera or an NFC chip using NFC technology and process the data contained therein. The method presented here can thus be used everywhere and works with any modern portable telecommunication device.
  • all customer data such as billing and shipping address are stored permanently after a single entry and are available there for every purchase.
  • the Wallet has a fuse, which the customer prefers to switch on optionally.
  • the data of the QR code or the NFC chip can be scanned directly into the wallet or payment system app and are stored there for the method described here and sent via the telecommunication connection of the mobile telecommunication device.
  • a management server can be reached by the wallet operator or the payment provider as well as by a merchant via a secure telecommunication connection.
  • the dealers connected to the system are in a merchant database; the wallet operators or payment system providers are stored in a payment system provider database.
  • Both databases contain a list of all traders and payment system providers or wallet operators attached to the procedure. These databases can be operated together on the management server or separately on different servers. In the latter case, a permanent secure telecommunication connection between the servers with the merchant and payment system provider databases and the management server is necessary.
  • the method uses methods that violate the limitation of a Prevent material quota. It ensures a smooth handling by solving the problem of a limited stock and the interface problem for the exchange of this information between retailer and customer through the interposition of a management server, which acts as a link between the dealer and the customer. When sold out, the customer receives a corresponding message.
  • the management server also provides methods that ensure the exchange of personal customer data between the wallet operator and the merchant for shipping without storing this customer data.
  • the management server uses a special interface and associated methods to communicate with merchant merchandise management systems in order to carry out quota requests and shopping cart postings and to receive status messages in the return channel.
  • the management server itself is the bridge through which each wallet operator or payment system provider can communicate with each ERP system and exchange the data or messages necessary for the procedure. This distinguishes the method presented here from conventional Internet shop systems, which often have no connection to a merchandise management system with stock information. The system presented here can supplement or even completely replace conventional Internet shops.
  • the transported data is limited to the absolute minimum in every step of the process so that the transmission of the sensitive customer data is only requested when the quota check has been performed positively.
  • these data are only transmitted by the wallet operator or payment system provider if the clearing has also been positive, ie the payment has already been made.
  • the personal customer data are also transmitted by the management server via a secure connection directly from the wallet operator to the merchandise management system of the merchant for the purpose of shipping and not cached. For the tasks of the administration servers, these personal customer data are irrelevant.
  • In-process time-out routines ensure that missing telecommunication connections between the management server and the merchant as well as between the payment system provider or wallet operator and the management server lead to a termination of the payment transaction and corresponding messages to the customer. These time-out routines are located on the management server. Likewise, negative results (NOK) of validation operations such as e.g. Identities of merchants or payment system providers / wallet operators not confirmed by the merchant or payment system provider databases or the payment rejection of a payment system provider to terminate the process with corresponding notifications to the customer.
  • NOK negative results
  • the first payload data set sent by the portable telecommunication device to the wallet operator or payment system provider is a few kilobytes in size.
  • the status messages each account for less than 1 Kb.
  • the bulk of the information or data is exchanged between the wallet operator or the payment system provider, the management server and the merchandise management system within high-speed cable-based Internet connections.
  • the entire process is designed to take an average of no more than 5 seconds to scan from the QR code or NFC chip to the customer's purchase confirmation.
  • the presented method in the field of mobile payment is used for mobile commerce and the purchase of goods or services (products) at any location without the interposition of an Internet shop and without a checkout. It achieves the ubiquity of a real mobile commerce by separating the data-driven product description from the data of the payment transaction. Only purchase-relevant data is transmitted via the mobile phone connection. So regardless of the data bandwidth the same shopping experience anywhere where at least the slowest data connection is available.
  • the product information is stored in the form of article number and supplier code without price information in a QR code or an NFC chip.
  • the description of the products takes place outside the portable telecommunication device in each representation form. Only the ability to scan a QR code or NFC chip must be given. Thus, the customer is allowed to directly and without detour via a web shop, for example, directly from a catalog, from a poster or flyer or similar non-Internet based merchandise or product presentation using a portable telecommunication device purchase.
  • a manipulation of the price information and the problem of limited quotas are solved by a connection to the merchandise management system of the merchant and a shopping cart function.
  • This connection or functions is provided by a management server, which has suitable interfaces as the bridge between customer and dealer.
  • the procedure does not store any personal data of the customer. Invoicing or shipping information is transported by the management server only from the customer via the payment system provider to the dealer.
  • the method therefore comprises, inter alia, the following method steps:
  • the coding for the checkout contains relevant purchase information, in particular comprising a dealer identifying information (merchant ID) and a product identifying information (product ID),
  • the request data record preferably checking information contained in the request data record, in particular the merchant ID (merchant identification examination) and the wallet operator ID or payment system provider ID (payment system provider identification examination) on the second server,
  • the clearing of the payment can in principle already be made before the request data record is sent by the wallet operator or payment system provider to the management server.
  • the request record would only be sent to the management server if the clearing was positive. This requires, however, that the Price of the product known to the wallet operator or the payment system provider at least insofar known that the creditworthiness of the customer can be checked for this payment transaction.
  • the request record would then already contain clearing-ok information.
  • the non-storage of the personal data of the customer on the management server has the particular advantage that the management server can act as a real intermediary between a customer or its wallet operator or payment system provider and the dealer, without apparent to the customer in appearance and without the consent of the customer, as the operator of the administration server with personal data bypasses.
  • the procedure makes it easy to link Wallet operators or payment system providers on the one hand and web shops or other dealers on the other.
  • FIG. 1 shows the system for the settlement process from a wallet operator app.
  • FIG. 2 shows the system for the settlement method from a payment system provider app
  • FIG. 3 shows the sequence of the settlement process with a wallet operator app.
  • FIG. 4 shows the sequence of the settlement process with a payment system provider app
  • FIG. 1 shows the system for operation with a wallet.
  • the system for the described method consists of a portable telecommunication device (1) with an arbitrary wallet (2).
  • the method requires a cellular or network connection (12) for contact with the wallet operator (3) who operates the wallet at (2).
  • the wallet operator (3) communicates with the management server (5) and the payment system provider (6) selected by the customer in the wallet via telecommunication links (13, 14).
  • An arbitrary point of Sale (4) is equipped with a QR code and / or NFC chip (7) containing the unique point-of-sale identification number PID.
  • This PID consists of a unique ID of the merchant and an article number.
  • FIG. 2 shows the system for operation with a payment system provider app.
  • the system for the method described consists of a portable telecommunication device (1) with any payment system app (2).
  • the method requires a cellular or network connection (12) for contact with the payment system provider (6) operating the payment system at (2).
  • the payment system provider (6) communicates with the management server (5) via a telecommunication connection (13).
  • Any point of sale (4) is equipped with a QR code and / or NFC chip (7) containing the unique point-of-sale identification number PID.
  • This PID consists of a unique ID of the merchant and an article number.
  • FIG. 3 and FIG. 4 respectively illustrate further details of the methods with a wallet (FIG. 3) and a payment system provider app (FIG. 4).
  • the process is initiated by the customer by either opening his wallet (2) in the portable telecommunication device (1) and selecting his preferred payment system for the upcoming payment or directly opening a payment system app (2) and passing the PID (7) over optically or electronically scans (10) the QR code or the NFC chip into its wallet or payment system app (2) and selects the desired quantity.
  • a customer record (a) consisting of the PID, the customer ID, the portable telecommunications device ID, the quantity, if any, of a billing address other than the billing address stored in the wallet or the payment system app, and - in the case of the wallet the indication of the chosen payment system is generated in the portable telecommunication device (1) and sent via the mobile radio connection (12) of the portable telecommunication device (1) to the wallet operator (3 - Fig. 3) or payment system provider (6 - Fig. 4).
  • the from the portable telecommunication device (1) coming customer record (a) reaches either the wallet operator (3 - 3) or the payment system provider (6 - 4). There the quota procedure is identified on the basis of the special data constellation and a customer identification check is carried out. A negative result of the customer identification check leads to a termination message to the customer.
  • the wallet operator (3 - FIG. 3) or the payment system provider (6 - FIG. 4) sends a quota request record
  • the quota request record (b) of the wallet operator (3 - 3) or payment system provider (6 - 4) arriving on the management server (5) firstly becomes the payment system provider ident check by matching with the payment system provider database (8).
  • the management server (5) breaks the process with a NOK via the telecommunication connection (13) to the wallet operator (3 - FIG. 3). or payment system provider (6 - Fig. 4). This reports the demolition to his customer.
  • the management server If the wallet operator (3) or payment system provider (6) is listed in the payment system provider database (8), the management server generates an OK (OK) and forwards the quota request record (b) for the merchant identification check to the merchants Database (9) on.
  • the management server (5) breaks the process with a NOK via the telecommunication connection (13) to the wallet operator (3 - FIG. 3) or payment system provider (6 - FIG ). This reports the demolition to his customer.
  • the management server (5) Does the management server (5) receive an OK from the Ident check from the dealer Database (9), the quota request record (b) now receives a basket number assigned by the management server. This shopping cart number is a unique unique ID. Then, the management server (5) forwards the quota request record (b) without the payment system provider ID via the telecommunication link (15) to the merchant (11).
  • the item number and quantity contained in the quota request record (b) is used to carry out the contingent check (KP) in the merchandise management system of the merchant (1 1) by querying the stock. If there is no quota or insufficient quota under the requested article number, a quota NOK message (NOK) is automatically sent via the telecommunication connection (15) from the merchant (11) to the management server (5) and from there via the Telecommunication connection (13) to the wallet operator (3 - Fig. 3) or the payment system provider (6 - Fig. 4) sent back. This reports the quota status as abort (sold out) to the customer.
  • KP contingent check
  • the requested quantity of goods is posted under the shopping basket number assigned by the management server (5) to a shopping cart (16) in the merchandise management system of the merchant (11) and provided with the current price from the merchandise management system.
  • the merchandise management system (1 1) then sends the quota reply record (c) via the telecommunication connection (15) to the management server (5).
  • This quota response record (c) contains all the details of the quota request record (b) (without the payment system provider ID), the pricing information from the merchandise management system and the quota OK message (OK).
  • the management server forwards this contingent response record (c) to the toll operator (3 - 3) or the payment system provider (6 - 4).
  • the toll provider (3 - Fig. 3) or payment system provider (6 - Fig. 4) transmits the price and quantity information to the customer via the mobile telephone connection (12). the.
  • the customer confirms the purchase and sends his purchase OK via the mobile telephone connection (12) back to the wallet operator (3 - Fig. 3) or payment system provider (6 - Fig. 4).
  • the customer's purchase OK from the quota reply record (c) is the clearing request record (d).
  • the wallet operator (3 - FIG. 3) uses the clearing request record (d) to obtain from the operator of the customer-selected payment system (6 - FIG. 3) the result of the clearing process in the form of the clearing response record (s). with the confirmation of the payment (OK) or the rejection (NOK) via the telecommunication connection (14).
  • the clearing response record (s) contains all the details of the clearing request record (d) and the test result.
  • the wallet operator (3 - Fig. 3) or payment system provider (6 - Fig. 4) sends the clearing response record (s) via the telecommunication connection (13) to the management server (5). If the clearing has resulted in a NOK, the management server (5) sends a deletion record consisting of the shopping cart number and a NOK via the telecommunication connection (15) for deleting the shopping cart (16) into the merchandise management system of the merchant (11). The deletion of the shopping cart leads to a reversal of the blocked in the basket quota in the inventory of the dealer (1 1).
  • the wallet operator sends the clearing OK together with the invoice and, if applicable, the shipping data of the customer and the shopping cart number to the management server (5).
  • This stores only the clearing OK together with the transaction ID and the shopping cart number and forwards the shopping cart number and transaction ID together with the customer's billing and shipping data without saving the personal data to the retailer's merchandise management system (1 1).
  • This confirms the receipt of the data to the management server (5) with a shopping cart OK.
  • the management server generates a process OK from this and forwards it via the telecommunication connection (13) to the wallet operator. This leads the confirmation of the process over the cellular connection (12) to the wallet or payment system app (2) in the customer's portable telecommunications device (1). This completes the process.

Landscapes

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

Abstract

Bei einem Verfahren für den ortsunabhängigen Handel mit Produkten unter Abwicklung der Zahlung über ein tragbares Telekommunikationsgerät werden die für die Kaufabwicklung relevanten Daten unter einer Point-of-Sale-ID (PID) codiert, die im Bereich einer Produktpräsentation außerhalb des tragbaren Telekommunikationsgeräts von diesem einscannbar angeordnet ist, und nach dem Einscannen durch das tragbare Telekommunikationsgerät über eine Telekommunikationsverbindung an einen Walletbetreiber oder an einen Bezahlanbieter übermittelt, wobei der Walletbetreiber oder der Bezahlsystemanbieter zur Kaufabwicklung ein Warenwirtschaftssystem des Händlers unter Zwischenschaltung eines Verwaltungsservers kontaktiert.

Description

Verfahren für den ortsunabhängigen Handel mit Produkten (Mobile Commerce) unter Abwicklung der Zahlung über ein tragbares Telekommunikationsgerät (Mobile Payment)
Ein einfaches, einheitliches, überall einsetzbares E-Commerce Verfahren mit Mobile Payment für den Handel mit Produkten gibt es bislang nicht. Die bekannten Lösungen setzen auf modifizierte Webshops oder Shopping-Apps einzelner Anbieter.
Die heute am weitesten verbreiteten tragbaren Telekommunikationsgeräte, wie Mobiltelefone, Smartphones, PDAs und Tablets verfügen über eine integrierte Kamera. APPs erlauben es, diese Kamerafunktion wie einen Scanner zu verwenden, um z.B. Barcodes oder QR-Codes einzulesen. Ebenfalls können die meisten Smartphones Daten von NFC-Chips (Near Field Communication) über spezielle Geräteausstattungen kontaktlos einlesen. Unter den Begriff der tragbaren Telekommunikationsgeräte fallen für das erfindungsgemäß vorgestellte Verfahren alle mobilen Geräte, die Daten über eine Telekommunikationsverbindung übertragen können. Diese Geräte können über spezielle Anwendungen, APPs genannt, mit neuen Funktionen ausgestattet werden.
Auch Bezahlsysteme werden in tragbare Telekommunikationsgeräte über speziell für die Betriebssysteme dieser Geräte entwickelte APPs integriert. Diese APPs beinhalten entweder ein einzelnes Bezahlsystem oder eine (Cyber)Wallet. Unter einer Wallet oder Cyberwallet ist eine Anwendung (APP) für ein tragbares Telekommunikationsgerät zu verstehen, in der sich mehrere verschiedene Bezahloptionen zentral verwalten lassen. Eine Wallet ist somit ein Pendant zu einem Portemonnaie. Zur bequemeren Nutzung und zur Beschleunigung des Zugriffs auf die Bezahloptionen sind sämtliche Daten, die für die Abwicklung eines Zahlungs- oder Versandvorgang benötigt werden, beim Walletbetreiber gespeichert. Zum Schutz vor unberechtigtem Zugriff sind die Wallets daher zumeist mit einer Sicherheitsfunktion ausgestattet, welche unabhängig vom Sicherheitssystem des tragbaren Telekommunikationsgeräts funktioniert. In eine Wallet kann die Scanfunktion über die Kamera des tragbaren Telekommunikationsgeräts integriert werden. Clearing bedeutet Zahlungsabwicklung. Während das Clearing für einzelne Bezahlsysteme direkt vom Bezahlsystemanbieter durchgeführt wird, führt der Walletbetreiber das Clearing über unterschiedliche Verfahren ab. Die Walletbetreiber müssen daher die Schnittstellenanforderungen der bei ihnen integrierbaren Bezahlsysteme umsetzen. Gemeinsames Merkmal aller Verfahren sind Meldungen über den Zahlungsstatus in Form von Datensätzen.
Jeder Händler pflegt seine Warenbestände heute über ein Warenwirtschaftssystem, welches bei manueller Dateneingabe der Wareneingänge und -ausgänge mindestens einen tagesaktuellen Überblick über die Warenbestände ermöglicht. Sind die Verkaufsstellen per Telekommunikationsverbindung an das Warenwirtschaftssystem angeschlossen, ist sogar jederzeit der aktuelle Warenbestand ermittelbar. Die letztgenannten Systeme ermöglichen in Verbindung mit automatisierten Bestellsystemen auch den Just-in-Time-Warenverkehr.
Es sind Verfahren bekannt, die über tragbare Telekommunikationsgeräte mittels einer Mobilfunkverbindung über QR-Code- oder NFC-Technologie Verbindung zu einem Webshop herstellen, um Käufe bzw. Verkäufe abzuwickeln. Einige Webshop-Systeme sind direkt an die Warenwirtschaftssysteme der Händler angeschlossen und ermöglichen dadurch eine Angabe bzw. die Auswertung der verfügbaren Lagerbestände.
Mobile Commerce kann streng genommen nur "Einkaufen überall" bedeuten. Wer allerdings wirklich überall seine Waren bzw. Dienstleistungen verkaufen möchte, steht vor fünf grundsätzlichen Problemen:
1 . Wegen nicht flächendeckend verfügbaren schnellen Internetverbindungen muss er die Datenmenge für die Produktpräsentation und Kaufabwicklung gering halten, um überall ein gleich gutes Einkaufserlebnis garantieren zu können.
2. Er muss die notwendigen Produktdaten an den Käufer übermitteln.
3. Um Überverkäufe zu verhindern, muss er seine Lagerbestände bzw. Kontingente berücksichtigen. Dafür braucht er überall Zugriff auf das Warenwirt- schaftssystem.
4. Er muss den Betrag kassieren können und den Verkauf bestätigen, hat aber nicht überall eine Kasse und auch keine Face-to-Face-Kommunikation mit dem Kunden.
5. Er braucht schließlich die Rechnungs- und vor allem die Versanddaten des Kunden, um die verkaufte Ware zuzustellen.
Mobile Payment-Kunden erwarten im Mobile Commerce eine unkomplizierte und vor allem schnelle Kaufabwicklung mit einem geringen Aufwand an Eingaben und Verfahrensschritten. Dies dient nicht nur der Bequemlichkeit und garantiert ein gutes Einkaufserlebnis, sondern gilt auch als Kompetenzbeweis und dient damit der Herstellung eines Vertrauensverhältnisses.
Wer versucht diese Anforderung durch einen klassischen Internetshop zu lösen, muss das Shopsystem auf die Bedingungen des Mobile Commerce in Verbindung mit dem Mobile Payment über tragbare Telekommunikationsgeräte anpassen. Das Shop-System muss dazu "responsive" ausgelegt sein, um die Webseiten in angemessener Größe und Lesbarkeit auch auf kleinen Smartphone-Displays attraktiv darzustellen. Ein Ansatz ist die Herstellung einer Shop-App, die unter Umgehung des Internetbrowsers die Waren in einem Smartphone-tauglichen Format präsentiert. Dennoch nutzt auch die Shop-App die im Moment des Kaufs verfügbare Internetverbindung des Smartphone für die Präsentation und die Abwicklung. Ein Nachteil dieser Shop-App-Lösung ist die große Anzahl von Shop-Apps, die ein Nutzer auf seinem Smartphone installieren und regelmäßig aktualisieren müsste, um bei allen seinen bevorzugten Händlern einkaufen zu können. Zudem muss der Kunde seine Kundendaten und möglichweise noch eine abweichende Lieferadresse bei jedem Händler registrieren und aktualisieren, was ein nicht unerheblicher Aufwand ist und die meisten Kunden abschreckt.
Ein weiteres Problem ist die Zahlungsabwicklung. Obwohl viele Webshops die gleichen Zahlungsmethoden akzeptieren, muss der Kunde die Autorisierung für die Zahlung schon aus Sicherheitsgründen für jeden Kauf neu eingeben. Diese Konstellation kann und darf nicht die Zukunft eines Mobile Commerce sein. Alle Shopsysteme, die für das Internet hergestellt wurden, können kein echtes Mobile Commerce-Shoppingerlebnis bieten, auch wenn diese im Ansatz an das Mobile Commerce angepasst wurden und die Zahlung der Produkte über ein tragbares Telekommunikationsgerät grundsätzlich möglich ist. Produkte können zwar abgebildet und in ihren Eigenschaften beschrieben werden, jedoch sind dazu gewisse Mindestdatenmengen notwendig, die im Internet bei jedem Aufruf des Kunden neu übertragen und geladen werden müssen. Zudem müssen sich die Kunden, wenn kein Direktzugriff zu einem bestimmten Produkt über eine Internetadresse angeboten wird, im Internet-Shop oder der App zum Produkt navigieren. Je nach Länge der Internetadresse muss der Kunde viel tippen oder je nach Ver- schachtelungstiefe mindestens zwei, jedoch meistens noch mehr Navigationsschritte machen, bis er das gewünschte Produkt auswählen kann.
Des Weiteren verfügen 50% der potentiellen Käufer wegen nicht flächendeckend vorhandener schneller Datenbandbreiten regelmäßig nur über eine EDGE- bzw. GPRS-Datenverbindung für den Internetzugang, was die Übertragung zu vieler Daten langwierig macht. Auch Kunden, die im Versorgungsgebiet schneller Datenverbindungen wohnen, haben möglicherweise unterwegs oder in Gebäuden nur eine EDGE- oder GPRS-Verbindung. Dies hat erheblichen Einfluss auf das Mobile Commerce-Kauferlebnis über Webshops, insbesondere auf die Verwendung von Bilddaten und Beschreibungstexten. Ein Verzicht auf ausreichende beschreibende Informationen durch Wegfall von Bilddaten und Beschreibungen oder eine Reduktion auf ein kryptisches Minimum über z.B. Abkürzungen beschädigt jedoch die Erwartungen an das Kauferlebnis und minimiert die Kompetenzvermutung und das Vertrauen.
Neben den Produktinformationen müssen zudem die Daten, welche für die Zahlungsabwicklung und den Versand notwendig sind, d.h. die Eingabe von Kunden-, Rechnungs- oder Versanddaten bzw. der Zugriff auf Kundenkonten im Shopsystem vorgenommen werden. Diese Eingaben sind oft mühevoll, weil nur eine kleine Tastatur zur Verfügung steht und die Eingabe der Daten oft in Masken erfolgen muss, die für die Nutzung im Internet dimensioniert wurden. Das Mobile Commerce braucht für seinen Durchbruch einen eigenen Weg, Produkte anzubieten und zu verkaufen. Während die Shops im Internet durch immer bessere Datenbandbreiten ein immer vollständigeres Einkaufserlebnis bieten können, muss der Mobile Commerce als Einkauf von unterwegs mit möglichst wenigen Daten auskommen, um überall die gleiche Abwicklungsgeschwindigkeit und damit das gleiche Einkaufserlebnis zu erreichen. Auch muss die Produktpräsentation in der Lage sein, den Kunden unmittelbarer und spontaner zu erreichen. Nicht der Kunde soll das Produkt im Internet suchen, sondern das Produkt sollte den Kunden finden können, und das auf eine Art und Weise, die den Kunden vor möglichst wenig Hürden stellt, wenn er das Produkt oder die Dienstleistung weitgehend spontan erwerben möchte.
Eine Aufgabe der Erfindung ist daher, ein Verfahren bereit zu stellen, dass es Kunden ermöglicht, zukünftig überall, weitgehend spontan und unkompliziert alle Arten von Produkten (Waren und Dienstleistungen) über ihr tragbares Telekommunikationsgerät kaufen können. Das vermittelte Einkaufserlebnis soll vom Kunden als immer gleich gut und sicher empfunden werden. Die Datenmenge sollte dabei so weit wie möglich auf ein notwendiges Mindestmaß reduziert sein.
Der Erfindung liegt weiter die Aufgabe zugrunde, dass das E-Commerce Verfahren mit Mobile Payment auch die unmittelbare Nutzung von Produktpräsentationen mit Text und Bild ermöglichen soll, die klassischerweise regelmäßig außerhalb des mobilen Telekommunikationsgeräts in Form von z.B. Aufklebern, Handzetteln, Anzeigen, Plakaten, Bildschirmpräsentationen, Schaufensterauslagen etc. stattfinden. Der Kunde soll ausgehend von einem Katalog, einem Werbeplakat, einem Flyer, einer Zeitungsanzeige oder ähnlichem mit seinem mobilen Telekommunikationsgerät direkt einen Kaufvorgang initiieren können, ohne dabei einen Umweg über einen Online-Shop eines Händlers und eine gegebenenfalls noch erforderliche bzw. zuvor bereits erfolgte Registrierung oder eine Suche im Internet in Kauf nehmen zu müssen.
Die im Verfahren verwendete Datenmenge muss möglichst gering sein, weil UMTS- oder WLAN- Verbindungen nicht flächendeckend verfügbar sind. Lediglich die Verbindung über EDGE funktioniert fast ganz deutschlandweit, ist aber auf maximal 260 kbit/s begrenzt. Stellenweise steht sogar nur GPRS mit maximal 20 kbit/s zur Verfügung. Die auch in ländlichen Gebieten, auf Autobahnen oder in Gebäuden zur Verfügung stehenden langsamen Datenverbindungen müssen für ein echtes Mobile Commerce-Verfahren ausreichen und einen Kaufabschluss innerhalb weniger Sekunden ermöglichen.
Als rechtssicheres, zwischen Verkäufer und Käufer geschaltetes Verfahren eines Dritten sollen personenbezogene Daten wie Rechnungs- und Versanddaten nur vom Walletbetreiber bzw. Bezahlsystemanbieter zum Zweck der Zahlungsabwicklung sowie vom Händler zum Zweck der Versandabwicklung und Rechnungserstellung gespeichert werden. Das Verfahren muss den Anforderungen an den Datenschutz genügen.
Eine Warenkorbfunktion soll das Kontingentproblem lösen, d.h. jede Kundenanfrage für einen Kauf soll zunächst einer Kontingentprüfung gegen den vorhandenen oder zu erwartenden Lagerbestand unterzogen werden. Bei vorhandenem oder rechtzeitig eintreffendem Kontingent (Just-in-Time-Verfahren) soll die Ware beim Händler vorläufig reserviert und für jeden Kunden in einem individuellen Warenkorb unter zunächst einer anonymen Warenkorb-ID zwischengespeichert werden. Dieser Warenkorb soll erst dann mit einem speziellen Kunden über die persönlichen Kundendaten in Verbindung gebracht werden, wenn aus dem Clearingverfahren die Zahlung bereits als gewährleistet gemeldet wurde. Hierdurch wird vermieden, dass ein Händler Kundendaten erhält, wenn gar letztlich gar kein Verkauf zustande kommt.
Die Abwicklung soll für den Käufer und den Verkäufer transaktionssicher sein, d.h. geeignete Abbruch- und Rückabwicklungsroutinen für alle möglichen Hardwareausfälle, Kommunikationsstörungen oder Bedienungsfehler sollen im Verfahren integriert sein.
Zur Lösung der vorstehend genannten Aufgaben sieht die Erfindung vor, dass die für die Kaufabwicklung relevanten Daten des Produkts, also jeder Ware bzw. Dienstleistung, in einem QR-Code oder NFC-Chip unter einer eineindeutigen PID (Point-of-Sale-ID) codiert und durch diese PID repräsentiert werden. Diese PID umfasst bevorzugt eine Händler-ID und der das Produkt identifizierende Artikelnummer. Die PID kann insbesondere als QR-Code, Barcode, NFC-Chip oder einer vergleichbaren optisch oder elektronisch von einem mobilen Telekommunikationsgerät einscannbaren Codierung im Bereich der Produktpräsentation vorhanden sein. So kann beispielsweise der QR-Code optisch und der NFC-Chip elektronisch in die Wallet bzw. die Bezahlsystem-App im tragbaren Telekommunikationsgerät eingescannt werden. Diese Codierungen, also insbesondere die QR-Codes oder NFC-Chips, können als eigentlicher Point of Sale verstanden werden.
Die Kosten zum Beispiel für einen QR-Code oder einen Barcode sind minimal, die Kosten für einen NFC-Chip nur geringfügig höher. Das Verfahren wird dadurch kostengünstig auch flächendeckend einsetzbar. Investitionen sind auf ein betriebswirtschaftlich leicht vertretbares Maß für eine flächendeckende Anwendung begrenzt und dadurch auch für landesweit tätige Händler interessant.
Über den Scan der Codierung, insbesondere des QR-Codes oder des NFC-Chips, verfügt der Käufer bzw. die Wallet oder das Bezahlsystem über sämtliche kaufrelevanten Informationen. Damit ist das Verfahren überall dort einsetzbar, wo sich ein QR-Code abbilden oder ein NFC-Chip anbringen lässt. Jedes moderne tragbare Telekommunikationsgerät wie Smartphone, Tablet usw. können QR-Codes über die integrierte Kamera oder einen NFC-Chip über die NFC-Technologie in eine Wallet oder eine Bezahlsystem-App einscannen und die darin enthaltenen Daten verarbeiten. Das hier vorgestellte Verfahren ist somit überall einsetzbar und funktioniert mit jedem modernen tragbaren Telekommunikationsgerät.
Dadurch, dass das Einscannen der Codierung den Kunden nicht etwa zu einem registrierungsbedürftigen Online-Shop des Händlers führt, sondern der Code direkt einem Walletbetreiber oder einem Bezahlanbieter übermittelt wird, bevorzugt durch vorheriges einscannen in eine App und anschließenden Übermitteln, ist gewährleistet, dass der Kaufvorgang unter Einbindung eines noch zu erläuternden Verwaltungsservers und natürlich unter Einbindung des Kunden direkt abgewickelt werden kann. Dies sorgt für eine Unmittelbarkeit des Kaufs. Der Kunde gelangt nicht erst über Umwege zum eigentlichen Produkt, insbesondere nicht über eine zwischengeschaltete Website eines Händlers, auf der der Kunde das gewünschte Produkt gegebenenfalls erst nach weiterem Durchschreiten verschiedener Hierarchiestufen einer Menüstruktur aufsuchen muss und über die letztlich auch die Zahlungsabwicklung erfolgt, die wiederum das Durchschreiten weiterer Verifizierungsschritte erfordern kann. So kann der Kunde beispielsweise ein in einem Zeitungsinserat beworbenes Produkt durch einscannen der PID direkt„vom Blatt weg" einkaufen. Der Walletbetreiber bzw. Bezahlsystemanbieter ist demnach vom eigentlichen Händler zu unterscheiden.
In der Wallet oder der Bezahlsystem-App sind sämtliche Kundendaten, wie Rech- nungs- und Versandadresse nach einmaliger Eingabe dauerhaft gespeichert und stehen dort für jeden Kauf zur Verfügung. Die Wallet verfügt über eine Sicherung, die der Kunde bevorzugt wahlweise zuschalten kann. Die Daten des QR-Code oder des NFC-Chip lassen sich direkt in die Wallet oder Bezahlsystem-App einscannen und werden dort für das hier beschriebene Verfahren gespeichert und über die Telekommunikationsverbindung des mobilen Telekommunikationsgeräts versandt.
Ein Verwaltungsserver ist sowohl vom Walletbetreiber bzw. dem Bezahlanbieter als auch von einem Händler über eine sichere Telekommunikationsverbindung erreichbar. Die an das System angeschlossenen Händler sind zudem in einer Händler-Datenbank, die Walletbetreiber bzw. Bezahlsystemanbieter sind in einer Bezahlsystemanbieter-Datenbank hinterlegt. Beide Datenbanken beinhalten eine Liste, in der alle an das Verfahren angeschlossenen Händler sowie die Bezahlsystemanbieter bzw. Walletbetreiber hinterlegt sind. Diese Datenbanken können gemeinsam auf dem Verwaltungsserver oder getrennt auf unterschiedlichen Servern betrieben werden. Für letzteren Fall ist eine ständige sichere Telekommunikationsverbindung zwischen den Servern mit den Händler- und Bezahlsystemanbieter-Datenbanken und dem Verwaltungsserver notwendig.
Das Verfahren verwendet Methoden, die eine Verletzung der Limitierung eines Warenkontingents verhindern. Es sorgt für eine reibungslose Abwicklung indem das Problem eines limitierten Lagerbestands sowie die Schnittstellenproblematik für den Austausch dieser Information zwischen Händler und Kunden durch Zwischenschaltung eines Verwaltungsservers gelöst werden, der als Bindeglied zwischen dem Händler und dem Kunden fungiert. Bei Ausverkauf erhält der Kunde eine entsprechende Meldung. Der Verwaltungsserver hält zudem Methoden bereit, die den Austausch der persönlichen Kundendaten zwischen Walletbetreiber und Händler für den Versand sicherstellt, ohne diese Kundendaten selbst zu speichern.
Der Verwaltungsserver kommuniziert über eine spezielle Schnittstelle und zugehörige Methoden mit den Warenwirtschaftssystemen der Händler um die Kontingent- Anfragen und die Warenkorbbuchungen durchzuführen und im Rückkanal Statusmeldungen zu erhalten. Auf der anderen Seite ist eine spezielle Schnittstelle für die Kommunikation zwischen Walletbetreiber bzw. Bezahlsystemanbieter und dem Verwaltungsserver mit entsprechenden Methoden vorhanden, insbesondere um dem Kunden Mitteilungen über den Status zu senden. Der Verwaltungsserver stellt selbst die Brücke dar, über die jeder Walletbetreiber bzw. Bezahlsystemanbieter mit jedem Warenwirtschaftssystem kommunizieren und die für das Verfahren notwendigen Daten bzw. Meldungen austauschen kann. Dies unterscheidet das hier vorgestellte Verfahren von herkömmlichen Internet-Shopsystemen, die oft keine Anbindung an ein Warenwirtschaftssystem mit Lagerbestandsinformationen haben. Das hier vorgestellte System kann herkömmliche Internetshops sinnvoll ergänzen oder sogar völlig ersetzen. Die transportierten Daten sind in jedem Verfahrensschritt auf das absolute Minimum begrenzt, so dass die Übertragung der sensiblen Kundendaten erst dann angefragt wird, wenn die Kontingentprüfung positiv verlaufen ist. Übertragen werden diese Daten allerdings seitens des Walletbe- treibers bzw. Bezahlsystemanbieters nur, wenn auch das Clearing positiv verlaufen ist, also die Zahlung bereits erfolgt ist. Die persönlichen Kundendaten werden zudem durch den Verwaltungsserver über eine gesicherte Verbindung direkt vom Walletbetreiber an das Warenwirtschaftssystem des Händlers zum Zweck des Versands übermittelt und nicht zwischengespeichert. Für die Aufgaben des Ver- waltungsservers sind diese persönlichen Kundendaten irrelevant.
Verfahrensinterne Time-Out-Routinen sorgen dafür, dass fehlende Telekommunikationsverbindungen sowohl zwischen dem Verwaltungsserver und dem Händler als auch zwischen dem Bezahlsystemanbieter bzw. Walletbetreiber und dem Verwaltungsserver zu einem Abbruch des Zahlungsvorgangs und entsprechenden Meldungen an den Kunden führen. Diese Time-Out-Routinen befinden sich auf dem Verwaltungsserver. Ebenso führen negative Ergebnisse (NOK) von Validierungsvorgängen, wie z.B. von der Händler- bzw. Bezahlsystemanbieter- Datenbanken nicht bestätigte Identitäten von Händlern oder Bezahlsystemanbie- ter/Walletbetreiber oder die Zahlungsablehnung eines Bezahlsystemanbieters zum Abbruch des Verfahrens mit entsprechenden Meldungen an den Kunden.
Obwohl eine Vielzahl von Informationen geprüft und viele Daten transportiert werden, finden nur wenige Datenübertragungen über die knappe Bandbreite der Mobiltelefonverbindung statt. Der vom tragbaren Telekommunikationsgerät an den Walletbetreiber bzw. Bezahlsystemanbieter versandte erste Nutzdatensatz ist wenige Kilobyte groß. Die Statusmeldungen machen jeweils weniger als 1 Kb aus. Der Hauptteil der Informationen bzw. Daten wird innerhalb von kabelgestützten Highspeed-Internetverbindungen zwischen dem Walletbetreiber bzw. Bezahlsystemanbieter, dem Verwaltungsserver und dem Warenwirtschaftssystem ausgetauscht. Das gesamte Verfahren ist so ausgelegt, dass vom Scan des QR-Codes bzw. des NFC-Chips bis zur Kaufbestätigung an den Kunden durchschnittlich nicht mehr als 5 Sekunden Zeit benötigt werden.
Zusammenfassend lässt sich sagen, dass das vorgestellte Verfahren auf dem Gebiet des Mobile Payment für den Mobile Commerce angewandt wird und der Kaufabwicklung für Waren oder Dienstleistungen (Produkte) an jedem beliebigen Ort ohne die Zwischenschaltung eines Internet-Shops und ohne eine Kasse dient. Dabei erreicht es die Ubiquität eines echten Mobile Commerce durch Trennung der datenlastigen Produktbeschreibung von den Daten des Zahlungsvorgangs. Lediglich kaufrelevante Daten werden über die Mobiltelefonverbindung übertragen. So kann unabhängig von der Datenbandbreite das gleiche Einkaufserlebnis überall gewährleistet werden, wo zumindest die langsamste Datenverbindung zur Verfügung steht.
Die Produktinformationen sind in Form von Artikelnummer und Anbieterkennzeichen ohne Preisinformation in einem QR-Code oder einem NFC-Chip gespeichert. Die Beschreibung der Produkte findet außerhalb des tragbaren Telekommunikationsgeräts in jeder Darstellungsform statt. Lediglich die Möglichkeit, einen QR- Code oder NFC-Chip zu scannen muss gegeben sein. Somit ist es dem Kunden ermöglicht, ein Produkt direkt und ohne Umwege über einen Web-Shop zum Beispiel direkt aus einem Katalog heraus, von einem Plakat oder von einem Flyer oder einer ähnlichen nicht Internet-basierten Waren- oder Produktpräsentation unter Nutzung eines tragbaren Telekommunikationsgerät zu erwerben.
Eine Manipulation der Preisinformation und das Problem begrenzter Kontingente werden durch eine Verbindung zum Warenwirtschaftssystem des Händlers und eine Warenkorbfunktion gelöst. Diese Verbindung bzw. Funktionen stellt ein Verwaltungsserver zur Verfügung, der als Brücke zwischen Kunde und Händler über geeignete Schnittstellen verfügt.
Das Verfahren speichert keine personenbezogenen Daten des Kunden. Rech- nungs- bzw. Versandinformationen werden vom Verwaltungsserver lediglich vom Kunden über den Bezahlsystemanbieter zum Händler transportiert.
Das Verfahren umfasst demnach unter anderem die folgenden Verfahrensschritte:
- Einscannen einer außerhalb des mobilen Telekommunikationsgeräts angeordneten Codierung (Point-of-Sale-ID) mittels eines mobilen Telekommunikationsgeräts durch einen Nutzer, wobei die Codierung für die Kaufabwicklung relevante Kaufinformation enthält, insbesondere umfassend eine einen Händler identifizierende Information (Händler-ID) und eine ein Produkt identifizierende Information (Produkt-ID),
- Senden eines Kunden-Datensatzes, der die Kaufinformation und eine den Kunden identifizierende Information enthält, über eine erste Telekommunikationsverbindung an einen ersten, das Clearing der Zahlung ermöglichenden Server (Ser- ver des Walletbetreibers oder Bezahlsystemanbieters),
- Generieren eines Anfrage- Datensatzes, der die Kaufinformation und bevorzugt eine den Walletbetreiber bzw. Bezahlanbieter identifizierende Information (Be- zahlsystemanbieter-ID) enthält, auf dem ersten Server und senden dieses Anfrage-Datensatzes an einen sich vom ersten Server unterscheidenden zweiten Server (Verwaltungsserver) über eine zweite Telekommunikationsverbindung,
- bevorzugt Prüfen von in dem Anfrage-Datensatz enthaltener Information, insbesondere der Händler-ID (Händler-Ident-Prüfung) und der Walletbetreiber-ID bzw. Bezahlsystemanbieter-ID (Bezahlsystemanbieter-Ident-Prüfung) auf dem zweiten Server,
- Weiterleiten von in dem Anfrage-Datensatz enthaltener Information, insbesondere der für den Händler relevanten Kaufinformation, an einen dritten, das Warenkontingent des Händlers verwaltenden Server (Warenwirtschaftssystem des das Produkt anbietenden Händlers) über eine dritte Telekommunikationsverbindung,
- Prüfen der Verfügbarkeit des angefragten Produkts auf dem dritten Server (Kontingent-Prüfung) und Senden einer Kontingent-Meldung vom dritten Server an den zweiten Server,
- Weiterleiten von in der Kontingent-Meldung enthaltener Information zur Verfügbarkeit des Produkts vom zweiten Server an den ersten Server,
- Durchführen des Clearings der Zahlung, gegebenenfalls unter vorheriger erneuter Anforderung einer Kaufbestätigung (Kauf-OK) vom Kunden, durch den ersten Server,
- Übermitteln von personenbezogenen (Versand-) Daten des Kunden vom ersten Server über den zweiten Server an den dritten Server, bevorzugt ohne Zwi- schenspeicherung der personenbezogenen Daten des Kunden auf dem zweiten Server.
Das Clearing der Zahlung kann grundsätzlich selbstverständlich auch schon vorgenommen werden, bevor der Anfrage-Datensatz vom Wallet-Betreiber bzw. Bezahlsystemanbieter an den Verwaltungsserver gesandt wird. Der Anfrage- Datensatz würde in einem solchen Fall nur dann an den Verwaltungsserver gesandt werden, wenn das Clearing positiv war. Dies bedingt allerdings, dass der Preis des Produkts bekannt dem Wallet-Betreiber bzw. dem Bezahlsystem- Anbieter zumindest insoweit bekannt ist, dass die Bonität des Kunden für diesen Zahlungsvorgang überprüft werden kann. Der Anfrage- Datensatz würde dann bereits eine Clearing-Ok Information enthalten.
Das Nicht-Speichern der personenbezogenen Daten des Kunden auf dem Verwaltungsserver hat insbesondere den Vorteil, dass der Verwaltungsserver als echter Vermittler zwischen einem Kunden bzw. dessen Wallet-Betreiber bzw. Bezahlsystem-Anbieter und dem Händler fungieren kann, ohne gegenüber dem Kunden erkennbar in Erscheinung zu treten und ohne dass es einer Einwilligung des Kunden dazu bedürfte, wie der Betreiber des Verwaltungsservers mit personenbezogenen Daten umgeht.
Das Verfahren ermöglicht in einfacher Weise die Verknüpfung von Wallet- Betreibern bzw. Bezahlsystemanbietern auf der einen sowie von Webshops oder sonstigen Händlern auf der anderen Seite.
Anhand der Zeichnungen wird die Erfindung nachstehend eingehender beschrieben. Es zeigt:
Fig. 1 das System für das Abwicklungsverfahren aus einer Walletbetreiber-App Fig. 2 das System für das Abwicklungsverfahren aus einer Bezahlsystemanbie- ter-App
Fig. 3 den Ablauf des Abwicklungsverfahrens mit einer Walletbetreiber-App Fig. 4 den Ablauf des Abwicklungsverfahrens mit einer Bezahlsystemanbieter- App
Figur 1 zeigt das System für den Betrieb mit einer Wallet. Das System für das beschriebene Verfahren besteht aus einem tragbaren Telekommunikationsgerät (1 ) mit einer beliebigen Wallet (2). Das Verfahren setzt eine Mobilfunk- oder Netzwerkverbindung (12) für den Kontakt zu dem Walletbetreiber (3) der die Wallet unter (2) betreibt voraus. Der Walletbetreiber (3) kommuniziert mit dem Verwaltungsserver (5) und dem vom Kunden in der Wallet ausgewählten Bezahlsystemanbieter (6) über Telekommunikationsverbindungen (13, 14). Ein beliebiger Point of Sale (4) ist mit einem QR-Code und/oder NFC-Chip (7) ausgestattet, welcher die eindeutige Point-of-Sale-ldentifikations-Nummer PID enthält. Diese PID besteht aus einer eineindeutigen ID des Händlers und einer Artikelnummer.
Figur 2 zeigt das System für den Betrieb mit einer Bezahlsystemanbieter-App. Das System für das beschriebene Verfahren besteht aus einem tragbaren Telekommunikationsgerät (1 ) mit einer beliebigen Bezahlsystem-App (2). Das Verfahren setzt eine Mobilfunk-oder Netzwerkverbindung (12) für den Kontakt zu dem Bezahlsystemanbieter (6), der das Bezahlsystem unter (2) betreibt, voraus. Der Bezahlsystemanbieter (6) kommuniziert mit dem Verwaltungsserver (5) über eine Telekommunikationsverbindung (13). Ein beliebiger Point of Sale (4) ist mit einem QR-Code und/oder NFC-Chip (7) ausgestattet, welcher die eindeutige Point-of- Sale-Identifikations-Nummer PID enthält. Diese PID besteht aus einer eineindeutigen ID des Händlers und einer Artikelnummer.
Figur 3 bzw. Figur 4 veranschaulichen weitere Einzelheiten der Verfahren mit einer Wallet (Fig. 3) bzw. einer Bezahlsystemanbieter-App (Fig. 4).
Das Verfahren wird durch den Kunden eingeleitet, indem er im tragbaren Telekommunikationsgerät (1 ) entweder seine Wallet (2) öffnet und darin sein für die anstehende Zahlung bevorzugtes Bezahlsystem auswählt oder direkt eine Bezahlsystem-App (2) öffnet und die PID (7) über den QR-Code oder den NFC-Chip in seine Wallet- bzw. die Bezahlsystem-App (2) optisch oder elektronisch einscannt (10) und die gewünschte Menge auswählt. Ein Kunden-Datensatz (a), bestehend aus der PID, der Kunden-ID, der ID des tragbaren Telekommunikationsgeräts, der Menge, ggfs. einer in der Wallet oder der Bezahlsystem-App gespeicherten von der Rechnungsadresse abweichenden Versandadresse und - im Fall der Wallet - der Angabe zum gewählten Bezahlsystem wird im tragbaren Telekommunikationsgerät (1 ) generiert und über die Mobilfunkverbindung (12) des tragbaren Telekommunikationsgeräts (1 ) an den Walletbetreiber (3 - Fig. 3) oder Bezahlsystemanbieter (6 - Fig. 4) gesandt.
Der vom tragbaren Telekommunikationsgerät (1 ) kommende Kunden-Datensatz (a) erreicht entweder den Walletbetreiber (3 - Fig. 3) oder den Bezahlsystemanbieter (6 - Fig. 4). Dort wird anhand der speziellen Datenkonstellation das Kontingent- Verfahren identifiziert und eine Kunden-Ident-Prüfung durchgeführt. Ein negatives Ergebnis der Kunden-Ident-Prüfung führt zu einer Abbruchmeldung an den Kunden.
Nach erfolgreicher Kunden-Ident-Prüfung sendet der Walletbetreiber (3 - Fig. 3) oder der Bezahlsystemanbieter (6 - Fig. 4) einen Kontingent-Anfrage-Datensatz
(b) bestehend aus der PID, der Bezahlsystemanbieter-ID, einer eindeutigen Vor- gangs-ID und der gewünschten Menge über die Telekommunikationsverbindung (13) an den Verwaltungsserver (5).
Der auf dem Verwaltungsserver (5) eingehende Kontingent-Anfrage-Datensatz (b) des Walletbetreibers (3 - Fig. 3) bzw. Bezahlsystemanbieters (6 - Fig. 4) wird zunächst der Bezahlsystemanbieter-Ident-Prüfung durch Abgleich mit der Bezahlsystemanbieter-Datenbank (8) unterzogen.
Ist der Walletbetreiber (3) bzw. Bezahlsystemanbieter (6) nicht in der Bezahlsystemanbieter-Datenbank (8) gelistet, bricht der Verwaltungsserver (5) den Vorgang mit einem NOK über die Telekommunikationsverbindung (13) an den Walletbetreiber (3 - Fig. 3) bzw. Bezahlsystemanbieter (6 - Fig. 4) ab. Dieser meldet den Abbruch an seinen Kunden.
Ist der Walletbetreiber (3) bzw. Bezahlsystemanbieter (6) in der Bezahlsystemanbieter-Datenbank (8) gelistet, generiert der Verwaltungsserver ein OK (OK) und leitet den Kontingent-Anfrage-Datensatz (b) zur Händler-Ident-Prüfung an die Händler-Datenbank (9) weiter.
Ist der Händler nicht in der Händler-Datenbank (9) gelistet, bricht der Verwaltungsserver (5) den Vorgang mit einem NOK über die Telekommunikationsverbindung (13) an den Walletbetreiber (3 - Fig. 3) bzw. Bezahlsystemanbieter (6 - Fig. 4) ab. Dieser meldet den Abbruch an seinen Kunden.
Erhält der Verwaltungsserver (5) ein OK aus der Ident-Prüfung von der Händler- Datenbank (9), erhält der Kontingent-Anfrage-Datensatz (b) nun eine vom Verwaltungsserver zugewiesene Warenkorbnummer. Diese Warenkorbnummer ist eine einmalige eindeutige ID. Dann leitet der Verwaltungsserver (5) den Kontingent- Anfrage- Datensatz (b) ohne die Bezahlsystemanbieter ID über die Telekommunikationsverbindung (15) zum Händler (1 1 ).
Über die im Kontingent-Anfrage-Datensatz (b) enthaltene Artikelnummer und Menge wird im Warenwirtschaftssystem des Händlers (1 1 ) die Kontingent-Prüfung (KP) durch Abfrage des Lagerbestandes durchgeführt. Ist kein Kontingent oder ein nicht mehr ausreichendes Kontingent unter der angefragten Artikelnummer vorhanden, wird automatisch eine Kontingent-NOK-Meldung (NOK) über die Telekommunikationsverbindung (15) vom Händler (1 1 ) an den Verwaltungsserver (5) und von dort weiter über die Telekommunikationsverbindung (13) an den Wallet- betreiber (3 - Fig. 3) oder den Bezahlsystemanbieter (6 - Fig. 4) zurück gesandt. Dieser meldet den Kontingentstatus als Abbruch (Ausverkauft) an den Kunden.
Ist ausreichend Kontingent zur Bedienung des Kaufwunsches vorhanden, wird die angefragte Warenmenge unter der vom Verwaltungsserver (5) zugewiesenen Warenkorbnummer in einen Warenkorb (16) im Warenwirtschaftssystem des Händlers (1 1 ) gebucht und mit dem aktuellen Preis aus dem Warenwirtschaftssystem versehen.
Das Warenwirtschaftssystem (1 1 ) sendet daraufhin den Kontingent-Antwort- Datensatz (c) über die Telekommunikationsverbindung (15) an den an den Verwaltungsserver (5). Dieser Kontingent-Antwort-Datensatz (c) enthält alle Angaben des Kontingent-Anfrage-Datensatzes (b) (ohne Bezahlsystemanbieter-ID), zudem die Preisinformation aus dem Warenwirtschaftssystem und die Kontingent-OK- Meldung (OK).
Der Verwaltungsserver leitet diesen Kontingent-Antwort-Datensatz (c) an den Wal- letbetreiber (3 - Fig. 3) oder den Bezahlsystemanbieter (6 - Fig. 4) weiter. Der Wal- letbetreiber (3 - Fig. 3) oder Bezahlsystemanbieter (6 - Fig. 4) übermittelt die Preis- und Mengeninformation über die Mobiltelefonverbindung (12) an den Kun- den. Der Kunde bestätigt den Kauf und sendet sein Kauf-OK über die Mobiltelefonverbindung (12) zurück an den Walletbetreiber (3 - Fig. 3) oder Bezahlsystemanbieter (6 - Fig. 4).
Beim Walletbetreiber (3 - Fig. 3) bzw. Bezahlsystemanbieter (6 - Fig. 4) wird durch das Kauf-OK des Kunden aus dem Kontingent-Antwort-Datensatz (c) der Clearing- Anfrage-Datensatz (d). Dieser enthält alle Daten des Kontingent-Antwort- Datensatzes (c) ohne Artikelnummer und Menge sowie die für das Clearing notwendigen Daten des vom Kunden ausgewählten Bezahlsystems.
Der Walletbetreiber (3 - Fig. 3) holt sich mit dem Clearing-Anfrage-Datensatz (d) vom Betreiber des vom Kunden gewählten Bezahlsystems (6 - Fig. 3) das Ergebnis des Clearingverfahrens in Form des Clearing-Antwort-Datensatzes (e) mit der Bestätigung der Zahlung (OK) oder der Ablehnung (NOK) über die Telekommunikationsverbindung (14) ein. Der Clearing-Antwort-Datensatz (e) enthält alle Angaben des Clearing-Anfrage-Datensatzes (d) und das Prüfergebnis.
Hat der Kunde für die Zahlung die App eines Bezahlsystemanbieters (6 - Fig. 4) ausgewählt, wird dieser hausintern die Zahlungsanfrage prüfen und den Clearing- Antwort- Datensatz (e) erstellen.
Der Walletbetreiber (3 - Fig. 3) bzw. Bezahlsystemanbieter (6 - Fig. 4) sendet den Clearing-Antwort-Datensatz (e) über die Telekommunikationsverbindung (13) an den Verwaltungsserver (5). Wenn das Clearing zu einem NOK geführt hat, sendet der Verwaltungsserver (5) einen Lösch-Datensatz, bestehend aus der Warenkorbnummer und einem NOK über die Telekommunikationsverbindung (15) zum Löschen des Warenkorbs (16) in das Warenwirtschaftssystem des Händlers (1 1 ). Die Löschung des Warenkorbs führt zu einer Rückbuchung des im Warenkorb geblockten Kontingents in den Lagerbestand des Händlers (1 1 ).
Enthält der vom Bezahlsystemanbieter kommende Clearing-Antwort-Datensatz (e) ein Clearing-OK, sendet der Walletbetreiber das Clearing-OK zusammen mit den Rechnungs- und ggfs. den Versanddaten des Kunden und der Warenkorbnummer an den Verwaltungsserver (5). Dieser speichert nur das Clearing-OK zusammen mit der Vorgangs-ID und der Warenkorbnummer ab und leitet Warenkorbnummer und Vorgangs-ID zusammen mit den Rechnungs- und Versanddaten des Kunden ohne Speicherung der persönlichen Daten an das Warenwirtschaftssystem des Händlers (1 1 ) weiter. Dieses bestätigt den Empfang der Daten an den Verwaltungsserver (5) mit einem Warenkorb-OK. Der Verwaltungsserver generiert daraus ein Vorgang-OK und leitet dieses über die Telekommunikationsverbindung (13) an den Walletbetreiber. Dieser leitet die Bestätigung des Vorgangs über die Mobilfunkverbindung (12) an die Wallet oder Bezahlsystem-App (2) im tragbaren Telekommunikationsgerät des Kunden (1 ). Damit ist der Vorgang abgeschlossen.
Bezugszeichenliste
1 tragbares Telekommunikationsgerät
2 Wallet bzw. Bezahlsystem-App
3 Walletbetreiber
4 POS - Point of Sale
5 Verwaltungsserver
6 Bezahlsystemanbieter
7 QR-Code oder NFC-Chip
8 Bezahlsystemanbieter-Datenbank
9 Händler-Datenbank
10 Einlese-Verbindung für den QR-Code oder NFC-Chip
1 1 Warenwirtschaftssystem des Händlers
12 Telekommunikationsverbindung zwischen der Wallet bzw. Bezahlsystem-App und dem Walletbetreiber bzw. Bezahlsystemanbieter
13 Telekommunikationsverbindung zwischen Verwaltungsserver und Walletbetreiber bzw. Bezahlsystemanbieter
14 Telekommunikationsverbindung zwischen Walletbetreiber und Bezahlsystemanbieter
15 Telekommunikationsverbindung zwischen Verwaltungsserver und Händler
16 Warenkorb a. Kunden-Datensatz
b. Kontingent-Anfrage-Datensatz
c. Kontingent-Antwort-Datensatz
d. Clearing-Anfrage-Datensatz
e. Clearing-Antwort-Datensatz
KP Anfrage Kontingent
OK positives Prüfergebnis
NOK negatives Prüfergebnis

Claims

Patentansprüche
1 . Verfahren für den ortsunabhängigen Handel mit Produkten unter Abwicklung der Zahlung über ein tragbares Telekommunikationsgerät,
dadurch gekennzeichnet, dass
die für die Kaufabwicklung relevanten Daten unter einer Point-of-Sale-ID (PID) codiert sind, die im Bereich einer Produktpräsentation außerhalb des tragbaren Telekommunikationsgeräts von diesem einscannbar angeordnet ist, und von dem tragbaren Telekommunikationsgerät (1 ) über eine Telekommunikationsverbindung (12) an einen Walletbetreiber (3) oder an einen Bezahlanbieter (6) übermittelt werden, wobei der Walletbetreiber (3) oder der Bezahlsystemanbieter zur Kaufabwicklung ein Warenwirtschaftssystem (1 1 ) des Händlers unter Zwischenschaltung eines Verwaltungsservers (5) kontaktiert.
2. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Point-of-Sale ID (PID) eine Händler-ID und eine Produkt-ID enthält.
3. Verfahren nach Patentanspruch 1 oder 2, dadurch gekennzeichnet, dass die
Point-of-Sale ID (PID) als Barcode, QR-Code oder NFC-Chip vorhanden ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch die weiteren Verfahrensschritte
- Vornahme einer Kunden-Ident-Prüfung durch den Walletbetreiber (3) oder Bezahlanbieter (6),
- senden eines Kontingent-Anfrage-Datensatzes (b) an den Verwaltungsserver (5) über eine Telekommunikationsverbindung (13) nach erfolgreicher Kunden- Ident-Prüfung,
- Kontaktieren des Warenwirtschaftssystems (1 1 ) des Händlers durch den Verwaltungsserver (5).
5. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass vor dem Kontaktieren des Warenwirtschaftssystems (1 1 ) des Händlers durch den Verwaltungsserver (5) eine Bezahlsystemanbieter-Ident-Prüfung vorgenommen wird.
6. Verfahren nach einem der beiden vorhergehenden Ansprüche, dadurch gekennzeichnet, dass vor dem Kontaktieren des Warenwirtschaftssystems (1 1 ) des Händlers durch den Verwaltungsserver (5) eine Händler-Ident-Prüfung vorgenommen wird.
7. Verfahren nach einem der drei vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Kontingent-Anfrage-Datensatz (b) eine vom Verwaltungsserver (5) zugewiesene Warenkorb-ID erhält.
8. Verfahren nach einem der vier vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der vom Walletbetreiber (3) oder Bezahlsystemanbieter (6) gesendete Kontingent-Anfrage-Datensatz (b) ohne die Bezahlsystemanbie- ter-ID von dem Verwaltungsserver (5) an das Warenwirtschaftssystem (1 1 ) des Händlers gesandt wird.
9. Verfahren nach einem der fünf vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Warenwirtschaftssystem (1 1 ) des Händlers eine Kontingent-Prüfung (KP) vorgenommen wird.
10. Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass nach erfolgreicher Kontingent-Prüfung (KP) ein Kontingent-Antwort- Datensatz (c) vom Warenwirtschaftssystem (1 1 ) des Händlers über eine Telekommunikationsverbindung (15) an den Verwaltungsserver (5) gesandt wird.
1 1 . Verfahren nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass der Verwaltungsserver (5) den Kontingent-Antwort-Datensatz (c) an den Walletbetreiber oder den Bezahlsystemanbieter weiterleitet, der die für ein Kauf-OK des Kunden erforderlichen Daten an den Kunden weiterleitet.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach einem Kauf-OK, das nach vom Kunden über die Telekommunikationsverbindung (12) an den Wallet-Betreiber (3) oder Bezahlsystemanbieter (6) gesendet wird, vom Walletbetreiber (3) oder Bezahlsysteman- bieter (6) ein Clearing-Antwort-Datensatz (e) erstellt wird, der das Ergebnis eines Clearingverfahrens (Clearing-OK oder Clearing-NOK) enthält.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Clearing-Antwort-Datensatz (e) vom Walletbetreiber (3) oder Bezahlsystemanbieter (6) an den Verwaltungsserver weitergeleitet gesendet wird.
14. Verfahren zum Betreiben eines in ein Verfahren nach einem der vorhergehenden Ansprüche eingebundenen Verwaltungsservers (5), bei dem der Verwaltungsserver (5) von einem Wallet-Betreiber oder Bezahlsystemanbieter über eine Telekommunikationsverbindung (13) für den Kauf eines Produkts relevante Daten, die zumindest eine Händler-ID eines Händlers und eine Produkt- ID eines von einem Kunden angefragten Produkt enthalten, erhält, und der Verwaltungsserver (5) das Warenwirtschaftssystem (1 1 ) des Händlers kontaktiert.
PCT/EP2014/071464 2013-10-08 2014-10-07 Verfahren für den ortsunabhängigen handel mit produkten (mobile commerce) unter abwicklung der zahlung über ein tragbares telekommunikationsgerät (mobile payment) WO2015052198A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE112014004631.0T DE112014004631A5 (de) 2013-10-08 2014-10-07 Verfahren für den ortsunabhängigen Handel mit Produkten (Mobile Commerce) unter Abwicklung der Zahlung über ein tragbares Telekommunikationsgerät (Mobile Payment)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013016594 2013-10-08
DE102013016594.6 2013-10-08

Publications (1)

Publication Number Publication Date
WO2015052198A1 true WO2015052198A1 (de) 2015-04-16

Family

ID=51830277

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2014/071464 WO2015052198A1 (de) 2013-10-08 2014-10-07 Verfahren für den ortsunabhängigen handel mit produkten (mobile commerce) unter abwicklung der zahlung über ein tragbares telekommunikationsgerät (mobile payment)

Country Status (2)

Country Link
DE (2) DE102014003878A1 (de)
WO (1) WO2015052198A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021112724A1 (de) 2020-12-29 2022-06-30 Boards & More Gmbh Flügelrigg
EP4023546A1 (de) 2020-12-29 2022-07-06 Boards & More GmbH Flügelrigg
DE102021214265A1 (de) 2021-12-13 2023-06-15 Boards & More Gmbh Wing

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110251910A1 (en) * 2010-04-13 2011-10-13 James Dimmick Mobile Phone as a Switch
US20120150750A1 (en) * 2010-12-14 2012-06-14 Xtreme Mobility Inc. System and method for initiating transactions on a mobile device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110251910A1 (en) * 2010-04-13 2011-10-13 James Dimmick Mobile Phone as a Switch
US20120150750A1 (en) * 2010-12-14 2012-06-14 Xtreme Mobility Inc. System and method for initiating transactions on a mobile device

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021112724A1 (de) 2020-12-29 2022-06-30 Boards & More Gmbh Flügelrigg
EP4023546A1 (de) 2020-12-29 2022-07-06 Boards & More GmbH Flügelrigg
DE102021214265A1 (de) 2021-12-13 2023-06-15 Boards & More Gmbh Wing
WO2023110897A1 (de) 2021-12-13 2023-06-22 Boards & More Gmbh Wing für windkraftgetriebene sportarten

Also Published As

Publication number Publication date
DE112014004631A5 (de) 2016-09-29
DE102014003878A1 (de) 2015-04-09

Similar Documents

Publication Publication Date Title
KR100659668B1 (ko) 가상 추천 게이트를 이용한 이-마켓 플레이스의 회원추천영업 지원 시스템 및 그 방법
DE102011088614A1 (de) Verfahren zur Handhabung von elektronischen Gutscheinen
DE112005002673T5 (de) Verbessertes lokales Internet-Einkaufssystem und Verfahren dazu
WO2003042938A2 (de) Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge
DE212014000189U1 (de) Verwaltung und Abwicklung von Händlerdarlehen
DE202012100172U1 (de) Elektronisches Gutscheinsystem
DE20220745U1 (de) Sicheres Online-Zahlungssystem
DE112010001967T5 (de) Bezahlverfahren und System für einenetzwerkbasierte Marktplatztransaktion
EP1143323A1 (de) Informations- und Kommunikationssystem
WO2015052198A1 (de) Verfahren für den ortsunabhängigen handel mit produkten (mobile commerce) unter abwicklung der zahlung über ein tragbares telekommunikationsgerät (mobile payment)
US20130290214A1 (en) Method and apparatus for providing reviews and feedback for professional service providers
US7506028B2 (en) Internet-supported information system
CH710912B1 (de) Sichere Transaktionsverarbeitung in einem Kommunikationssystem.
KR20000049678A (ko) 인터넷을 이용한 카드 추천 및 발급 시스템 및 방법과카드몰을 이용한 포인트 산출방법
EP1193658A1 (de) Verfahren und Anordnung zur Übertragung eines elektronischen Geldbetrages aus einem Guthabenspeicher
KR102525497B1 (ko) 부동산 중개 시스템 및 중개 방법
JP6351816B1 (ja) ポイントシステムを用いた３者型クラウドファンディングシステム
WO2014029893A1 (de) Warensystem und verfahren für ein warensystem
DE102018112795A1 (de) Verfahren zur Erzeugung eines Finanzierungsangebots
DE10126746A1 (de) Elektronisches Rabatt-System
KR20050112015A (ko) 네트워크를 이용한 독립 쇼핑몰 운영 방법 및 이를실행하기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는기록매체
Afzal EC adoption and Critical Success factors of EC in SMEs in Iran
DE102005060746A1 (de) Verfahren zur Übertragung von digitalen Daten zwischen einem mobilen Gerät und einem Anzeigeterminal
DE10151200A1 (de) System, Verfahren und Computerprogramm-Produkt zur Erzeugung und/oder Verwendung einer mobilen Digitalkarte
DE202018100360U1 (de) Computersystem zur Abwicklung von Bestellvorgängen

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14790020

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 1120140046310

Country of ref document: DE

Ref document number: 112014004631

Country of ref document: DE

REG Reference to national code

Ref country code: DE

Ref legal event code: R225

Ref document number: 112014004631

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14790020

Country of ref document: EP

Kind code of ref document: A1