DE112019007575T5 - Informationverarbeitungsserver, Informationverarbeitungsverfahren, Programm und Servicebereitstellungs-Unterstützungssystem - Google Patents

Informationverarbeitungsserver, Informationverarbeitungsverfahren, Programm und Servicebereitstellungs-Unterstützungssystem Download PDF

Info

Publication number
DE112019007575T5
DE112019007575T5 DE112019007575.6T DE112019007575T DE112019007575T5 DE 112019007575 T5 DE112019007575 T5 DE 112019007575T5 DE 112019007575 T DE112019007575 T DE 112019007575T DE 112019007575 T5 DE112019007575 T5 DE 112019007575T5
Authority
DE
Germany
Prior art keywords
user
payment
amount
payment amount
predetermined
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.)
Pending
Application number
DE112019007575.6T
Other languages
English (en)
Inventor
Hodaka MUKOHARA
Shumpei Suzuki
Kobue Nose
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.)
Honda Motor Co Ltd
Original Assignee
Honda Motor Co Ltd
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 Honda Motor Co Ltd filed Critical Honda Motor Co Ltd
Publication of DE112019007575T5 publication Critical patent/DE112019007575T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/085Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855Payment architectures involving remote charge determination or related payment systems involving a third party
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/02Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/14Payment architectures specially adapted for billing systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326Payment applications installed on the mobile devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/389Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/403Solvency checks
    • G06Q20/4037Remote solvency checks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, 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/405Establishing or using transaction specific rules
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Commerce
    • G06Q30/06Buying, selling or leasing transactions

Landscapes

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

Abstract

Ein in der vorliegenden Ausführungsform offengelegter Informationsverarbeitungsserver ist ein Informationsverarbeitungsserver, der eine periodische Zahlung einer Vielzahl von Benutzern, die zu einer Gruppe gehören, verwaltet, wobei der Server aufweist: eine Festlegungseinheit, die einen vorbestimmten persönlichen Betrag festlegt, der an einem vorbestimmten Fälligkeitsdatum von einem jeden der Vielzahl von Benutzern zu zahlen ist; eine Erfassungseinheit, die Informationen erfasst, die jeweils die Zahlungsbeträge angeben, die von der Vielzahl von Benutzern für jedes vorbestimmte Fälligkeitsdatum angegeben werden; und eine Bestimmungseinheit, die in einem Fall, in dem die von der Erfassungseinheit erfassten Informationen einen ersten Zahlungsbetrag eines ersten Benutzers, der den vorbestimmten persönlichen Betrag übersteigt, und einen zweiten Zahlungsbetrag eines zweiten Benutzers, der den vorbestimmten persönlichen Betrag nicht ausschöpft, aufweisen, die angenommenen Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers so bestimmt, dass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Bezahlungsbetrags des ersten Benutzers ergänzt wird.

Description

  • TECHNISCHER ANWENDUNGSBEREICH
  • Die vorliegende Erfindung bezieht sich auf einen Informationsverarbeitungsserver, ein Informationsverarbeitungsverfahren, ein Programm und ein Servicebereitstellungs-Unterstützungssystem.
  • STAND DER TECHNIK
  • Im Allgemeinen kann in dem Fall des Erwerbs eines teuren Fahrzeugs, wie einem Motorrad oder einem Fahrzeug mit vier Rädern, ein Darlehen genutzt werden, bei dem ein Kaufbetrag aufgeteilt wird und in regelmäßigen Abständen ein fester Betrag gezahlt wird. Zum Beispiel legt Patentliteratur 1 ein Verfahren des Bestimmens von sowohl dem Betrag der Darlehensrückzahlungen eines Fahrzeugkaufpreises als auch den Betrag der Darlehensrückzahlungen einer Fahrschulgebühr bezüglich eines Erwerbs eines Führerscheins und das Bereitstellen der bestimmten Beträge an einem Bedienungsendgerät offen. Gemäß einem solchen Verfahren ist es möglich, die Komfortabilität eines Benutzers, der einen Erwerb eines Führerscheins und den Kauf eines Fahrzeugs mittels eines Darlehens in Betracht zieht, zu verbessern.
  • LISTE DER ZITIERTEN LITERATUR
  • PATENTLITERATUR
  • PTL 1: Japanisches Patent mit der Nr. 6518824
  • ÜBERSICHT ÜBER DIE ERFINDUNG
  • TECHNISCHE PROBLEMSTELLUNG
  • Im Übrigen basieren herkömmliche Kredite und Mietgebühren auf der Annahme, dass ein Benutzer die regelmäßige Zahlung alleine vornimmt. Daher kann das Risiko für einen Benutzer hoch sein, der dazu in der Lage ist, einen Kredit oder eine Mietgebühr zu zahlen, in Anbetracht einer durchschnittlichen Zahlungsfähigkeit, jedoch mit einer Zahlungsfähigkeit, die aufgrund einer hohen Schwankung bei den Einnahmen eines Zahlungszeitraums (zum Beispiel jeden Tag, jeden Monat) für jede Zahlung schwankt, und es kann schwierig sein, die Darlehen und Mietbeträge zu nutzen.
  • Die vorliegende Erfindung wurde angesichts der obigen Probleme gemacht und es ist ein Ziel davon, ein Verfahren zu verwirklichen, das dazu ausgelegt ist, ein Risiko bei der Zahlung für einen Benutzer, der eine schwankende Zahlungsfähigkeit hat, weiter zu verringern.
  • LÖSUNG FÜR DIE PROBLEMSTELLUNG
  • Gemäß der vorliegenden Erfindung wird ein Informationsverarbeitungsserver vorgesehen, der eine periodische Zahlung einer Vielzahl von Benutzern, die zu einer Gruppe gehören, verwaltet, wobei der Server aufweist:
    • eine Festlegungseinheit, die einen vorbestimmten persönlichen Betrag, der an einem vorbestimmten Fälligkeitsdatum von einem jeden der Vielzahl der Benutzer zu zahlen ist, festlegt;
    • eine Erfassungseinheit, die Informationen erfasst, die die Zahlungsbeträge angeben, die jeweils von der Vielzahl der Benutzer für jedes vorbestimmte Fälligkeitsdatum angegeben werden; und
    • eine Bestimmungseinheit, die in einem Fall, in dem die von der Erfassungseinheit erfassten Informationen einen ersten Zahlungsbetrag des ersten Benutzers aufweisen, der den vorbestimmten persönlichen Betrag übersteigt, und einen zweiten Zahlungsbetrag eines zweiten Benutzers, der den vorbestimmten Zahlungsbetrag nicht ausschöpft, die angenommenen Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers bestimmt, sodass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Zahlungsbetrags des ersten Benutzers ergänzt wird.
  • VORTEILHAFTE WIRKUNGEN DER ERFINDUNG
  • Gemäß der vorliegenden Erfindung ist es möglich, ein Verfahren vorzusehen, das dazu ausgelegt ist, ein Risiko bei der Zahlung für einen Benutzer, de eine schwankende Zahlungsfähigkeit hat, weiter zu verringern.
  • Figurenliste
  • Die Zeichnungen im Anhang, die aufgenommen sind und einen Teil der Beschreibung bilden, veranschaulichen Ausführungsformen der Erfindung und dienen zusammen mit der Beschreibung zum Erläutern der Prinzipien der Erfindung.
    • 1 ist ein Diagramm, das ein Beispiel eines Servicebereitstellungs-Unterstützungssystems gemäß der vorliegenden Ausführungsform der vorliegenden Erfindung darstellt.
    • 2 ist ein Blockdiagramm, das ein Beispiel einer funktionalen Gestaltung eines Informationsverarbeitungsservers gemäß der vorliegenden Ausführungsform darstellt.
    • 3 ist ein Blockdiagramm, das ein Beispiel einer Softwaregestaltung des Informationsverarbeitungsservers gemäß der vorliegenden Ausführungsform darstellt.
    • 4 ist ein Blockdiagramm, das ein funktionales Gestaltungsbeispiel einer Benutzerkommunikationsvorrichtung gemäß der vorliegenden Ausführungsform darstellt.
    • 5 ist ein Ablaufdiagramm, das eine Reihe von Ausführungsschritten eines Zahlungsbetrag-Steuerungsprozesses gemäß der vorliegenden Ausführungsform darstellt.
    • 6 ist ein Ablaufdiagramm, das eine Reihe von Ausführungsschritten eines Gesamtzahlungsbetrag-Bestimmungsprozesses gemäß der vorliegenden Ausführungsform darstellt.
    • 7 ist ein Ablaufdiagramm, das eine Reihe von Ausführungsschritten eines Zahlungsprozesses für jeden Benutzer gemäß der vorliegenden Ausführungsform darstellt.
    • 8 ist ein Diagramm, das ein Beispiel der Zahlungsinformationen eines ersten Benutzers, der zu einer Gruppe gehört, gemäß der vorliegenden Ausführungsform darstellt.
    • 9 ist ein Diagramm, das ein Beispiel von Zahlungsinformationen eines zweiten Benutzers, der zu der Gruppe gehört, gemäß der vorliegenden Ausführungsform darstellt.
    • 10 ist ein Diagramm, das ein Beispiel eines Zahlungsbetrags-Eingabebildschirms gemäß der vorliegenden Ausführungsform darstellt.
  • BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
  • Im Folgenden werden Ausführungsformen im Detail mit Bezugnahme auf die Zeichnungen im Anhang beschrieben. Es ist hervorzuheben, dass die folgenden Ausführungsformen nicht dazu gedacht sind, den Umfang der beanspruchten Erfindung einzuschränken, und keine Beschränkung für eine Erfindung gemacht wird, die eine Kombination von allen in den Ausführungsformen beschriebenen Merkmalen erfordert. Zwei oder mehrere der in den Ausführungsformen beschriebenen mehreren Merkmale können nach Angemessenheit kombiniert werden. Darüber hinaus werden die gleichen Bezugsziffern an gleiche oder ähnliche Gestaltungen vergeben und auf eine redundante Beschreibung davon wird verzichtet.
  • [Systemübersicht]
  • 1 ist ein Diagramm, das ein Gestaltungsbeispiel eines Servicebereitstellungs-Unterstützungssystems gemäß der vorliegenden Ausführungsform darstellt. Ein Servicebereitstellungs-Unterstützungssystem 10 gemäß der vorliegenden Ausführungsform weist einen Informationsverarbeitungsserver 100 und eine vom Benutzer 102 verwendete Benutzerkommunikationsvorrichtung 103 auf. Hier ist der Informationsverarbeitungsserver 100 ausgestaltet, mit einer Vielzahl von Benutzerkommunikationsvorrichtungen 103, die jeweils von einer Vielzahl von Benutzern 102 verwendet werden, zu kommunizieren.
  • Der Informationsverarbeitungsserver 100 ist ein Server, der von einem Serviceanbieter verwaltet wird, einen später beschriebenen Zahlungsbetrag-Steuerungsprozess ausführt und eine periodische Zahlung von einer Vielzahl von Benutzern verwaltet, die zu einer Gruppe gehören. Wenngleich Details eines Zahlungsbetrags-Steuerungsprozesses später beschrieben werden, wird ein Zahlungsbetrag (auch als ein angenommener Zahlungsbetrag bezeichnet), von dem davon ausgegangen wird, dass er von einem jeden Benutzer 102 zu bezahlen ist, basierend auf einem Zahlungsbetrag (auch als tatsächlicher Zahlungsbetrag bezeichnet), der von einem jeden Benutzer 102 gezahlt wird (zum Beispiel über die Benutzerkommunikationsvorrichtung 103), gesteuert. Im unten beschriebenen Zahlungsbetrag-Steuerungsprozess nimmt der einzelne Benutzer 102 in periodischen Abständen eine individuelle Zahlung vor. Bei einem Zahlungszeitpunkt ist es in einem Fall, in dem der Zahlungsbetrag (tatsächlicher Zahlungsbetrag) des Benutzers einem vorbestimmten zu zahlenden Zahlungsbetrag übersteigt, möglich, den Zahlungsbetrag eines anderen Benutzers in der Gruppe zu ergänzen, der den zu zahlenden Zahlungsbetrag nicht übersteigt. Wie oben beschrieben, wenn die Zahlung an jedem Zahlungszeitpunkt aus der Vielzahl von Benutzern, die die Gruppe bilden, ergänzt wird, ist es möglich, eine Wahrscheinlichkeit zu verringern, dass die Zahlung eines einzelnen Benutzers nicht einen erforderlichen Betrag ausschöpft, und ein Risiko der Zahlung selbst für einen Benutzer zu verringern, der eine schwankende Zahlungsfähigkeit hat.
  • In der vorliegenden Ausführungsform vermietet der Serviceanbieter das Fahrzeug 101 an den Benutzer 102. Der Benutzer 102 leistet einen vorbestimmten Zahlungsbetrag an den Serviceanbieter in Anbetracht der Mietserviceleistung in vorbestimmten Zeitspannen (zum Beispiel jeden Tag, jede Woche und jeden Monat).
  • Die von dem Benutzer 102 an den Serviceanbieter vorgenommene Zahlung kann in der Währung des Landes sein, in der der Service erbracht wird, oder eine virtuelle Währung oder Punkte, die vom Serviceanbieter oder einer dritten Partei ausgegeben und verwaltet werden, können verwendet werden.
  • Das Fahrzeug 101 ist zum Beispiel ein Fahrzeug mit zwei Rädern und kann einen Kunden zusätzlich zu dem Benutzer 102, der ein Fahrer ist, befördern. Das Fahrzeug 101 kann dazu in der Lage sein, mit dem Informationsverarbeitungsserver 100 zu kommunizieren und kann Daten (auch als Fahrdaten bezeichnet), wie eine von einem Sensor des Fahrzeugs 101erfasste Beschleunigung, an den Informationsverarbeitungsserver zu einem beliebigen Zeitpunkt oder einem vorbestimmten Zeitpunkt übertragen. Die Fahrdaten werden im Folgenden beschrieben. Es ist hervorzuheben, dass ein Fall, in dem das Fahrzeug 101 ein Fahrzeug mit zwei Rädern ist, als ein Beispiel der vorliegenden Ausführungsform beschrieben wird, das Fahrzeug 101 aber auch ein Fahrzeug mit vier Rädern sein kann.
  • Die Benutzerkommunikationsvorrichtung 103 ist zum Beispiel ein Smartphone, das vom Benutzer 102 besessen oder durch den Serviceanbieter verliehen wird, und kann mit dem Informationsverarbeitungsserver 100 über ein Kommunikationsnetzwerk kommunizieren. Der Benutzer 102 kann einen Zahlungsbetrag (tatsächlichen Zahlungsbetrag) unter Verwendung der Benutzerkommunikationsvorrichtung 103 angeben und Informationen zu dem Zahlungsbetrag an den Informationsverarbeitungsserver übertragen.
  • [Funktionales Gestaltungsbeispiel des Informationsverarbeitungsservers]
  • 2 ist ein Blockdiagramm, das ein Beispiel einer funktionalen Gestaltung des Informationsverarbeitungsservers 100 darstellt. Ein Steuerbereich 200 weist einen oder mehrere Prozessoren (zentrale Verarbeitungseinheit (CPU) 201), einen Nur-Lese-Speicher (ROM) 202 und einen Direktzugriffspeicher (RAM) 203 auf. Die CPU 201 liest und führt ein Computerprogramm (einfach als ein Programm bezeichnet), das im ROM 202 gespeichert ist, aus, wodurch verschiedene im Folgenden beschriebene Prozesse gesteuert werden. Das ROM 202 ist ein nicht-flüchtiger Speicherbereich und speichert Programme entsprechend den verschiedenen Verarbeitungsarten. Es ist hervorzuheben, dass ein Halbleiterspeicher anstelle der HDD verwendet werden kann. Das RAM 203 ist ein flüchtiger Speicherbereich und wird zum Beispiel als ein Arbeitsspeicher verwendet. Es ist hervorzuheben, dass der Steuerbereich 200 eine Grafikverarbeitungseinheit (GPU), einen anwendungsspezifischen integrierten Schaltkreis (ASIC), einen dedizierten Schaltkreis oder Ähnliches aufweisen kann. Darüber hinaus kann der Steuerbereich 200 so ausgestaltet sein, dass ein jedes konstituierende Element des Steuerbereichs 200 virtualisiert ist.
  • Eine Stromversorgungseinheit 204 ist eine Komponente, die dem Informationsverarbeitungsserver 100 externe Energie zuleitet. Eine Kommunikationseinheit 205 ist eine Komponente, die mit dem Fahrzeug 101, der Benutzerkommunikationsvorrichtung 103 und Ähnlichem über ein Kommunikationsnetzwerk kommuniziert und im Besonderen bezüglich eines Kommunikationsverfahrens, eines Kommunikationsprotokolls und Ähnlichem nicht beschränkt ist.
  • Eine Aufzeichnungseinheit 206 weist zum Beispiel ein nicht-flüchtiges Aufzeichnungsmedium, wie ein Festplattenlaufwerk (HDD) auf, und zeichnet auf und enthält verschiedene Arten von Informationen der DB oder Ähnliches, wie oben beschrieben.
  • [Softwaregestaltung des Informationsverarbeitungsservers]
  • 3 ist ein Blockdiagramm, das ein Beispiel einer Softwaregestaltung des Informationsverarbeitungsservers 100 gemäß der vorliegenden Ausführungsform darstellt.
  • In der vorliegenden Ausführungsform liest die CPU 201 ein im ROM 202 oder Ähnlichem gespeichertes Programm, um eine jede Einheit zu implementieren. Ein jede Datenbank (DB) ist in der Aufzeichnungseinheit 206 gespeichert. Es ist darauf hinzuweisen, dass 3 ein Beispiel der Softwaregestaltung darstellt, die zur Implementierung der vorliegenden Ausführungsform erforderlich ist, sodass eine jede Softwaregestaltung der Firmware, des BS, der Middleware, eines Webservice-Moduls und Ähnlichem weggelassen wird.
  • Eine Benutzerinformations-Erfassungseinheit 303 erfasst Benutzerinformationen vom dem Fahrzeug 101 und der Benutzerkommunikationsvorrichtung 103 über die Kommunikationseinheit 205. Die Benutzerinformationen weisen Informationen eines Zahlungsbetrags (tatsächlicher Zahlungsbetrag) auf, die von der Benutzerkommunikationsvorrichtung 103 empfangen werden, Fahrdaten die vom Fahrzeug 101 hochgeladen werden, und Ähnliches.
  • Die Benutzerinformationsverwaltungseinheit 301 ist eine Komponente, die die Benutzerdaten verwaltet, die von der Benutzerinformations-Erfassungseinheit 303 für jeden Benutzer erfasst werden. Die Benutzerinformationsverwaltungseinheit 301 ermöglicht die Angabe von Benutzerinformationen zum Beispiel zur Verwendung der Kennung eines Benutzers, um die Daten des Benutzers in eine Benutzerverwaltungs-DB 310 zu schreiben oder die Benutzerinformationen zu lesen, die in der Benutzerverwaltungs-DB 310 aufgezeichnet sind.
  • Eine Gruppeninformations-Verwaltungseinheit 302 ist eine Komponente, die eine gebildete Gruppe und Benutzer verwaltet, die Mitglieder der Gruppe sind. Die Gruppeninformation-Verwaltungseinheit 302 ermöglicht die Angabe von Gruppeninformationen zum Beispiel durch die Verwendung der Kennung einer Gruppe und verknüpft die Gruppenkennung mit der Kennung des Benutzers, der ein Mitglied ist, um die Daten der Gruppe in eine Gruppenverwaltung DB 311 zu schreiben. Darüber hinaus liest die Gruppeninformations-Verwaltungseinheit 302 Gruppeninformationen, die in der Gruppenverwaltung DB 311 aufgezeichnet sind und Informationen zu einem Benutzer, der ein Mitglied einer spezifischen Gruppe ist.
  • Eine persönliche Zahlungsverwaltungseinheit 304 ist eine Komponente, die Zahlungsinformationen für jeden Benutzer verwaltet. Die persönliche Zahlungsverwaltungseinheit 304 bestimmt einen angenommenen Zahlungsbetrag für einen jeden Benutzer auf der Basis der Zahlungsbeträge (tatsächliche Zahlungsbeträge) einer Vielzahl von Benutzern, die eine Gruppe bilden. Die persönliche Zahlungsverwaltungseinheit 304 kann Informationen wie einen angenommenen Zahlungsbetrag und andere Zahlungsbeträge in einer persönlichen Zahlungshistorie-DB 313 aufzeichnen. Darüber hinaus liest die persönliche Zahlungsverwaltungseinheit 304 die Zahlungshistorieninformationen, die in der persönlichen Zahlungshistorie-DB 313 aufgezeichnet sind. Die von der persönlichen Zahlungsverwaltungseinheit 304 verarbeiteten Zahlungsinformationen werden später mit Bezugnahme auf 8 und 9 beschrieben.
  • Eine Gruppenzahlungs-Verwaltungseinheit 305 bestimmt einen Zahlungsstatus der gesamten Gruppe und zeichnet eine Historie des Zahlungsbetrags, der von der gesamten Gruppe gezahlt wird, in einer Gruppenzahlungshistorie-DB 314 auf oder liest die Historie aus der Gruppenzahlungshistorie-DB 314. In der Gruppenzahlungshistorie-DB 314 werden ein vorbestimmter Betrag, der von der gesamten Gruppe zu zahlen ist, die Anzahl der Vorkommen für einen Fall, in dem der Zahlungsbetrag der gesamten Gruppe den vorbestimmten Betrag nicht ausschöpft, und Ähnliches zusätzlich zu der Historie des Zahlungsbetrags, der von der gesamten Gruppe gezahlt wird, aufgezeichnet.
  • Eine Begleichungsverarbeitungseinheit 306 ist eine Komponente, die auf Informationen eines persönlichen Kontos zugreift, das in einer persönlichen Konto-DB 312 aufgezeichnet ist und einen Transaktionsprozess für einen Zuzahlungsbetrag und einen angenommenen Zahlungsbetrag durchführt, wenn die tatsächliche Zahlung eines jeden Benutzers und die Anpassung (Zuzahlung oder Rückzahlung) des Zahlungsbetrags als eine tatsächliche Zahlungstransaktion ausgeführt werden. Die persönliche Konto-DB 312 kann weiterhin eine Historie der Transaktionen für jeden Benutzer aufzeichnen. Die Historie der Transaktionen kann unter Verwendung einer Blockchain-Technologie aufgezeichnet werden und eine Aufzeichnung unter Verwendung der Blockchain kann ein Risiko verhindern, dass der Datensatz einer jeden Transaktion illegal gefälscht wird.
  • Wenn die Zahlung eines jeden Benutzers abgeschlossen ist, kann eine Zahlungsergebnis-Bereitstellungseinheit 307 zum Beispiel Informationen (Zahlungsergebnisinformationen) für den Benutzer erstellen, um den angenommenen Zahlungsbetrag oder den Zuzahlungsbetrag, der für den Zahlungsbetrag (tatsächlichen Zahlungsbetrag) des Benutzers festgelegt ist, zu bestätigen. Dann kann die Zahlungsergebnis-Bereitstellungseinheiten 307 die erstellten Zahlungsergebnisinformationen an die Benutzerkommunikationsvorrichtung 103 (über die Kommunikationseinheit 205) übertragen.
  • [Überblick über die Zahlungsinformationen und den Zahlungsbetrag-Steuerungsprozess]
  • Wie oben beschrieben, bestimmt die persönliche Zahlungsverwaltungseinheit 304 einen angenommen Zahlungsbetrag für jeden Benutzer auf der Basis der Zahlungsbeträge (tatsächliche Zahlungsbeträge), die von einer Vielzahl von Benutzern gezahlt werden, die eine Gruppe bilden. Die Zahlungsinformationen weisen einen angenommen Zahlungsbetrag und einen Zuzahlungsbetrag auf, der von der persönlichen Zahlungsverwaltungseinheit 304 bestimmt wird. 8 stellt Zahlungsinformationen 900 eines zu der Gruppe gehörenden ersten Benutzers dar. Die Zahlungsinformationen weisen zum Beispiel ein Feld eines Zahlungsfälligkeitsdatums 901, ein Feld eines Zahlungsbetrags (tatsächlicher Zahlungsbetrag) 902, ein Feld eines angenommenen Zahlungsbetrags 903 und ein Feld eines Zuzahlungsbetrags 904 auf.
  • Das Zahlungsfälligkeitsdatum gibt den Zeitraum einer jeden Zahlung an (zum Beispiel jeden Tag, jeden Monat). In der vorliegenden Ausführungsform wird das Zahlungsfälligkeitsdatum für jeden Tag festgelegt. D. h., es wird davon ausgegangen, dass der Benutzer des Fahrzeugs 101 einen vorbestimmten Betrag (persönlichen Zahlungsbetrag) als die Mietkosten zahlt, der von einem jeden Benutzer an einem jeden Fälligkeitsdatum zu zahlen ist. Im Beispiel von 8 gibt das Zahlungsfälligkeitsdatum 901 N bis N-3 an und gibt das Fälligkeitsdatum der letzten drei Tage zusätzlich zu Tag N mit dem aktuellen Tag als N an.
  • Der Zahlungsbetrag (tatsächlicher Zahlungsbetrag) 902 gibt einen Zahlungsbetrag an, der von dem ersten Benutzer unter Verwendung der Benutzerkommunikationsvorrichtung 103 am Zahlungsfälligkeitsdatum (zum Beispiel Tag N) gezahlt wird. Der Zahlungsbetrag (tatsächlicher Zahlungsbetrag) 902 ist ein Betrag, der vom Benutzer beliebig genannt werden kann. Zum Beispiel ist es in einem Fall, in dem der persönliche Zahlungsbetrag für die Fahrzeugmietkosten 400 (die Währungseinheit ist beliebig) beträgt, wünschenswert, dass der erste Benutzer einen Zahlungsbetrag (tatsächlichen Zahlungsbetrag) von 400 oder mehr angibt, um die Zahlung fortzusetzen. Wenn der erste Benutzer einen Zahlungsbetrag (tatsächlichen Zahlungsbetrag) von 400 oder mehr angibt, wird wenigstens der Betrag, der vom ersten Benutzer am Tag N zu zahlen ist, gezahlt.
  • Es ist hervorzuheben, dass in der vorliegenden Ausführungsform der Informationsverarbeitungsserver 100 eine Konto-DB aufweist. Die Konto-DB kann jedoch in einem Server einer dritten Partei vorgesehen sein. D. h., die Zahlung kann in der Konto-DB des Servers der dritten Partei basierend auf Informationen von der Kommunikationsvorrichtung 103 vorgenommen werden, und der Informationsverarbeitungsserver 100 kann die Zahlungsinformationsverwaltung auf Basis der Informationen vom Server der dritten Partei durchführen.
  • Die angenommene Zahlungsbetrag 903 unterscheidet sich vom Zahlungsbetrag (tatsächlicher Zahlungsbetrag) 902, der vom Benutzer angegeben werden kann, ist ein Betrag, der von einem Zahlungsbetrag-Berechnungsprozess des Informationsverarbeitungsservers 100 bestimmt wird und gibt einen Zahlungsbetrag an, von dem ausgegangen wird, dass ihn der erste Benutzer als seine/ihre eigenen Mietkosten an einem spezifischen Fälligkeitsdatum (zum Beispiel Tag N) gezahlt hat.
  • Der Zuzahlungsbetrag 904 gibt eine kumulative Summe eines Zuzahlungsbetrags an, der vom ersten Benutzer für den Fehlbetrag eines anderen zweiten Benutzers, der den persönlichen Zahlungsbetrag nicht zahlen kann, vorgesehen wird, oder einen Zuzahlungsbetrag, der von einem anderen zweiten Benutzer für die Unterdeckung des ersten Benutzers, der den persönlichen Zahlungsbetrag nicht zahlen kann, vorgesehen wird.
  • Eine spezifischere Beschreibung wird mit Bezugnahme auf die Beispiele von 8 und 9 gegeben. Es ist hervorzuheben, dass 9 die Zahlungsinformationen des zweiten Benutzers veranschaulicht. Es wird davon ausgegangen, dass der persönliche Zahlungsbetrag auf 400 festgelegt ist.
  • Als Beispiel wird die Zahlung am Tag N-1 herangezogen. In einem Fall, in dem das Zahlungsfälligkeitsdatum N-1 ist, wie in 8 dargestellt, gibt der erste Benutzer 500 als den Zahlungsbetrag (tatsächlichen Zahlungsbetrag) an. Dieser Betrag ist ein Betrag, der 400 übersteigt, der ein persönlicher Zahlungsbetrag ist. Andererseits gibt in einem Fall, in dem das Zahlungsfälligkeitsdatum N-1 ist, der zweite Benutzer nur 300 als den Zahlungsbetrag (tatsächlichen Zahlungsbetrag) an, wie in 9 dargestellt. Das heißt, es wird davon ausgegangen, dass der zweite Benutzer die 400, die der persönliche Zahlungsbetrags sind, am Tag N-1 aufgrund einer Schwankung in der Zahlungsfähigkeit nicht zahlen kann.
  • In einem Fall, in dem ein solcher Zahlungsbetrag (tatsächlicher Zahlungsbetrag) im Zahlungsbetrag-Steuerungsprozess angegeben wird, wird der angenommene Zahlungsbetrag für den ersten Benutzer auf 400 festgelegt und die restlichen 100 werden als Zuzahlungsbetrag für die Zuzahlung der Zahlung des zweiten Benutzers verwendet. Daher ist der angegebene Zahlungsbetrag des zweitens Benutzers am Tag N-1 300 + 100 = 400, und es wird erwogen, dass der zweite Benutzer die Zahlung von 400 entsprechend dem persönlichen Zahlungsbetrag vornehmen kann. Da der zweite Benutzer 100 als einen Zuzahlungsbetrag vom ersten Benutzer empfangen hat, ist der Zuzahlungsbetrag 904 „-100“, was angibt, dass der zweite Benutzer eine Zuzahlung von 100 vom ersten Benutzer empfangen hat. Umgekehrt ist der Zuzahlungsbetrag 904 des ersten Benutzers „+ 100“, was angibt, dass der erste Benutzer eine Zuzahlung von 100 für den zweiten Benutzer leistet.
  • Ferner wird ein Beispiel beschrieben, in dem das Zahlungsfälligkeitsdatum der Tag N ist und der zweite Benutzer den Zuzahlungsbetrag zurückzahlt. In einem Fall, in dem die Zahlungsfälligkeitsdatum der Tag N ist, gibt der erste Benutzer zum Beispiel 400 als den Zahlungsbetrag (tatsächlichen Zahlungsbetrag) an und der zweite Benutzer gibt 500 als den Zahlungsbetrag (tatsächlichen Zahlungsbetrag) an.
  • Zum Beispiel wird in einem Fall, in dem der angenommene Zahlungsbetrag des zweiten Benutzers berechnet wird, zuerst der Zuzahlungsbetrag (d. h. 100) von 500 abgezogen, was der Zahlungsbetrag (tatsächliche Zahlungsbetrag) ist. Das liegt darin begründet, dass der Zuzahlungsbetrag an den ersten Benutzer zurückgezahlt wird. Demgemäß wird der angenommene Zahlungsbetrag des zweiten Benutzers 400 und der Zuzahlungsbetrag geht auf o zurück.
  • Andererseits ist der angenommene Zahlungsbetrag des ersten Benutzers 500 (= 400 plus 100), da zu 400, das der Zahlungsbetrag (tatsächlicher Zahlungsbetrag) ist, ein Zuzahlungsbetrag (d. h. 100) hinzuaddiert wird, der vom zweiten Benutzer zurückgezahlt wird.
  • Wie oben beschrieben, berechnet der Informationsverarbeitungsserver 100 im Zahlungsbetrag-Steuerungsprozess den angenommenen Zahlungsbetrag und den Zuzahlungsbetrag gemäß dem Zahlungsbetrag (tatsächlicher Zahlungsbetrag) des Benutzers in der Gruppe. Demgemäß kann, selbst wenn der Zahlungsbetrag eines spezifischen Benutzers zeitweise nicht den persönlichen Zahlungsbetrag erreicht, eine Anpassung durchgeführt werden, indem der Zahlungsbetrag eines anderen Benutzers verwendet wird. Daher kann selbst in einem Fall, in dem die Zahlung verzögert ist, und das Guthaben des Benutzers verringert wird, wenn der Benutzer die Bezahlung alleine vornimmt, die Zahlung sicher fortgesetzt werden.
  • [Fahrdaten]
  • Die Fahrdaten werden für jeden Benutzer verwaltet und für jeden Benutzer erzeugt, wenn die Fahrdaten vom Fahrzeug 101 erfasst werden. Die Fahrdaten können eine Startzeit und eine Endzeit des Fahrens durch den Benutzer aufweisen, Zeitreihendaten, die einen Übergang der Position des Fahrzeugs zwischen dem Startzeitpunkt und dem Endzeitpunkt angeben, Zeitreihendaten, die einen Übergang der Geschwindigkeit des Fahrzeugs zwischen dem Startzeitpunkt und dem Endzeitpunkt angeben, und Zeitreihendaten, die den Übergang der Beschleunigung des Fahrzeugs zwischen dem Startzeitpunkt und dem Endzeitpunkt angeben. Darüber hinaus können Informationen, die angeben, ob das Fahrzeug ohne Wartung in einem entsprechenden Zeitraum gefahren ist, zu den Fahrdaten hinzugefügt werden.
  • [Benutzergruppe]
  • Wie oben beschrieben, werden in der Gruppenverwaltungs-DB 311 die Informationen zu Benutzern, die eine Gruppe bilden, und die Informationen zu der Gruppe verwaltet. Die Gruppe kann in beliebiger Weise erzeugt werden. Zum Beispiel kann ein spezifischer Benutzer die Benutzerkommunikationsvorrichtung 103 dazu nutzen, einen anderen Benutzer einladen, um eine Gruppe mit dem Benutzer zu bilden, der die Einladung angenommen hat.
  • Alternativ kann der Informationsverarbeitungsserver 100 einen Abgleichungsprozess eines Benutzers für eine große Anzahl von Benutzern durchführen, die beim Serviceanbieter registriert sind, und für einen spezifischen Nutzer einen anderen Benutzer empfehlen, der zum Bilden eine Gruppe mit dem Benutzer geeignet ist.
  • Zum Beispiel kann der Serviceanbieter dem Benutzer der Benutzerkommunikationsrichtung 103 vorab eine Haushaltsbuchanwendung bereitstellen, um dem Benutzer die Eingabe einer Tagesbilanz zu ermöglichen. In diesem Fall empfängt der Informationsverarbeitungsserver 100 Daten zu Einnahmen und Ausgaben und sammelt diese, die von der Benutzerkommunikationsvorrichtung 103 übertragen worden und gibt die Zahlungsfähigkeit eines jeden Benutzers auf der Basis der Daten an. Zum Beispiel wird ein Benutzer, dessen Zahlungsfähigkeit über einem persönlichen Zahlungsbetrag für eine vorbestimmte Zeitspanne liegt (zum Beispiel eine Zeitspanne, während der der Benutzer im Allgemeinen ein Fahrzeug mietet) liegt, angegeben und der angegebene Benutzer wird als ein Kandidat für ein Gruppenmitglied empfohlen.
  • Die vorliegende Erfindung ist nicht auf einen Fall beschränkt, in dem die durchschnittliche Zahlungsfähigkeit eines jeden Benutzers den persönlichen Zahlungsbetrag übersteigt, wie oben beschrieben. Wenn die durchschnittliche Zahlungsfähigkeit der Mitglieder, die eine Gruppe bilden, einen Gruppenzahlungsbetrag (zum Beispiel 2000 in einer Gruppe von 5 Personen) übersteigt, können die Mitglieder als Kandidaten empfohlen werden. Auf diese Weise kann beispielsweise in einem Fall, in dem die Mitglieder, die eine durchschnittliche Zahlungsfähigkeit haben, die den Gruppenzahlungsbetrag übersteigt, empfohlen werden, eine Kombination aus einem Benutzer, der eine hohe durchschnittliche Zahlungsfähigkeit hat und einem Benutzer, der eine etwas niedrige durchschnittliche Zahlungsfähigkeit hat, empfohlen werden.
  • Der Informationsverarbeitungsserver 100 kann Benutzer, die ähnliche Qualitätsstufen in einem Fahrbereich, einem Verhaltensmuster an einem Tag oder einem Wartungszustand des Fahrzeugs haben, basierend auf den erfassten Fahrdaten oder Positionsinformationen von der Kommunikationsvorrichtung 103 gruppieren. In diesem Fall kann nach der Gruppierung der Benutzer der Informationsverarbeitungsserver 100 einen Benutzer empfehlen, der eine durchschnittliche Zahlungsfähigkeit einer einzelnen Person oder eine Zahlungsfähigkeit einer Gruppe, die einen Referenzwert übersteigt, hat.
  • [Funktionales Gestaltungsbeispiel der Benutzerkommunikationsvorrichtung 103]
  • Als Nächstes wird ein funktionales Gestaltungsbeispiel der Benutzerkommunikationsvorrichtung 103 beschrieben. 4 ist ein Blockdiagramm, das ein funktionales Gestaltungsbeispiel der Benutzerkommunikationsvorrichtung 103 darstellt. Ein Steuerbereich 410 weist eine oder mehrere CPUs 411, ein ROM 412 und ein RAM 413 auf. Die CPU 411 liest und führt ein im ROM 412 gespeichertes Programm aus, um verschiedene Arten der Verarbeitung in der Kommunikationsvorrichtung zu steuern. Das Programm kann die oben beschriebene Haushaltsbuchanwendung aufweisen. Das ROM 412 ist ein nicht-flüchtiges Speichermedium und wird beispielsweise ein Halbleiterspeicher verwendet, um Programme zu speichern, die verschiedenen Arten der Verarbeitung entsprechen. Das RAM 413 ist ein flüchtiges Speichermedium und wird zum Beispiel als ein Arbeitsspeicher verwendet. Es ist hervorzuheben, dass der Steuerbereich 410, eine GPU, einen ASIC, einen dedizierten Schaltkreis oder Ähnliches aufweisen kann.
  • Die Benutzerkommunikationsvorrichtung 103 gemäß der vorliegenden Ausführungsform weist eine Informationsschnittstelle nach außen und verschiedene Komponenten, die die für die Operation der Benutzerkommunikationsvorrichtung 103 erforderliche Energie bereitstellen und Ähnliches auf. Eine jede im Folgenden zu beschreibende Komponente arbeitet unter der Steuerung des Steuerbereichs 410. Eine Bedienungseinheit 414 ist eine Komponente, die verschiedene Bedienvorgänge auf der Kommunikationsvorrichtung empfängt und zum Beispiel einen Schalter und ein berührungsempfindliches Feld aufweist. In der vorliegenden Ausführungsform empfängt zum Beispiel die Bedienungseinheit 414 die Eingabe des Zahlungsbetrags (tatsächlicher Zahlungsbetrag) von einem jeden Benutzer, die Eingabe des Saldos in die Haushaltsbuchanwendung und ähnliches oben Beschriebene.
  • Eine Kommunikationseinheit 415 ist eine Komponente zur Kommunikation mit einer externen Vorrichtung (zum Beispiel dem Informationsverarbeitungsserver 100) über ein Netzwerk und ist im Besonderen hinsichtlich eines Kommunikationsverfahrens, eines Kommunikationsprotokolls und Ähnlichem nicht beschränkt. Zum Beispiel überträgt die Kommunikationseinheit 415 die Zahlungsinformationen und ähnliche Eingaben von dem Benutzer an den Informationsverarbeitungsserver 100 oder empfängt die Zahlungsergebnisinformationen und Ähnliches, die vom Informationsverarbeitungsserver 100 erzeugt wurden.
  • Eine Stromversorgungseinheit 416 ist eine Komponente, die einer jeden Einheit der Benutzerkommunikationsvorrichtung 103 Strom zuleitet, und entspricht einer Batterie. Die Anzeigeeinheit 417 weist einen Bildschirm zum Eingeben einer Zahlung, einen Bildschirm zum Anzeigen der Zahlungsergebnisinformationen, eine Anzeige zum Anzeigen von Kartendaten zur Navigation und Ähnliches auf. Die Anzeigeeinheit 417 und die Bedienungseinheit 414 können integral zum Beispiel als eine Berührungsfeldanzeige (Touch Panel-Anzeige) ausgestaltet sein.
  • Eine Sensoreinheit 421 weist verschiedene Sensoren, wie ein globales Positionierungssystem (GPS) zum Erfassen der eigenen Positionsinformationen und eine Kamera auf.
  • [Gestaltung des Fahrzeugs 101].
  • Wenngleich die Gestaltung des Fahrzeugs 101 nicht dargestellt ist, weist das Fahrzeug 101 auf einen Steuerbereich, der eine oder mehrere CPUs aufweist, ein Speichermedium wie ein ROM und ein RAM, verschiedene Sensoren, wie ein GPS und einen Beschleunigungssensor und eine Kommunikationseinheit, die dazu ausgelegt ist eine drahtlose Kommunikation durchzuführen. Die CPU des Fahrzeugs 101 liest und führt ein Programm aus, das im Aufzeichnungsmedium gespeichert ist, wodurch Daten, die von einem Sensor, in dem Fahrzeug als Fahrdaten (über die Kommunikationseinheit) bezogen werden, an den Informationsverarbeitungsserver 100 übertragen werden.
  • [Reihe von Ausführungsschritten des Zahlungsbetrag-Steuerungsprozesses]
  • Als Nächstes wird eine Reihe von Ausführungsschritten des Zahlungsbetrag-Steuerungsprozesses im Informationsverarbeitungsserver 100 gemäß der vorliegenden Ausführungsform mit Bezugnahme auf 5 beschrieben. In der vorliegenden Ausführungsform liest die CPU 201 des Informationsverarbeitungsservers 100 ein im ROM 202 gespeichertes Programm und führt es aus, um diesen Prozess zu implementieren. Ein jeder Verarbeitungsschritt wird in Zusammenwirken von beispielsweise der Komponenten in 2 und den Verarbeitungseinheiten in 3 implementiert. Aus Gründen der Einfachheit wird jedoch jeder Verarbeitungsschritt im Ganzen als durch den Informationsverarbeitungsserver 100 ausgeführt beschrieben.
  • In S501 legt der Informationsverarbeitungsserver 100 einen von einem jedem Benutzer am Fälligkeitsdatum zu zahlenden Betrag (d. h. einen persönlichen Zahlungsbetrag) und einen von der gesamten Gruppe an jeden Fälligkeitsdatum zu zahlenden Betrag (d. h. einen Gruppenzahlungsbetrag) fest. Die Gruppenzahlungsbeträge sind beispielsweise eine Zahl, die durch Multiplikation des persönlichen Zahlungsbetrags mit der Anzahl von Benutzern erhalten wird.
  • Es ist hervorzuheben, dass sich im Zahlungsbetrag-Steuerungsprozess die Anzahl der zu der Gruppe gehörenden Benutzer erhöhen oder verringern kann. Daher kann in Reaktion auf die Erhöhung oder die Verringerung der Anzahl der Benutzer der Informationsverarbeitungsserver 100 einen vorbestimmten Betrag für die Gruppe basierend auf der neuen Anzahl der Benutzer und dem persönlichen Zahlungsbetrag ändern.
  • In S502 erfasst der Informationsverarbeitungsserver 100 Informationen, die den Zahlungsbetrag von einem jeden Benutzer von der Benutzerkommunikationsvorrichtung 103 in Verbindung mit einem jeden Benutzer, der zu der Gruppe gehört, am Zahlungsfälligkeitsdatum angeben. Die Informationen, die den Zahlungsbetrag angeben, entsprechen den Informationen, die im Zahlungsbetrag (tatsächlicher Zahlungsbetrag) 902, der in den oben beschriebenen 8 und 9 dargestellt ist, angegeben werden.
  • Ein jeder Benutzer gibt beispielsweise einen Zahlungsbetrag auf dem in 10 dargestellten Zahlungsbetrag-Eingabebildschirm in die Benutzerkommunikationsvorrichtung 103 ein. Ein in 10 dargestellter Zahlungsbetrag-Eingabebildschirm 1101 weist zum Beispiel einen Benutzernamensanzeige 1102, ein Eingabefeld 1103 eines heutigen Zahlungsbetrags, einen Zahlungsbetrag (tatsächlicher Zahlungsbetrag) 1105 und ein Zahlungshistorienfeld 114 auf.
  • Wenn der Benutzer einen Zahlungsbetrag für den heutigen Tag als den Zahlungsbetrag (tatsächlicher Zahlungsbetrag) 1105 gemäß seinen/ihren eigenen Einnahmen eingibt, wird der Zahlungsbetrag an den Informationsverarbeitungsserver 100 übertragen. Die Benutzerkommunikationsvorrichtung 103 erfasst Informationen einer Zahlungshistorie 1104, die sich auf den bislang angenommenen Zahlungsbetrag des Benutzers vom Informationsverarbeitungsserver 100 bezieht und stellt die Informationen auf dem Zahlungsbetrag-Eingabebildschirm dar. Die Zahlungshistorieninformationen werden zum Beispiel durch die Zahlungsergebnis-Bereitstellungseinheiten 307 des Informationsverarbeitungsservers 100 erzeugt. Auf diese Weise kann der Benutzer den Zahlungsbetrag für den heutigen Tag eingeben, während die Zahlungshistorie bislang berücksichtigt wird. Es ist hervorzuheben, dass ein Beispiel dargestellt wurde, in dem der bislang angenommene Zahlungsbetrag in der Zahlungshistorie angezeigt wird. Es können jedoch ferner mindestens eines von der Historie des angenommenen Zahlungsbetrags und des Zahlungsbetrags (tatsächlicher Zahlungsbetrag) und des Zuzahlungsbetrags angezeigt werden.
  • In S503 bestimmt der Informationsverarbeitungsserver 100, indem ein Gesamtzahlungsbetrag der gesamten Gruppe (Gesamtzahlungsbetrag-Bestimmungsprozess) bestimmt wird, ob der Gesamtzahlungsbetrag eine Zahlungsfortsetzungsbedingung erfüllt. Der Gesamtzahlungsbetrag-Bestimmungsprozess wird später mit Bezugnahme auf 6 beschrieben.
  • In S504 führt der Informationsverarbeitungsserver 100 einen Zahlungsprozess für jeden Benutzer aus und bestimmt den angenommenen Zahlungsbetrag 903 und den Zuzahlungsbetrag 904 für jeden Benutzer. Es ist hervorzuheben, dass in diesem Schritt davon ausgegangen wird, dass der Prozess wiederholt so viele Male aufgerufen wird, wie die Anzahl der Benutzer, die zu der Gruppe gehören. Der Zahlungsprozess für jeden Benutzer wird später mit Bezugnahme auf 7 beschrieben.
  • In S505 bestimmt der Informationsverarbeitungsserver 100 basierend auf dem Verarbeitungsergebnis des Gesamtzahlungsbetrag-Bestimmungsprozesses in S503, ob dieser Prozess die Fortsetzungsbedingung erfüllt. Zum Beispiel bezieht sich der Informationsverarbeitungsserver 100 auf Flag-Informationen (später beschrieben), die angeben, dass die Zahlung in der gesamten Gruppe nicht fortgesetzt werden kann, und bestimmt in S503, ob bestimmt wird, dass die Zahlung nicht von der gesamten Gruppe geleistet werden kann. In einem Fall, in dem in S503 bestimmt wird, dass von der gesamten Gruppe keine Zahlung geleistet werden kann, wird bestimmt, dass die Fortsetzungsbedingung nicht erfüllt ist und diese Reihe der Ausführungsschritte wird beendet. Darüber hinaus wird selbst in einem Fall, in dem alle Benutzer, die die Gruppe bilden, die Bezahlung beenden oder stoppen und die Gruppe verlassen, bestimmt, dass die Fortsetzungsbedingung nicht erfüllt ist und diese Reihe der Ausführungsschritte wird beendet. Andernfalls kehrt der Informationsverarbeitungsserver 100 zur Verarbeitung von S502 zurück und wiederholt die Verarbeitung.
  • [Reihe von Ausführungsschritten des Gesamtzahlungsbetrag-Bestimmungsprozesses]
  • Als Nächstes wird eine Reihe von Ausführungsschritten des Gesamtzahlungsbetrag-Bestimmungsprozesses mit Bezugnahme auf 6 beschrieben. Ähnlich wie bei dem oben beschriebenen Zahlungsbetrag-Steuerungsprozess wird dieser Prozess durch die CPU 201 des Informationsverarbeitungsservers 100 implementiert, der ein im ROM 202 gespeichertes Programm liest und ausführt. Ein jeder Verarbeitungsschritt wird in Zusammenwirken von beispielsweise der Komponenten in 2 und den Verarbeitungseinheiten in 3 implementiert. Aus Gründen der Einfachheit wird jedoch jeder Verarbeitungsschritt im Ganzen als durch den Informationsverarbeitungsserver 100 ausgeführt beschrieben. Der Prozess wird gelesen, wenn die Verarbeitung in S503 ausgeführt wird.
  • In S601 bestimmt der Informationsverarbeitungsserver 100, ob der Gesamtbetrag der Zahlungsbeträge (tatsächliche Zahlungsbetrag) der Benutzer in der in S502 erfassten Gruppe gleich oder größer als der Betrag ist, der von der gesamten Gruppe zu zahlen ist (d. h., der Gruppenzahlungsbetrag). In einem Fall, in dem der Gesamtbetrag der Zahlungsbeträge (tatsächliche Zahlungsbeträge) der Benutzer in der Gruppe gleich oder größer als der Gruppenzahlungsbetrag ist (zum Beispiel 2000 in einer Gruppe von 5 Personen), geht der Informationsverarbeitungsserver 100 zu S605 weiter. Andernfalls erfüllt der Gesamtbetrag der Zahlungsbeträge (tatsächlicher Zahlungsbetrag) der Benutzer in der Gruppe nicht den Gruppenzahlungsbetrag und somit geht der Prozess zu S602 weiter.
  • In S602 erhöht der Informationsvermittlungsserver 100 einen Zahlungsunfähigkeitszähler, um die Anzahl der Male zu zählen, die die Zahlungsbeträge des Benutzers in der Gruppe nicht den Gruppenzahlungsbetrag erfüllen, um 1 (es ist hervorzuheben, dass der Zahlungsunfähigkeitszähler auf o initialisiert ist).
  • In S603 bestimmt der Informationsverarbeitungsserver 100, ob der Zahlungsunfähigkeitszähler gleich oder höher als eine vorbestimmte Anzahl ist. In einem Fall, in dem der Zahlungsunfähigkeitszähler gleich oder höher als die vorbestimmte Anzahl ist, geht der Informationsverarbeitungsserver 100 zu S604 weiter und bestimmt, dass die Zahlung in der gesamten Gruppe nicht fortgesetzt werden kann. Zu diesem Zeitpunkt setzt der Informationsverarbeitungsserver 100 beispielsweise die Flag-Informationen, die angeben, dass die Zahlung in der gesamten Gruppe nicht fortgesetzt werden kann, auf 1. Anders ausgedrückt, führt in einem Fall, in dem die Anzahl der Male der Zahlungsbeträge der Vielzahl von Benutzer als gesamte Gruppe nicht den Gruppenzahlungsbetrag erfüllt, gleich oder größer als die vorbestimmte Anzahl ist, der Informationsverarbeitungsserver 100 einen Prozess des Stoppens der Zahlung für jedes Fälligkeitsdatum von der Vielzahl der Benutzer durch (d. h. diese Verarbeitungsreihe).
  • Andererseits geht in einem Fall, in dem der Zahlungsunfähigkeitszähler kleiner als die bestimmte Anzahl von Malen ist, der Informationsverarbeitungsserver 100 zu S605 weiter und bestimmt, dass die (Fortsetzung von der) Zahlung von der gesamten Gruppe vorgenommen werden kann. Zu diesem Zeitpunkt setzt beispielsweise der Informationsverarbeitungsserver 100 die Flag-Informationen auf o, die angeben, dass die Zahlung in der gesamten Gruppe nicht fortgesetzt werden kann. Danach kehrt der Informationsverarbeitungsserver 100 zur Verarbeitung der Quelle des Aufrufs zurück.
  • [Reihe von Ausführungsschritten des Zahlungsprozesses für jeden Benutzer]
  • Als Nächstes wird eine Reihe von Ausführungsschritten des Zahlungsprozesses für jeden Benutzer mit Bezugnahme auf 7 beschrieben. Ähnlich wie bei dem oben beschriebenen Zahlungsbetrag-Steuerungsprozess wird dieser Prozess durch die CPU 201 des Informationsverarbeitungsservers 100 implementiert, der ein im ROM 202 gespeichertes Programm liest und ausführt. Ein jeder Verarbeitungsschritt wird in Zusammenwirken von beispielsweise den Komponenten in 2 und den Verarbeitungseinheiten in 3 implementiert. Aus Gründen der Einfachheit wird jedoch jeder Verarbeitungsschritt im Ganzen als durch den Informationsverarbeitungsserver 100 ausgeführt beschrieben. Es ist hervorzuheben, dass zur einfacheren Beschreibung in diesem Prozess als ein Beispiel die Verarbeitung für einen Benutzer beschrieben wird. De facto wird der Prozess wiederholt so viele Male aufgerufen, wie die Anzahl der Benutzer, die zu der Gruppe gehören.
  • In S701 subtrahiert (d. h., zahlt zurück) der Informationsverarbeitungsserver 100 den Zuzahlungsbetrag, der von einem anderen Benutzer empfangen wurde, vom Zahlungsbetrag (tatsächlicher Zahlungsbetrag) des Benutzers. Mit Bezugnahme auf 9 entspricht diese Verarbeitung der Berechnung des angenommenen Zahlungsbetrags (zum Beispiel 500 - 100) in einem Fall, in dem das Zahlungsfälligkeitsdatum N ist.
  • Es ist hervorzuheben, dass in diesem Beispiel ein Fall, in dem die Anzahl der Benutzer, an die der Zuzahlungsbetrag zu leisten ist, als Beispiel als 1 beschrieben wird. Jedoch können in einem Fall, in dem eine Vielzahl von Benutzern, an die der Zuzahlungsbetrag leisten ist, Informationen zu den Benutzern, an die der Zuzahlungsbeitrag zu leisten ist, an die Benutzerkommunikationsvorrichtung 103 übertragen werden, und der Benutzer, an die der Zuzahlungsbetrag zu leisten ist, kann in Reaktion auf die Erfassung der Auswahl durch den Benutzer bestimmt werden. Darüber hinaus kann in einem Fall, in dem eine Vielzahl von Benutzern vorliegen, an die der Zuzahlungsbetrag zu leisten ist, den Informationsverarbeitungsserver 100 auswählen, an welche Benutzer die Rückzahlung zu leisten ist. Zum Beispiel kann die Zuzahlung für einen Benutzer mit einer hohen Priorität gemäß einer vorbestimmten Prioritätsreihenfolge geleistet werden, indem zum Beispiel ein Benutzer ausgewählt wird, dem der höchste Zuzahlungsbetrag aus der Vielzahl der Benutzer bereitgestellt wurde.
  • In S702 bestimmt der Informationsverarbeitungsserver 100, ob der Zahlungsbetrag nach der Subtraktion gleich oder größer als ein vorbestimmter Wert ist (hier entsprechend dem persönlichen Zahlungsbetrag). In einem Fall, in dem der Informationsverarbeitungsserver 100 bestimmt, dass der Zahlungsbetrag nach der Subtraktion gleich oder größer als der vorbestimmte Wert ist, geht die Verarbeitung zu S703 weiter und andernfalls geht die Verarbeitung zu S710 weiter.
  • In S703 bestimmt der Informationsverarbeitungsserver 100, ob der Zahlungsbetrag nach der Subtraktion der gleiche wie der vorbestimmte Wert (persönlicher Zahlungsbetrag) ist. In einem Fall, in dem der Zahlungsbetrag nach der Subtraktion der gleiche wie der vorbestimmte Wert (persönlicher Zahlungsbetrag) ist, befindet sich der Zahlungsbetrag nach der Subtraktion in einem Zustand, in dem keine Überzahlung oder kein Fehlbetrag bezüglich des persönlichen Zahlungsbetrags vorliegt, und somit dient der Zahlungsbetrag weder zum Zuzahlen der Zahlung eines anderen Benutzers noch wird er durch die Zahlung eines anderen Benutzers ergänzt. Daher geht die Verarbeitung des Informationsverarbeitungsservers 100 zu S707 weiter. Andererseits kann in einem Fall, in dem der Zahlungsbetrag nach der Subtraktion den vorbestimmten Wert übersteigt, der Informationsverarbeitungsserver 100 eine Zuzahlung für einen anderen Benutzer vornehmen, und somit geht die Verarbeitung zu S704 weiter.
  • In S704 bestimmt der Informationsverarbeitungsserver 100, ob ein anderer Benutzer in der Gruppe vorhanden ist, der eine Zuzahlung benötigt. In einem Fall, in dem der Informationsverarbeitungsserver 100 bestimmt, dass ein anderer Benutzer in der Gruppe vorhanden ist, der eine Zuzahlung benötigt, geht die Verarbeitung zu S705 weiter und andernfalls geht die Verarbeitung zu S706 weiter.
  • Es ist hervorzuheben, dass in diesem Beispiel ein Fall, in dem die Anzahl der Benutzer, die eine Zuzahlung benötigten, 1 ist, als ein Beispiel beschrieben wurde. Jedoch können in einem Fall, in dem eine Vielzahl von Benutzern vorliegen, die eine Zuzahlung benötigen, Informationen zu dem Benutzer, der eine Zuzahlung benötigt, an die Benutzerkommunikationsvorrichtung 103 übertragen werden und der Benutzer, an den die Zuzahlung geleistet wird, kann gemäß dem Erfassen der Auswahl durch den Benutzer bestimmt werden. Weiterhin kann in einem Fall, in dem eine Vielzahl von anderen Benutzern vorhanden sind, die eine Zuzahlung benötigen, der Informationsverarbeitungsserver 100 den Benutzer auswählen, für den eine Zuzahlung gemacht wird. Zum Beispiel kann die Zuzahlung für einen Benutzer mit einer hohen Priorität gemäß einer vorbestimmten Prioritätsreihenfolge geleistet werden, in dem zum Beispiel ein Benutzer ausgewählt wird, der den höchsten Zuzahlungsbetrag aus der Vielzahl der Benutzer benötigt.
  • In S705 stellt der Informationsverarbeitungsserver 100 nach der Subtraktion in S703 den Zuzahlungsbetrag, der für den anderen Benutzer benötigt wird, aus dem Betrag, der den persönlichen Zahlungsbetrag übersteigt, im Zahlungsbetrag bereit. Daher wird der Zuzahlungsbetrag für den anderen Benutzer in dem den persönlichen Zahlungsbetrag übersteigenden Betrag von dem in S701 erhaltenen Zahlungsbetrag subtrahiert.
  • In S706 bestimmt die Informationsverarbeitungseinheit 100 den Zahlungsbetrag nach der Subtraktion als den eigenen Zahlungsbetrag. D. h., der Informationsverarbeitungsserver 100 bestimmt als den angenommenen Zahlungsbetrag des Benutzers einen Betrag, der ein Betrag ist, der durch Subtraktion des Zuzahlungsbetrags erhalten wird und gleich oder größer als der persönliche Zahlungsbetrag ist. Dieser Verarbeitung entspricht, zum Beispiel, dass am Tag N-1 in 8 der angenommene Zahlungsbetrag des ersten Benutzers als 400 bestimmt wird, nachdem der Zuzahlungsbetrag (100) für den zweiten Benutzer subtrahiert wurde.
  • In S707 bestimmt der Informationsverarbeitungsserver 100, ob ein Zuzahlungsbetrag vorliegt, der von einem anderen Benutzer in der Gruppe zurückgezahlt wurde, und in einem Fall, in dem ein zurückgezahlter Zuzahlungsbetrag vorliegt, wird der Zuzahlungsbetrag zu dem in Schritt S706 bestimmten angenommenen Zahlungsbetrag hinzuaddiert. D. h., in einem Fall, in dem ein Zuzahlungsbetrag zurückgezahlt wird, wird der angenommene Zahlungsbetrag des Benutzers, der den Zuzahlungsbetrag bereitgestellt hat, basierend auf dem in S706 bestimmten angenommen Zahlungsbetrag des Benutzers und dem zurückgezahlten Zuzahlungsbetrag bestimmt. Es ist hervorzuheben, dass S707 zwischen S701 und S702 ausgeführt werden kann.
  • Es ist hervorzuheben, dass die Verarbeitung von S707 dem Hinzuaddieren des vom zweiten Benutzer zurückgezahlten Zuzahlungsbetrags zu dem angenommenen Zahlungsbetrag für den ersten Benutzer am Tag N in 8 entspricht.
  • Um eine Zahlung eines persönlichen Zahlungsbetrags oder mehr zu motivieren, können dem Benutzer, dessen kumulierte Summe von angenommenen Zahlungsbeträgen einen Zielwert erreicht hat, zusätzliche Serviceleistungen bereitgestellt werden. D. h., in S708 bestimmt der Informationsverarbeitungsserver 100, ob die bislang kumulierte Summe der angenommenen Zahlungsbeträge des Benutzers (d. h. im Beispiel von 8 die kumulative Summe der angenommenen Zahlungsbeträge für N-3 bis N Tage) gleich oder größer als ein vorbestimmter Zielwert ist. Einem Benutzer, der den vorbestimmten Zielwert erreicht hat, wird zum Beispiel ein Service bereitgestellt, der dem Benutzer ermöglicht, die Zahlung zu beenden und eine Lieferung des Fahrzeugs zu erhalten.
  • In einem Fall, in dem der Informationsverarbeitungsserver 100 bestimmt, dass die kumulative Summe der angenommenen Zahlungsbeträge den vorbestimmten Zielwert übersteigt, geht die Verarbeitung zu S720 weiter. In S720 beendet der Informationsverarbeitungsserver 100 die persönliche Zahlung durch den Benutzer und veranlasst den Benutzer, die Gruppe zu verlassen. D. h., der Benutzer beendet die Zahlung in der Gruppe und die Gruppe hat ein Mitglied weniger. Andererseits kehrt in einem Fall, in dem in S708 bestimmt wird, dass die kumulative Summe der angenommenen Zahlungsbeträge des Benutzers bislang nicht gleich oder größer als der vorbestimmte Zielwert ist, die Verarbeitung zu S504 zurück, das die Aufrufquelle ist.
  • In S71.0 bestimmt der Informationsverarbeitungsserver 100, ob ein anderer Benutzer eine Zuzahlung für die Unterdeckung leisten kann. D. h., in einem Fall, in dem es in S702 als NEIN bestimmt wird, bedeutet dies, dass der Zahlungsbetrag nach der Subtraktion den persönlichen Zahlungsbetrag nicht ausschöpft und somit wird bestimmt, ob ein anderer Benutzer die Zuzahlung leisten kann, um den persönlichen Zahlungsbetrag zu erzielen. In einem Fall, in dem der Informationsverarbeitungsserver 100 bestimmt, dass ein anderer Benutzer eine Zuzahlung für die Unterdeckung leisten kann, geht die Verarbeitung zu S711 weiter und andernfalls geht die Verarbeitung zu S707 ohne weitere Schritte weiter.
  • In S711 bestimmt der Informationsverarbeitungsserver 100 als den angenommenen Zahlungsbetrag einen Betrag, der erhalten wird, wenn der Zuzahlungsbetrag von einem anderen Benutzer für die Unterdeckung des zu verarbeitenden Benutzers bereitgestellt wird. Zu diesem Zeitpunkt wird der ergänzte Zahlungsbetrag dergestalt bestimmt, dass der angenommene Zahlungsbetrag des zu verarbeitenden Benutzers der gleiche wie der persönliche Zahlungsbetrag ist. Auf diese Weise kann der zu verarbeitende Benutzer den persönlichen Zahlungsbetrag ausschöpfen, während der Benutzer, der die Zuzahlung leistet, daran gehindert werden kann, den Zahlungsbetrag unnötig zu kürzen. In dem in 9 dargestellten Beispiel entspricht diese Verarbeitung dem Empfangen einer Zuzahlung vom ersten Benutzer, wenn eine die Unterdeckung im Zahlungsbetrag des zweiten Benutzers an Tag N-1 auftritt. Wenn die Verarbeitung von S711 endet, setzt de Informationsverarbeitungsserver 100 die die Verarbeitung beim oben beschriebenen S707 fort.
  • Wie oben beschrieben, wird in der Zahlungsverwaltung für jeden Benutzer bestimmt, ob der erste Zahlungsbetrag des ersten Benutzers, der den persönlichen Zahlungsbetrag übersteigt (Ja in S702 und Nein in S703) und der zweite Zahlungsbetrag des zweiten Benutzers, der den persönlichen Zahlungsbetrag nicht ausschöpft, in den Informationen des Zahlungsbetrags für jeden Benutzer, der in S502 (Ja in S704) bestimmt wurde, enthalten sind. Dann werden in einem Fall, in dem bestimmt wird, dass der erste Zahlungsbetrag und der zweite Zahlungsbetrag enthalten sind, die Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers so bestimmt, dass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Zahlungsbetrags des ersten Benutzers ergänzt wird (S705) (S707 und S711).
  • Während die Zahlung als eine Gruppe mit einer solchen Operation geleistet wird, selbst wenn der persönliche Zahlungsbetrag an einem spezifischen Zahlungsfälligkeitsdatum nicht erfüllt ist, kann der Benutzer eine Zuzahlung für eine Zahlung von einem anderen Benutzer in der Gruppe erhalten. Darüber hinaus, wenn sein/ihr eigener Zahlungsbetrag den persönlichen Zahlungsbetrag übersteigt, kann der Benutzer die Zahlung eines anderen Benutzers ergänzen, der den persönlichen Zahlungsbetrag nicht ausschöpft. D. h., es ist möglich, für einen Benutzer, der eine schwankende Zahlungsfähigkeit hat, ein Risiko bei der Zahlung weiter zu verringern.
  • Es ist hervorzuheben, dass in der obigen Beschreibung ein Beispiel beschrieben wurde, in dem dem Benutzer das Fahrzeug geliehen wird, den Zahlungsbetrag ansammelt, während die Mietkosten bezahlt werden und die Lieferung des Leihfahrzeugs erhält, wenn der angesammelte Zahlungsbetrag den Zielbetrag erreicht. Die vorliegende Erfindung ist jedoch nicht auf das Beispiel des Erhaltens der Lieferung des Fahrzeugs beschränkt. D. h. andere Produkte als das Fahrzeug können ein Ziel sein. Weiterhin ist der zusätzliche Service nicht auf die Lieferung des geliehenen Produkts beschränkt und ein weiterer Service, wie eine Lieferung eines Produkts, das sich von dem geliehenen Produkt unterscheidet oder die Bereitstellung einer Einheit (Punkt), die einen wirtschaftlichen Wert hat, können vorgesehen werden. Darüber hinaus ist die vorliegende Erfindung nicht auf einen Fall beschränkt, in dem ein Produkt ausgeliehen wird und es kann auch auf eine Zahlung eines Darlehens angewendet werden, bei dem eine gewisse Zahlung an jedem vorbestimmten Fälligkeitsdatum geleistet wird.
  • In der oben beschriebenen Ausführungsformen bestimmt der Informationsverarbeitungsserver 100 in S708, ob die bislang kumulative Summe der angenommenen Zahlungsbeträge des Benutzers (d. h. im Beispiel von 8, die kumulative Summe der tatsächlichen Zahlungsbeträge von Tag N-3 bis N) gleich oder höher als der vorbestimmte Zielwert ist. Es kann jedoch bestimmt werden, ob das Ergebnis, das erhalten wird, wenn die kumulative Summe der angenommenen Zahlungsbeträge hinzuaddiert wird, wobei der Zuzahlungsbetrag, der vorgesehen wurde, um die Zahlung eines anderen Benutzers zu ergänzen, aber noch nicht zurückgezahlt wurde, gleich oder größer als der Zielwert ist. Auf diese Weise kann das Ziel schneller basierend auf dem Geldbetrag, den der Benutzer bereits gezahlt hat, erreicht werden. Darüber hinaus kann bestimmt werden, ob das Ergebnis, das erhalten wird, wenn der Zuzahlungsbetrag, der aus der Zahlung eines anderen Benutzers bereitgestellt wurde und noch nicht zurückgezahlt wurde, von der kumulativen Summe der tatsächlichen Zahlungsbeträge subtrahiert wird, gleich oder größer als der Zielwert ist. Auf diese Weise ist es möglich, die Rückzahlung des Zuzahlungsbetrags, der aus der Zahlung eines anderen Benutzers bereitgestellt wird, zu motivieren. Anders ausgedrückt, es kann bestimmt werden, ob die kumulative Summe der tatsächlichen Zahlungsbeträge gleich oder größer als der vorbestimmte Zielwert ist.
  • <Zusammenfassung der Ausführungsformen>
    • 1. Der Informationsverwaltungsserver gemäß der obigen Ausführungsform ist ein Informationsverarbeitungsserver (zum Beispiel 100), der eine periodische Zahlung einer Vielzahl von Benutzern, die zu einer Gruppe gehören, verwaltet, wobei der Server aufweist:
      • eine Festlegungseinheit, (zum Beispiel 304, S501) die einen vorbestimmten persönlichen Betrag, der an einem vorbestimmten Fälligkeitsdatum von einem jeden der Vielzahl der Benutzer zu zahlen ist, festgelegt,
      • eine Erfassungseinheit (zum Beispiel 304, S502), die Informationen erfasst, die die Zahlungsbeträge angeben, die jeweils von der Vielzahl der Benutzer für ein jedes vorbestimmte Fälligkeitsdatum genannt werden, und
      • eine Bestimmungseinheit (zum Beispiel 304, S706, S711), die in einem Fall, in dem die von der Erfassungseinheit erfassten Informationen einen ersten Zahlungsbetrag eines ersten Benutzers aufweisen, der den vorbestimmten persönlichen Betrag übersteigt, und einen zweiten Zahlungsbetrag eines zweiten Benutzers, der den vorbestimmten Zahlungsbetrag nicht ausschöpft, die angenommenen Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers bestimmt, sodass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Zahlungsbetrag des ersten Benutzers ergänzt wird.
  • Gemäß dieser Ausführungsform ist es möglich, eine Risiko bei der Zahlung für einen Benutzer, der eine schwankende Zahlungsfähigkeit hat, weiter zu verringern.
  • 2. Im Informationsverarbeitungsserver der vorliegenden Ausführungsform,
    nimmt die Bestimmungseinheit eine Zuzahlung für den zweiten Zahlungsbetrag des zweiten Benutzers dergestalt vor, dass ein Betrag, der als der angegebene Zahlungsbetrag des zweiten Benutzers bestimmt wird, der gleiche wie der vorbestimmte persönliche Betrag (zum Beispiel S711) ist.
  • Gemäß dieser Ausführungsform kann ein Benutzer, der eine Zahlung macht, die den vorbestimmten persönlichen Betrag nicht ausschöpft, den persönlichen Zahlungsbetrag ausschöpfen, während ein Benutzer, der die Zuzahlung macht, gehindert werden kann, den Zahlungsbetrag unnötig zu verringern.
  • 3. Im Informationsverarbeitungsserver der vorliegenden Ausführungsform,
    bestimmt die Bestimmungseinheit einen Betrag, der ein Betrag ist, der durch Subtraktion des als Zuzahlung verwendeten Teils erhalten wird und gleich oder größer als der vorbestimmte persönliche Betrag ist, als angenommenen Zahlungsbetrag des ersten Benutzers (zum Beispiel S706).
  • Gemäß dieser Ausführungsform kann der Benutzer, der die Zuzahlung leistet, einen Betrag, der den vorbestimmten persönlichen Betrag übersteigt, als seine/ihre eigene Bezahlung ansammeln, und somit kann der Zielwert schnell erreicht werden.
  • 4. Im Informationsverarbeitungsserver der vorliegenden Ausführungsform,
    bestimmt die Bestimmungseinheit den angenommenen Zahlungsbetrag des zweiten Benutzers, indem der als die Zuzahlung für den zweiten Benutzer verwendete Teil subtrahiert wird, um den Teil, der als Zuzahlung für den zweiten Benutzer verwendet wird, dem ersten Benutzer gemäß dem zweiten Zahlungsbetrag, der von dem zweiten Benutzer genannt wird, an einem nächsten vorbestimmten Fälligkeitsdatum zurückzuzahlen (zum Beispiel S701).
  • Gemäß dieser Ausführungsform wird der ergänzte Zahlungsbetrag zurückgezahlt und somit ist es möglich, ein Gefühl des Widerstands, um eine Zuzahlung für einen anderen Benutzer in der Gruppe zu leisten, zu verringern.
  • 5. Im Informationsverarbeitungsserver der obigen Ausführungsform,
    bestimmt in einem Fall, in dem der als die Zuzahlung für den zweiten Benutzer verwendete Teil vom zweiten Benutzer an den ersten Benutzer am nächsten vorbestimmten Fälligkeitsdatum zurückgezahlt wird, die Bestimmungseinheit den angenommenen Zahlungsbetrag des ersten Benutzers basierend auf dem ersten Zahlungsbetrag des ersten Benutzers und dem vom zweiten Benutzer zurückgezahlten Teil (zum Beispiel S707).
  • Gemäß dieser Ausführungsform kann der Benutzer, der die Zuzahlung leistet, das Ergebnis, das erhalten wird, wenn sein/ihr eigener angenommener Zahlungsbetrag zu dem Rückzahlungsbetrag hinzuaddiert wird, ansammeln und somit kann der Zielwert schnell erreicht werden.
  • 6. Im Informationsverarbeitungsserver der obigen Ausführungsform,
    ist die Festlegungseinheit weiterhin dazu ausgelegt, einen vorbestimmten Betrag für eine Gruppe festzulegen, der an jedem vorbestimmten Fälligkeitsdatum von der Vielzahl von Benutzern als gesamte Gruppe (zum Beispiel S305 und S501) zu zahlen ist, wobei der Server weiterhin aufweist:
    • eine Stoppeinheit (zum Beispiel 305, S604), die in einem Fall, in dem die Anzahl der Male, die ein Zahlungsbetrag der gesamten Gruppe der Vielzahl von Benutzern nicht ausschöpft, dass der vorbestimmte Betrag für die Gruppe gleich oder größer als eine vorbestimmte Zahl ist, die an jedem vorbestimmten Fälligkeitsdatum von der Vielzahl der Benutzer vorgenommene Zahlung gestoppt.
  • Gemäß dieser Ausführungsform ist es möglich, wenn die Zahlungsfähigkeit der gesamten Gruppe niedrig ist, die Zahlung der Gruppe zu stoppen und den Verlust des Serviceanbieters zu verringern.
  • 7. Im Informationsverarbeitungsserver der obigen Ausführungsform,
    ändert die Festlegungseinheit den vorbestimmten Betrag für die Gruppe basierend auf der Anzahl der neuen Benutzer und dem vorbestimmten persönlichen Betrag gemäß einer Erhöhung oder einer Verringerung der Anzahl der Vielzahl von Benutzern.
  • Gemäß dieser Ausführungsform ist es möglich, die Zahlungsfähigkeit der gesamten Gruppe in Reaktion auf eine Erhöhung oder eine Verringerung der Anzahl der Benutzer zu verwalten.
  • Die Erfindung ist nicht auf die obigen Ausführungsform beschränkt und verschiedene Variationen/Änderungen sind innerhalb des Geistes der Erfindung möglich.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • JP 6518824 [0003]

Claims (10)

  1. Informationsverarbeitungsserver, der eine periodische Zahlung einer Vielzahl von Benutzern, die zu einer Gruppen gehören, verwaltet, wobei der Server dadurch gekennzeichnet ist, dass er aufweist: eine Festlegungseinheit, die einen vorbestimmten persönlichen Betrag, der an einem vorbestimmten Fälligkeitsdatum von einem jeden der Vielzahl der Benutzer zu zahlen ist, festlegt; eine Erfassungseinheit, die Informationen erfasst, die die Zahlungsbeträge angeben die jeweils von der Vielzahl der Benutzer für jedes vorbestimmte Fälligkeitsdatum genannt werden; und eine Bestimmungseinheit, die in einem Fall, in dem die von der Erfassungseinheit erfassten Informationen einen ersten Zahlungsbetrag des ersten Benutzers aufweisen, der den vorbestimmten persönlichen Betrag übersteigt, und einen zweiten Zahlungsbetrag eines zweiten Benutzers, der den vorbestimmten Zahlungsbetrag nicht ausschöpft, genau nach Sie, die angenommenen Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers bestimmt, sodass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Zahlungsbetrags des ersten Benutzers ergänzt wird.
  2. Informationsbereitstellungsvorrichtung nach Anspruch 1, dadurch gekennzeichnet, dass die Bestimmungseinheit eine Zuzahlung für den zweiten Zahlungsbetrag des zweiten Benutzers dergestalt vornimmt, dass ein Betrag, der als der angegebene Zahlungsbetrag des zweiten Benutzers bestimmt wird, der gleiche wie der vorbestimmte persönliche Betrag ist.
  3. Informationsverarbeitungsserver nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Bestimmungseinheit einen Betrag, der ein Betrag ist, der durch Subtraktion des als Zuzahlung verwendeten Teils erhalten wird und gleich oder größer als der vorbestimmte persönliche Betrag ist, als den angenommenen Zahlungsbetrag des ersten Benutzers bestimmt.
  4. Informationsverarbeitungsserver nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Bestimmungseinheit den angenommenen Zahlungsbetrag des zweiten Benutzers bestimmt, indem der als die Zuzahlung für den zweiten Benutzer verwendete Teil subtrahiert wird, um den Teil, der als Zuzahlung für den zweiten Benutzer verwendet wird, dem ersten Benutzer gemäß dem zweiten Zahlungsbetrag, der von dem zweiten Benutzer genannt wird, an einem nächsten vorbestimmten Fälligkeitsdatum zurückzuzahlen.
  5. Informationsverarbeitungsserver nach Anspruch 4, dadurch gekennzeichnet, dass in einem Fall, in dem der als die Zuzahlung für den zweiten Benutzer verwendete Teil vom zweiten Benutzer an den ersten Benutzer am nächsten vorbestimmten Fälligkeitsdatum zurückgezahlt wird, die Bestimmungseinheit den angenommenen Zahlungsbetrag des ersten Benutzers basierend auf dem ersten Zahlungsbetrag des ersten Benutzers und dem vom zweiten Benutzer zurückgezahlten Teil bestimmt.
  6. Informationsverarbeitungsserver nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die Festlegungseinheit weiterhin dazu ausgelegt ist, einen vorbestimmten Betrag für eine Gruppe festzulegen, der an jedem vorbestimmten Fälligkeitsdatum von der Vielzahl von Benutzern als gesamte Gruppe zu zahlen ist, wobei der Server weiterhin aufweist: eine Stoppeinheit, die in einem Fall, in dem die Anzahl der Male eines Zahlungsbetrags der gesamten Gruppe der Vielzahl von Benutzern nicht ausschöpft, dass der vorbestimmte Betrag für die Gruppe gleich oder größer als eine vorbestimmte Zahl ist, die Zahlung, die an einem jeden vorbestimmten Fälligkeitsdatum von der Vielzahl der Benutzer vorgenommen wird, stoppt.
  7. Informationsverarbeitungsserver nach Anspruch 6, dadurch gekennzeichnet, dass die Festlegungseinheit den vorbestimmten Betrag für die Gruppe basierend auf der Anzahl von neuen Benutzern und dem vorbestimmten persönlichen Betrag gemäß einer Erhöhung oder einer Verringerung der Anzahl der Vielzahl von Benutzern ändert.
  8. Informationsverarbeitungsverfahren, das in einem Informationsverarbeitungsserver ausgeführt wird, der eine persönliche Zahlung einer Vielzahl von Benutzern, die zu einer Gruppen gehören, verwaltet, wobei das Verfahren dadurch gekennzeichnet ist, dass es aufweist: Festlegen eines vorbestimmten persönlichen Betrags, der an einem vorbestimmten Fälligkeitsdatum von einem jeden von der Vielzahl der Benutzer zu zahlen ist; Erfassen von Informationen, die die Zahlungsbeträge angeben, die jeweils von der Vielzahl der Benutzer für jedes vorbestimmte Fälligkeitsdatum genannt werden; und Bestimmen in einem Fall, in dem die von der Erfassungseinheit erfassten Informationen einen ersten Zahlungsbetrag eines ersten Benutzers aufweisen, der den vorbestimmten persönlichen Betrag übersteigt, und einen zweiten Zahlungsbetrag eines zweiten Benutzers, der den vorbestimmten Zahlungsbetrag nicht ausschöpft, die angenommenen Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers, sodass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Zahlungsbetrag des ersten Benutzers ergänzt wird.
  9. Programm, um einen Informationsverarbeitungsserver, der eine periodische Zahlung einer Vielzahl von Benutzern, die zu einer Gruppe gehören, verwaltet, zu veranlassen, um einen jeden Schritt eines Informationsverarbeitungsverfahrens auszuführen, wobei das Verfahren dadurch gekennzeichnet ist, dass es aufweist: Festlegen eines vorbestimmten persönlichen Betrags, der an einem vorbestimmten Fälligkeitsdatum von einem jeden der Vielzahl der Benutzer zu zahlen ist; Erfassen von Informationen, die die Zahlungsbeträge angeben, die jeweils von der Vielzahl der Benutzer für jedes vorbestimmte Fälligkeitsdatum genannt werden; und Bestimmen in einem Fall, in dem die von der Erfassungseinheit erfassten Informationen einen ersten Zahlungsbetrag eines ersten Benutzers aufweisen, der den vorbestimmten persönlichen Betrag übersteigt, und einen zweiten Zahlungsbetrag eines zweiten Benutzers, der den vorbestimmten Zahlungsbetrag nicht ausschöpft, die angenommenen Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers, sodass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Zahlungsbetrag des ersten Benutzers ergänzt wird.
  10. Servicebereitstellungs-Unterstützungssystem, das einen Informationsverarbeitungsserver aufweist, der eine periodische Zahlung einer Vielzahl von Benutzern, die zu einer Gruppe gehören, und eine Vielzahl von Kommunikationsvorrichtungen verwaltet, dadurch gekennzeichnet, dass die Vielzahl der Kommunikationsvorrichtungen mit der Vielzahl von Benutzern jeweils verknüpft sind, und der Informationsverarbeitungsserver aufweist eine Festlegungseinheit, die einen vorbestimmten persönlichen Betrag festlegt, der an einem vorbestimmten Fälligkeitsdatum von einem jeden der Vielzahl der Benutzer zu zahlen ist, eine Erfassungseinheit, die Informationen erfasst, die die Zahlungsbeträge angeben, die jeweils von der Vielzahl der Benutzer für jedes vorbestimmte Fälligkeitsdatum genannt werden, und eine Bestimmungseinheit, die in einem Fall, in dem die von der Erfassungseinheit erfassten Informationen einen ersten Zahlungsbetrag eines ersten Benutzers aufweisen, der den vorbestimmten persönlichen Betrag übersteigt, und einen zweiten Zahlungsbetrag eines zweiten Benutzers, der den vorbestimmten Zahlungsbetrag nicht ausschöpft, die angenommenen Zahlungsbeträge des ersten Benutzers und des zweiten Benutzers bestimmt, sodass der zweite Zahlungsbetrag des zweiten Benutzers durch einen Teil des ersten Zahlungsbetrags des ersten Benutzers ergänzt wird.
DE112019007575.6T 2019-08-29 2019-08-29 Informationverarbeitungsserver, Informationverarbeitungsverfahren, Programm und Servicebereitstellungs-Unterstützungssystem Pending DE112019007575T5 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/033957 WO2021038802A1 (ja) 2019-08-29 2019-08-29 情報処理サーバ、情報処理方法、プログラムおよびサービス提供支援システム

Publications (1)

Publication Number Publication Date
DE112019007575T5 true DE112019007575T5 (de) 2022-05-05

Family

ID=74683434

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112019007575.6T Pending DE112019007575T5 (de) 2019-08-29 2019-08-29 Informationverarbeitungsserver, Informationverarbeitungsverfahren, Programm und Servicebereitstellungs-Unterstützungssystem

Country Status (6)

Country Link
US (1) US20220172185A1 (de)
JP (1) JP7284276B2 (de)
CN (1) CN114245903A (de)
BR (1) BR112022002430A2 (de)
DE (1) DE112019007575T5 (de)
WO (1) WO2021038802A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0218824Y2 (de) 1984-08-02 1990-05-25

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001222605A (ja) * 2000-02-09 2001-08-17 Osaka Gas Co Ltd 価値授受方法、価値計算装置、及び記録媒体
JP2002230308A (ja) * 2001-02-05 2002-08-16 Hamagin System Service Kk 資金管理装置、資金管理方法、及び、プログラム
JP2003180100A (ja) * 2001-12-07 2003-06-27 Norifumi Taro 機能特化通貨を使用した経済運営システム
JP2003271887A (ja) * 2002-03-18 2003-09-26 Mizuho Bank Ltd 資金管理方法及び資金管理プログラム
US20130046679A1 (en) * 2005-05-06 2013-02-21 Caringfamily, Llc Joint payment
US20080162349A1 (en) * 2006-12-22 2008-07-03 PRATT John Method of collecting money or resources from a group of contributors
US20090070255A1 (en) * 2007-09-07 2009-03-12 Durga Ramana Muktevi Social lending and borrowing in virtual financial community
US20100078472A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Group peer-to-peer financial transactions
TWI389049B (zh) * 2009-03-11 2013-03-11 Shacom Com Inc 網路直接金融的方法與系統
US20140019334A1 (en) * 2009-04-07 2014-01-16 Luis Antonio Cervera Method to Facilitate Credit and Savings
US20110060639A1 (en) * 2009-09-09 2011-03-10 Alfredo Garcia Method for financing the acquisition of an asset for members of a group
WO2012037404A2 (en) * 2010-09-15 2012-03-22 TIO Networks Corporation Brokered bill payment
US20120173396A1 (en) * 2010-12-30 2012-07-05 Paydivvy, Inc. Bill division and group payment systems and methods
US20140108235A1 (en) * 2012-10-16 2014-04-17 American Express Travel Related Services Company, Inc. Systems and Methods for Payment Settlement
TWI498841B (zh) * 2013-10-03 2015-09-01 Efficient method of network labeling
US20150149344A1 (en) * 2013-11-26 2015-05-28 International Business Machines Corporation Synchronous split payment transaction management
US20160027106A1 (en) * 2014-07-24 2016-01-28 Rosca Finance Llc Computer-based peer-to-peer rotating savings and lending allowing for a revolver-type credit system and method
US20170193477A1 (en) * 2015-11-23 2017-07-06 BillHero, Inc. Bill payment infrastructure for bill splittees
US20170185976A1 (en) * 2015-12-28 2017-06-29 Mastercard International Incorporated Methods, systems, and computer readable media for an electronic infrastructure for a rotating savings and credit association
WO2018020387A1 (en) * 2016-07-29 2018-02-01 Tcg Methods and systems for a community-based mobile savings and lending platform
US20180108011A1 (en) * 2016-10-19 2018-04-19 Mastercard International Incorporated Method and system for a virtual payment card funded by multiple sources
US20200258158A1 (en) * 2019-02-07 2020-08-13 Sou Sou Investment Solutions, LLC System and method for providing virtual social banking networks by a platform utilizing artificial intelligence and blockchain technology
SG10201905292WA (en) * 2019-06-11 2021-01-28 Mastercard International Inc Method and system for facilitating transactions
US20230098217A1 (en) * 2019-08-13 2023-03-30 Splitcart Llc Co-purchasing system & method

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0218824Y2 (de) 1984-08-02 1990-05-25

Also Published As

Publication number Publication date
JP7284276B2 (ja) 2023-05-30
US20220172185A1 (en) 2022-06-02
JPWO2021038802A1 (de) 2021-03-04
WO2021038802A1 (ja) 2021-03-04
BR112022002430A2 (pt) 2022-05-03
CN114245903A (zh) 2022-03-25

Similar Documents

Publication Publication Date Title
DE69423218T4 (de) Datensammlungs- und wiederauffindungssystem mit einem abrechnungsmeter
DE69615074T2 (de) System und Verfahren zur Kontrolle der Zahl von Teileinheiten in einem Inventar
US8719135B2 (en) Real-time insurance estimate based on non-personal identifying information
DE10056278B4 (de) Verfahren und System zum Kommunizieren zwischen einem Lieferanten - und Kundengeräten
EP2476087B1 (de) Bezahlsystem, einkaufssystem und verfahren zum durchführen einer vielzahl von bezahlvorgängen
DE202008018372U1 (de) System zum Verfolgen der Reaktion auf Anzeigen
DE60004766T2 (de) Verfahren zur dynamischen zeitplanung von publikationen in einem automatisierten dokumentenausgabesystem
DE112016005473T5 (de) Verfahren zur standortbezogenen Werbung und System dafür
DE10156363A1 (de) Drahtloses Bord-Transaktionssystem und- Verfahren
DE102015111671A1 (de) Verfahren und Gerät zum Bestimmen von relativen Fahreigenschaften unter Verwendung von partizipativen Messsystemen
DE112005003452T5 (de) Dienstleistungssystem oder Dienstleistungsverfahren zum Bereitstellen von verschiedenartigen Diensten, einschliesslich der Diagnose eines mobilen Körpers, und tragbares Informationsgerät das für das System verwendet wird
DE112005003451T5 (de) Dienstleistungssystem oder Dienstleistungsverfahren zum Bereitstellen von verschiedenartigen Diensten, einschliesslich der Diagnose eines mobilen Körpers, und tragbares Informationsgerät für das System
DE69424218T2 (de) Vorrichtung zum Herstellen von kristallisiertem Glas
DE102017222263A1 (de) System und Verfahren zur Umsetzung eines Nachfragereaktionsereignisses mit variablen Boni für Fahrzeuge
WO2023160917A1 (de) Verfahren zur prägung und nutzung fahrzeugbezogener non-fungible-tokens und informationstechnisches system
DE102008050302A1 (de) Verfahren und System um Verkäufern Zugang zu ausgewählten Verbrauchern bereitzustellen
EP3073423A1 (de) Vorrichtung, verfahren und computerprogramm zum erstellen einer zeitlichen abfolge von aktivitäten eines nutzers
WO2006117043A1 (de) Datenverarbeitungsverfahren zur zeitlich optimalen berechnung grosser ergebnisdatensätze
DE69110930T2 (de) Verwaltungssystem mit Informationsträgern für Autoparkgebühren.
DE212017000034U1 (de) Computersystem zum Bestimmen von Prämiensätzen und Ermässigungen sowie Speicher dafür
DE112019007575T5 (de) Informationverarbeitungsserver, Informationverarbeitungsverfahren, Programm und Servicebereitstellungs-Unterstützungssystem
WO2005109359A1 (de) Elektronisches zahlungssystem mit digitalen geldeinheiten
DE102015210776A1 (de) Datenverknüpfungsunterstützungssystem und Datenverknüpfungsunterstützungsverfahren
EP2120197A1 (de) Verfahren und System zum elektronischen Erzeugen personenbezogener Preiswerte und/oder Bonuswerte
DE112019007571T5 (de) Informationsverarbeitungsserver, Informationsverarbeitungsverfahren, Programm und Dienstbereitstellungsunterstützungssystem

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R084 Declaration of willingness to licence