JP7438916B2 - 情報作成方法、及びコンピュータプログラム - Google Patents

Description

本発明は、サービス又は商品の料金の決済に必要な取引情報を作成する情報作成方法、及びコンピュータプログラムに関する。

近距離無線通信により識別情報を通信して、サービス又は商品の料金の決済を可能とする非接触ＩＣチップを用いた電子マネーが普及している。また、二次元バーコードをカメラで撮影するという容易な操作により、利用者の銀行口座又はクレジットカードで決済を完了する決済サービスも普及している（特許文献１等）。このような電子マネー及び決済サービスによりキャッシュレス化が進んでいる。

特開２００７－３２８５４９号公報

キャッシュレス決済では依然として費用の支払者はサービス又は商品を享受する利用者個人であることが前提であり、銀行口座又はクレジットカードとの紐づけに基づいて決済される。

しかしながら、サービス又は商品の利用は、個人的な目的には限られない。公共交通機関を利用した移動は、業務上の利用が多くの割合を占めている。この場合、上述したような普及しているキャッシュ決済を利用すると、利用者が所属している組織の経理部門との間での精算処理が必要になり煩雑であるから、結局利用者は現金で支払い、利用の証明書となる領収書等を用いて事後的に清算処理を行なう。

本発明は、利用者がサービス又は商品の内容、提供者及び支払者を決定してから取引を開始する取引のみならず、支払者が確定してから利用者及び提供者を決定する取引、提供者が確定してから利用者及び支払者が確定する取引も実現するプラットフォームをユーザが利用可能となる情報作成方法、及びコンピュータプログラムを提供することを目的とする。

本開示の一実施形態の情報作成方法は、サービス又は商品の対価の決済に必要となる取引情報を作成する情報作成方法であって、サービス又は商品の内容の選択を受け付け、選択されたサービス又は商品の提供を条件として取引情報の起票のリクエストを送信し、前記条件に応じる前記サービス又は商品の提供者の提供者識別情報、及び、前記対価を支払う支払者の支払者識別情報のリストと、前記提供者識別情報及び支払者識別情報の選択、及び前記サービス又は商品に係る対価の支払いを前記支払者における経費処理とするか又は利用者の個人負担とするかの選択を受け付ける画面とを含む検索画面を表示する。

本開示の一実施形態のコンピュータプログラムは、表示部を備えるコンピュータに、サービス又は商品の対価の決済に必要となる取引情報の情報を表示させるコンピュータプログラムであって、前記コンピュータに、サービス又は商品の内容の選択を受け付け、選択されたサービス又は商品の提供を条件として取引情報の起票のリクエストを送信し、前記条件に応じる前記サービス又は商品の提供者の提供者識別情報、及び、前記対価を支払う支払者の支払者識別情報のリストと、前記提供者識別情報及び支払者識別情報の選択、及び前記サービス又は商品に係る対価の支払いを前記支払者における経費処理とするか又は利用者の個人負担とするかの選択を受け付ける画面とを含む検索画面を表示する処理を実行させる。

本開示の情報作成方法、及びコンピュータプログラムでは、決済、経費処理の根拠となる取引情報は、この取引情報に含まれる前記内容特定情報、対価情報、提供者識別情報、利用者識別情報、及び支払者識別情報の内のいずれか１つでも決定されると起票され、サービス又は商品の利用を開始可能である。取引情報に含まれるべき前記内容特定情報、対価情報、提供者識別情報、利用者識別情報、及び支払者識別情報は、逐次追加されて作成され、決済、経費処理が可能になる。

サービス又は商品の内容、対価、利用者、提供者、及び支払者の内のいずれか１つが決定されて起票された取引情報を、サービス又は商品の内容等の属性で検索することが可能になる。男性のみ、女性のみ、飲食のみ、特定の地域のみ等の属性で取引情報を検索し、利用者は、利用者が決まっていない取引情報を容易に見つけて利用することができるし、提供者も、提供者が決まっていない取引情報を容易に見つけることができる。

取引情報の起票のリクエストを、サービス又は商品の内容と、提供者、利用者、支払者のいずれかと、経費処理及び個人負担のいずれを選択するかとを含む条件と共に送信することができる。

利用者がサービス又は商品の内容、提供者及び支払者を決定してから取引を開始する取引の形のみならず、支払者が確定してから利用者及び提供者を募集する取引、提供者が確定してから利用者及び支払者を募集する取引等、新たな取引の形を実現することが可能である。

１つの提供者から提供されるサービス又は商品を複数の利用者が享受する場合でも夫々に取引情報が起票され、順次提供が完了して料金が確定するとそれぞれの取引情報が完成し、サービス提供の事実が確定してから、決済、経費処理が可能になる。

本開示におけるプラットフォームでは、利用者、提供者及び支払者の内の２つが定まっていない段階で決済、経費処理の根拠となる取引情報を作成してサービス又は商品の利用を可能とする。決済、経費処理の元となる情報は、利用の進行状況に合わせて利用者、提供者及び支払者の全ての情報が順次確定されて完成する。これにより、キャッシュレス決済を個人及び経費の両方で利用することができる。実際に提供が完了したサービス又は商品の内容及び利用された事実に基づいて情報が完成されるので、同一のサービスを複数の利用者で利用した場合（相乗り、相席等）にも各々の利用者が享受したサービスに基づく料金の確定及び支払が実現される。

情報作成システムの概要を示す図である。 情報作成システムの利用者端末装置の構成を示すブロック図である。 情報作成システムの提供者端末装置の構成を示すブロック図である。 情報作成システムの支払者端末装置の構成を示すブロック図である。 情報作成装置の構成を示すブロック図である。 利用者ＤＢに記憶される情報の内容例を示す図である。 提供者ＤＢに記憶される情報の内容例を示す図である。 支払者ＤＢに記憶される情報の内容例を示す図である。 帳票ＤＢに記憶される情報の内容例を示す図である。 募集条件ＤＢに記憶される情報の内容例を示す図である。 情報作成装置における処理手順の一例を示すフローチャートである。 利用者端末装置にて表示される画面の一例を示す。 利用者端末装置にて表示される画面の一例を示す。 利用者端末装置からのリクエストに基づいてデジタル帳票が完成までのシーケンスを示す図である。 デジタル帳票が完成していく過程の示す概要図である。 提供者端末装置にて表示される画面の一例を示す。 提供者端末装置にて表示される画面の一例を示す。 利用者への応募の通知画面の内容例を示す図である。 利用者端末装置にて表示されるデジタルチケットの一例を示す。 デジタルチケットの内容例を示す図である。 提供者端末装置からのリクエストに基づいてデジタル帳票が完成までのシーケンスを示す図である。 第２のケースにおけるデジタル帳票の概要図である。 利用者端末装置にて表示される画面の一例を示す。 提供者端末装置にて表示される画面例を示す図である。 利用者端末装置にて表示される画面例を示す図である。 第３のケースにおけるデジタル帳票の概要図である。 実施の形態２における利用者端末装置で表示される検索画面の内容例を示す。 タクシーの相乗りを実現するデジタル帳票に関する処理手順の一例を示すシーケンス図である。 タクシーの相乗りを実現するデジタル帳票に関する処理手順の一例を示すシーケンス図である。 タクシーの相乗りを実現するデジタル帳票に関する処理手順の一例を示すシーケンス図である。 実施の形態２において提供者端末装置で表示される検索画面の内容例を示す。 実施の形態３において提供者端末装置に表示される画面の一例を示す。 実施の形態３において利用者端末装置に表示される画面の一例を示す。 実施の形態４において支払者端末装置に表示される画面の一例を示す。 実施の形態４において利用者端末装置に表示される画面の一例を示す。

本開示をその実施の形態を示す図面を参照して具体的に説明する。以下の実施の形態では、本開示の情報作成方法を適用した情報作成システムについて説明する。

（実施の形態１）
図１は、情報作成システム１００の概要を示す図である。情報作成システム１００は、サービス又は商品の利用者と、サービス又は商品を提供する提供者と、サービス又は商品の利用に必要な料金を支払う支払者との間での料金の決済、支払者における経費処理に必要な取引情報を作成するシステムである。

情報作成システム１００は、利用者が実際にサービス又は商品をキャッシュレスで享受でき、実際の利用に則した料金が確定した場合には支払者から提供者へ支障なく料金が支払われる仕組みを実現するプラットフォームを提供する。本開示のプラットフォームでは、決済、又は経費処理の根拠とすることができる取引情報として、デジタル帳票ＤＦを用いる。

本開示のプラットフォームでは、１つ１つの取引に対してデジタル帳票ＤＦが起票され、起票されたデジタル帳票ＤＦを元にデジタルチケットが発行されて利用者によって利用可能となる。本開示のプラットフォームは、サービス又は商品の内容は、デジタル帳票ＤＦが起票された後に決定することを許容し、支払者として利用者自身のみならず、利用者の雇用者、利用者のスポンサーであることを許容する。

本開示のプラットフォームでは、利用者、提供者、又は支払者のいずれか１つから、サービス（商品）を受けたい、サービス（商品）のユーザを募集しているといったリクエストを受け付ける。プラットフォームは、リクエストにマッチするサービス提供者、支払者、又は利用者等を募集し、利用者、提供者及び支払者の情報及び料金が確定した場合に、支払者から提供者への料金の支払いが実行されることを保証する。決済サービスは別途異なるシステムであってよく、本開示のプラットフォームは、決済サービスが使用する支払の根拠となるデジタル帳票ＤＦを作成する。プラットフォームにおいて支払者は、料金が確定した場合に、利用者が確実にサービス又は商品を享受したかを確認した上で料金を提供者へ支払うことが可能である。提供者は、利用者自身又は利用者の雇用者等である支払者から料金を確実に回収することができる。利用者はキャッシュレスでサービス又は商品を享受できる。

利用者、提供者、及び支払者は夫々、このようにキャッシュレス及び確実な支払を実現するプラットフォームを利用するために、コンピュータプログラムを自身のコンピュータにインストールし、プラットフォーム事業者と契約する。プラットフォーム事業者との契約で発行されるアカウントの種別によって、このコンピュータプログラムを使用する利用者、提供者及び支払者のコンピュータは夫々、利用者端末装置１、提供者端末装置２、及び、支払者端末装置３となる。

本開示のプラットフォームによって提供される機能は具体的には、利用者端末装置１、提供者端末装置２、及び支払者端末装置３が通信接続可能なサーバとして機能するコンピュータである情報作成装置４における処理によって実現される。

ネットワークＮは、所謂インターネットである公衆通信網Ｎ１と、所定の移動通信規格による無線通信を実現するキャリアネットワークＮ２とを含む。公衆通信網Ｎ１にはアクセスポイントＡＰが含まれる。キャリアネットワークＮ２には基地局ＢＳが含まれる。利用者端末装置１、提供者端末装置２、及び支払者端末装置３は夫々、情報作成装置４と公衆通信網Ｎ１又はキャリアネットワークＮ２を介して通信接続が可能である。支払者端末装置３は、専用線を介して情報作成装置４と通信接続が可能であってもよい。

図２は、情報作成システム１００の利用者端末装置１の構成を示すブロック図である。利用者端末装置１は上述したようにスマートフォン等の通信機能を有するコンピュータを用いる。利用者端末装置１は、制御部１０、記憶部１１、通信部１２、表示部１３、操作部１４、読取部１５及び位置情報取得部１６を備える。

制御部１０は、ＣＰＵ（Central Processing Unit ）又はＧＰＵ（Graphics Processing Unit）を用いたプロセッサであり、内蔵するＲＯＭ（Read Only Memory）及びＲＡＭ（Random Access Memory）等のメモリを用い、各構成部を制御して処理を実行する。制御部１０は、プロセッサ、メモリ、記憶部１１及び通信部１２を集積した１つのハードウェア（ＳｏＣ：System On a Chip）として構成されていてもよい。制御部１０は、記憶部１１に記憶されている端末用アプリケーションプログラム１Ｐに基づいて情報作成装置４と通信接続が可能であり、後述するサービス利用に係る情報を表示し、操作を受け付ける。

記憶部１１は、フラッシュメモリを用い、端末用アプリケーションプログラム１Ｐを含む制御部１０が参照するプログラム及びデータを記憶する。記憶部１１には、サービスの利用者を識別する利用者ＩＤとなるアカウント情報が記憶されている。制御部１０は、利用者ＩＤに対応するアカウント情報及び端末用アプリケーションプログラム１Ｐに基づき、利用者向けのグラフィカルインタフェースを表示部１３に表示させ、利用者用のアプリケーションとして情報作成装置４と情報を送受信する。

通信部１２は、公衆通信網Ｎ１又はキャリアネットワークＮ２を介した情報作成装置４との無線通信を実現する無線通信モジュールである。通信部１２は例えば、Wi-Fi に対応する無線通信デバイス、又は、キャリア通信用モジュールを用いる。

表示部１３は、液晶パネル又は有機ＥＬディスプレイ等のディスプレイ装置を用いる。操作部１４は、利用者の操作を受け付けるインタフェースであり、物理ボタン、ディスプレイ内蔵のタッチパネルデバイス、スピーカ及びマイクロフォン等を用いる。操作部１４は、物理ボタン又はタッチパネルにて表示部１３で表示している画面上で操作を受け付けてもよいし、マイクロフォンにて入力音声から操作内容を認識し、スピーカで出力する音声との対話形式で操作を受け付けてもよい。

読取部１５は、提供者ＩＤ等のコードを読み取るリーダである。読取部１５は、バーコードリーダ、カメラ、及び無線タグリーダの内の少なくともいずれか１つである。読取部１５は、それらのいずれをも含み、コードの提示態様によっていずれかを選択的に使用してコードを読み取ってもよい。読取部１５は読み取ったコードを制御部１０へ通知する。

位置情報取得部１６は、利用者端末装置１の位置情報を取得するデバイスである。位置情報取得部１６は、ＧＰＳ（Global Positioning System）受信デバイスを用いるか、又は、通信部１２のWi-Fi によって位置情報を特定するデバイスを用いてもよい。

図３は、情報作成システム１００の提供者端末装置２の構成を示すブロック図である。提供者端末装置２は上述したようにタブレット端末等の通信機能を有するコンピュータを用いる。サービスを実際に提供するスタッフではなくサポートスタッフ又は管理者が使用する提供者端末装置２は、デスクトップ、ラップトップ型のパーソナルコンピュータを用いる。

提供者端末装置２は、制御部２０、記憶部２１、通信部２２、表示部２３、操作部２４及び読取部２５を備える。

制御部２０は、ＣＰＵ又はＧＰＵを用いたプロセッサであり、内蔵するＲＯＭ又はＲＡＭ等のメモリを用い、各構成部を制御して処理を実行する。制御部２０は、記憶部２１に記憶されている端末用アプリケーションプログラム２Ｐに基づいて情報作成装置４と通信接続が可能であり、サービス提供に係る情報を表示し、操作を受け付ける。

記憶部２１は、フラッシュメモリを用い端末用アプリケーションプログラム２Ｐを含む制御部２０が参照するプログラム及びデータを記憶する。記憶部２１には、サービス提供者を識別する提供者ＩＤに対応するアカウント情報が記憶されている。記憶部２１は、提供者端末装置２を操作する個別のスタッフを個々に識別する情報を記憶していてもよい。制御部２０は、提供者ＩＤに対応するアカウント情報及び端末用アプリケーションプログラム２Ｐに基づき、提供者向けのグラフィカルインタフェースを表示部２３に表示させ、提供者用のアプリケーションとして情報作成装置４と情報をやり取りする。

通信部２２は、公衆通信網Ｎ１又はキャリアネットワークＮ２を介した情報作成装置４との無線通信を実現する無線通信モジュールである。通信部２２は例えば、Wi-Fi に対応する無線通信デバイス、又は、キャリア通信用モジュールを用いる。

表示部２３は、液晶パネル又は有機ＥＬディスプレイ等のディスプレイ装置を用いる。操作部２４は、サービス提供者の操作を受け付けるインタフェースであり、物理ボタン、ディスプレイ内蔵のタッチパネルデバイス、スピーカ及びマイクロフォン等を用いる。操作部２４は、物理ボタン又はタッチパネルにて表示部２３で表示している画面上で操作を受け付けてもよいし、マイクロフォンにて入力音声から操作内容を認識し、スピーカで出力する音声との対話形式で操作を受け付けてもよい。

読取部２５は、他の機器から情報を読み取るリーダである。読取部２５は、バーコードリーダ、又はカメラであってもよい。読取部２５は、サービスの料金を計算するための他の装置（レジ端末、メータ）と接続されるインタフェースであってもよい。料金は、操作部２４を用いて入力されてもよい。

読取部２５は、後述するように利用者端末装置１から提示された利用者ＩＤを読み取るリーダとして機能してもよい。この場合、読取部２５はバーコードリーダ、カメラ、又は近距離無線通信モジュールであり、サービス又は商品の顧客である利用者の利用者ＩＤを含む情報を取得する。読取部２５は読み取った情報を制御部２０へ通知する。

提供者端末装置２においても、後述するようにタクシー運転手が所持するものである場合、位置情報が取得できることが望ましい。提供者端末装置２は位置情報取得部を備えてもよいし、タクシーメータ、ナビシステムから位置情報を取得できるようにしてもよい。

提供者端末装置２は、サービスがタクシー事業であればタクシーメータ、飲食店であればレジ端末、宿泊業であればチェックインチェックアウトシステムから料金を取得できるようにしてあれば汎用コンピュータに端末用アプリケーションプログラム２Ｐをインストールし、提供者ＩＤを対応付けることで実現される。

図４は、情報作成システム１００の支払者端末装置３の構成を示すブロック図である。支払者端末装置３は上述したように、支払者である企業の経理部門、利用者の上長で決済権利を有する管理者、又はスポンサーとなり得る利用者により使用される。支払者端末装置３は、パーソナルコンピュータ又はサーバコンピュータでもよいし、経理部門のスタッフによって個々に管理されるタブレット端末、スマートフォンであってもよい。

支払者端末装置３は、制御部３０、記憶部３１、通信部３２、表示部３３及び操作部３４を備える。

制御部３０は、ＣＰＵ又はＧＰＵを用いたプロセッサであり、内蔵するＲＯＭ又はＲＡＭ等のメモリを用い、各構成部を制御して処理を実行する。制御部３０は、記憶部３１に記憶されている端末用アプリケーションプログラム３Ｐに基づき、情報作成装置４と通信接続が可能であり、後述する支払承認に関する情報を表示し、操作を受け付ける。

記憶部３１は、ハードディスク又はＳＳＤ（Solid State Drive ）を用いる。記憶部３１は、端末用アプリケーションプログラム３Ｐを含む制御部３０が参照するプログラム及びデータを記憶する。記憶部３１には、支払者を識別する支払者ＩＤとなるアカウント情報が記憶されている。記憶部３１には、図４に示すように、支払者の企業に所属する利用者の利用者ＩＤ、及び利用者の属性を含む利用者情報を含む支払者ＤＢ３０１が記憶されていてもよい。経理部門で使用される支払者端末装置３の支払者ＤＢ３０１には、決済が完了した経費情報が含まれてもよい。

制御部３０は、記憶部３１に記憶されている支払者ＩＤに対応するアカウント情報及び端末用アプリケーションプログラム３Ｐに基づき、支払者向けのグラフィカルインタフェースを表示部３３に表示させ、支払者用のアプリケーションとして情報作成装置４と情報をやり取りする。

通信部３２は、情報作成装置４との通信接続を実現するネットワークカードである。支払者端末装置３は、公衆通信網Ｎ３を介して情報作成装置４に通信接続してもよいし、専用線を介して情報作成装置４に通信接続してもよい。

表示部３３は、液晶パネル又は有機ＥＬディスプレイ等のディスプレイ装置を用いる。操作部３４は、企業の経理部門のスタッフの操作を受け付けるインタフェースであり、キーボード及びポインティングデバイスを用いる。操作部３４は、スピーカ及びマイクロフォン等を用い、マイクロフォンにて入力音声から操作内容を認識し、スピーカで出力する音声との対話形式で操作を受け付けてもよい。

端末用アプリケーションプログラム１Ｐ，２Ｐ，３Ｐは、コンピュータの種別（ラップトップ、デスクトップか、スマートフォン又はタブレット端末か）に対しては異なるが、機能は共通するアプリケーションプログラムである。利用者端末装置１の記憶部１１に利用者ＩＤに対応するアカウント情報のみならず、プラットフォーム事業者との契約の上で支払者ＩＤに対応するアカウント情報も記憶されている場合、利用者端末装置１は、支払者端末装置３にもなり得る。即ち利用者はアカウントの切り替えによって、上長の承認者即ち支払者権限で振る舞うことも可能である。同様にして利用者端末装置１は、提供者端末装置２にも切り替わることが可能である。勿論、端末用アプリケーションプログラム１Ｐ，２Ｐ，３Ｐは、利用者向け、サービス提供者向け、及び支払者向けに夫々特化したコンピュータプログラムとして提供されてもよい。

図５は、情報作成装置４の構成を示すブロック図である。情報作成装置４は上述したように、サーバコンピュータを用いる。実施の形態１において以下では、情報作成装置４は１台のサーバコンピュータとして説明するが、複数のサーバコンピュータで機能又は処理を分散させてもよい。

情報作成装置４は、制御部４０、記憶部４１、通信部４２及び入出力部４４を備える。制御部４０は、ＣＰＵ又はＧＰＵを用いたプロセッサであり、内蔵するメモリを用いて各構成部を制御して処理を実行する。制御部４０は、記憶部４１に記憶されている情報処理プログラム４Ｐに基づく情報処理を実行する。

記憶部４１は、ハードディスク又はＳＳＤを用いる。記憶部４１は、情報処理プログラム４Ｐを記憶しているほか、制御部４０が参照する他のプログラム及びデータを記憶する。

通信部４２は、公衆通信網Ｎ１又はキャリアネットワークＮ２における通信を実現する。制御部４０は、通信部４２により公衆通信網Ｎ１又はキャリアネットワークＮ２を介して利用者端末装置１、提供者端末装置２又は支払者端末装置３との間で情報の送受信が可能である。

入出力部４４は、プラットフォームに関する各種情報を記憶するサービスＤＢ（Data Base ：データベース）４０１との接続インタフェースである。サービスＤＢ４０１は、記憶部４１内に構築されてもよい。

サービスＤＢ４０１は、利用者ＤＢ４０２、提供者ＤＢ４０３、支払者ＤＢ４０４、帳票ＤＢ４０５、募集条件ＤＢ４０６を含む。

図６は、利用者ＤＢ４０２に記憶される情報の内容例を示す図である。利用者ＤＢ４０２は、利用者ＩＤに対応付けて利用者の名前等の属性を記憶している。属性には利用者の電話番号、メールアドレス等の連絡先情報、所属する企業名、社員ＩＤ等が含まれるとよい。利用者ＤＢ４０２は、利用者ＩＤに対応付けて利用者が所属する企業による経費に計上する場合のデフォルトの支払者を識別する支払者ＩＤを記憶している。経費に計上する場合の勘定科目と関連付けたデフォルトの業務番号が記憶されていてもよい。利用者ＤＢ４０２は、利用者の銀行口座を識別する情報、又は利用者個人のクレジットカードの情報である支払情報を記憶する。

図７は、提供者ＤＢ４０３に記憶される情報の内容例を示す図である。提供者ＤＢ４０３は、サービス又は商品の提供者の提供者ＩＤに対し、提供者の名前等の属性、提供者の種別等を記憶する。提供者ＩＤは、提供者が組織的である場合に直接的なサービス提供スタッフ、例えばタクシーの運転手、飲食店の店舗又は飲食店のスタッフＩＤ等で識別されてもよいし、事業者毎に識別されてもよい。提供者ＤＢ４０３は、提供者への料金の入金用銀行口座を識別する情報を記憶する。

図８は、支払者ＤＢ４０４に記憶される情報の内容例を示す図である。支払者ＤＢ４０４は、支払者の支払者ＩＤを対応付けて支払者である企業の名称等の属性を記憶する。支払者ＤＢ４０４は、支払者の引き落とし用、払込用の銀行口座を識別する情報を記憶する。

支払者ＩＤは支払者である企業からの申請に応じてプラットフォーム事業者によって発行される。利用者ＩＤは、支払者からの申請に、支払者の組織に属する利用者の分だけ発行される。利用者ＩＤは、個人的に発行されてもよく、この場合支払者のデフォルトは利用者自身である。利用者ＤＢ４０２、及び支払者ＤＢ４０４に記憶される情報は、発行された支払者ＩＤ又は利用者ＩＤに対応付けて支払者によって支払者端末装置３から遠隔で登録されてもよい。提供者ＤＢ４０３に記憶される情報も、サービス又は商品の提供者からの加盟申請に応じて管理者により発行される提供者ＩＤに対応付けて登録されてよい。

図９は、帳票ＤＢ４０５に記憶される情報の内容例を示す図である。帳票ＤＢ４０５は、デジタル帳票ＤＦを記憶する。デジタル帳票ＤＦは、取引ＩＤ、発行日時、利用開始日時、利用終了日時、利用目的、利用したサービス又は商品の名称、詳細内容、金額、利用者の利用者ＩＤ、サービス又は商品を提供する提供者の提供者ＩＤ、支払者の支払者ＩＤを含む。デジタル帳票ＤＦは、個人負担又は経費処理かの種別を含む。経費処理の場合には勘定項目を識別できるように業務番号が含まれるとよい。１回の利用に対して支払者と利用者自身とで費用が分担される場合、第２の支払者として利用者ＩＤ又は他の支払者の支払者ＩＤが含まれる。デジタル帳票ＤＦは、利用者の利用者ＩＤ、サービス又は商品を提供する提供者の提供者ＩＤ、及び支払者の支払者ＩＤの内のいずれかが１つで発行可能な情報である。デジタル帳票ＤＦは、後述するようにサービス提供の進行状況に沿って順次完成される。デジタル帳票ＤＦは、決済に必要な情報がサービス完了後に確定することを許容する。

図１０は、募集条件ＤＢ４０６に記憶される情報の内容例を示す図である。募集条件ＤＢ４０６は、情報作成装置４へ送信される利用者端末装置１、提供者端末装置２又は支払者端末装置３からのリクエストに含まれる募集条件の内容を記憶する。募集条件は、募集を識別するための募集ＩＤに対応付けられ、料金、場所等の条件の内容と、募集によって起票されたデジタル帳票ＤＦの取引ＩＤとを含む。募集が終了すると情報作成装置４によって募集条件は消去される。

このように構成される情報作成システム１００においてプラットフォームとして機能する情報作成装置４は、利用者ＩＤ、提供者ＩＤ及び支払者ＩＤの内の少なくとも１つが定まるとデジタル帳票ＤＦを起票する。デジタル帳票ＤＦにおいて利用者ＩＤは、サービス又は商品の享受に関する取引において、利用者が誰であるかを示す。提供者ＩＤは、利用者に提供されるサービス又は商品が何であるかに対応する。支払者ＩＤは、サービス又は商品に対する対価を誰が支払うかを示す。情報作成装置４は、起票したデジタル帳票ＤＦにおける全ての情報が確定した場合に支払の根拠となるデジタル帳票ＤＦを完成させる。情報作成装置４は、完成したデジタル帳票ＤＦを元にして決済サービスへ決済を要求することが可能であり、決済が完了すると経費情報を作成して支払者端末装置３へ送信することが可能である。

プラットフォームの利用準備手順について説明する。利用準備では、企業の経理部門が、パーソナルコンピュータに、情報作成装置４又は図示しない配信サーバから配信される端末用アプリケーションプログラム３Ｐをインストールする。端末用アプリケーションプログラム３Ｐのインストールと、企業に対し支払者ＩＤとして発行されたアカウント情報とにより、汎用コンピュータであるパーソナルコンピュータは情報作成システム１００の支払者端末装置３として機能する。端末用アプリケーションプログラム３Ｐに基づき支払者端末装置３は、経理部門のオペレータから支払者ＩＤ、及び名称等の属性の登録を受け付け、受け付けた支払者ＩＤ及び属性の情報を情報作成装置４へ送信する。支払者ＩＤは事前の申請によって情報作成装置４を管理するプラットフォーム事業者から発行されたものであってもよい。支払者端末装置３は、サービス又は商品の提供者への料金の支払いに用いられる決済用銀行口座の情報を受け付け、情報作成装置４へ送信する。これにより、図６に示したように支払者ＤＢ４０４に支払者の情報が支払者ＩＤに対応付けて記憶される。支払者端末装置３は、オペレータの操作に基づき、支払者である企業等の組織に所属する利用者の人数分の利用者ＩＤの発行を情報作成装置４へ依頼し、発行された利用者ＩＤを受信するとよい。

実施の形態１の情報作成システム１００では、利用者はスマートフォンに、情報作成装置４又は図示しない配信サーバから配信される端末用アプリケーションプログラム１Ｐをインストールする。端末用アプリケーションプログラム１Ｐのインストールと、利用者に対して利用者ＩＤとして発行されたアカウント情報とにより、汎用コンピュータであるスマートフォンは情報作成システム１００の利用者端末装置１として機能する。端末用アプリケーションプログラム１Ｐに基づき利用者端末装置１は、利用者から利用者ＩＤ、及び名前、メールアドレス等の連絡先を含む属性の登録を受け付け、受け付けた利用者ＩＤ及び属性の情報を情報作成装置４へ送信する。利用者ＩＤは、デフォルトの支払者との関係を正確に対応付けるために、上述したように支払者となる所属企業からの申請によって情報作成装置４にて予め発行されたものであることが好ましい。利用者端末装置１は、端末用アプリケーションプログラム１Ｐの個人利用時の支払情報の登録を受け付け、情報作成装置４へ送信する。個人利用時の支払情報は、利用者個人の銀行口座、又はクレジットカード情報である。これにより、図６に示したように利用者ＤＢ４０２に利用者の情報が利用者ＩＤに対応付けて記憶される。

利用準備段階においてサービス又は商品の提供者は、パーソナルコンピュータ又はスタッフのタブレット端末に、情報作成装置４又は図示しない配信サーバから配信される端末用アプリケーションプログラム２Ｐをインストールする。端末用アプリケーションプログラム２Ｐのインストールと、事前にプラットフォーム事業者との契約に基づき提供者ＩＤとして発行されたアカウント情報とにより、汎用コンピュータであるパーソナルコンピュータ又はタブレット端末は、情報作成システム１００の提供者端末装置２として機能する。端末用アプリケーションプログラム２Ｐに基づき提供者端末装置２は、サービス提供者のオペレータから提供者ＩＤ、及び名称等の属性の登録を受け付け、受け付けた提供者ＩＤ及び属性の情報を情報作成装置４へ送信する。同一のサービス事業者で、複数台の提供者端末装置２を用いる場合、事業者の経理部門のオペレータが用いるパーソナルコンピュータの提供者端末装置２にて登録を受け付けるとよい。この特定の提供者端末装置２は、サービス又は商品に係る料金の入金に用いられる入金用銀行口座の情報を受け付け、情報作成装置４へ送信する。これにより、図７に示したように提供者ＤＢ４０３に提供者の情報が提供者ＩＤに対応付けて記憶される。

提供者端末装置２は利用準備の一環として、サービスを識別するサービスコードの発行をプラットフォーム事業者へ依頼する。サービスコードは例えば、提供者を事象単位毎に識別するＩＤであって提供者ＩＤと同一でもよいし、提供者が複数のスタッフにて構成されている場合に、スタッフを個々に識別するＩＤであってもよいし、スタッフの配置場所を識別するＩＤであってもよい。この場合、特定の提供者端末装置２は、スタッフの識別情報の数分のサービスコードの発行を、各々のスタッフを識別する情報と対応付けて情報作成装置４へ依頼してもよい。特定の提供者端末装置２以外の提供者端末装置２は、提供者に対して発行された提供者ＩＤを少なくとも含むサービスコードを受信して用いる。サービスコードが提供者毎ではなくスタッフ又は配置場所等を識別するように付される場合には、各スタッフが用いる提供者端末装置２は、提供者ＩＤにスタッフを識別する情報を合わせたサービスコードを用いてよい。提供者は、サービスの提供場所で二次元コード化された提供者ＩＤ、又はサービスコードを提示するとよい。提示方法は、シール媒体に印刷して貼付する方法であってもよいし、提供者端末装置２の表示部２３に表示される方法であってもよい。

上述の利用準備に基づく実際のサービス利用時の処理についてフローチャートを参照して説明する。プラットフォームの情報作成装置４は、利用者、提供者、又は支払者のいずれか１つから、サービス（商品）を受けたい、サービス（商品）のユーザを募集しているといったリクエストを受け付けると利用者、提供者及び支払者間でマッチングを行なう。情報作成装置４は具体的には、以下に示す処理を実行する。図１１は、情報作成装置４における処理手順の一例を示すフローチャートである。

利用者端末装置１は、利用者ＩＤを用いて端末用アプリケーションプログラム１Ｐを利用している間、即ち、端末用アプリケーションプログラム１Ｐに基づき利用者向けの画面を表示させている間、位置情報取得部１６にて取得できる位置情報を、情報作成装置４へ向けて逐次送信する。

情報作成装置４の制御部４０は、利用者端末装置１から送信される位置情報を、位置情報の送信元の利用者端末装置１に対応する利用者ＩＤに対応付けて記憶部４１に逐次記憶する。利用者ＤＢ４０２において利用者ＩＤに対応付けて位置情報を記憶し、逐次更新してもよい。

情報作成装置４の制御部４０は、利用者端末装置１、提供者端末装置２、又は支払者端末装置３のいずれかから、利用者、提供者又は支払者の募集のリクエストを受け付ける（ステップＳ１０１）。募集リクエストには、リクエスト元を識別するためのＩＤと、募集の条件とが含まれる。

制御部４０は、受け付けた募集リクエストに応じて取引ＩＤを採番し、デジタル帳票ＤＦを起票する（ステップＳ１０２）。デジタル帳票ＤＦは、取引ＩＤと、リクエスト元の利用者ＩＤ、提供者ＩＤ又は支払者ＩＤの内、少なくともいずれか１つとを含んで起票される。デジタル帳票ＤＦとして帳票ＤＢ４０５に記憶された以後は、利用者、提供者又は支払者が検索・閲覧できるようになる。

制御部４０は、受け付けた募集リクエストに含まれる募集の条件を募集ＩＤに対応付けて募集条件ＤＢ４０６に記憶する（ステップＳ１０３）。募集条件ＤＢ４０６には、募集ＩＤとステップＳ１０２で発行されたデジタル帳票ＤＦの取引ＩＤとが対応付けられて記憶される。募集条件ＤＢ４０６では、制御部４０は募集ＩＤに対応付けて募集中であることを示す情報を記憶しておく。

制御部４０は、利用者の最新の位置情報、提供者のサービス種別等に応じてステップＳ１０１で受け付けたリクエストの募集条件に対応する利用者の利用者ＩＤ、又は提供者の利用者ＩＤを抽出する（ステップＳ１０４）。

制御部４０は、ステップＳ１０４で抽出された利用者ＩＤの利用者、又は提供者ＩＤの提供者に対し、ステップＳ１０１で受け付けた募集の内容を対応付ける（ステップＳ１０５）。ステップＳ１０５において制御部４０は具体的には、ステップＳ１０４で抽出した利用者ＩＤ、又は提供者ＩＤに対し、ステップＳ１０３で記憶した募集の条件の募集ＩＤを対応付けて記憶する。

ステップＳ１０５の対応付けにより、抽出された利用者ＩＤの利用者端末装置１、又は提供者ＩＤの提供者端末装置２にて、対応付けられた募集の一覧を表示させることができる。ステップＳ１０５では、抽出された利用者ＩＤ又は提供者ＩＤに対し、募集内容をプッシュ通知してもよい。

制御部４０は、ステップＳ１０４で抽出された利用者ＩＤの利用者、又は提供者ＩＤの提供者から、募集に対する応募を受け付ける（ステップＳ１０６）。

なおステップＳ１０４及びステップＳ１０５は必須ではなく、抽出された利用者ＩＤの利用者、提供者ＩＤの提供者以外が使用する利用者端末装置１、提供者端末装置２、支払者端末装置３からでも検索、応募が可能であってよい。デジタル帳票ＤＦは、利用者、提供者、支払者、又はその他管理者等の操作によって種別、時期、提供者等の情報によってデジタルチケットマーケットに挙げられ、検索及び閲覧し易くなるようにしてもよい。

制御部４０は、受け付けた応募の内容を、リクエスト元へ通知し（ステップＳ１０７）、応募してきた利用者又は提供者の内からの選定を受け付ける（ステップＳ１０８）。制御部４０は、選定された利用者の利用者端末装置１又は提供者の提供者端末装置２へ、選定を通知し（ステップＳ１０９）、確認を受け付ける（ステップＳ１１０）。

ステップＳ１１０の確認により利用者及び提供者が確定すると、デジタル帳票ＤＦは利用者が提供者からサービスを受けるためのデジタルチケットとして利用可能になる。

制御部４０は、確認が受け付けられた場合、ステップＳ１０３で記憶した募集条件に対し、募集条件ＤＢ４０６において募集を終了したことを記憶し（ステップＳ１１１）、利用者の利用者ＩＤ又は提供者の提供者ＩＤを、ステップ１０２で発行したデジタル帳票ＤＦに追記する（ステップＳ１１２）。

制御部４０は、デジタル帳票ＤＦに対応するサービス又は商品の提供の進行状況をモニタする（ステップＳ１１３）。ステップＳ１１３の進行状況のモニタでは第１に、提供者端末装置２又は利用者端末装置１から、デジタル帳票ＤＦの利用者ＩＤが示す利用者が実際に利用を開始したか、提供者ＩＤが示す提供者によってサービス又は商品が提供されているかが確認される。例えば、利用開始時に利用者は利用者端末装置１の読取部１５によって、サービス提供者によって提示されるサービスコードを読み取る。サービスコードは、上述したように少なくとも提供者ＩＤを含み、スタッフ又は配置場所等を識別する情報が含まれる。制御部１０は、読み取ったサービスコードと利用者端末装置１に対応する利用者ＩＤとを対応付けて情報作成装置４へ送信する。あるいは、提供者が提供開始時に利用者から提示される利用者ＩＤを提供者端末装置２の読取部２５で読み取り、提供者のサービスコードと対応付けて情報作成装置４へ送信してもよい。これにより、実際に利用者が利用を開始したことが確認される。

制御部４０は、モニタリングした進行状況を元に、サービス又は商品の提供が完了し、料金が確定したか否かを判断する（ステップＳ１１４）。ステップＳ１１４にて未完で未確定であると判断された場合（Ｓ１１４：ＮＯ）、制御部４０は処理をステップＳ１１３へ戻す。

ステップＳ１１４において提供が完了したか否かは、例えば提供者端末装置２の操作部２４にて完了通知を受け付け、制御部２０が情報作成装置４へ通知してもよい。完了したか否かは、サービス提供者から出力した完了通知のレシート等を利用者端末装置１の読取部１５で読み取り、制御部１０が読み取った結果を情報作成装置４へ通知してもよい。完了したか否かは、タクシーであればタクシーメータ等の料金メータ、レジにおける処理完了を検知してもよい。

ステップＳ１１４にて提供が完了し、料金が確定したと判断された場合（Ｓ１１４：ＹＥＳ）、制御部４０は、デジタル帳票ＤＦにおける料金及びサービス若しくは商品の提供内容を追記し（ステップＳ１１５）、処理を完了する。デジタル帳票ＤＦにおける必要な情報が全て確定した場合、デジタル帳票ＤＦが取引情報として作成され、これに基づいて決済、経理処理が実行可能になる。

図１１のフローチャートに示した処理手順に基づくサービスの実現を、具体例を挙げて説明する。実施の形態１では、プラットフォームに加盟する多様なサービス提供者の内、タクシー事業者のサービスを例に挙げて説明する。本開示の情報作成システム１００では、利用者、提供者及び支払者のいずれもサービスのリクエストを出すことができる。

タクシー事業者のサービスの場合、提供者の提供者端末装置２は一例では、タクシー事業者の営業所に設置されるパーソナルコンピュータである。一例では、各運転者が所持するタブレット端末、又はスマートフォンが、端末用アプリケーションプログラム２Ｐをインストールし、提供者ＩＤ、及び運転者（実際のサービスを提供するスタッフ）を識別するＩＤを使用することで提供者端末装置２として機能する。各運転者が所持するか、または車両に搭載される提供者端末装置２は位置情報取得部を備え、制御部２０は、利用者端末装置１と同様に逐次、提供者端末装置２の位置情報を取得し、情報作成装置４と通信接続したタイミングで最新の位置情報又は位置情報の履歴を送信する。情報作成装置４は、提供者端末装置２から送信される位置情報を、運転者を識別するＩＤ又は車両番号に対応付けて記憶する。提供者ＤＢ４０３にて、位置情報が記憶され逐次更新されてもよい。

タクシー事業者のサービスを利用者が本開示のプラットフォーム上で利用するためには、利用者が乗車するタクシーを募集する第１のケースと、タクシーが利用者を募集する第２のケースと、提供者がタクシーチケットを発行して利用者及び提供者を募る第３のケースとがある。以下、夫々のケースに分けてプラットフォームを利用したチケットレス決済の実現について説明する。いずれの場合も、リクエストに応じてデジタル帳票ＤＦが起票されるとデジタルチケットマーケットに出品された状態となり、利用者端末装置１、提供者端末装置２、及び支払者端末装置３から、デジタル帳票ＤＦに含まれる利用者ＩＤ、提供者ＩＤ、支払者ＩＤ、サービス内容、金額等のいずれかの情報によって検索・閲覧できる。

［１．利用者からリクエスト発行］
第１のケースとして、利用者がタクシーに乗ることをリクエストする場合を例に挙げて説明する。以下、第１のケースにおけるデジタル帳票ＤＦに基づく処理についてシーケンス図及び画面例を参照して説明する。

図１２及び図１３は、利用者端末装置１にて表示される画面の一例を示す。図１２は、利用者が利用者ＩＤと対応付けて端末用アプリケーションプログラム１Ｐを起動した場合に表示されるメイン画面１３０を示す。メイン画面１３０は例えば、プラットフォームに加盟しているサービスの内、利用者が予め設定している使用可能なメニューのリストを含む。図１２の例では、メイン画面１３０はタクシーに乗るためのメニューボタン１３１を含む。メイン画面１３０の態様は図１２に示す内容には限られない。

図１３は、メイン画面１３０においてタクシーに乗るメニューボタン１３１が選択された場合の検索画面１３２を示す。検索画面１３２には、タクシーを利用するデジタルチケットを発行するための設定項目の入力画面が含まれる。検索画面１３２には複数の項目夫々について、選択肢を変更するための矢印アイコン１３３が含まれる。矢印アイコン１３３が選択されると、例えば「出発地」であれば「現在地」又は「住所」等を含む選択肢がプルダウンメニューから選択できる。検索画面１３２では、利用したいタクシーの「出発時間」、「目的地」、及び「希望到着時間」を指定することが可能である。目的地については、場所又は住所を入力欄に入力すると、地図上で検索が可能であってもよい。検索画面１３２には、利用者を募集しているタクシーの募集内容を表示するための募集表示ボタン１３５が含まれる。募集表示ボタン１３５については後述する。検索画面１３２ではそのほか、タクシーを募集するリクエスト用のタクシーの「利用目的」、「業務番号」、「利用条件」、「支払方法」、及びリクエストの条件として「タクシー種別」の設定が可能である。「タクシー種別」は例えば、ＶＩＰ対応車両、福祉車両、ワンボックス又は指定なしが設定可能である。「利用条件」は利用者と支払者との間で取決められた経費処理の上限値等であり、デフォルトで設定されている条件が自動的に適用されてよい。「支払方法」として、利用者が属する企業が経費として支払う「経費処理」と、利用者自身が支払う「個人利用」とのいずれかの選択が可能である。「経費処理」の場合は「業務番号」として勘定項目に関連付けられている情報の選択が可能である。

検索画面１３２には、デジタル帳票ＤＦに基づくタクシー利用のためのデジタルチケットをリクエストするボタン１３４が含まれている。利用者端末装置１の制御部１０は、表示部１３上で利用者がボタン１３４をタップしたことを操作部１４によって検知した場合、利用者を乗せるタクシーを募集するリクエストを情報作成装置４へ送信する。

図１４は、利用者端末装置１からのリクエストに基づいてデジタル帳票ＤＦが完成するまでのシーケンスを示す図である。図１４のシーケンス図に示す手順の内、情報作成装置４の処理手順で図１１のフローチャートで示した手順については同一のステップ番号を付して詳細な説明を省略する。

利用者端末装置１の制御部１０が、図１３の検索画面１３２におけるボタン１３４の操作を受け付け、利用者を乗せるタクシーを募集するリクエストを通信部１２から送信する（ステップＳ２０１）。リクエストには、検索画面１３２で設定された「利用目的」、「業務番号」、「利用条件」、「支払方法」、及び「リクエストの条件」が含まれている。

情報作成装置４の制御部４０が、利用者端末装置１からのリクエストを受信し、これを受け付け（Ｓ１０１）、リクエストに基づくデジタル帳票ＤＦを起票する（Ｓ１０２）。このケースにおいてステップＳ１０２で起票されるデジタル帳票ＤＦは、図９の帳票ＤＢ４０５に示しているように、利用者ＩＤ、提供者ＩＤ及び支払者ＩＤの内、利用者ＩＤのみが確定している。

図１５は、デジタル帳票ＤＦが完成していく過程の示す概要図である。図１５はＡ、Ｂ、Ｃの順にデジタル帳票ＤＦの各項目が埋まる過程を示している。図１５Ａに示すように、ステップＳ１０２の段階では、決済又は経費処理に必要な項目である（１）取引を識別する情報（取引ＩＤ）、（２）提供されたサービス又は商品の内容を示す情報（項目）、（３）料金、（４）サービス又は商品の提供者（支払先）、（５）サービス又は商品の利用者、（６）料金の支払者の内、（５）が定まることで（１）が採番されている状態である。ステップＳ１０１で受信したリクエストに含まれる「支払方法」が「経費処理」であるため、（６）の支払者は、利用者が所属する企業に仮決定される。このように、本開示におけるプラットフォームでは、支払者及び提供者が定まっていない段階で決済、経費処理の元となるデジタル帳票ＤＦを起票する。

図１４のシーケンス図に戻り説明を続ける。
情報作成装置４の制御部４０は、ステップＳ１０１で受信したリクエストから募集条件を記憶し（Ｓ１０３）、募集条件に合致する提供者の提供者ＩＤを、提供者端末装置２から逐次受信している位置情報に基づいて抽出する（Ｓ１０４）。制御部４０はステップＳ１０４において例えば、リクエストに含まれる出発地に、出発時間よりも所定の時間（例えば１－５分）までに到着できる位置にあるタクシーの提供者端末装置２を、各提供者端末装置２からの位置情報に基づいて抽出する。

制御部４０は、抽出した提供者ＩＤに対応付けて、ステップＳ１０３で記憶した募集条件の募集ＩＤを対応付ける（Ｓ１０５）。

制御部４０は、ステップＳ１０５において抽出した提供者端末装置２へ向けて、出発地までの距離が短い順に、タクシーの募集がある旨の通知を送信する方法でもよいし、提供者端末装置２を使用するタクシー運転手が募集を検索する方法で募集に対する応募を受けてもよい。

提供者端末装置２の制御部２０は、通知を受けるか又は検索により募集を取得し（ステップＳ３０１）、募集に対する応募を受け付ける（ステップＳ３０２）。

提供者端末装置２における画面例を挙げて応募の受け付けについて説明する。図１６及び図１７は、提供者端末装置２にて表示される画面の一例を示す。図１６は、提供者が提供者ＩＤと対応付けて端末用アプリケーションプログラム２Ｐを起動した場合に表示されるメイン画面２３０を示す。図１６に示すメイン画面２３０は、タクシー事業者向けに特化された端末用アプリケーションプログラム２Ｐに組み込まれたアプリケーションプログラムに基づいて表示されている。メイン画面２３０は、タクシー車両の当日のスケジュールと、近くの乗客を探すためのメニューボタン２３１及び乗客を募集するリクエストのためのボタン２３２を含む。ボタン２３２による処理については後述する。図１６の例においてスケジュールには、現在時刻、予約状況が示されている。メイン画面２３０の態様は、図１６に示す内容には限られない。

図１７は、メイン画面２３０において乗客を探すためのメニューボタン２３１が選択された場合の検索画面２３３を示す。検索画面２３３には、提供者端末装置２が対応する提供者ＩＤを抽出対象とした募集がある場合には、その募集内容のリスト２３４が表示される。図１７のリスト２３４では、提供者ＩＤを抽出した募集の内、絞り込みの条件として予約状況に基づく発着時刻及び発着地点で絞り込んだ募集のリストが表示されている。検索画面２３３のリスト２３４には、各募集に対し、いずれかを選択するためのボタン２３５が含まれている。ボタン２３５が選択されると、提供者端末装置２からの応募が受け付けられる。

図１４のシーケンスに戻り説明を続ける。図１７に示した検索画面２３３にて応募のためにいずれかのボタン２３５が選択されることで、提供者端末装置２の制御部２０により応募の通知が通信部２２から情報作成装置４へ送信される（ステップＳ３０３）。

情報作成装置４の制御部４０は、応募を受け付け（Ｓ１０６）、受け付けた応募の内容をリクエスト元の利用者の利用者端末装置１へ通知する（Ｓ１０７）。

利用者端末装置１の制御部１０は、応募の通知を受け付け（ステップＳ２０２）、応募の選定を受ける（ステップＳ２０３）。図１８は、利用者への応募の通知画面１３６の内容例を示す図である。通知画面１３６は、図１３の検索画面１３２でリクエストのボタン１３４を選択した後の待機後に表示される。通知画面１３６には、リクエストに対して応募してきたタクシーの情報がリスト表示され、選定ボタン１３７が含まれている。利用者はいずれかのタクシーを選択して対応する選定ボタン１３７を選択する。

図１４のシーケンスに戻り説明を続ける。図１８に示した通知画面１３６にて選定ボタン１３７が選択されることで、利用者端末装置１の制御部１０により選定結果が通信部１２から情報作成装置４へ送信される（ステップＳ２０４）。

情報作成装置４では、制御部４０が選定結果を受信することで選定を受け付け（Ｓ１０８）、選定された提供者の提供者端末装置２へ選定を通知する（Ｓ１０９）。

提供者端末装置２の制御部２０は、選定通知を受信して（ステップＳ３０４）、確認を受け付け、情報作成装置４へ送信する（ステップＳ３０５）。

情報作成装置４の制御部４０は、提供者端末装置２から確認を受け付ける（Ｓ１１０）。ステップＳ１０６にて複数の応募があった場合、選定されなかった提供者へは選定されなかった旨の通知がされるとよい。提供者端末装置２では、図１７に示した画面の後に、応募が選定された旨の通知画面が表示され、通知画面に含まれる確認ボタンによって確認が受け付けられる。

情報作成装置４の制御部４０は、選定された提供者の提供者ＩＤをデジタル帳票ＤＦに追記する（Ｓ１１２）。これにより、図１５Ｂに示すように、デジタル帳票ＤＦにおいて提供者の項目が埋まる。

図１９は、利用者端末装置１にて表示されるデジタルチケット１３８の一例を示す。図１９は、図１８にて選定ボタン１３７を選択した場合に、リクエストに応じて利用者が利用することが可能となったタクシー利用のためのデジタルチケット１３８の内容を示している。デジタルチケット１３８は、チケットの基となるデジタル帳票ＤＦの取引ＩＤ、チケットの発行日、サービス内容、料金等の情報を含む。

制御部４０は、その後、選定された提供者の提供者ＩＤのタクシーにリクエスト元の利用者が乗車したか否か、及び予定時刻までにタクシーが到着したか否か等の進行状況を、逐次送信される位置情報、タクシーにおける乗車確認等の情報に基づいてモニタする（Ｓ１１３）。制御部４０は、タクシーの提供者端末装置２から降車、及び料金確定の通知を受けたか否かによって、サービスの提供完了及び料金が確定したか否かを判断する（Ｓ１１４）。

制御部４０は、提供者端末装置２から料金確定の通知を受けると（Ｓ１１４：ＹＥＳ）、利用者端末装置１及び支払者端末装置３において確認又は承認を受けて提供されたサービスの内容、料金及び支払者を確定させてデジタル帳票ＤＦに追記する（Ｓ１１５）。図２０は、デジタルチケット１３８の内容例を示す図である。図１９で表示されたデジタルチケット１３８では料金が確定した後、図２０に示すように、料金の欄に、確定された料金が表示され、利用者によって確認する確認ボタン１３９が含まれる。確認ボタン１３９が選択された場合、情報作成装置４にて確認が受け付けられる。図２０のデジタルチケット１３８においては確定した料金が、経費処理の場合の支払者と利用者との間の利用条件に応じて上限以内であれば支払者は所属企業、上限を超過した一部料金については個人負担とするなど、Ｓ１１５の時点で確定される。その他、支払者端末装置３へ通知が送信され、支払者端末装置３の操作によって承認を受けてもよい。これにより、図１５Ｃに示すようにデジタル帳票ＤＦにおいて全ての項目が埋まり、これに基づいて決済及び経費処理が可能になる。

［２．提供者からリクエスト発行］
第２のケースとして、提供者であるタクシー事業者が利用者を募る場合を例に説明する。以下、第２のケースにおけるデジタル帳票ＤＦに基づく処理についてシーケンス図及び画面例を参照して説明する。

図１６の提供者端末装置２におけるメイン画面２３０中の乗客リクエストするためのボタン２３２により、提供者端末装置２の制御部２０は、タクシーの乗客を募集するリクエストを情報作成装置４へ送信する。

図２１は、提供者端末装置２からのリクエストに基づいてデジタル帳票ＤＦが完成までのシーケンスを示す図である。図２１のシーケンス図に示す手順の内、図１４の利用者端末装置１を起点とした処理手順、図１１のフローチャートで示した手順と共通する処理については同一のステップ番号又は対応するステップ番号を付して詳細な説明を省略する。

提供者端末装置２で制御部２０は、図１６の乗客リクエストのためのボタン２３２の操作を受け付け、タクシーに乗る利用者を募集するリクエストを通信部２２から送信する（ステップＳ３１１）。リクエストには、予約状況に基づく発着時刻及び発着地点に関する「リクエスト条件」が含まれている。

これにより、情報作成装置４の制御部４０によって、利用者ＩＤ、提供者ＩＤ及び支払者ＩＤの内、提供者ＩＤのみが確定したデジタル帳票ＤＦが発行される。図２２は、第２のケースにおけるデジタル帳票ＤＦの概要図である。図２２はＡ、Ｂ、Ｃの順にデジタル帳票ＤＦの各項目が埋まる過程を示している。図２２Ａに示すように、ステップＳ１０２の段階では、決済又は経費処理に必要な項目の内、（４）サービス又は商品の提供者（支払先）が定まることで（１）が採番されている状態である。このように、本開示におけるプラットフォームでは、利用者及び支払者が定まっていない段階で決済、経費処理の元となるデジタル帳票ＤＦを発行する。

図２１のシーケンスに戻り説明を続ける。情報作成装置４の制御部４０は、ステップＳ１０１で受信したリクエストに対応する募集条件に合致する利用者の利用者ＩＤを、利用者端末装置１から逐次受信している位置情報に基づいて抽出する（Ｓ１０４）。ステップＳ１０４の抽出は、端末用アプリケーションプログラム１Ｐをアクティブにしている利用者端末装置１等に絞り込まれてもよい。制御部４０はステップＳ１０４において例えば、リクエストに含まれる出発地点に近い場所で、端末用アプリケーションプログラム１Ｐを使用している利用者の利用者端末装置１を、利用者端末装置１の位置情報に基づいて抽出する。制御部４０は、抽出した利用者ＩＤと、ステップＳ１０３で記憶した募集条件の募集ＩＤとを対応付ける（Ｓ１０５）。

ステップＳ１０５にて利用者ＩＤに募集ＩＤが対応付けられることにより、利用者端末装置１の制御部１０が図１３の検索画面１３２における募集表示ボタン１３５を選択すると、制御部１０は利用者ＩＤに対応付けられている募集を取得する（ステップＳ２１１）。ステップＳ２１１において制御部１０は、利用者ＩＤが対応付けられていない募集を取得し、後に検索絞り込みを行なうようにしてもよい。制御部１０は、取得した募集、即ち、利用者を募集している近くのタクシーの募集内容のリストを表示し、募集に対する応募を受け付ける（ステップＳ２１２）。

図２３は、利用者端末装置１にて表示される画面の一例を示す。図２３に示す画面は、図１３の検索画面１３２において募集表示ボタン１３５が選択された場合に表示される。この場合、図２３に示すように検索画面１３２には、利用者端末装置１が対応する利用者ＩＤを抽出対象とした募集のリスト１４０が表示される。図２３のリスト１４０では、利用者ＩＤを抽出した募集の内、利用の条件として「目的地」及び「希望到着時刻」によって絞り込まれた募集のリストが表示されている。リスト１４０には、各募集に対し、いずれかを選択するためのボタン１４１が含まれている。ボタン１４１が選択されると、利用者端末装置１からの応募が受け付けられる。

図２１のシーケンスに戻り説明を続ける。図２３に示したリスト１４０にて選択のボタン１４１が選択されることで、利用者端末装置１の制御部１０により応募の通知が通信部１２から情報作成装置４へ送信される（ステップＳ２１３）。

情報作成装置４の制御部４０は、応募を受け付け（Ｓ１０６）、受け付けた応募の内容をリクエスト元の提供者の提供者端末装置２へ通知する（Ｓ１０７）。

提供者端末装置２の制御部２０は、応募の通知を受け付け（ステップＳ３１２）、応募の選定を受ける（ステップＳ３１３）。提供者端末装置２では、図１７に示した検索画面２３３同様の画面に、リクエストに対して応募してきた利用者としての乗客の情報が、表示部２３にリストとして表示され、ボタン２３５の選択によっていずれかの利用者が選定される。タクシーは、いずれかの利用者を選択し、応募してきた利用者の場所へ向かう。

図２１のシーケンスに戻り説明を続ける。乗客として応募してきた利用者が選定されることで、提供者端末装置２の制御部２０により選定結果が通信部２２から情報作成装置４へ送信される（ステップＳ３１４）。

情報作成装置４では、制御部４０が選定結果を受信することで選定を受け付け（Ｓ１０８）、選定された利用者の利用者端末装置１へ選定を通知する（Ｓ１０９）。

利用者端末装置１の制御部１０は、選定通知を受信して（ステップＳ２１４）、確認を受け付け、情報作成装置４へ送信する（ステップＳ２１５）。

情報作成装置４の制御部４０は、利用者端末装置１から確認を受け付ける（Ｓ１１０）。ステップＳ１０６にて複数の応募があった場合、選定されなかった利用者へは選定されなかった旨の通知がされるとよい。利用者端末装置１では、図２３に示した画面の後に、応募が選定された旨の通知画面が表示され、通知画面に含まれる確認ボタンによって確認が受け付けられる。

情報作成装置４の制御部４０は、選定された利用者の利用者ＩＤをデジタル帳票ＤＦに追記する（Ｓ１１２）。これにより、図２２Ｂに示したように、デジタル帳票ＤＦにおいて利用者の項目が埋まる。

制御部４０は、その後、選定された利用者の利用者ＩＤの利用者端末装置１が、リクエスト元のタクシーに乗車したか否か、及び予定時刻までにタクシーが到着したか否か等の進行状況を、逐次送信される位置情報、タクシーにおける乗車確認等の情報に基づいてモニタする（Ｓ１１３）。その後の処理は、第１のケースと同様である。そして図２２Ｃに示したようにデジタル帳票ＤＦにおいて全ての項目が埋まり、これに基づいて決済及び経費処理が可能になる。

［３．支払者からリクエスト発行］
第３のケースとして、支払者が提供者及び利用者を募る場合を例に説明する。以下、第３のケースにおけるデジタル帳票ＤＦに基づく処理について説明する。

支払者端末装置３においても第１のケース又は第２のケースと同様にして、制御部３０は、支払者ＩＤと対応付けた端末用アプリケーションプログラム３Ｐに基づいて、利用者及び提供者が未定のデジタルチケットの発行リクエストを送信することができる。例えば、第１のケース及び第２のケースと同様に、支払者に対応する組織に属する利用者が業務上、特定の場所へタクシーで移動する必要がある場合に、利用者端末装置１からリクエストが送信されなくても同様にして利用者はキャッシュレスでサービスを受け、提供者は支払者から料金の支払いを受けることができる。支払者にとっての顧客の送迎で通常はタクシーチケットを配布して対応するような場合に、支払者端末装置３からのリクエストで発行されたデジタルチケットを、後に定まる利用者の利用者端末装置１へ向けて送信すればよい。

第３のケースにおける処理手順は、図１１のフローチャート、図１３及び図２１のシーケンスを参照して説明できる。

支払者端末装置３の制御部３０は、支払者ＩＤが対応する端末用アプリケーションプログラム３Ｐに基づいて、タクシー及び乗客を募集するリクエストを通信部３２から送信する。リクエストには例えば、タクシーというサービスの種別と、利用者を支払者の組織に属する利用者とする条件とが指定されている。また例えば、組織に属する利用者であって、移動が必要な業務中の特定の利用者の利用者ＩＤが指定されていてもよい。リクエストには、支払者の支払者ＩＤと、発行されるデジタル帳票ＤＦに基づくデジタルチケットの所有者となる利用者（顧客）の利用者ＩＤとが指定されてもよい。

第３ケースにおいて情報作成装置４の制御部４０は、リクエストに基づいて支払者ＩＤのみが決定したデジタル帳票ＤＦを起票し（Ｓ１０２）、募集条件に対応する利用者及び提供者をいずれも抽出する（Ｓ１０４）。ここで、提供者の抽出は、特定の利用者ＩＤの利用者端末装置１の位置情報に基づき、特定の利用者の近くに存在するタクシーが抽出されるとよい。抽出された利用者ＩＤ及び提供者ＩＤには、リクエストに係る募集ＩＤが対応付けられる（Ｓ１０５）。

これにより、提供者端末装置２において提供者が乗客を探索しようとすると、募集内容のリストが表示部２３に表示され、提供者は支払者に対応する組織に属する利用者、又は支払者が指定する顧客を乗客とするタクシーとして応募することが可能になる。図２４は、提供者端末装置２にて表示される画面例を示す図である。図２４では、図１６で示したメイン画面２３０に、支払者としてＤＥＦ商事に属するいずれかの社員を乗せるタクシーの募集内容が表示されており、募集に応募するためのボタン２３６が表示されている。

また第３のケースでは、利用者端末装置１の表示部１３に表示される「発行済みのデジタルチケット」の一覧として募集内容のリストが表示されてもよい。図２５は、利用者端末装置１にて表示される画面例を示す図である。図２５では、図１３で示した検索画面１３２に対し、支払者からのリクエストによって発行済みのデジタルチケットを選択するためのボタン１４２が追加されている。ボタン１４２が選択された場合、利用者が使用可能なタクシー用のデジタル帳票ＤＦの取引ＩＤを含むチケット一覧に基づき、いずれかのチケットの利用に対して応募ができる。

提供者又は利用者が募集に応募すると、情報作成装置４では応募を受け付けてマッチングする。制御部４０は例えば、図２４で応募してきた提供者であるタクシーのリストを、支払者端末装置３で選定できるようにしてもよいし、対象の利用者の利用者端末装置１で表示して選定できるようにしてもよい。同様にして、図２５で応募してきた利用者のリストを、支払者端末装置３で選定できるようにしてもよいし、近くにいる提供者であるタクシーの提供者端末装置２で表示して選定できるようにしてもよい。制御部４０は、タクシーの位置及び利用者の目的地に応じて自動的に両者をマッチングしてもよい。

利用者に対し、起票されたデジタル帳票ＤＦ（少なくとも支払者ＩＤが確定済み）の取引ＩＤを印刷出力した紙媒体が渡され、利用者によって選択された提供者が取引ＩＤに基づいてデジタルチケットを検索し、これを利用することによって利用者、提供者、支払者がマッチングされるようにしてもよい。つまり、募集に対する応募は利用者端末装置１、提供者端末装置２、及び支払者端末装置３間での情報の授受に限られず、サービスの利用時の取引ＩＤの提示であってもよい。

図２６は、第３のケースにおけるデジタル帳票ＤＦの概要図である。図２６はＡ、Ｂ、Ｃの順にデジタル帳票ＤＦの各項目が埋まる過程を示している。図２６Ａに示すように、情報作成装置４にて支払者端末装置３からのリクエストに基づいてデジタル帳票ＤＦを発行する段階では、決済又は経費処理に必要な項目の内、（６）料金の支払者が定まることで（１）が採番されている状態である。このように、本開示におけるプラットフォームでは、利用者及び提供者が定まっていない段階で決済、経費処理の元となるデジタル帳票ＤＦを発行する。例えば提供者が募集に応募すると、支払者にて選定された提供者が定まり、図２５Ｂに示すように、デジタル帳票ＤＦにおける提供者の情報が定まる。以後の処理は、第２のケース同様に、応募してきた利用者を、支払者又は提供者にて選定し、選定された利用者が提供者のタクシーに乗車したか否か等の進行状況をモニタし、料金が確定した場合に、図２６Ｃに示すように全ての情報が定まってデジタル帳票ＤＦが完成し、決済及び経費処理が可能となる。

このように、本開示におけるプラットフォームでは、利用者、提供者及び支払者の内の２つが定まっていない段階で決済、経費処理の元となるデジタル帳票ＤＦを発行する。つまり利用者、提供者及び支払者のいずれもサービスのリクエストを出すことができる。情報作成システム１００では、情報作成装置４が、リクエストにマッチするサービス提供者、支払者、又は利用者等を募集し、利用者、提供者及び支払者の情報及び料金が確定したデジタル帳票ＤＦを完成させると、デジタル帳票ＤＦに基づく決済及び経費処理が可能となる。

実施の形態１の説明では、交通機関の経費としてタクシーのみを説明したが、バス、電車、飛行機等の他の公共交通機関にも適用することは可能である。例えば、情報作成装置４では、募集に対する応募を受け付ける代わりに、目的地まで利用できるバス、電車、飛行機等の検索結果（特急列車や飛行機の場合は空きがある便等）を提供者端末装置２から夫々受け付け、検索結果から選定を受け付け、選定された提供者の提供者には利用する利用者の利用者ＩＤを通知する。利用者が利用する時点で利用者ＩＤを利用者端末装置１から提供者側で確認（認証）することができれば、その後は利用状況をモニタし、料金が確定した時点でデジタル帳票ＤＦを確定することができる。利用者ＩＤは、交通系ＩＣカードと紐付けされていれば、交通系ＩＣカードにおけるカード情報によって利用者の利用を確認することも可能である。

利用者は、複数の交通機関を乗り継いでいく間に、空きがある交通機関を利用者端末装置１にて表示される検索画面１３２にて検索し、夫々に対するリクエスト、又は既存のデジタル帳票ＤＦに基づいて募集している中でマッチする交通機関を選定してもよい。

（実施の形態２）
実施の形態２では、プラットフォームを利用する多様なサービス提供者の内、タクシー事業者によるサービスについて説明する。実施の形態２におけるサービス提供者であるタクシー事業者は、プラットフォームを利用することによってタクシーの相乗りサービスを実現する。

実施の形態１で示したように、本開示のプラットフォームを使用することによって、料金が確定した時点で現金、クレジットカードによる支払がなくとも、サービスの内容即ち実績に基づいた支払者からサービス提供者への支払いが可能である。本開示のプラットフォームを利用した場合、１人の利用者が乗客としてタクシーを利用中に、出発地点又は終着地点が異なる他の利用者が乗客として乗ったとしても、各々の利用者のサービス内容（距離）が確定できれば、相乗りしている時間等によって事後的に割引等の精算が可能である。実施の形態２における構成及び実行される処理手順は、実施の形態１と同様であるから同一の符号を用いて以下、相乗りサービスの実現について説明する。

実施の形態２におけるタクシーの相乗りサービスを実現するためには、募集条件に、相乗りの可否、１回のリクエストにおける乗客の人数、タクシーにおける乗車可能な人数、乗客又は運転士の属性（例えば性別、用途）、並びにタクシーの種別の情報等が必要である。

図２７は、実施の形態２における利用者端末装置１で表示される検索画面１３２の内容例を示す。実施の形態２では検索画面１３２で設定される「条件」に、「利用目的」、「業務番号」、「利用条件」、「支払方法」、及びリクエストの条件として「タクシー種別」に加え、相乗りの可否、乗客の人数、希望する乗客又は運転士の属性が設定されている。相乗りの可否は、「タクシー種別」にて「車種：ワンボックス」又は「福祉車両」が選択されている場合のみに選択可能な条件であってもよい。

図２８－図３０は、タクシーの相乗りを実現するデジタル帳票ＤＦに関する処理手順の一例を示すシーケンス図である。図２８－図３０に示す処理手順の内、実施の形態１の図１４のシーケンス、図１１の情報作成装置４の処理手順と共通する手順については同一のステップ番号を付して詳細な説明を省略する。

図２７に示した検索画面１３２にてリクエストのボタン１３４が選択された場合、利用者端末装置１から利用者を相乗り可の条件でのせるタクシーを募集するリクエストが情報作成装置４へ送信される（Ｓ２０１）。

情報作成装置４の制御部４０は、最初の利用者の利用者端末装置１からのリクエストに対する処理Ｓ１０１－Ｓ１０５を実行する。制御部４０は、相乗り可の条件込みで、ステップＳ３０３から送信された提供者端末装置２からの応募を利用者端末装置１へ通知する（Ｓ１０７）。

提供者端末装置２では、制御部２０が、近くにいる利用者からの募集に自装置が対応付けられた場合に募集を取得し（Ｓ３０１）、応募を受け付ける（Ｓ３０２）。

ステップＳ３０２の応募の受け付けは、提供者端末装置２が音声にて操作を受け付ける構成とするとよい。図１７の検索画面２３３にて、表示される募集内容のリスト２３４の夫々に、相乗りの可否の情報が追加され、相乗り可の募集内容が選択可能になる。ステップＳ３０２では既に乗客が乗っているタクシーの提供者端末装置２にて、相乗りを可としている募集が来ていることを音声で通知し、応募するか否かを音声認識によって受け付けてもよい（Ｓ３０２）。既に乗客が乗っているタクシーの提供者端末装置２では、別のデジタル帳票ＤＦが起票されている。つまり、同一の時間にサービスが実行される、提供者ＩＤが共通するデジタル帳票ＤＦの存在が可能である。

ステップＳ３０２の応募の受け付けでは、既に乗客がいるタクシーの提供者端末装置２からの相乗り状態での応募か否か、相乗り乗客を更に募集をするか否かが選択されることが必須とされてよい。

情報作成装置４の制御部４０は、提供者端末装置２からの応募をその条件（相乗り状態であるか、相乗り乗客を更に募集するか否か）と共にＳ１０１のリクエスト元の利用者端末装置１へ通知し（Ｓ１０７）、選定を受け付ける（Ｓ１０８）。ステップＳ１０８の選定のステップにおいて、相乗り乗客を更に募集をすることの可否の選択がされるとよい。

制御部４０は、選定された提供者端末装置２へ選定を通知し（Ｓ１０９）、確認を受け付ける（Ｓ１１０）、これらの処理と前後して又は同時的に、以下のステップＳ１２１の処理を実行する（図２８－図３０ではＳ１１０の後に実行する）。

制御部４０は、ステップＳ１２１にて、選定された提供者端末装置２からステップＳ１０６で受け付けた応募に、相乗り乗客を更に募集することが選択されているか、又はステップＳ１０８の選定を受け付けるステップで、相乗り乗客を更に募集をすることが可として選択されているか否かを判断する（ステップＳ１２１）。

相乗り乗客を更に募集をすることが選択されていないと判断された場合（Ｓ１２１：ＮＯ）、制御部４０は、処理をステップＳ１１１へ進め、以後の処理を実行する。この場合、乗客は１人で選定されたタクシーの利用を開始するか、既に乗客がいるタクシーの利用を開始する。

相乗り乗客を更に募集をすることが選択されていると判断された場合（Ｓ１２１：ＹＥＳ）、制御部４０は、選定された提供者端末装置２に対応する提供者ＩＤのみを指定したデジタル帳票ＤＦを起票する（ステップＳ１２２）。制御部４０は、相乗り可の募集条件に合致する利用者の利用者ＩＤを、利用者端末装置１から逐次受信している位置情報に基づいて抽出する（ステップＳ１２３）。制御部４０は、抽出した利用者ＩＤに対応付けて、ステップＳ１０３で記憶している募集条件の募集ＩＤを対応付ける（ステップＳ１２４）。制御部４０は、ステップＳ１２２の前に、新たな募集内容を、募集ＩＤを付与して記憶し、ステップＳ１２４で対応付けてもよい。ステップＳ１２２－１２４、及び以後の処理は、リクエスト元の利用者のタクシーの乗車開始と並行して行なわれてよい。

制御部４０はその後、図２１のシーケンス図におけるステップＳ１０６に対応する処理（ステップＳ１２６）によって新たな同乗者の利用者からの応募を受け付け、提供者端末装置２又は元のリクエスト送信者の利用者の利用者端末装置１へ通知して（ステップＳ１２７）、選定を受け付ける（ステップＳ１２８）。

この間、利用者端末装置１及び／又は提供者端末装置２では、応募通知を受け付け（ステップＳ２２２、ステップＳ３２２）、選定を受け付けて（ステップＳ２２３、ステップＳ３２３）、選定を送信する（ステップＳ２２４、ステップＳ３２４）。

制御部４０は、選定された利用者の利用者端末装置１へ選定を通知し（ステップＳ１２９）、確認を受け付ける（ステップＳ１３０）。

もう１つの利用者端末装置１では、ステップＳ１２４で対応付けられた募集を取得し（ステップＳ２３１）、応募を受け付け（ステップＳ２３２）、応募を送信する（ステップＳ２３３）。選定が通知された場合、この利用者端末装置１の制御部１０は、選定通知を受け付け（ステップＳ２３４）、利用者からの確認を受け付けて送信する（ステップＳ２３５）。

情報作成装置４の制御部４０は、以後ステップＳ１１１を実行し、ステップＳ１０２のデジタル帳票ＤＦに提供者を追記すると共に、更なる乗客がいる場合にはステップＳ１２２のデジタル帳票ＤＦに利用者を追記し（ステップＳ１３１）、デジタル帳票ＤＦに対する進行状況をモニタする（ステップＳ１３２）。

制御部４０は、相乗り中のいずれかの利用者が降車し、サービス提供が終了したことを検知すると（ステップＳ１３３）、降車した利用者の利用距離と、相乗り利用による割引を考慮した料金を算出し（ステップＳ１３４）、算出した料金を追記する（ステップＳ１３５）。ステップＳ１３４において制御部４０は、相乗り区間における距離に応じた割引を適用してもよいし、相乗りを利用したことに対して利用区間全てについて割引を適用してもよい。

制御部４０は、相乗りした利用者全てのサービス提供が完了したか否かを判断し（ステップＳ１３６）、サービス提供が完了していないと判断された場合（Ｓ１３６：ＮＯ）、処理をステップＳ１３２へ戻す。

ステップＳ１３６にてサービス提供が完了したと判断された場合（Ｓ１３６：ＹＥＳ）、制御部４０は処理を終了する。

相乗りを実現するための処理は、これに限らず、例えばステップＳ１０４の時点で募集条件に合致する提供者のみならず、募集条件に合致する利用者も抽出してもよい。ステップＳ１０４における抽出では、リクエストに含まれるタクシーの利用経路の出発地点、経由可能な地点の周辺に情報作成装置４の制御部４０はステップＳ１０５において、提供者端末装置２のみならず利用者の利用者端末装置１も対応付ける。そしてステップＳ１０６において、利用者端末装置１及び提供者端末装置２の両方から応募を受け付けてもよい。

提供者端末装置２は、タクシー車両毎、乗務員毎に使用する構成として説明したが、タクシーの事業所に設置される端末であってもよい。この場合、オペレータが各タクシー運転手と無線等によってタクシー及び乗客の手配を行ないながら提供者端末装置２を操作し、相乗りの乗客をマッチングしてもよい。

実施の形態１と同様に、提供者端末装置２からのリクエストを起点として、相乗りを可とする利用者を乗客として募集することによって相乗りを実現してもよい。図３１は、実施の形態２において提供者端末装置２で表示される検索画面２３３の内容例を示す。実施の形態２の提供者端末装置２の検索画面２３３ではリクエストの「条件」として、乗客の位置、出発時間、乗客の最大人数、相乗りの可否、利用者の属性の設定が可能である。リクエストの条件の各項目の隣にドロップダウンメニューを表示するためのボタン２３７が含まれ、どのような条件とするかを設定することができる。利用者の属性としては、性別の指定が可能である。これにより、女性限定専用の相乗りタクシーを実現できる。ボタン２３７を選択した場合に表示されるドロップダウンメニュー内の選択によって相乗りの可否の設定が可能である。また提供者端末装置２からリクエストを送信する場合、又はリクエストに対して応募する場合に、ドロップダウンメニューから割引等の設定を選択することが可能である。

タクシーの車種が福祉車両であり、複数の利用者が乗ることができる車両である場合、車いすでの移動な必要な人の相乗り同乗者の募集が実現できる。

実施の形態２で示したように、本開示のプラットフォームの利用によって、相乗りタクシーにおける支払精算が可能になる。利用者にとっても相乗りを可としたことによる割引等を受けた上で実際に乗車した距離の分だけ、後に精算が可能である。経費処理のみならず個人利用も可能である。経費処理を選択した利用者と、個人利用を選択した利用者が同乗したとしても夫々のデジタル帳票ＤＦに基づいて決済及び経費処理が可能である。このように本開示のプラットフォームを利用することによって、相乗りタクシー事業の実現が容易になる。

（実施の形態３）
実施の形態１及び２では、タクシー又は他の交通機関への適用を例に挙げて説明したが、他のサービス提供に対しても適用可能である。実施の形態３では、宿泊施設、飲食店のサービスに適用した場合について説明する。具体的には、提供者である宿泊施設から、その施設の近くに存在する利用者に対して宿泊客として募集することを例として説明する。以下に説明する利用者の募集の処理は、飲食店にて顧客を募集する処理にも適用可能である。

図３２は、実施の形態３において提供者端末装置２に表示される画面の一例を示す。提供者端末装置２は、宿泊施設毎に設置されるパーソナルコンピュータに端末用アプリケーションプログラム２Ｐをインストールし、提供者ＩＤに対応するアカウント情報に基づき使用されるものであり、施設の管理者が操作する。図３２に示すメイン画面２３０には、宿泊施設向けに特化された宿泊管理アプリケーションに組み込まれた端末用アプリケーションプログラム２Ｐに基づき、当日の宿泊一覧と、宿泊客を募集するリクエストのためのボタン２３２を含む。リクエストには図３２に示すように、当日の宿泊における宿泊人数、割引設定等をドロップダウンメニューのためのボタン２３７によって設定可能である。

図３２に示されたリクエストのボタン２３２が選択された場合、提供者端末装置２の制御部２０は、図２１のシーケンス図に示したステップＳ３１１の宿泊客を募集するリクエストを通信部２２から情報作成装置４へ送信する処理を実行する。

宿泊施設の提供者端末装置２から送信されたリクエストを起点とする処理手順は、実施の形態１の図２１のシーケンス図に示したステップＳ３１１以降のシーケンスと同様であるから詳細な説明は省略する。図２１のシーケンス図におけるタクシー事業者に係る処理は、宿泊施設における処理に代替される。

図３３は、実施の形態３において利用者端末装置１に表示される画面の一例を示す。図３３に示す画面例は、メイン画面１３０である。メイン画面１３０には、利用サービスのリストに加えて通知欄１４３が含まれる。通知欄１４３には、利用者端末装置１が対応する利用者ＩＤを抽出対象とした募集のリスト１４４が表示される。図３３のリスト１４４では例えば図３２に示した提供者「Ｅホテル品川」にて品川駅１０００ｍ以内に存在する利用者を抽出した募集のリストが表示されている。過去に利用した履歴のある利用者、過去に支払履歴がある支払者の組織に属する利用者が優先して抽出されてもよい。リスト１４４には、各募集に対し、いずれかを選択するためのボタン１４５が含まれている。ボタン１４５が選択されると、募集内容の詳細と共に応募を受け付ける画面が表示される。

利用者は、応募時に経費処理なのか、個人負担であるのかの選択が可能である。経費処理である場合は、利用者が属する組織を支払者として、デジタル帳票ＤＦが完成する。支払者の承認が得られれば、これに基づいて決済及び経費処理が可能になる。このようにして同様の処理手順によって、宿泊施設からの空き室の販売機会の増進を見込むことができると共に、経費処理も容易化され、利用者にとっても利便性が非常に高い。

（実施の形態４）
実施の形態４では、プラットフォームを利用する多様なサービス提供者の内、医療に関するサービスについて説明する。実施の形態４におけるサービス提供者である医療サービス事業者は、プラットフォームを利用することによって公的な補助がされる検診サービスを実現する。具体的には、支払者である自治体（若しくは国）から、特定の条件の利用者に対して医療機関への検診者として利用者を募集することを例として説明する。

図３４は、実施の形態４において支払者端末装置３に表示される画面の一例を示す。支払者端末装置３は、自治体に設置されるパーソナルコンピュータに支払者ＩＤと対応する端末用アプリケーションプログラム３Ｐをインストールしたものであり、自治体が支払者となるサービスに関する管理者が操作する。図３４に示すメイン画面３３０には、自治体向けの画面に、検診の受診者を募集するリクエストのためのボタン３３２を含む。リクエストには図３４に示すように、受診の対象者となる利用者を絞り込むための設定項目をドロップダウン用のボタン３３１によって設定可能である。図３４で示すように、募集の条件として年齢、性別、補助内容が設定可能である。

図３４に示されたリクエストのボタン３３２が選択された場合、支払者端末装置３の制御部３０は、受診者を募集するリクエストを通信部３２から情報作成装置４へ送信する。

自治体の支払者端末装置３から送信されたリクエストを起点とする処理手順は、実施の形態１の第３のケースで説明した処理手順と同様であるから詳細な説明を省略する。

図３５は、実施の形態４において利用者端末装置１に表示される画面の一例を示す。図３５に示す画面例は、端末用アプリケーションプログラム１Ｐに基づき表示されるメイン画面１３０である。メイン画面１３０に含まれる通知欄１４３に、利用者端末装置１が対応する利用者ＩＤを抽出対象とした募集のリスト１４４が表示される。図３５のリスト１４４では、図３５に示した支払者「Ｔ市」が検診クーポンの対象とする利用者を抽出した募集のリストが表示されている。リスト１４４には、各募集に対し、いずれかを選択するためのボタン１４５が含まれている。ボタン１４５が選択されると、募集内容の詳細と共に応募を受け付ける画面が表示される。

本開示のプラットフォームは、上述したような検診クーポンのみならず、乳幼児医療、高齢者医療、ワクチン接種等の自治体による医療機関における費用の補助に適用することも可能である。このように本開示のプラットフォームでは、利用者による提供者からのサービスの提供完了によってデジタル帳票ＤＦを完成させて決済、経費処理が可能となるので、利用者が実際に診療を受けたのか、検査を受けたのか等を、支払者が確認した上で経費処理が可能である。したがって利用者が医療機関で実際に予防接種、定期検診を受けたことのエビデンスを持って、利用者以外の支払者が実費を支払うこと、即ち受診をエビデンスとして経費支払が可能である。

上述のように開示された実施の形態は全ての点で例示であって、制限的なものではない。本発明の範囲は、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれる。

１ 利用者端末装置
１０ 制御部
１１ 記憶部
１２ 通信部
１３ 表示部
１３８ デジタルチケット
１Ｐ，２Ｐ，３Ｐ 端末用アプリケーションプログラム
２ 提供者端末装置
２０ 制御部
２２ 通信部
３ 支払者端末装置
３０ 制御部
３２ 通信部
４ 情報作成装置
４０ 制御部
４１ 記憶部
４２ 通信部
４０１ サービスＤＢ
４Ｐ 情報処理プログラム

Claims (2)

1. サービス又は商品の対価の決済に必要となる取引情報を作成する情報作成方法であって、
   利用者の利用者端末装置と、該利用者端末装置が通信接続し、起票のリクエストに基づきデジタル帳票データを作成する情報作成装置とを含むシステムにて、
   前記利用者端末装置がサービス又は商品の内容の選択を受け付け、
   選択されたサービス又は商品を利用する利用者の利用者識別情報を含み、前記サービス又は商品の提供を条件として取引情報の起票のリクエストを、前記利用者端末装置から前記情報作成装置へ送信し、
   前記情報作成装置は、新たに又は予め応募される前記サービス又は商品の提供者の提供者識別情報と、前記情報作成装置にて新たに又は予め応募される前記サービス又は商品の対価を支払う支払者の支払者識別情報とから、前記条件に対応するものとして、前記情報作成装置にて抽出し、
   前記利用者端末装置が、
   抽出された前記提供者識別情報及び支払者識別情報のリストと、
   前記リストから前記提供者識別情報及び支払者識別情報のいずれかの選択を、前記対価の額の決定前に任意の順で受け付け可能であって、前記リストから支払者識別情報を前記対価の額の決定後に受け付け可能である選択インタフェース、及び、前記サービス又は商品に係る対価の支払いを前記支払者における経費処理とするか又は利用者の個人負担とするかの選択を、前記対価の額の決定前又は決定後のタイミングで、任意に選択可能な選択インタフェースを含む画面と
   を含む検索画面を表示し、
   前記選択インタフェースで、提供者識別情報の選択、支払者識別情報の選択、前記経費処理とするか又は利用者の個人負担とするかの選択のうちのいずれかが選択される都度、選択された項目を前記情報作成装置で受信し、残りの項目を受け付ける選択インタフェースを含む画面を前記利用者端末装置で表示する
   情報作成方法。
2. 表示部を備える利用者端末装置と、前記利用者端末装置に通信接続可能であって起票のリクエストに基づきデジタル帳票データを作成する情報作成装置とを含むシステムにて、前記情報作成装置から、サービス又は商品の対価の決済に必要となる取引情報の情報を前記利用者端末装置に表示させるコンピュータプログラムであって、
   前記情報作成装置に、
   前記利用者端末装置にてサービス又は商品の内容の選択を受け付け、
   選択されたサービス又は商品を利用する利用者の利用者識別情報を含み、前記サービス又は商品の提供を条件として取引情報の起票のリクエストを、前記利用者端末装置から受信し、
   新たに又は予め応募される前記サービス又は商品の提供者の提供者識別情報と、前記サービス又は商品の対価を支払う支払者の支払者識別情報とから、前記条件に対応するものとして、前記情報作成装置にて抽出し、
   抽出された前記提供者識別情報及び支払者識別情報のリストと、
   前記リストから前記提供者識別情報及び支払者識別情報のいずれかの選択を、前記対価の額の決定前に任意の順で受け付け可能であって、前記リストから支払者識別情報を前記対価の額の決定後に受け付け可能である選択インタフェース、及び、前記サービス又は商品に係る対価の支払いを前記支払者における経費処理とするか又は利用者の個人負担とするかの選択を、前記対価の額の決定前又は決定後のタイミングで、任意に選択可能な選択インタフェースを含む画面と
   を含む検索画面を前記利用者端末装置に表示させ、
   前記選択インタフェースで、提供者識別情報の選択、支払者識別情報の選択、前記経費処理とするか又は利用者の個人負担とするかの選択のうちのいずれかが選択される都度、選択された項目を受信し、残りの項目を受け付ける選択インタフェースを含む画面を前記表示部に表示させる
   処理を実行させるコンピュータプログラム。

Images