DE60302416T2 - Verfahren zur Verwaltung von Prepaid-Konten und zum Ausführen von Transaktionen in einem elektronischen Handelssystem - Google Patents

Verfahren zur Verwaltung von Prepaid-Konten und zum Ausführen von Transaktionen in einem elektronischen Handelssystem Download PDF

Info

Publication number
DE60302416T2
DE60302416T2 DE60302416T DE60302416T DE60302416T2 DE 60302416 T2 DE60302416 T2 DE 60302416T2 DE 60302416 T DE60302416 T DE 60302416T DE 60302416 T DE60302416 T DE 60302416T DE 60302416 T2 DE60302416 T2 DE 60302416T2
Authority
DE
Germany
Prior art keywords
service
subscriber
account
request
commerce
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60302416T
Other languages
English (en)
Other versions
DE60302416D1 (de
Inventor
William Dale Gahanna Bartter
Yigang Naperville Cai
Allan Terry Glendale Rush
Brian Robertson Rae
Mark Raymond Dublin Locher
Sridhar Sripathi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia of America Corp
Original Assignee
Lucent Technologies Inc
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 Lucent Technologies Inc filed Critical Lucent Technologies Inc
Publication of DE60302416D1 publication Critical patent/DE60302416D1/de
Application granted granted Critical
Publication of DE60302416T2 publication Critical patent/DE60302416T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/005—Personal communication services, e.g. provisions for portability of subscriber numbers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/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/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic 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/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/403—Solvency checks
    • 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/403—Solvency checks
    • G06Q20/4037—Remote solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/47—Fraud detection or prevention means
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/51—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP for resellers, retailers or service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/765—Linked or grouped accounts, e.g. of users or devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/70—Administration or customization aspects; Counter-checking correct charges
    • H04M15/77—Administration or customization aspects; Counter-checking correct charges involving multiple accounts per user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/82—Criteria or parameters used for performing billing operations
    • H04M15/8214—Data or packet based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/83—Notification aspects
    • H04M15/85—Notification aspects characterised by the type of condition triggering a notification
    • H04M15/854—Available credit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H04M15/90—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP using Intelligent Networks [IN] or Advanced Intelligent Networks [AIN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M17/10—Account details or usage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M17/20—Prepayment of wireline communication systems, wireless communication systems or telephone systems with provision for recharging the prepaid account or card, or for credit establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0029—Provisions for intelligent networking
    • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/102—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measure for e-commerce
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/0148—Fraud detection or prevention means
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/016—Billing using Intelligent Networks [IN] or Advanced Intelligent Networks [AIN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/01—Details of billing arrangements
    • H04M2215/018—On-line real-time billing, able to see billing information while in communication, e.g. via the internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20—Technology dependant metering
    • H04M2215/2013—Fixed data network, e.g. PDN, ATM, B-ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20—Technology dependant metering
    • H04M2215/2026—Wireless network, e.g. GSM, PCS, TACS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/20—Technology dependant metering
    • H04M2215/204—UMTS; GPRS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/32—Involving wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/54—Resellers-retail or service providers billing, e.g. agreements with telephone service operator, activation, charging/recharging of accounts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/72—Account specifications
    • H04M2215/724—Linked accounts
    • H04M2215/7254—Multiple accounts per user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/78—Metric aspects
    • H04M2215/782—Data or packet based
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/81—Notifying aspects, e.g. notifications or displays to the user
    • H04M2215/815—Notification when a specific condition, service or event is met
    • H04M2215/8166—Available credit
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13003—Constructional details of switching devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1305—Software aspects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13095—PIN / Access code, authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13097—Numbering, addressing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1313—Metering, billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13196—Connection circuit/link/trunk/junction, bridge, router, gateway
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1329—Asynchronous transfer mode, ATM
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13339—Ciphering, encryption, security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13345—Intelligent networks, SCP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Marketing (AREA)
  • Telephonic Communication Services (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Erfindung betrifft allgemein das Gebiet des elektronischen Handels (oder "E-Commerce") und insbesondere ein intelligentes, netzwerkgestütztes E-Commerce-System, das Vorbezahlungs-Dienstangebote enthält.
  • ALLGEMEINER STAND DER TECHNIK
  • Es ist bekannt, daß Kommunikationsnetze wie zum Beispiel das Internet Kommunikationseinrichtungen verbinden, die ein großes geographisches Gebiet überspannen. Im allgemeinen ist das (manchmal als World Wide Web bezeichnete) Internet eine Kombination lokaler Netzwerke (LANs) und großflächiger Netzwerke (WANs), die dieselben Protokolle sprechen, um so vielfältigen, mit dem Internet verbundenen Kommunikationseinrichtungen die Kommunikation miteinander zu erlauben. Die im Internet verwendete Protokollsuite ist als TCP (Transmission Control)/IP (Internet Protocol) (oder TCP/IP) bekannt. Kommunikationseinrichtungen, die auf das Internet zugreifen können, sind zum Beispiel Computer, Mobiltelefone, drahtlose Fernsprecher, Pager, Sprechfunkgeräte und PDAs (personal digital assistants). Die Kommunikationseinrichtungen verbinden sich mit dem Internet unter Verwendung von Zugangstechnologien wie etwa Ethernet, Telefonleitungen, Basis-Funkgeräten, Satelliten oder ATM-Netzwerken (asynchroner Transfermodus).
  • Benutzer von mit dem Ethernet verbundenen Kommunikationseinrichtungen können wohlbekanntlich durch vielfältige Websites surfen, die von Geschäftsunternehmen, Behörden, Finanz- und Bildungsinstituten und dergleichen gehostet werden. Es ist bekannt, daß bestimmte dieser Sites Waren oder Dienstleistungen zum Verkauf anbieten, die elektronisch vom Internetbenutzer erworben werden können (d.h. durch Durchführung von Zeigen- und -Klicken, Tastenbetätigungen und dergleichen über die Benutzereinrichtung). Diese Art von Verkaufstransaktion ist allgemein als elektronischer Handel oder E-Commerce bekannt. Wie zur Zeit bekannt ist, erfordern E-Commerce-Transaktionen, daß der Benutzer, nachdem er zu erwerbende Artikel oder Dienstleistungen ausgewählt hat, eine Kreditkartennummer eingibt, um die Bezahlung zu bewirken. (Als Alternative kann der Kunde bereits bei einer früheren Transaktion eine Kreditkarte eingegeben haben und der Verkäufer hat einen Datensatz der Karte behalten). Danach verifiziert der Verkäufer die Kreditkartenautorisation, liefert die gewählten Waren oder Dienstleistungen und erhält Bezahlung von der Kreditkartengesellschaft. Der Kunde bezahlt bei der Kreditkartengesellschaft zu einem bestimmten späteren Zeitpunkt.
  • Ein Problem, das entsteht, besteht darin, daß bestimmte potentielle E-Commerce-Kunden möglicherweise noch keine Kreditkarte besitzen, aber dennoch Waren oder Dienstleistungen im Internet erwerben möchten. Diese Kunden wären zum Beispiel Minderjährige, Personen von auf Bargeld basierenden Ökonomien, Personen, die wahrscheinlich bei Kreditprüfungen durchfallen oder Personen, die keine Kreditkarten mögen. Dies ist ein enormer potentieller Markt, der von E-Commerce-Händlern zur Zeit nicht angezapft wird. Um diesen Markt anzuzapfen, wäre es wünschenswert, daß netzwerkgestützte Händler solchen Kunden "Vorbezahlungs-Dienst" anbieten, so daß die Kunden aus den verschiedensten gesellschaftlichen Gruppierungen für ein bestimmtes Niveau von Waren oder Dienstleistungen im voraus bezahlen können, (statt zu einem bestimmten späteren Zeitpunkt wie bei herkömmlichen E-Commerce-Transaktionen eine Rechnung zu bezahlen), so daß dem Kunden die Gelegenheit gegeben wird, E-Commerce-Transaktionen auszuführen, solange das Kreditniveau in dem Vorbezahlungs-Account nicht gelöscht ist. Vorbezahlungsdienstangebote sind für die Sprechtelekommunikation bekannt, waren aber bisher nicht für E-Commerce-Transaktionen verfügbar.
  • US-A-2002/062249 beschreibt ein interaktives, voll integriertes profitgestütztes Online-Werteaustausch- und -Begleichungsprogramm, das die Maximierung von Profiten/Gutschriften betrifft, wie zum Beispiel Gutschriften für häufiges Fliegen oder andere Anreizgutschriften, die mit herkömmlichen Kreditkartentransaktionen assoziiert sind. Zu diesem Zweck stellt es einen Mechanismus bereit, um Käufer darüber zu informieren, welche Kreditkarte(n) verwendet werden sollen, um die besten Profite zu erhalten, während variierende Präferenzen für individuelle Käufer berücksichtigt werden.
  • EP-A-1 096 809 betrifft ein System und Verfahren zur Bereitstellung von Diensten des IN (intelligenten Netzwerks). Bei der Bereitstellung solcher Dienste werden INAP-Nachrichten (INAP = Anwendungsteil des intelligenten Netzwerks) zwischen Dienstvermittlungspunkten eines Telekommunikationsnetzes und Dienststeuerpunkten (STP) ausgetauscht.
  • KURZE DARSTELLUNG DER ERFINDUNG
  • Ein Verfahren und System gemäß der Erfindung werden in den unabhängigen Ansprüchen definiert. Bevorzugte Formen werden in den abhängigen Ansprüchen definiert.
  • Ausführungsformen des Systems und Verfahrens gemäß der vorliegenden Erfindung liefern ein intelligentes, netzwerkgestütztes E-Commerce-System, das Vorbezahlungs-Dienstangebote enthält. Der Vorbezahlungs-E-Commerce-Dienst baut auf bereits existierenden Vorbezahlungs- Sprachtelekommunikationsdienstangeboten auf und ist mit diesen kompatibel, wodurch es Vorbezahlungskunden möglich wird, Fernsprech- und andere Diensttransaktionen durchzuführen, einschließlich auf dem Internet basierender Vorbezahlungskäufe und/oder Vorbezahlung auf Verkaufspunktbasis für beliebige Produkte oder Dienstleistungen ohne Erfordernis von Kreditkarten oder Verträgen und ohne monatliche Rechnungen zu erhalten. Der Dienst ist zentralisiert, so daß Kunden ein einziges Vorbezahlungs-Account (anstelle mehrerer einzelner Accounts) einrichten können, wobei dieses Account mehreren Dienstanbietern und Teilnehmern durch ein gemeinsames Gateway zugänglich ist.
  • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • Die obigen und weitere Vorteile der Erfindung werden bei Durchsicht der folgenden ausführlichen Beschreibung und bei Bezugnahme auf die Zeichnungen ersichtlich. Es zeigen:
  • 1 ein Blockschaltbild eines intelligenten, netzwerkgestützten E-Commerce-Systems, das Vorbezahlungsdienstangebote gemäß der vorliegenden Erfindung enthält;
  • 2 ein Flußdiagramm eines Verfahrens zum Authentifizieren eines Vorbezahlungsteilnehmer-Account in einem intelligenten, netzwerkgestützten System zum elektronischen Handel;
  • 3 ein Flußdiagramm eines Verfahrens zum Anfordern des Kontostands eines Vorbezahlungs-Teilnehmer-Account in einem intelligenten, netwerkgestützten elektronischen Handelssystem;
  • 4 ein Flußdiagramm eines Verfahrens zum Anfordern einer Belastung eines Teilnehmer-Account in einem intelligenten, netzwerkgestützten elektronischen Handelssystem;
  • 5 ein Flußdiagramm eines Verfahrens zum Anfordern einer Direktgutschrift für ein Teilnehmer-Account in einem intelligenten, netzwerkgestützten elektronischen Handelssystem; und
  • 6 ein Flußdiagramm des Betriebs eines intelligenten, netzwerkgestützten E-Commerce-Systems durch einen Endbenutzer.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM(EN)
  • Nunmehr mit Bezug auf die Zeichnungen und unter anfänglicher Bezugnahme auf 1 ist ein intelligentes, netzwerkgestütztes E-Commerce-System 100 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Das E-Commerce-System 100 umfaßt ein Dienstsystem 102, das über einen Gateway-Server 104 mit einem Paketnetzwerk 106 (wie gezeigt einem TCP/IP-Netzwerk) verbunden ist. Das Paketnetzwerk 106 hat eine Schnittstelle zu verschiedenen E-Commerce-Händlern und/oder -Diensten (die im folgenden als "Dienstanbieter" bezeichnet werden), die Zugriff auf das Dienstsystem 102 anfordern können, um E-Commerce-Transaktionen auszuführen. Wie gezeigt, gehören zu den Dienstanbietern eine Kurznachrichtendienstzentrale ("SMSC") 108, ein WAP-Server (Web Application Platform) 110, GPRS-Netzwerke (General Packet Radio Service) 112, Händlernetzwerke 114 und Finanznetzwerke 116. Wie gezeigt greifen die Händler- und Finanznetzwerke 114, 116 über das Internet 118 oder "Verkaufspunkt"-Server 120 auf das Dienstsystem zu. Teilnehmer des Vorbezahlungs-E-Commerce-Dienstes (d.h. E-Commerce-Kunden) können auch über das Internet 118 oder Verkaufspunkt-Server 120 Zugang zu dem Dienstsystem besitzen.
  • Es versteht sich, daß die in dem E-Commerce-System 100 gezeigten Dienstanbieter keine erschöpfende Liste repräsentieren, sondern allgemein vielfältige, Vorbezahlungs-Kunden verfügbare E-Commerce-Optionen abbilden. Die Arten von Diensten, die von den Dienstanbietern verfügbar sein können, sind zum Beispiel u.a. Kauf von Waren, Kinokarten, Fernsprechdiensten, SMS-Dienst, WAP-Dienst, Internetbenutzung, Internet-Spiele und -Musik oder -Datei-Heraufladen/-Herunterladen. Der Kunde tritt über (nicht gezeigte) Kommunikationseinrichtungen, darunter u.a. zum Beispiel Mobiltelefone, drahtlose, in der Hand gehaltene Einrichtungen, Kiosks, Verkaufspunkt-Clients, Internet-Bildschirme usw. mit dem Dienstanbieter in Dialog.
  • Das Dienstsystem 102 umfaßt mehrere Dienststeuerpunkte ("SCPs") 122, ein Dienstmanagersystem ("SMS") 124 und ein Auflad-Kartenverwaltungssystem ("ROMS") 126. Jede dieser Einrichtungen enthält jeweils Prozessoren und Speicher (nicht gezeigt) zur Bewirkung bestimmter Transaktionen in bezug auf die Dienste und Fähigkeiten des Dienstsystems 102. Wie später ausführlicher in der vorliegenden Schrift beschrieben werden wird, umfassen die von dem Dienstsystem 102 unterstützten Transaktionen das Authentifizieren von Vorbezahlungs-Teilnehmer-Accounts (2), das Anfordern eines Kontostands von Teilnehmer-Accounts (3), das Anfordern einer Belastung eines Teilnehmer-Accounts (4) und das Anfordern einer Gutschrift für ein Teilnehmer-Account (5).
  • Die SCPs führen Teilnehmer-Accounts und dienen in der Rolle eines "Portals" zu Teilnehmer-Kontoständen, wodurch es Dienstanbietern ermöglicht wird, im Verlauf von E-Commerce-Transaktionen auf Teilnehmer-Accounts zuzugreifen und diese zu modifizieren. Bei einer Ausführungsform wird für Redundanzzwecke ein angepaßtes Paar SCPs vorgesehen; wobei für jeden Teilnehmer ein designierter "primärer" SCP und "sekundärer" SCP vorliegt.
  • Die SCPs sind über Verbindungen 128 (wie gezeigt, API-Verbindung(en)(Anwendungsprogrammierschnittstelle)) mit dem Gateway-Server 104 verbunden. Eine API-Strecke ist zum Beispiel das von Lucent Technologies entwickelte LDAP (Lightweight Directory Access Protocol). Die SCPs 122 sind ferner über Strecken 132 (wie gezeigt (SS7-Fernsprechzeichengabestrecken) mit einem Fernsprechnetzwerk 130 verbunden, so daß das Dienstsystem 102 für Benutzer des Fernsprechnetzwerks 130 Vorbezahlungs-Sprachdienst zusätzlich zu den durch die netzwerkgestützten Dienstanbieter 108-120 bereitgestellten Diensten unterstützen kann. Das Fernsprechnetzwerk 130 kann unter Verwendung von SS7-Strecken ein verdrahtetes oder Drahtleitungsnetzwerk umfassen.
  • Das SMS 124 führt Provisionierungs-, Administrations- und Verwaltungsfunktionen für das Dienstsystem 102 aus. Dazu gehört allgemein das Erzeugen und/oder Führen von mit dem Dienstsystem 102 assoziierten Teilnehmer- und Dienstinformationen und das Herunterladen von Informationen je nach Bedarf zu den SCPs 122. Das SMS 124 kommuniziert über eine API-Strecke 128 oder TCP/IP-Schnittstelle (nicht gezeigt) (z.B. CORBA über TCP/IP) mit den SCPs. Genauer gesagt gehören zu den Aufgaben der SMS 124 die folgenden: Einrichten neuer Teilnehmer-Accounts und/oder Verwaltung existierender Accounts (einschließlich Teilnehmer-IDs, Kreditbeträge); Abbilden von Teilnehmer-IDs auf primäre/sekundäre SCPs; Identifizieren verschiedener Attribute der Teilnehmer (zum Beispiel Alter, Geschlecht, Sprachentyp, Währungtyp, Benutzungsdaten, Dienstpräferenzen und/oder -einschränkungen); und das Generieren umfassender Berichte über Account-/Benutzungsinformationen.
  • Das RCMS 126 ermöglicht ein periodisches Wiederaufladen oder Wiederauffüllen der Teilnehmer-Accounts und das Übermitteln der Aufladeinformationen je nach Bedarf zu dem SMS 124. Das RCMS 124 kommuniziert über eine API-Strecke 128 oder TCP/IP-Schnittstelle (nicht gezeigt) mit dem SMS 124.
  • Der Gateway-Server 104 dient als Schnittstelle für Dienstanbieter und/oder Teilnehmer zum Zugriff auf das Dienstsystem 102 (und daher zum Zugriff auf Vorbezahlungs-Teilnehmer-Accounts), um E-Commerce-Transaktionen zu ermöglichen. Der Gateway-Server 104 ist ein Funktionselement, das in einer oder mehreren physischen Einrichtungen verankert sein kann. Wie gezeigt, greifen alle netzwerkgestützten Dienstanbieter 108-120 über das TCP/IP-Netzwerk 106 auf den Gateway-Server zu, während das Fernsprechnetzwerk 130 direkt unter Verwendung des SS7-Protokolls auf das Dienstsystem 102 zugreifen kann. Das TCP/IP-Netzwerk 106 ist für den Transport von IP-Nachrichten (oder "Datagrammen") über einen oder mehrere (nicht gezeigte) Router ausgelegt. Es versteht sich, daß alternative Konfigurationen möglich sind. Zum Beispiel können bestimmte Dienstanbieter 108-120 direkt eine Schnittstelle zu dem Gateway-Server 104 aufweisen (d.h. über von dem TCP/IP-Netzwerk 106 verschiedene Strecken/Netzwerke).
  • Bei einer Ausführungsform werden Nachrichten zwischen dem Gateway-Server und den Dienstanbietern 108-120 und/oder Teilnehmern unter Verwendung von XML (eXtensible Markup Language) übermittelt. XML ist das universelle Format für strukturierte Dokumente und Daten im Web. Das XML-Protokoll gibt somit Dienstanbietern und Teilnehmern sehr viel Flexibilität beim Zugriff auf Teilnehmer-Account-Informationen. Zum Beispiel können Dienstanbieter oder Teilnehmer von Internet-Bildschirmen, Verkaufspunkt-Datenverarbeitungseinrichtungen, drahtlosen Einrichtungen oder im allgemeinen einer beliebigen Einrichtung, die mit dem Gateway-Server 104 über das XML-Protokoll kommunizieren kann, auf die Account-Informationen zugreifen. Es versteht sich, daß andere Protokolle als XML verwendet werden könnten.
  • Bei einer Ausführungsform führt der Gateway-Server 104 drei Hauptfunktionen aus: Protokollumsetzung für E-Commerce-Operationen, Teilnehmerabbildung auf die SCP(s) und Operationen-Protokollierung. Die Protokollumsetzungsfunktion umfaßt das Übersetzen von XML-Anfragen oder Transaktionsanforderungen von Dienstanbietern oder Teilnehmern in das von dem Dienstsystem 102 unterstützte API-Format; und umgekehrt das Übersetzen von API-Antworten des Dienstsystems 102 in das XML-Format zur Ablieferung an Dienstanbieter 108-120 oder Teilnehmer. Die Abbildungsfunktion umfaßt das Führen einer Datenbank, die den primären und sekundären SCP für jeden Teilnehmer, für den eine E-Commerce-Transaktion durchgeführt wurde, identifiziert. Für Teilnehmer, die das E-Commerce-System zum ersten Mal benutzen, fragt der Gateway-Server das SMS 124 ab, um den primären und sekundären SCP zu identifizieren, und behält die Informationen danach in einer Abbildungstabelle/-datenbank. Nach dem Empfang einer Anfrage oder Transaktion in bezug auf einen bestimmten Teilnehmer konsultiert der Gateway-Server danach die Abbildungstabelle, um den primären und sekundären SCP zu bestimmen (wodurch daher der Dienstanbieter und Teilnehmer von einer solchen Last befreit werden). Wahlweise kann der Gateway-Server periodisch Abbildungen von Teilnehmern, die für einen Zeitraum inaktiv sind, löschen. Darüber hinaus kann der Gateway-Server periodisch primäre und sekundäre SCPs neu identifizieren falls/wenn Ausfälle in den ursprünglich identifizierten primären oder sekundären SCPs auftreten. Bei einer Ausführungsform gibt das Gateway, wenn eine automatische Provisionierung neuer Einträge von Teilnehmern auf den Gateway-Server über SMS vorliegt (d.h. SMS automatisch neue Teilnehmer in der Abbildungstabelle in dem Gateway provisioniert) Fehlernachricht an die Client-Systeme zurück, wenn es eine nicht erkennbare Teilnehmer-ID in ankommenden Anforderungen empfängt. Die Protokollierungsfunktion protokolliert alle Anforderungen und gibt das Ergebnis jeder Anforderung (d.h. Erfolg oder Mißerfolg) an.
  • Bei einer Ausführungsform enthält der Gateway-Server Prozessor und Speicher (nicht gezeigt, die betreibbar sind, um eine Teilnehmerbasis von einer Million Kunden zu unterstützen. Dieses Performance-Niveau kann abhängig von dem Umfang des E-Commerce-Systems 100 skaliert/abgestimmt werden.
  • 2-6 sind Flußdiagramme verschiedener von dem E-Commerce-System unterstützter E-Commerce-Transaktionen. Zu diesen Transaktionen gehört das Authentifizieren von Vorbezahlungs-Teilnehmer-Accounts (2), das Anfordern eines Kontostands von Teilnehmer-Accounts (3), das Anfordern einer Belastung eines Teilnehmer-Accounts (4); das Anfordern einer Gutschrift für ein Teilnehmer-Account (5); und der Betrieb des E-Commerce-Systems durch einen Endbenutzer (d.h. um einen Online-Kauf auszuführen). Die Schritte von 2-6 werden gegebenenfalls unter Verwendung gespeicherter Softwareroutinen in dem Gateway-Server 104, in dem SCP bzw. den SCPs 122 oder dem SMS 128 des E-Commerce-Systems 100 implementiert.
  • Nunmehr mit Bezug auf 2 ist ein Flußdiagramm einer Teilnehmerauthentifizierungsoperation gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Im allgemeinen wird mit dieser Operation verifiziert, daß ein gültiges Teilnehmer-Account in dem E-Commerce-System 100 existiert. Zum Beispiel kann ein Dienstanbieter wünschen, Teilnehmerauthentifikation zu erhalten, bevor ein Dienst, für den Gebühren anfallen, oder Waren an einen potentiellen Kunden abgeliefert werden.
  • Im Schritt 202 empfängt der Gateway-Server 104 eine Teilnehmerauthentifizierungsanforderung. Die Anforderung kann zum Beispiel von einem beliebigen der netzwerkgestützten Dienstanbieter 108-120 kommen, die eine E-Commerce-Transaktion mit einem potentiellen Kunden in Betracht ziehen. Bei einer Ausführungsform enthält die Anforderung eine Teilnehmer-ID und einen Account-Code in Assoziation mit dem potentiellen Kunden. Bei einer Ausführungsform ist die Anforderung eine Nachricht des XML-Protokolls.
  • Als Reaktion auf die Anforderung konsultiert im Schritt 204 der Gateway-Server 104 seine Abbildungstabelle, um zu bestimmen, ob Teilnehmerdaten entsprechend der Teilnehmer-ID und/oder dem Account-Code, die bzw. der in der Anforderung identifiziert wurden, zu finden sind. Bei einer Ausführungsform enthalten diese Teilnehmerdaten eine Identifikation von Primär- oder Sekundär-SCP(s) des E-Commerce-Systems. Es versteht sich, daß verschiedene Dienstanbieter abhängig von den verschiedenen Benennungs-/Bezifferungsschemata der Dienstanbieter verschiedene ID(s) oder Account-Codes für denselben Teilnehmer aufweisen können. Zum Beispiel könnte für einen Mobil-Drahtlos-Dienstanbieter die Teilnehmer-ID abhängig von dem Netzwerk des Dienstanbieters eine MSISDN (Mobile Station International Subscriber Directory Number) oder eine MDN (Mobile Directory Number) sein. Bei einer Ausführungsform enthält die Abbildungstabelle gegebenenfalls eine Abbildung von Mehrfach-ID(s) auf einzelne Teilnehmer, um verschiedene Teilnehmer-ID(s)/-Account-Codes zu berücksichtigen.
  • Wenn keine Teilnehmerdaten gefunden werden (bestimmt im Schritt 206), fragt der Gateway-Server wahlweise das SMS (bestimmt im Schritt 208) ab, um zu bestimmen, ob das SMS 124 einen der Teilnehmer-ID entsprechenden primären und/oder sekundären SCP identifizieren kann. Als Reaktion auf eine positive Bestimmung im Schritt 208 fragt der Gateway-Server das SMS im Schritt 210 ab. Bei einer Ausführungsform identifiziert zum Beispiel die Abbildungstabelle des Gateway-Servers nicht den primären oder sekundären SCP für erstmalige Benutzer.
  • In einem solchen Fall kann der Gateway-Server das SMS abfragen, um den primären und sekundären SCP für den erstmaligen Benutzer zu identifizieren. Danach behält der Gateway-Server die Informationen in seiner Abbildungstabelle.
  • Wenn nach Abfragen des SMS immer noch keine Teilnehmerdaten zu finden sind oder wenn der Gateway-Server bestimmt, das SMS nicht abzufragen (Schritt 208), gibt der Gateway-Server eine Fehlernachricht an das anfordernde System zurück (Schritt 212). Wenn dagegen Teilnehmerdaten gefunden werden (d.h. der Gateway-Server den der Teilnehmer-ID entsprechenden primären und/oder sekundären SCP identifiziert), sendet der Gateway-Server im Schritt 214 eine Authentifikationsanforderungsnachricht zu dem designierten SCP bzw. den designierten SCPs. Bei einer Ausführungsform umfaßt dies das Senden der Teilnehmer-ID und des Account-Codes in entsprechendem API-Format zu dem primären SCP, und wenn innerhalb einer vorbestimmten Zeit keine Antwort empfangen wird, zu dem sekundären SCP. Als Alternative kann offensichtlich der Gateway-Server die Authentifizierungsanforderung gleichzeitig zu dem primären und sekundären SCP senden. Der Zweckmäßigkeit halber soll im folgenden der Begriff "SCP" als den handelnden SCP bedeutend verstanden werden, gleichgültig, ob es sich um den primären oder den sekundären SCP handelt.
  • Im Schritt 216 bestimmt der SCP den Teilnehmerstatus des potentiellen Kunden. Bei einer Ausführungsform umfaßt dies das Bestimmen, ob die Teilnehmer-ID existiert (d.h. ob die Teilnehmer-ID einem gültigen Teilnehmer entspricht); ob der Account-Code existiert (d.h. ob der Account-Code einem gültigen Account entspricht); und ob die Teilnehmer-ID mit dem Account-Code übereinstimmt (d.h. das Account zu dem Teilnehmer gehört). Wenn irgendwelche dieser Bedingungen negativ sind, was in den Entscheidungsblöcken 218, 220, 222 bestimmt wird, gibt der SCP im Schritt 224 eine Nichtauthentifizierungsnachricht an den Gateway-Server zurück. Wenn dagegen jede der Bedingungen positiv ist, gibt der SCP im Schritt 226 eine Authentifizierungsnachricht an den Gateway-Server zurück. Der Gateway-Server leitet die Nachricht im Schritt 228 nach entsprechender Umsetzung aus dem API- in das XML-Format an das anfordernde System weiter.
  • 3 ist ein Flußdiagramm einer Kontostandanforderungsoperation gemäß einer Ausführungsform der vorliegenden Erfindung. Im allgemeinen wird diese Operation für einen Teilnehmer benutzt, um den Kontostand seines/ihres Teilnehmer-Account bzw. seiner/ihrer Teilnehmer-Accounts, das bzw. die von dem E-Commerce-System 100 geführt werden, zu erhalten. Ein Teilnehmer kann ein oder mehrere Accounts führen.
  • Im Schritt 302 empfängt der Gateway-Server 104 eine Kontostandanforderung. Bei einer Ausführungsform umfaßt die Anforderung eine XML-Format-Nachricht mit einer Teilnehmer-ID und Account-Code, die bzw. der mit dem Teilnehmer assoziiert ist. Es wird als Beispiel angenommen, daß die Anforderung von einem Teilnehmer kommt. Als Alternative oder zusätzlich könnte(n) Kontostandanforderung(en) von anderen Endbenutzern als dem Teilnehmer, wie zum Beispiel Dienstanbietern oder Repräsentanten des Teilnehmers sowie von Finanzinstitutionen, behördlichen Beamten und dergleichen mit autorisiertem Zugang zu Teilnehmer-ID und Account-Code empfangen werden.
  • Als Reaktion auf die Anforderung konsultiert der Gateway-Server 104 im Schritt 304 seine Abbildungstabelle, um zu bestimmen, ob entsprechend der Teilnehmer-ID und/oder dem Account-Code, die bzw. der in der Anforderung identifiziert wurden, Teilnehmerdaten zu finden sind. Bei einer Ausführungsform umfassen diese Teilnehmerdaten eine Identifikation eines mit Teilnehmer-ID und/oder Account-Code assoziierten primären oder sekundären SCP bzw. primären oder sekundären SCPs.
  • Wenn keine Teilnehmerdaten zu finden sind (bestimmt im Schritt 306), fragt der Gateway-Server wahlweise das SMS ab (bestimmt im Schritt 308), um zu bestimmen, ob das SMS 124 einen der Teilnehmer-ID entsprechenden primären und/oder sekundären SCP identifizieren kann. Als Reaktion auf eine positive Bestimmung im Schritt 308 fragt der Gateway-Server im Schritt 310 das SMS ab. Wenn nach Abfrage des SMS immer noch keine Teilnehmerdaten zu finden sind oder wenn der Gateway-Server bestimmt, das SMS nicht abzufragen (Schritt 308), gibt der Gateway-Server im Schritt 312 eine Fehlernachricht an das anfordernde System zurück. Wenn dagegen Teilnehmerdaten zu finden sind (d.h. der Gateway-Server den der Teilnehmer-ID entsprechenden primären und/oder sekundären SCP identifiziert), sendet der Gateway-Server im Schritt 314 eine Kontostandanforderungsnachricht dem designierten SCP bzw. den designierten SCPs.
  • Im Schritt 316 bestimmt der handelnde SCP, ob die Kontostandsanforderungsoperation für das Teilnehmer-Account freigegeben oder gesperrt ist. Der Freigabe- oder Sperrstatus des Account kann von dem Dienstsystem 102 selbst oder als Reaktion auf Teilnehmeranweisungen spezifiziert werden. Zum Beispiel könnte die Kontostandsanforderungsoperation durch das Dienstsystem 102 gesperrt werden, um Kontostandanforderungen per Telefon statt über das Internet zu ermöglichen; oder die Kontostandanforderungsoperation könnte nur für einen bestimmten Anforderer oder eine Liste von Anforderern als Reaktion auf Teilnehmeranweisungen freigegeben werden. Der Freigabe- oder Sperrstatus kann für verschiedene Accounts desselben Teilnehmers unterschiedlich sein.
  • Wenn die Kontostandsanforderungsoperation freigegeben ist (bestimmt im Schritt 318), gibt der SCP im Schritt 320 mit den Teilnehmer-Account assoziierte Kontostandinformationen an den Gateway-Server zurück. Wahlweise können, wenn der Teilnehmer mehrere Accounts führt, die Kontostandinformationen den Kontostand jedes der Accounts enthalten, für das die Kontostandanforderungsoperation freigegeben ist. Wenn die Kontostandanforderungsoperation gesperrt ist, gibt der SCP eine Fehlernachricht oder ein bestimmtes anderes Indicia zurück, daß die Kontostandanforderungsoperation verweigert wird (Schritt 322). Im Schritt 324 setzt der Gateway-Server die Nachricht dann aus dem API- in das XML-Format um und leitet die Kontostandinformationen oder die Fehlernachricht zu dem Teilnehmer oder Endbenutzer weiter.
  • 4 ist ein Flußdiagramm einer Belastungsanforderungsoperation gemäß einer Ausführungsform der vorliegenden Erfindung. Diese Operation wird im allgemeinen für einen Dienstanbieter verwendet, um den Kontostand eines Teilnehmer-Accounts als Reaktion auf eine E-Commerce-Transaktion zu belasten.
  • Im Schritt 402 empfängt der Gateway-Server 104 eine Belastungsanforderung von einem Dienstanbieter. Die Anforderung kann zum Beispiel von einem beliebigen der netzwerkgestützten Dienstanbieter 108-120 kommen, die Waren oder Dienstleistungen als Reaktion auf eine E-Commerce-Transaktion an einen Kunden abgeliefert haben (oder abliefern werden). Zum Beispiel kann die Anforderung aus einem drahtlosen Netzwerk (z.B. über WAP, GPRS usw.) oder einem Händler über das Internet oder den Verkaufspunkt-Server kommen. Bei einer Ausführungsform enthält die Anforderung eine Teilnehmer-ID, den Kaufbetrag und eine mit dem Dienstanbieter assoziierte Händler-ID. Bei einer Ausführungsform ist die Anforderung eine XML-Protokoll-Nachricht.
  • Als Reaktion auf die Anforderung konsultiert der Gateway-Server 104 in Schritt 404 seine Abbildungstabelle, um den primären und/oder sekundären SCP, der mit der Teilnehmer-ID assoziiert ist bzw. die primären und/oder sekundären SCPs, die mit der Teilnehmer-ID assoziiert sind, im wesentlichen wie in bezug auf 2 beschrieben zu bestimmen. Als Beispiel wird angenommen, daß der Gateway-Server in der Lage ist, den primären und/oder sekundären SCP im Schritt 404 erfolgreich zu identifizieren. Im Schritt 406 sendet der Gateway-Server eine Belastungsanforderungsnachricht zu dem designierten SCP bzw. den designierten SCPs. Bei einer Ausführungsform liegt die Belastungsanfoderung im API-Format vor und enthält Parameter wie zum Beispiel Teilnehmer-ID, Account-Code, Transaktions-ID, Nachrichtentyp (d.h. Belastungsanforderung), Account-Indikator, Belastungsbetrag und Währungsindikator.
  • Im Schritt 408 bestimmt der handelnde SCP den Kontostand und den Dienststatus, der mit dem Teilnehmer-Account assoziiert ist. Bei einer Ausführungsform umfaßt dies das Bestimmen, ob der Kontostand ausreicht, um den angeforderten Kauf zu ermöglichen (oder gegebenenfalls die Minimalkontostandschwellen ausreichend übersteigt); und ob das Account freigegeben oder gesperrt ist. Wenn ein unzureichender Kontostand besteht oder das Account gesperrt ist, was in den Entscheidungsblöcken 410, 412 bestimmt wird, gibt der SCP im Schritt 420 eine Fehlernachricht, die je nach Fall unzureichenden Kontostand oder gesperrtes Account anzeigt, an den Gateway-Server zurück. Wenn dagegen ein ausreichender Kontostand besteht und das Account freigegeben ist, belastet der SCP im Schritt 414 das Teilnehmer-Account, verzeichnet die Transaktion im Schritt 416 in einem Verbindungseinzelheitendatensatz (CDR – Call Detail Record) und sendet im Schritt 418 eine Bestätigungsnachricht zu dem Gateway-Server mit dem aktualisierten Kontostand des Account. Bei einer Ausführungsform enthält der CDR Parameter wie zum Beispiel Teilnehmer-ID, Account-Code, Transaktions-ID, Belastungsbetrag, Währungsindikator, Account-Indikator und Nachrichtentyp (d.h. Belastungsanforderung). Der Gateway-Server leitet die Bestätigung oder Fehlernachricht (je nach Fall) im Schritt 422 nach entsprechender Umsetzung aus dem API- in das XML-Format an das anfordernde System weiter.
  • 5 ist ein Flußdiagramm einer Gutschreibeanforderungsoperation gemäß einer Ausführungsform der vorliegenden Erfindung. Diese Operation wird im allgemeinen für einen Dienstanbieter verwendet, um dem Kontostand eines Teilnehmer-Account als Reaktion auf die Rücksendung von Waren, Widerruf des Kaufs, zu hohe Gebührenberechnung und dergleichen etwas gutzuschreiben.
  • Im Schritt 502 empfängt der Gateway-Server 104 eine Gutschreibe-/Rückerstattungsanforderung von einem Dienstanbieter. Die Anforderung kann zum Beispiel von einem beliebigen der in Verbindung mit 4 bezüglich Belastungsanforderungen beschriebenen Dienstanbietern kommen. Bei einer Ausführungsform enthält die Anforderung eine Teilnehmer-ID und den dem Teilnehmer-Account gutzuschreibenden Betrag. Bei einer Ausführungsform ist die Anforderung eine XML-Protokoll-Nachricht.
  • Als Reaktion auf die Anforderung konsultiert der Gateway-Server 104 in Schritt 504 seine Abbildungstabelle, um den primären und/oder sekundären SCP, der mit der Teilnehmer-ID assoziiert ist bzw. die primären und/oder sekundären SCPs, die mit der Teilnehmer-ID assoziiert sind, im wesentlichen wie in bezug auf 2 beschrieben zu bestimmen. Als Beispiel wird angenommen, daß der Gateway-Server in der Lage ist, den primären und/oder sekundären SCP im Schritt 504 erfolgreich zu identifizieren. Im Schritt 506 sendet der Gateway-Server eine Gutschreibeanforderungsnachricht zu dem designierten SCP bzw. den designierten SCPs. Bei einer Ausführungsform liegt die Gutschreibeanforderung im SPI-Format vor und enthält Parameter wie zum Beispiel Teilnehmer-ID, Account-Code, Transaktions-ID, Nachrichtentyp (d.h. Gutschreibeanforderung), Händlerkennung, Account-Indikator, Gutschreibebetrag und Währungsindikator.
  • Im Schritt 508 schreibt der handelnde SCP dem Teilnehmer-Account etwas gut und im Schritt 510 verzeichnet der SCP die Transaktion in einem Verbindungseinzelheitendatensatz (CDR – Call Detail Record). Bei einer Ausführungsform enthält der CDR Parameter wie zum Beispiel Teilnehmer-ID, Account-Code, Transaktions-ID, Gutschreibebetrag, Währungsindikator, Account-Indikator, Nachrichtentyp (d.h. Gutschreibeanforderung) und Händleridentifizierer. Im Schritt 512 sendet der SCP eine Bestätigungsnachricht mit dem aktualisierten Kontostand an den Gateway-Server. Der Gateway-Server leitet die Bestätigungsnachricht im Schritt 514 nach entsprechender Umsetzung aus dem API- in das XML-Format an das anfordernde System weiter.
  • 6 ist ein Flußdiagramm des Betriebs eines intelligenten, netzwerkgestützten E-Commerce-Systems durch einen Endbenutzer. Für das vorliegende Beispiel wird angenommen, daß der Endbenutzer über das Internet 118 auf das E-Commerce-System zugreift. Alternativ dazu könnte der Endbenutzer offensichtlich auch über eine drahtlose Einrichtung/ein drahtloses Netzwerk auf das System zugreifen.
  • Im Schritt 602 klickt der Endbenutzer (z.B. auf ein Webseitensymbol) und führt Tastenbetätigungen aus, so wie es angemessen sein kann, um einen Online-Kauf von einem Online-Händler einzuleiten. Im Schritt 604 sammelt eine Client-Anwendung (d.h. E-Commerce-Software) für den Kauf relevante Informationen wie zum Beispiel Benutzer-ID, Händler-ID, Gebührenbetrag und dergleichen. Die Client-Anwendung kann in einem Server verankert sein, der vom Händler oder von einer zentralisierten Entität, die mehrere Händler versorgt, betrieben wird. Im Schritt 606 sendet die Client-Anwendung eine Abfrage mit den relevanten Informationen zu dem Gateway-Server 104. Bei einer Ausführungsform liegt die Abfrage im XML-Format vor.
  • Im Schritt 608 bestimmt der Gateway-Server 104, ob er in der Lage ist, primär- und/oder sekundär-SCP(s) zu identifizieren, zu denen die Anforderung geroutet werden soll. Wenn nicht, fragt der Gateway-Server 104 im Schritt 610 im wesentlichen wie in Beziehung zu 2, 3 beschrieben den SMS 124 ab. Wenn der Gateway-Server in der Lage ist, den primären und/oder sekundären SCP erfolgreich zu identifizieren, sendet der Gateway-Server im Schritt 612 eine direkte Belastungsanforderungsnachricht zu dem designierten SCP bzw. den designierten SCPs. Bei einer Ausführungsform liegt die Belastungsanforderung im API-Format vor und enthält Parameter wie zum Beispiel Teilnehmer-ID, Account-Code, Transaktions-ID, Nachrichtentyp (d.h. Belastungsanforderung), Account-Indikator, Belastungsbetrag und Währungsindikator.
  • Im Schritt 614 versucht der handelnde SCP, das Teilnehmer-Account zu validieren. Bei einer Ausführungsform umfaßt dies das Prüfen des Ausreichens des Kontostands und des Freigabestatus des Accounts im wesentlichen wie in Verbindung mit 4 beschrieben. Wenn das Account nicht gültig ist, gibt der SCP im Schritt 618 eine Fehlernachricht an den Gateway-Server zurück. Der Gateway-Server leitet die Fehlernachricht im Schritt 620 zu dem Client weiter und der Client verweigert im Schritt 624 die Kaufanforderung von dem Endbenutzer.
  • Wenn das Account gültig ist, versucht der SCP, im Schritt 616 die Händler-ID zu validieren. Wenn die Händler-ID nicht gültig ist, gibt der SCP im Schritt 618 eine Fehlernachricht an den Gateway-Server zurück. Der Gateway-Server leitet die Fehlernachricht im Schritt 620 an den Client weiter und der Client verweigert die Kaufanforderung von dem Endbenutzer im Schritt 624. Wenn die Händler-ID dagegen gültig ist, belastet der SCP das Teilnehmer-Account und verzeichnet die Transaktion im Schritt 626 in einem Verbindungsdetaildatensatz (CDR) und sendet eine Bestätigungsnachricht zu dem Gateway-Server (Schritt 628). Der Gateway-Server leitet die Bestätigung im Schritt 630 zu dem Client weiter und der Client bestätigt den Kauf (d.h. schließt den Verkauf ab) im Schritt 632 mit dem Endbenutzer.
  • Im Schritt 626 sendet der SCP zur Bewirkung der Bezahlung des Händlers eine Nachricht zu seiner Bank (d.h. der Bank des E-Commerce-Dienstanbieters), wodurch sie instruiert wird, den Gebührenbetrag an die Bank des Händlers (oder alternativ dazu an den Händler) abzuzahlen. Im allgemeinen erfolgt eine solche Bezahlung eine kurze Zeit nach dem Abschluß der Transaktion (z.B. am Ende des Geschäftstages), so wie es für Banktransaktionen üblich ist.

Claims (10)

  1. Verfahren zur Durchführung einer E-Commerce-Transaktion zur Verwendung in einem E-Commerce-System (100) mit einem Dienstsystem (102), das über einen Gateway-Server (104) mit einem Paketnetzwerk (106) verbunden ist, wobei das E-Commerce-System mehrere Dienstanbieter und Kunden (108-120) versorgt, die operativ mit dem Paketnetzwerk verbunden sind, wobei das Verfahren die folgenden Schritte umfaßt: Empfangen einer Anforderung, eine E-Commerce-Transaktion durchzuführen; und Zugreifen auf Kunden-Account-Informationen zur Durchführung der E-Commerce-Transaktion; dadurch gekennzeichnet, daß die Kunden-Account-Informationen Informationen umfassen, die mit einem oder mehreren von dem Dienstsystem geführten Vorbezahlungs-Accounts assoziiert sind, die Teilnehmer-Accounts definieren; der Gateway-Server (104) die Teilnehmer-Accounts auf einen oder mehrere Dienststeuerpunkte (122) des Dienstsystems (102) abbildet; und die Dienststeuerpunkte (122) zusätzlich zu der Unterstützung von E-Commerce-Transaktionen Vorbezahlungs-Sprachdienst für Benutzer eines Fernsprechnetzwerks (130) unterstützen.
  2. Verfahren nach Anspruch 1, ferner mit dem folgenden Schritt: der Gateway-Server (104) übersetzt die Anforderung aus einem von dem Paketnetzwerk (106) benutzten ersten Protokoll in ein von dem Dienstsystem (102) unterstütztes zweites Protokoll.
  3. Verfahren nach Anspruch 1, wobei das Dienstsystem ein Dienstmanagersystem (124) und ein Einzahlungskartenverwaltungssystem (126) enthält, wobei das Verfahren die folgenden Schritte umfaßt: das Dienstmanagersystem erstellt neue und führt existierende Teilnehmer-Accounts; und das Einzahlungskartenverwaltungssystem ermöglicht ein periodisches Einzahlen in die Teilnehmer-Accounts und ein Übermitteln von Einzahlungsinformationen zu dem Dienstmanagersystem.
  4. Verfahren nach Anspruch 1, wobei die E-Commerce-Transaktion eine Authentifikation eines Kunden umfaßt, wobei das Verfahren die folgenden Schritte umfaßt Empfangen einer Authentifikationsanforderung von einem Dienstanbieter, wobei die Authentifikationsanforderung mit dem Kunden assoziierte Informationen enthält; Zugreifen auf Vorbezahlungs-Kunden-Accountinformationen zur Bestimmung eines Teilnehmerstatus des Kunden, wobei der Teilnehmerstatus angibt, ob der Kunde ein von dem Dienstsystem geführtes gültiges Vorbezahlungs-Account besitzt; und auf der Basis des Teilnehmerstatus, Senden einer Authentifikationsnachricht und einer Nichtauthentifikationsnachricht zu dem Dienstanbieter.
  5. Verfahren nach Anspruch 1, wobei die E-Commerce-Transaktion eine Kontostandanforderungsoperation umfaßt, wobei das Verfahren die folgenden Schritte umfaßt: Empfangen einer Kontostandanforderung von einem Endbenutzer, wobei die Kontostandanforderung eine Teilnehmer-ID und/oder einen mit dem Vorbezahlungs-Kunden-Account assoziierten Account-Code enthält; Zugreifen auf Vorbezahlungs-Kunden-Accountinformationen zur Bestimmung eines Freigabestatus der Kontostandanforderungsoperation; wenn die Kontostandanforderungsoperation freigegeben ist, Erhalten von mit dem Vorbezahlungs-Kunden-Account assoziierten Kontostandinformationen und Senden mindestens eines Teils der Kontostandinformationen zu dem Endbenutzer; und wenn die Kontostandanforderungsoperation gesperrt ist, Senden einer Fehlernachricht zu dem Endbenutzer.
  6. Verfahren nach Anspruch 1, wobei die E-Commerce-Transaktion eine Abbuchanforderungsoperation umfaßt, wobei das Verfahren die folgenden Schritte umfaßt: Empfangen einer Abbuchanforderung von einem Dienstanbieter, wobei die Abbuchanforderung einen Abbuchbetrag, eine Teilnehmer-ID und eine Händler-ID enthält; Zugreifen auf Vorbezahlungs-Kunden-Accountinformationen zur Bestimmung eines Freigabestatus der Abbuchanforderungsoperation; wenn die Abbuchanforderungsoperation freigegeben ist, Subtrahieren des Abbuchbetrags von einem Kunden-Account, wodurch sich ein aktualisierter Kontostand ergibt, und Senden einer Bestätigungsnachricht zu dem Dienstanbieter; und wenn die Abbuchanforderungsoperation gesperrt ist, Senden einer Fehlernachricht zu dem Dienstanbieter.
  7. Verfahren nach Anspruch 1, wobei die E-Commerce-Transaktion eine Gutschreibeanforderungsoperation umfaßt, wobei das Verfahren die folgenden Schritte umfaßt: Empfangen einer Gutschreibeanforderung von einem Dienstanbieter, wobei die Gutschreibeanforderung einen Gutschreibebetrag und eine Teilnehmer-ID enthält; Zugreifen auf Vorbezahlungs-Accountinformationen zum Hinzufügen des Gutschreibebetrags zu einem Kunden-Account, wodurch sich ein aktualisierter Kontostand ergibt; und Senden einer Bestätigungsnachricht zu dem Dienstanbieter.
  8. E-Commerce-System (100), umfassend: einen operativ mit einem Paketnetzwerk (106) verbundenen Gateway-Server (104), wobei das Paketnetzwerk operativ mit mehreren Dienstanbietern und Kunden (108-120) verbunden ist; und ein operativ mit dem Gateway-Server verbundenes Dienstsystem (102), dadurch gekennzeichnet, daß der Gateway-Server (104) so ausgelegt ist, daß er als eine Schnittstelle für Dienstanbieter und Kunden (108-120) für den Zugriff auf das Dienstsystem (102) dient; das Dienstsystem (102) mehrere Dienststeuerpunkte (122) umfaßt; wobei die Dienststeuerpunkte an ein Fernsprechnetzwerk (130) angeschlossen sind und so ausgelegt sind, daß sie zusätzlich zu der Unterstützung von E-Commerce-Dienst für die Dienstanbieter und Kunden (108-120) Vorbezahlungs-Dienst für die Benutzer des Fernsprechnetzwerks (130) unterstützen.
  9. E-Commerce-System nach Anspruch 8, wobei das Dienstsystem (102) ein Dienstmanagersystem (124) zum Erstellen neuer und zum Führen existierender Teilnehmer-Accounts enthält.
  10. E-Commerce-System nach Anspruch 9, wobei das Dienstsystem (102) ein Einzahlungskartenverwaltungssystem (126) zum periodischen Einzahlen in Teilnehmer-Accounts und zum Übermitteln von Einzahlungsinformationen zu dem Dienstmanagersystem enthält.
DE60302416T 2002-10-31 2003-08-14 Verfahren zur Verwaltung von Prepaid-Konten und zum Ausführen von Transaktionen in einem elektronischen Handelssystem Expired - Lifetime DE60302416T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/284,626 US20040088249A1 (en) 2002-10-31 2002-10-31 Network-based electronic commerce system incorporating prepaid service offerings
US284626 2002-10-31

Publications (2)

Publication Number Publication Date
DE60302416D1 DE60302416D1 (de) 2005-12-29
DE60302416T2 true DE60302416T2 (de) 2006-08-03

Family

ID=32093529

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60302416T Expired - Lifetime DE60302416T2 (de) 2002-10-31 2003-08-14 Verfahren zur Verwaltung von Prepaid-Konten und zum Ausführen von Transaktionen in einem elektronischen Handelssystem

Country Status (6)

Country Link
US (1) US20040088249A1 (de)
EP (1) EP1416456B1 (de)
JP (1) JP2004164598A (de)
KR (1) KR20040038618A (de)
AT (1) ATE311003T1 (de)
DE (1) DE60302416T2 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040021890A1 (en) * 2002-03-25 2004-02-05 Takumi Hirai Image forming apparatus, information processing apparatus and the authentication method
GB2416892B (en) * 2004-07-30 2008-02-27 Robert Kaplan Method and apparatus to enable validating entitlement to VoIP services
US7302468B2 (en) * 2004-11-01 2007-11-27 Motorola Inc. Local area preference determination system and method
US20060167818A1 (en) * 2005-01-21 2006-07-27 David Wentker Methods and system for performing data exchanges related to financial transactions over a public network
WO2006081492A2 (en) * 2005-01-26 2006-08-03 Telcordia Technologies, Inc. Payment system for the distribution of digital content using an intelligent services control point
EP1844437A4 (de) 2005-01-26 2010-06-02 Telcordia Tech Inc Systeme und verfahren zur verteilung von autorisiertem digitalem inhalt
US8041646B2 (en) * 2005-06-15 2011-10-18 E. E. System Corporation Method and system for real time online debit transactions
EP1949257A4 (de) * 2005-11-03 2011-04-20 Tti Inv S B Llc System und verfahren zum erzeugen von kundenrelationalen-marketing-informationen in einem system zur verteilung von digitalem inhalt
CN101056182B (zh) * 2006-04-14 2012-07-04 朗迅科技公司 汇聚预付费和后付费
CN101324942A (zh) * 2007-06-13 2008-12-17 阿里巴巴集团控股有限公司 利用包含ic卡的身份证进行交易的支付***及方法
CN101720074B (zh) * 2008-10-09 2013-06-05 华为技术有限公司 充值处理方法与***、通信装置
US20110299547A1 (en) * 2010-06-04 2011-12-08 Wael William Diab Method and system for managing energy costs utilizing a broadband gateway
JP2012014676A (ja) * 2010-05-31 2012-01-19 Sony Computer Entertainment Inc 仮想現実空間提供システム、仮想現実空間提供方法およびそのプログラム
EP2523389A3 (de) * 2011-05-09 2014-07-30 Telefonaktiebolaget LM Ericsson (publ) Verfahren und Vorrichtung zur Genehmigung eines Transaktionsdienstes durch eine Richtilinie und Ladungssteuerungsarchitektur
CA2849896A1 (en) * 2011-09-25 2013-03-28 Redbox Automated Retail, Llc System and method for management of credit subscriptions
US20130297485A1 (en) * 2012-05-01 2013-11-07 Mastercard International Incorporated Crowd-Sourced Credit Rating and Debt Tracking System to Facilitate Small Purchases on Trust Based Credit
CN107516254A (zh) * 2016-06-16 2017-12-26 浙江商业技师学院 电子商务综合服务装置
CN106886847A (zh) 2016-06-22 2017-06-23 阿里巴巴集团控股有限公司 一种资源处理方法及装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9098958B2 (en) * 1998-09-15 2015-08-04 U-Paid Systems, Ltd. Convergent communications platform and method for mobile and electronic commerce in a heterogeneous network environment
DE19950501A1 (de) * 1999-10-20 2001-04-26 Alcatel Sa Verfahren zum Bereitstellen von IN-Diensten
EP1117220A1 (de) * 2000-01-14 2001-07-18 Sun Microsystems, Inc. Verfahren und Vorrichtung zur Protokollübersetzung
US7318049B2 (en) * 2000-11-17 2008-01-08 Gregory Fx Iannacci System and method for an automated benefit recognition, acquisition, value exchange, and transaction settlement system using multivariable linear and nonlinear modeling
US20020143655A1 (en) * 2001-04-02 2002-10-03 Stephen Elston Remote ordering system for mobile commerce

Also Published As

Publication number Publication date
JP2004164598A (ja) 2004-06-10
KR20040038618A (ko) 2004-05-08
DE60302416D1 (de) 2005-12-29
US20040088249A1 (en) 2004-05-06
EP1416456B1 (de) 2005-11-23
ATE311003T1 (de) 2005-12-15
EP1416456A1 (de) 2004-05-06

Similar Documents

Publication Publication Date Title
DE60302416T2 (de) Verfahren zur Verwaltung von Prepaid-Konten und zum Ausführen von Transaktionen in einem elektronischen Handelssystem
DE69821992T2 (de) System und verfahren zum steuern von finanziellen überweisungen über ein drahtloses netzwerk
US5940812A (en) Apparatus and method for automatically matching a best available loan to a potential borrower via global telecommunications network
EP1120759A2 (de) Anordnung zur Bereitstellung und flexiblen Vergebührung einer Ware oder Dienstleistung sowie Ausgabeautomat zum Einsatz in einer solchen und Verfahren zum Betrieb einer solchen
EP1446778A2 (de) Bezahlungsprotokoll sowie datenübertragungsverfahren und -anordnung für bezahlvorgänge
WO2009003605A9 (de) Virtuelle prepaid- oder kreditkarte und verfahren und system zur bereitstellung einer solchen und zum elektronischen zahlungsverkehr
CN107784577A (zh) 一种信贷产品分发及推荐方法和实现该方法的***
DE19946539B4 (de) Verfahren zur Abrechnung von Internet-Geschäften über Mobilfunk
DE29624476U1 (de) System zum Ermöglichen des Bestellens und Bezahlens von Dienstleistungen mittels eines Kommunikationsnetzwerkes
US20080025490A1 (en) Method and System for Providing Long Distance Service
US20020035479A1 (en) Access contract changing method for automatically changing an access contract between a prepaid contract and a postpaid contract
DE60032343T2 (de) Verfahren und vorrichtung zum elektronischen geschäftsverkehr
EP1269438A1 (de) Elektronisches zahlungsverfahren und anordnung zu dessen durchführung
EP1450322A1 (de) Zahlungssystem und Zahlungsverfahren
EP1269739A2 (de) Datenübertragungsverfahren und -anordnung
US20030041025A1 (en) System and method for flexible promotional rates
WO2004006198A1 (de) Verfahren zur elektronischen bezahlung einer ware oder dienstleistung unter nutzung eines mobilfunknetzes und anordnung zu dessen durchführung
KR100364013B1 (ko) 인터넷 상에서 온라인으로 통합요금 청구 및 납부를 대행하는 방법
EP1175664B1 (de) Verfahren zum verteilen von wertcodes
JP2003067661A (ja) ポイント購入サーバーシステムを用いた、小額決済のための回収代行システム
EP1128340A1 (de) Verfahren zum Aufladen eines Kundenkontos für Telekommunikationsdienste und entsprechendes Aufladesystem
EP1450320A1 (de) Zahlungsmodul mit mehreren Zahlungskonten, Zahlungssystem und Zahlungsverfahren
DE10336519B4 (de) Verfahren zur Durchführung von Bezahlvorgängen in einem rechnerbasierten Kommunikationsnetzwerk
EP1512273A1 (de) VERFAHREN, COMPUTERPROGRAMM U. COMPUTERSYSTEM F R EINEN PREP AID TELE­KOMMUNIKATIONSDIENST
DE19649380C2 (de) Telekommunikationsverfahren und -vorrichtungen zur automatischen Mietspiegelerstellung und Verifikation

Legal Events

Date Code Title Description
8364 No opposition during term of opposition