本開示をその実施の形態を示す図面を参照して具体的に説明する。以下の実施の形態では、本開示の情報作成方法を適用した情報作成システムについて説明する。
(実施の形態1)
図1は、情報作成システム100の概要を示す図である。情報作成システム100は、サービス又は商品の利用者と、サービス又は商品を提供する提供者と、サービス又は商品の利用に必要な料金を支払う支払者との間での料金の決済、支払者における経費処理に必要な取引情報を作成するシステムである。
情報作成システム100は、利用者が実際にサービス又は商品をキャッシュレスで享受でき、実際の利用に則した料金が確定した場合には支払者から提供者へ支障なく料金が支払われる仕組みを実現するプラットフォームを提供する。本開示のプラットフォームでは、決済、又は経費処理の根拠とすることができる取引情報として、デジタル帳票DFを用いる。
本開示のプラットフォームでは、1つ1つの取引に対してデジタル帳票DFが起票され、起票されたデジタル帳票DFを元にデジタルチケットが発行されて利用者によって利用可能となる。本開示のプラットフォームは、サービス又は商品の内容は、デジタル帳票DFが起票された後に決定することを許容し、支払者として利用者自身のみならず、利用者の雇用者、利用者のスポンサーであることを許容する。
本開示のプラットフォームでは、利用者、提供者、又は支払者のいずれか1つから、サービス(商品)を受けたい、サービス(商品)のユーザを募集しているといったリクエストを受け付ける。プラットフォームは、リクエストにマッチするサービス提供者、支払者、又は利用者等を募集し、利用者、提供者及び支払者の情報及び料金が確定した場合に、支払者から提供者への料金の支払いが実行されることを保証する。決済サービスは別途異なるシステムであってよく、本開示のプラットフォームは、決済サービスが使用する支払の根拠となるデジタル帳票DFを作成する。プラットフォームにおいて支払者は、料金が確定した場合に、利用者が確実にサービス又は商品を享受したかを確認した上で料金を提供者へ支払うことが可能である。提供者は、利用者自身又は利用者の雇用者等である支払者から料金を確実に回収することができる。利用者はキャッシュレスでサービス又は商品を享受できる。
利用者、提供者、及び支払者は夫々、このようにキャッシュレス及び確実な支払を実現するプラットフォームを利用するために、コンピュータプログラムを自身のコンピュータにインストールし、プラットフォーム事業者と契約する。プラットフォーム事業者との契約で発行されるアカウントの種別によって、このコンピュータプログラムを使用する利用者、提供者及び支払者のコンピュータは夫々、利用者端末装置1、提供者端末装置2、及び、支払者端末装置3となる。
本開示のプラットフォームによって提供される機能は具体的には、利用者端末装置1、提供者端末装置2、及び支払者端末装置3が通信接続可能なサーバとして機能するコンピュータである情報作成装置4における処理によって実現される。
ネットワークNは、所謂インターネットである公衆通信網N1と、所定の移動通信規格による無線通信を実現するキャリアネットワークN2とを含む。公衆通信網N1にはアクセスポイントAPが含まれる。キャリアネットワークN2には基地局BSが含まれる。利用者端末装置1、提供者端末装置2、及び支払者端末装置3は夫々、情報作成装置4と公衆通信網N1又はキャリアネットワークN2を介して通信接続が可能である。支払者端末装置3は、専用線を介して情報作成装置4と通信接続が可能であってもよい。
図2は、情報作成システム100の利用者端末装置1の構成を示すブロック図である。利用者端末装置1は上述したようにスマートフォン等の通信機能を有するコンピュータを用いる。利用者端末装置1は、制御部10、記憶部11、通信部12、表示部13、操作部14、読取部15及び位置情報取得部16を備える。
制御部10は、CPU(Central Processing Unit )又はGPU(Graphics Processing Unit)を用いたプロセッサであり、内蔵するROM(Read Only Memory)及びRAM(Random Access Memory)等のメモリを用い、各構成部を制御して処理を実行する。制御部10は、プロセッサ、メモリ、記憶部11及び通信部12を集積した1つのハードウェア(SoC:System On a Chip)として構成されていてもよい。制御部10は、記憶部11に記憶されている端末用アプリケーションプログラム1Pに基づいて情報作成装置4と通信接続が可能であり、後述するサービス利用に係る情報を表示し、操作を受け付ける。
記憶部11は、フラッシュメモリを用い、端末用アプリケーションプログラム1Pを含む制御部10が参照するプログラム及びデータを記憶する。記憶部11には、サービスの利用者を識別する利用者IDとなるアカウント情報が記憶されている。制御部10は、利用者IDに対応するアカウント情報及び端末用アプリケーションプログラム1Pに基づき、利用者向けのグラフィカルインタフェースを表示部13に表示させ、利用者用のアプリケーションとして情報作成装置4と情報を送受信する。
通信部12は、公衆通信網N1又はキャリアネットワークN2を介した情報作成装置4との無線通信を実現する無線通信モジュールである。通信部12は例えば、Wi-Fi に対応する無線通信デバイス、又は、キャリア通信用モジュールを用いる。
表示部13は、液晶パネル又は有機ELディスプレイ等のディスプレイ装置を用いる。操作部14は、利用者の操作を受け付けるインタフェースであり、物理ボタン、ディスプレイ内蔵のタッチパネルデバイス、スピーカ及びマイクロフォン等を用いる。操作部14は、物理ボタン又はタッチパネルにて表示部13で表示している画面上で操作を受け付けてもよいし、マイクロフォンにて入力音声から操作内容を認識し、スピーカで出力する音声との対話形式で操作を受け付けてもよい。
読取部15は、提供者ID等のコードを読み取るリーダである。読取部15は、バーコードリーダ、カメラ、及び無線タグリーダの内の少なくともいずれか1つである。読取部15は、それらのいずれをも含み、コードの提示態様によっていずれかを選択的に使用してコードを読み取ってもよい。読取部15は読み取ったコードを制御部10へ通知する。
位置情報取得部16は、利用者端末装置1の位置情報を取得するデバイスである。位置情報取得部16は、GPS(Global Positioning System)受信デバイスを用いるか、又は、通信部12のWi-Fi によって位置情報を特定するデバイスを用いてもよい。
図3は、情報作成システム100の提供者端末装置2の構成を示すブロック図である。提供者端末装置2は上述したようにタブレット端末等の通信機能を有するコンピュータを用いる。サービスを実際に提供するスタッフではなくサポートスタッフ又は管理者が使用する提供者端末装置2は、デスクトップ、ラップトップ型のパーソナルコンピュータを用いる。
提供者端末装置2は、制御部20、記憶部21、通信部22、表示部23、操作部24及び読取部25を備える。
制御部20は、CPU又はGPUを用いたプロセッサであり、内蔵するROM又はRAM等のメモリを用い、各構成部を制御して処理を実行する。制御部20は、記憶部21に記憶されている端末用アプリケーションプログラム2Pに基づいて情報作成装置4と通信接続が可能であり、サービス提供に係る情報を表示し、操作を受け付ける。
記憶部21は、フラッシュメモリを用い端末用アプリケーションプログラム2Pを含む制御部20が参照するプログラム及びデータを記憶する。記憶部21には、サービス提供者を識別する提供者IDに対応するアカウント情報が記憶されている。記憶部21は、提供者端末装置2を操作する個別のスタッフを個々に識別する情報を記憶していてもよい。制御部20は、提供者IDに対応するアカウント情報及び端末用アプリケーションプログラム2Pに基づき、提供者向けのグラフィカルインタフェースを表示部23に表示させ、提供者用のアプリケーションとして情報作成装置4と情報をやり取りする。
通信部22は、公衆通信網N1又はキャリアネットワークN2を介した情報作成装置4との無線通信を実現する無線通信モジュールである。通信部22は例えば、Wi-Fi に対応する無線通信デバイス、又は、キャリア通信用モジュールを用いる。
表示部23は、液晶パネル又は有機ELディスプレイ等のディスプレイ装置を用いる。操作部24は、サービス提供者の操作を受け付けるインタフェースであり、物理ボタン、ディスプレイ内蔵のタッチパネルデバイス、スピーカ及びマイクロフォン等を用いる。操作部24は、物理ボタン又はタッチパネルにて表示部23で表示している画面上で操作を受け付けてもよいし、マイクロフォンにて入力音声から操作内容を認識し、スピーカで出力する音声との対話形式で操作を受け付けてもよい。
読取部25は、他の機器から情報を読み取るリーダである。読取部25は、バーコードリーダ、又はカメラであってもよい。読取部25は、サービスの料金を計算するための他の装置(レジ端末、メータ)と接続されるインタフェースであってもよい。料金は、操作部24を用いて入力されてもよい。
読取部25は、後述するように利用者端末装置1から提示された利用者IDを読み取るリーダとして機能してもよい。この場合、読取部25はバーコードリーダ、カメラ、又は近距離無線通信モジュールであり、サービス又は商品の顧客である利用者の利用者IDを含む情報を取得する。読取部25は読み取った情報を制御部20へ通知する。
提供者端末装置2においても、後述するようにタクシー運転手が所持するものである場合、位置情報が取得できることが望ましい。提供者端末装置2は位置情報取得部を備えてもよいし、タクシーメータ、ナビシステムから位置情報を取得できるようにしてもよい。
提供者端末装置2は、サービスがタクシー事業であればタクシーメータ、飲食店であればレジ端末、宿泊業であればチェックインチェックアウトシステムから料金を取得できるようにしてあれば汎用コンピュータに端末用アプリケーションプログラム2Pをインストールし、提供者IDを対応付けることで実現される。
図4は、情報作成システム100の支払者端末装置3の構成を示すブロック図である。支払者端末装置3は上述したように、支払者である企業の経理部門、利用者の上長で決済権利を有する管理者、又はスポンサーとなり得る利用者により使用される。支払者端末装置3は、パーソナルコンピュータ又はサーバコンピュータでもよいし、経理部門のスタッフによって個々に管理されるタブレット端末、スマートフォンであってもよい。
支払者端末装置3は、制御部30、記憶部31、通信部32、表示部33及び操作部34を備える。
制御部30は、CPU又はGPUを用いたプロセッサであり、内蔵するROM又はRAM等のメモリを用い、各構成部を制御して処理を実行する。制御部30は、記憶部31に記憶されている端末用アプリケーションプログラム3Pに基づき、情報作成装置4と通信接続が可能であり、後述する支払承認に関する情報を表示し、操作を受け付ける。
記憶部31は、ハードディスク又はSSD(Solid State Drive )を用いる。記憶部31は、端末用アプリケーションプログラム3Pを含む制御部30が参照するプログラム及びデータを記憶する。記憶部31には、支払者を識別する支払者IDとなるアカウント情報が記憶されている。記憶部31には、図4に示すように、支払者の企業に所属する利用者の利用者ID、及び利用者の属性を含む利用者情報を含む支払者DB301が記憶されていてもよい。経理部門で使用される支払者端末装置3の支払者DB301には、決済が完了した経費情報が含まれてもよい。
制御部30は、記憶部31に記憶されている支払者IDに対応するアカウント情報及び端末用アプリケーションプログラム3Pに基づき、支払者向けのグラフィカルインタフェースを表示部33に表示させ、支払者用のアプリケーションとして情報作成装置4と情報をやり取りする。
通信部32は、情報作成装置4との通信接続を実現するネットワークカードである。支払者端末装置3は、公衆通信網N3を介して情報作成装置4に通信接続してもよいし、専用線を介して情報作成装置4に通信接続してもよい。
表示部33は、液晶パネル又は有機ELディスプレイ等のディスプレイ装置を用いる。操作部34は、企業の経理部門のスタッフの操作を受け付けるインタフェースであり、キーボード及びポインティングデバイスを用いる。操作部34は、スピーカ及びマイクロフォン等を用い、マイクロフォンにて入力音声から操作内容を認識し、スピーカで出力する音声との対話形式で操作を受け付けてもよい。
端末用アプリケーションプログラム1P,2P,3Pは、コンピュータの種別(ラップトップ、デスクトップか、スマートフォン又はタブレット端末か)に対しては異なるが、機能は共通するアプリケーションプログラムである。利用者端末装置1の記憶部11に利用者IDに対応するアカウント情報のみならず、プラットフォーム事業者との契約の上で支払者IDに対応するアカウント情報も記憶されている場合、利用者端末装置1は、支払者端末装置3にもなり得る。即ち利用者はアカウントの切り替えによって、上長の承認者即ち支払者権限で振る舞うことも可能である。同様にして利用者端末装置1は、提供者端末装置2にも切り替わることが可能である。勿論、端末用アプリケーションプログラム1P,2P,3Pは、利用者向け、サービス提供者向け、及び支払者向けに夫々特化したコンピュータプログラムとして提供されてもよい。
図5は、情報作成装置4の構成を示すブロック図である。情報作成装置4は上述したように、サーバコンピュータを用いる。実施の形態1において以下では、情報作成装置4は1台のサーバコンピュータとして説明するが、複数のサーバコンピュータで機能又は処理を分散させてもよい。
情報作成装置4は、制御部40、記憶部41、通信部42及び入出力部44を備える。制御部40は、CPU又はGPUを用いたプロセッサであり、内蔵するメモリを用いて各構成部を制御して処理を実行する。制御部40は、記憶部41に記憶されている情報処理プログラム4Pに基づく情報処理を実行する。
記憶部41は、ハードディスク又はSSDを用いる。記憶部41は、情報処理プログラム4Pを記憶しているほか、制御部40が参照する他のプログラム及びデータを記憶する。
通信部42は、公衆通信網N1又はキャリアネットワークN2における通信を実現する。制御部40は、通信部42により公衆通信網N1又はキャリアネットワークN2を介して利用者端末装置1、提供者端末装置2又は支払者端末装置3との間で情報の送受信が可能である。
入出力部44は、プラットフォームに関する各種情報を記憶するサービスDB(Data Base :データベース)401との接続インタフェースである。サービスDB401は、記憶部41内に構築されてもよい。
サービスDB401は、利用者DB402、提供者DB403、支払者DB404、帳票DB405、募集条件DB406を含む。
図6は、利用者DB402に記憶される情報の内容例を示す図である。利用者DB402は、利用者IDに対応付けて利用者の名前等の属性を記憶している。属性には利用者の電話番号、メールアドレス等の連絡先情報、所属する企業名、社員ID等が含まれるとよい。利用者DB402は、利用者IDに対応付けて利用者が所属する企業による経費に計上する場合のデフォルトの支払者を識別する支払者IDを記憶している。経費に計上する場合の勘定科目と関連付けたデフォルトの業務番号が記憶されていてもよい。利用者DB402は、利用者の銀行口座を識別する情報、又は利用者個人のクレジットカードの情報である支払情報を記憶する。
図7は、提供者DB403に記憶される情報の内容例を示す図である。提供者DB403は、サービス又は商品の提供者の提供者IDに対し、提供者の名前等の属性、提供者の種別等を記憶する。提供者IDは、提供者が組織的である場合に直接的なサービス提供スタッフ、例えばタクシーの運転手、飲食店の店舗又は飲食店のスタッフID等で識別されてもよいし、事業者毎に識別されてもよい。提供者DB403は、提供者への料金の入金用銀行口座を識別する情報を記憶する。
図8は、支払者DB404に記憶される情報の内容例を示す図である。支払者DB404は、支払者の支払者IDを対応付けて支払者である企業の名称等の属性を記憶する。支払者DB404は、支払者の引き落とし用、払込用の銀行口座を識別する情報を記憶する。
支払者IDは支払者である企業からの申請に応じてプラットフォーム事業者によって発行される。利用者IDは、支払者からの申請に、支払者の組織に属する利用者の分だけ発行される。利用者IDは、個人的に発行されてもよく、この場合支払者のデフォルトは利用者自身である。利用者DB402、及び支払者DB404に記憶される情報は、発行された支払者ID又は利用者IDに対応付けて支払者によって支払者端末装置3から遠隔で登録されてもよい。提供者DB403に記憶される情報も、サービス又は商品の提供者からの加盟申請に応じて管理者により発行される提供者IDに対応付けて登録されてよい。
図9は、帳票DB405に記憶される情報の内容例を示す図である。帳票DB405は、デジタル帳票DFを記憶する。デジタル帳票DFは、取引ID、発行日時、利用開始日時、利用終了日時、利用目的、利用したサービス又は商品の名称、詳細内容、金額、利用者の利用者ID、サービス又は商品を提供する提供者の提供者ID、支払者の支払者IDを含む。デジタル帳票DFは、個人負担又は経費処理かの種別を含む。経費処理の場合には勘定項目を識別できるように業務番号が含まれるとよい。1回の利用に対して支払者と利用者自身とで費用が分担される場合、第2の支払者として利用者ID又は他の支払者の支払者IDが含まれる。デジタル帳票DFは、利用者の利用者ID、サービス又は商品を提供する提供者の提供者ID、及び支払者の支払者IDの内のいずれかが1つで発行可能な情報である。デジタル帳票DFは、後述するようにサービス提供の進行状況に沿って順次完成される。デジタル帳票DFは、決済に必要な情報がサービス完了後に確定することを許容する。
図10は、募集条件DB406に記憶される情報の内容例を示す図である。募集条件DB406は、情報作成装置4へ送信される利用者端末装置1、提供者端末装置2又は支払者端末装置3からのリクエストに含まれる募集条件の内容を記憶する。募集条件は、募集を識別するための募集IDに対応付けられ、料金、場所等の条件の内容と、募集によって起票されたデジタル帳票DFの取引IDとを含む。募集が終了すると情報作成装置4によって募集条件は消去される。
このように構成される情報作成システム100においてプラットフォームとして機能する情報作成装置4は、利用者ID、提供者ID及び支払者IDの内の少なくとも1つが定まるとデジタル帳票DFを起票する。デジタル帳票DFにおいて利用者IDは、サービス又は商品の享受に関する取引において、利用者が誰であるかを示す。提供者IDは、利用者に提供されるサービス又は商品が何であるかに対応する。支払者IDは、サービス又は商品に対する対価を誰が支払うかを示す。情報作成装置4は、起票したデジタル帳票DFにおける全ての情報が確定した場合に支払の根拠となるデジタル帳票DFを完成させる。情報作成装置4は、完成したデジタル帳票DFを元にして決済サービスへ決済を要求することが可能であり、決済が完了すると経費情報を作成して支払者端末装置3へ送信することが可能である。
プラットフォームの利用準備手順について説明する。利用準備では、企業の経理部門が、パーソナルコンピュータに、情報作成装置4又は図示しない配信サーバから配信される端末用アプリケーションプログラム3Pをインストールする。端末用アプリケーションプログラム3Pのインストールと、企業に対し支払者IDとして発行されたアカウント情報とにより、汎用コンピュータであるパーソナルコンピュータは情報作成システム100の支払者端末装置3として機能する。端末用アプリケーションプログラム3Pに基づき支払者端末装置3は、経理部門のオペレータから支払者ID、及び名称等の属性の登録を受け付け、受け付けた支払者ID及び属性の情報を情報作成装置4へ送信する。支払者IDは事前の申請によって情報作成装置4を管理するプラットフォーム事業者から発行されたものであってもよい。支払者端末装置3は、サービス又は商品の提供者への料金の支払いに用いられる決済用銀行口座の情報を受け付け、情報作成装置4へ送信する。これにより、図6に示したように支払者DB404に支払者の情報が支払者IDに対応付けて記憶される。支払者端末装置3は、オペレータの操作に基づき、支払者である企業等の組織に所属する利用者の人数分の利用者IDの発行を情報作成装置4へ依頼し、発行された利用者IDを受信するとよい。
実施の形態1の情報作成システム100では、利用者はスマートフォンに、情報作成装置4又は図示しない配信サーバから配信される端末用アプリケーションプログラム1Pをインストールする。端末用アプリケーションプログラム1Pのインストールと、利用者に対して利用者IDとして発行されたアカウント情報とにより、汎用コンピュータであるスマートフォンは情報作成システム100の利用者端末装置1として機能する。端末用アプリケーションプログラム1Pに基づき利用者端末装置1は、利用者から利用者ID、及び名前、メールアドレス等の連絡先を含む属性の登録を受け付け、受け付けた利用者ID及び属性の情報を情報作成装置4へ送信する。利用者IDは、デフォルトの支払者との関係を正確に対応付けるために、上述したように支払者となる所属企業からの申請によって情報作成装置4にて予め発行されたものであることが好ましい。利用者端末装置1は、端末用アプリケーションプログラム1Pの個人利用時の支払情報の登録を受け付け、情報作成装置4へ送信する。個人利用時の支払情報は、利用者個人の銀行口座、又はクレジットカード情報である。これにより、図6に示したように利用者DB402に利用者の情報が利用者IDに対応付けて記憶される。
利用準備段階においてサービス又は商品の提供者は、パーソナルコンピュータ又はスタッフのタブレット端末に、情報作成装置4又は図示しない配信サーバから配信される端末用アプリケーションプログラム2Pをインストールする。端末用アプリケーションプログラム2Pのインストールと、事前にプラットフォーム事業者との契約に基づき提供者IDとして発行されたアカウント情報とにより、汎用コンピュータであるパーソナルコンピュータ又はタブレット端末は、情報作成システム100の提供者端末装置2として機能する。端末用アプリケーションプログラム2Pに基づき提供者端末装置2は、サービス提供者のオペレータから提供者ID、及び名称等の属性の登録を受け付け、受け付けた提供者ID及び属性の情報を情報作成装置4へ送信する。同一のサービス事業者で、複数台の提供者端末装置2を用いる場合、事業者の経理部門のオペレータが用いるパーソナルコンピュータの提供者端末装置2にて登録を受け付けるとよい。この特定の提供者端末装置2は、サービス又は商品に係る料金の入金に用いられる入金用銀行口座の情報を受け付け、情報作成装置4へ送信する。これにより、図7に示したように提供者DB403に提供者の情報が提供者IDに対応付けて記憶される。
提供者端末装置2は利用準備の一環として、サービスを識別するサービスコードの発行をプラットフォーム事業者へ依頼する。サービスコードは例えば、提供者を事象単位毎に識別するIDであって提供者IDと同一でもよいし、提供者が複数のスタッフにて構成されている場合に、スタッフを個々に識別するIDであってもよいし、スタッフの配置場所を識別するIDであってもよい。この場合、特定の提供者端末装置2は、スタッフの識別情報の数分のサービスコードの発行を、各々のスタッフを識別する情報と対応付けて情報作成装置4へ依頼してもよい。特定の提供者端末装置2以外の提供者端末装置2は、提供者に対して発行された提供者IDを少なくとも含むサービスコードを受信して用いる。サービスコードが提供者毎ではなくスタッフ又は配置場所等を識別するように付される場合には、各スタッフが用いる提供者端末装置2は、提供者IDにスタッフを識別する情報を合わせたサービスコードを用いてよい。提供者は、サービスの提供場所で二次元コード化された提供者ID、又はサービスコードを提示するとよい。提示方法は、シール媒体に印刷して貼付する方法であってもよいし、提供者端末装置2の表示部23に表示される方法であってもよい。
上述の利用準備に基づく実際のサービス利用時の処理についてフローチャートを参照して説明する。プラットフォームの情報作成装置4は、利用者、提供者、又は支払者のいずれか1つから、サービス(商品)を受けたい、サービス(商品)のユーザを募集しているといったリクエストを受け付けると利用者、提供者及び支払者間でマッチングを行なう。情報作成装置4は具体的には、以下に示す処理を実行する。図11は、情報作成装置4における処理手順の一例を示すフローチャートである。
利用者端末装置1は、利用者IDを用いて端末用アプリケーションプログラム1Pを利用している間、即ち、端末用アプリケーションプログラム1Pに基づき利用者向けの画面を表示させている間、位置情報取得部16にて取得できる位置情報を、情報作成装置4へ向けて逐次送信する。
情報作成装置4の制御部40は、利用者端末装置1から送信される位置情報を、位置情報の送信元の利用者端末装置1に対応する利用者IDに対応付けて記憶部41に逐次記憶する。利用者DB402において利用者IDに対応付けて位置情報を記憶し、逐次更新してもよい。
情報作成装置4の制御部40は、利用者端末装置1、提供者端末装置2、又は支払者端末装置3のいずれかから、利用者、提供者又は支払者の募集のリクエストを受け付ける(ステップS101)。募集リクエストには、リクエスト元を識別するためのIDと、募集の条件とが含まれる。
制御部40は、受け付けた募集リクエストに応じて取引IDを採番し、デジタル帳票DFを起票する(ステップS102)。デジタル帳票DFは、取引IDと、リクエスト元の利用者ID、提供者ID又は支払者IDの内、少なくともいずれか1つとを含んで起票される。デジタル帳票DFとして帳票DB405に記憶された以後は、利用者、提供者又は支払者が検索・閲覧できるようになる。
制御部40は、受け付けた募集リクエストに含まれる募集の条件を募集IDに対応付けて募集条件DB406に記憶する(ステップS103)。募集条件DB406には、募集IDとステップS102で発行されたデジタル帳票DFの取引IDとが対応付けられて記憶される。募集条件DB406では、制御部40は募集IDに対応付けて募集中であることを示す情報を記憶しておく。
制御部40は、利用者の最新の位置情報、提供者のサービス種別等に応じてステップS101で受け付けたリクエストの募集条件に対応する利用者の利用者ID、又は提供者の利用者IDを抽出する(ステップS104)。
制御部40は、ステップS104で抽出された利用者IDの利用者、又は提供者IDの提供者に対し、ステップS101で受け付けた募集の内容を対応付ける(ステップS105)。ステップS105において制御部40は具体的には、ステップS104で抽出した利用者ID、又は提供者IDに対し、ステップS103で記憶した募集の条件の募集IDを対応付けて記憶する。
ステップS105の対応付けにより、抽出された利用者IDの利用者端末装置1、又は提供者IDの提供者端末装置2にて、対応付けられた募集の一覧を表示させることができる。ステップS105では、抽出された利用者ID又は提供者IDに対し、募集内容をプッシュ通知してもよい。
制御部40は、ステップS104で抽出された利用者IDの利用者、又は提供者IDの提供者から、募集に対する応募を受け付ける(ステップS106)。
なおステップS104及びステップS105は必須ではなく、抽出された利用者IDの利用者、提供者IDの提供者以外が使用する利用者端末装置1、提供者端末装置2、支払者端末装置3からでも検索、応募が可能であってよい。デジタル帳票DFは、利用者、提供者、支払者、又はその他管理者等の操作によって種別、時期、提供者等の情報によってデジタルチケットマーケットに挙げられ、検索及び閲覧し易くなるようにしてもよい。
制御部40は、受け付けた応募の内容を、リクエスト元へ通知し(ステップS107)、応募してきた利用者又は提供者の内からの選定を受け付ける(ステップS108)。制御部40は、選定された利用者の利用者端末装置1又は提供者の提供者端末装置2へ、選定を通知し(ステップS109)、確認を受け付ける(ステップS110)。
ステップS110の確認により利用者及び提供者が確定すると、デジタル帳票DFは利用者が提供者からサービスを受けるためのデジタルチケットとして利用可能になる。
制御部40は、確認が受け付けられた場合、ステップS103で記憶した募集条件に対し、募集条件DB406において募集を終了したことを記憶し(ステップS111)、利用者の利用者ID又は提供者の提供者IDを、ステップ102で発行したデジタル帳票DFに追記する(ステップS112)。
制御部40は、デジタル帳票DFに対応するサービス又は商品の提供の進行状況をモニタする(ステップS113)。ステップS113の進行状況のモニタでは第1に、提供者端末装置2又は利用者端末装置1から、デジタル帳票DFの利用者IDが示す利用者が実際に利用を開始したか、提供者IDが示す提供者によってサービス又は商品が提供されているかが確認される。例えば、利用開始時に利用者は利用者端末装置1の読取部15によって、サービス提供者によって提示されるサービスコードを読み取る。サービスコードは、上述したように少なくとも提供者IDを含み、スタッフ又は配置場所等を識別する情報が含まれる。制御部10は、読み取ったサービスコードと利用者端末装置1に対応する利用者IDとを対応付けて情報作成装置4へ送信する。あるいは、提供者が提供開始時に利用者から提示される利用者IDを提供者端末装置2の読取部25で読み取り、提供者のサービスコードと対応付けて情報作成装置4へ送信してもよい。これにより、実際に利用者が利用を開始したことが確認される。
制御部40は、モニタリングした進行状況を元に、サービス又は商品の提供が完了し、料金が確定したか否かを判断する(ステップS114)。ステップS114にて未完で未確定であると判断された場合(S114:NO)、制御部40は処理をステップS113へ戻す。
ステップS114において提供が完了したか否かは、例えば提供者端末装置2の操作部24にて完了通知を受け付け、制御部20が情報作成装置4へ通知してもよい。完了したか否かは、サービス提供者から出力した完了通知のレシート等を利用者端末装置1の読取部15で読み取り、制御部10が読み取った結果を情報作成装置4へ通知してもよい。完了したか否かは、タクシーであればタクシーメータ等の料金メータ、レジにおける処理完了を検知してもよい。
ステップS114にて提供が完了し、料金が確定したと判断された場合(S114:YES)、制御部40は、デジタル帳票DFにおける料金及びサービス若しくは商品の提供内容を追記し(ステップS115)、処理を完了する。デジタル帳票DFにおける必要な情報が全て確定した場合、デジタル帳票DFが取引情報として作成され、これに基づいて決済、経理処理が実行可能になる。
図11のフローチャートに示した処理手順に基づくサービスの実現を、具体例を挙げて説明する。実施の形態1では、プラットフォームに加盟する多様なサービス提供者の内、タクシー事業者のサービスを例に挙げて説明する。本開示の情報作成システム100では、利用者、提供者及び支払者のいずれもサービスのリクエストを出すことができる。
タクシー事業者のサービスの場合、提供者の提供者端末装置2は一例では、タクシー事業者の営業所に設置されるパーソナルコンピュータである。一例では、各運転者が所持するタブレット端末、又はスマートフォンが、端末用アプリケーションプログラム2Pをインストールし、提供者ID、及び運転者(実際のサービスを提供するスタッフ)を識別するIDを使用することで提供者端末装置2として機能する。各運転者が所持するか、または車両に搭載される提供者端末装置2は位置情報取得部を備え、制御部20は、利用者端末装置1と同様に逐次、提供者端末装置2の位置情報を取得し、情報作成装置4と通信接続したタイミングで最新の位置情報又は位置情報の履歴を送信する。情報作成装置4は、提供者端末装置2から送信される位置情報を、運転者を識別するID又は車両番号に対応付けて記憶する。提供者DB403にて、位置情報が記憶され逐次更新されてもよい。
タクシー事業者のサービスを利用者が本開示のプラットフォーム上で利用するためには、利用者が乗車するタクシーを募集する第1のケースと、タクシーが利用者を募集する第2のケースと、提供者がタクシーチケットを発行して利用者及び提供者を募る第3のケースとがある。以下、夫々のケースに分けてプラットフォームを利用したチケットレス決済の実現について説明する。いずれの場合も、リクエストに応じてデジタル帳票DFが起票されるとデジタルチケットマーケットに出品された状態となり、利用者端末装置1、提供者端末装置2、及び支払者端末装置3から、デジタル帳票DFに含まれる利用者ID、提供者ID、支払者ID、サービス内容、金額等のいずれかの情報によって検索・閲覧できる。
[1.利用者からリクエスト発行]
第1のケースとして、利用者がタクシーに乗ることをリクエストする場合を例に挙げて説明する。以下、第1のケースにおけるデジタル帳票DFに基づく処理についてシーケンス図及び画面例を参照して説明する。
図12及び図13は、利用者端末装置1にて表示される画面の一例を示す。図12は、利用者が利用者IDと対応付けて端末用アプリケーションプログラム1Pを起動した場合に表示されるメイン画面130を示す。メイン画面130は例えば、プラットフォームに加盟しているサービスの内、利用者が予め設定している使用可能なメニューのリストを含む。図12の例では、メイン画面130はタクシーに乗るためのメニューボタン131を含む。メイン画面130の態様は図12に示す内容には限られない。
図13は、メイン画面130においてタクシーに乗るメニューボタン131が選択された場合の検索画面132を示す。検索画面132には、タクシーを利用するデジタルチケットを発行するための設定項目の入力画面が含まれる。検索画面132には複数の項目夫々について、選択肢を変更するための矢印アイコン133が含まれる。矢印アイコン133が選択されると、例えば「出発地」であれば「現在地」又は「住所」等を含む選択肢がプルダウンメニューから選択できる。検索画面132では、利用したいタクシーの「出発時間」、「目的地」、及び「希望到着時間」を指定することが可能である。目的地については、場所又は住所を入力欄に入力すると、地図上で検索が可能であってもよい。検索画面132には、利用者を募集しているタクシーの募集内容を表示するための募集表示ボタン135が含まれる。募集表示ボタン135については後述する。検索画面132ではそのほか、タクシーを募集するリクエスト用のタクシーの「利用目的」、「業務番号」、「利用条件」、「支払方法」、及びリクエストの条件として「タクシー種別」の設定が可能である。「タクシー種別」は例えば、VIP対応車両、福祉車両、ワンボックス又は指定なしが設定可能である。「利用条件」は利用者と支払者との間で取決められた経費処理の上限値等であり、デフォルトで設定されている条件が自動的に適用されてよい。「支払方法」として、利用者が属する企業が経費として支払う「経費処理」と、利用者自身が支払う「個人利用」とのいずれかの選択が可能である。「経費処理」の場合は「業務番号」として勘定項目に関連付けられている情報の選択が可能である。
検索画面132には、デジタル帳票DFに基づくタクシー利用のためのデジタルチケットをリクエストするボタン134が含まれている。利用者端末装置1の制御部10は、表示部13上で利用者がボタン134をタップしたことを操作部14によって検知した場合、利用者を乗せるタクシーを募集するリクエストを情報作成装置4へ送信する。
図14は、利用者端末装置1からのリクエストに基づいてデジタル帳票DFが完成するまでのシーケンスを示す図である。図14のシーケンス図に示す手順の内、情報作成装置4の処理手順で図11のフローチャートで示した手順については同一のステップ番号を付して詳細な説明を省略する。
利用者端末装置1の制御部10が、図13の検索画面132におけるボタン134の操作を受け付け、利用者を乗せるタクシーを募集するリクエストを通信部12から送信する(ステップS201)。リクエストには、検索画面132で設定された「利用目的」、「業務番号」、「利用条件」、「支払方法」、及び「リクエストの条件」が含まれている。
情報作成装置4の制御部40が、利用者端末装置1からのリクエストを受信し、これを受け付け(S101)、リクエストに基づくデジタル帳票DFを起票する(S102)。このケースにおいてステップS102で起票されるデジタル帳票DFは、図9の帳票DB405に示しているように、利用者ID、提供者ID及び支払者IDの内、利用者IDのみが確定している。
図15は、デジタル帳票DFが完成していく過程の示す概要図である。図15はA、B、Cの順にデジタル帳票DFの各項目が埋まる過程を示している。図15Aに示すように、ステップS102の段階では、決済又は経費処理に必要な項目である(1)取引を識別する情報(取引ID)、(2)提供されたサービス又は商品の内容を示す情報(項目)、(3)料金、(4)サービス又は商品の提供者(支払先)、(5)サービス又は商品の利用者、(6)料金の支払者の内、(5)が定まることで(1)が採番されている状態である。ステップS101で受信したリクエストに含まれる「支払方法」が「経費処理」であるため、(6)の支払者は、利用者が所属する企業に仮決定される。このように、本開示におけるプラットフォームでは、支払者及び提供者が定まっていない段階で決済、経費処理の元となるデジタル帳票DFを起票する。
図14のシーケンス図に戻り説明を続ける。
情報作成装置4の制御部40は、ステップS101で受信したリクエストから募集条件を記憶し(S103)、募集条件に合致する提供者の提供者IDを、提供者端末装置2から逐次受信している位置情報に基づいて抽出する(S104)。制御部40はステップS104において例えば、リクエストに含まれる出発地に、出発時間よりも所定の時間(例えば1−5分)までに到着できる位置にあるタクシーの提供者端末装置2を、各提供者端末装置2からの位置情報に基づいて抽出する。
制御部40は、抽出した提供者IDに対応付けて、ステップS103で記憶した募集条件の募集IDを対応付ける(S105)。
制御部40は、ステップS105において抽出した提供者端末装置2へ向けて、出発地までの距離が短い順に、タクシーの募集がある旨の通知を送信する方法でもよいし、提供者端末装置2を使用するタクシー運転手が募集を検索する方法で募集に対する応募を受けてもよい。
提供者端末装置2の制御部20は、通知を受けるか又は検索により募集を取得し(ステップS301)、募集に対する応募を受け付ける(ステップS302)。
提供者端末装置2における画面例を挙げて応募の受け付けについて説明する。図16及び図17は、提供者端末装置2にて表示される画面の一例を示す。図16は、提供者が提供者IDと対応付けて端末用アプリケーションプログラム2Pを起動した場合に表示されるメイン画面230を示す。図16に示すメイン画面230は、タクシー事業者向けに特化された端末用アプリケーションプログラム2Pに組み込まれたアプリケーションプログラムに基づいて表示されている。メイン画面230は、タクシー車両の当日のスケジュールと、近くの乗客を探すためのメニューボタン231及び乗客を募集するリクエストのためのボタン232を含む。ボタン232による処理については後述する。図16の例においてスケジュールには、現在時刻、予約状況が示されている。メイン画面230の態様は、図16に示す内容には限られない。
図17は、メイン画面230において乗客を探すためのメニューボタン231が選択された場合の検索画面233を示す。検索画面233には、提供者端末装置2が対応する提供者IDを抽出対象とした募集がある場合には、その募集内容のリスト234が表示される。図17のリスト234では、提供者IDを抽出した募集の内、絞り込みの条件として予約状況に基づく発着時刻及び発着地点で絞り込んだ募集のリストが表示されている。検索画面233のリスト234には、各募集に対し、いずれかを選択するためのボタン235が含まれている。ボタン235が選択されると、提供者端末装置2からの応募が受け付けられる。
図14のシーケンスに戻り説明を続ける。図17に示した検索画面233にて応募のためにいずれかのボタン235が選択されることで、提供者端末装置2の制御部20により応募の通知が通信部22から情報作成装置4へ送信される(ステップS303)。
情報作成装置4の制御部40は、応募を受け付け(S106)、受け付けた応募の内容をリクエスト元の利用者の利用者端末装置1へ通知する(S107)。
利用者端末装置1の制御部10は、応募の通知を受け付け(ステップS202)、応募の選定を受ける(ステップS203)。図18は、利用者への応募の通知画面136の内容例を示す図である。通知画面136は、図13の検索画面132でリクエストのボタン134を選択した後の待機後に表示される。通知画面136には、リクエストに対して応募してきたタクシーの情報がリスト表示され、選定ボタン137が含まれている。利用者はいずれかのタクシーを選択して対応する選定ボタン137を選択する。
図14のシーケンスに戻り説明を続ける。図18に示した通知画面136にて選定ボタン137が選択されることで、利用者端末装置1の制御部10により選定結果が通信部12から情報作成装置4へ送信される(ステップS204)。
情報作成装置4では、制御部40が選定結果を受信することで選定を受け付け(S108)、選定された提供者の提供者端末装置2へ選定を通知する(S109)。
提供者端末装置2の制御部20は、選定通知を受信して(ステップS304)、確認を受け付け、情報作成装置4へ送信する(ステップS305)。
情報作成装置4の制御部40は、提供者端末装置2から確認を受け付ける(S110)。ステップS106にて複数の応募があった場合、選定されなかった提供者へは選定されなかった旨の通知がされるとよい。提供者端末装置2では、図17に示した画面の後に、応募が選定された旨の通知画面が表示され、通知画面に含まれる確認ボタンによって確認が受け付けられる。
情報作成装置4の制御部40は、選定された提供者の提供者IDをデジタル帳票DFに追記する(S112)。これにより、図15Bに示すように、デジタル帳票DFにおいて提供者の項目が埋まる。
図19は、利用者端末装置1にて表示されるデジタルチケット138の一例を示す。図19は、図18にて選定ボタン137を選択した場合に、リクエストに応じて利用者が利用することが可能となったタクシー利用のためのデジタルチケット138の内容を示している。デジタルチケット138は、チケットの基となるデジタル帳票DFの取引ID、チケットの発行日、サービス内容、料金等の情報を含む。
制御部40は、その後、選定された提供者の提供者IDのタクシーにリクエスト元の利用者が乗車したか否か、及び予定時刻までにタクシーが到着したか否か等の進行状況を、逐次送信される位置情報、タクシーにおける乗車確認等の情報に基づいてモニタする(S113)。制御部40は、タクシーの提供者端末装置2から降車、及び料金確定の通知を受けたか否かによって、サービスの提供完了及び料金が確定したか否かを判断する(S114)。
制御部40は、提供者端末装置2から料金確定の通知を受けると(S114:YES)、利用者端末装置1及び支払者端末装置3において確認又は承認を受けて提供されたサービスの内容、料金及び支払者を確定させてデジタル帳票DFに追記する(S115)。図20は、デジタルチケット138の内容例を示す図である。図19で表示されたデジタルチケット138では料金が確定した後、図20に示すように、料金の欄に、確定された料金が表示され、利用者によって確認する確認ボタン139が含まれる。確認ボタン139が選択された場合、情報作成装置4にて確認が受け付けられる。図20のデジタルチケット138においては確定した料金が、経費処理の場合の支払者と利用者との間の利用条件に応じて上限以内であれば支払者は所属企業、上限を超過した一部料金については個人負担とするなど、S115の時点で確定される。その他、支払者端末装置3へ通知が送信され、支払者端末装置3の操作によって承認を受けてもよい。これにより、図15Cに示すようにデジタル帳票DFにおいて全ての項目が埋まり、これに基づいて決済及び経費処理が可能になる。
[2.提供者からリクエスト発行]
第2のケースとして、提供者であるタクシー事業者が利用者を募る場合を例に説明する。以下、第2のケースにおけるデジタル帳票DFに基づく処理についてシーケンス図及び画面例を参照して説明する。
図16の提供者端末装置2におけるメイン画面230中の乗客リクエストするためのボタン232により、提供者端末装置2の制御部20は、タクシーの乗客を募集するリクエストを情報作成装置4へ送信する。
図21は、提供者端末装置2からのリクエストに基づいてデジタル帳票DFが完成までのシーケンスを示す図である。図21のシーケンス図に示す手順の内、図14の利用者端末装置1を起点とした処理手順、図11のフローチャートで示した手順と共通する処理については同一のステップ番号又は対応するステップ番号を付して詳細な説明を省略する。
提供者端末装置2で制御部20は、図16の乗客リクエストのためのボタン232の操作を受け付け、タクシーに乗る利用者を募集するリクエストを通信部22から送信する(ステップS311)。リクエストには、予約状況に基づく発着時刻及び発着地点に関する「リクエスト条件」が含まれている。
これにより、情報作成装置4の制御部40によって、利用者ID、提供者ID及び支払者IDの内、提供者IDのみが確定したデジタル帳票DFが発行される。図22は、第2のケースにおけるデジタル帳票DFの概要図である。図22はA、B、Cの順にデジタル帳票DFの各項目が埋まる過程を示している。図22Aに示すように、ステップS102の段階では、決済又は経費処理に必要な項目の内、(4)サービス又は商品の提供者(支払先)が定まることで(1)が採番されている状態である。このように、本開示におけるプラットフォームでは、利用者及び支払者が定まっていない段階で決済、経費処理の元となるデジタル帳票DFを発行する。
図21のシーケンスに戻り説明を続ける。情報作成装置4の制御部40は、ステップS101で受信したリクエストに対応する募集条件に合致する利用者の利用者IDを、利用者端末装置1から逐次受信している位置情報に基づいて抽出する(S104)。ステップS104の抽出は、端末用アプリケーションプログラム1Pをアクティブにしている利用者端末装置1等に絞り込まれてもよい。制御部40はステップS104において例えば、リクエストに含まれる出発地点に近い場所で、端末用アプリケーションプログラム1Pを使用している利用者の利用者端末装置1を、利用者端末装置1の位置情報に基づいて抽出する。制御部40は、抽出した利用者IDと、ステップS103で記憶した募集条件の募集IDとを対応付ける(S105)。
ステップS105にて利用者IDに募集IDが対応付けられることにより、利用者端末装置1の制御部10が図13の検索画面132における募集表示ボタン135を選択すると、制御部10は利用者IDに対応付けられている募集を取得する(ステップS211)。ステップS211において制御部10は、利用者IDが対応付けられていない募集を取得し、後に検索絞り込みを行なうようにしてもよい。制御部10は、取得した募集、即ち、利用者を募集している近くのタクシーの募集内容のリストを表示し、募集に対する応募を受け付ける(ステップS212)。
図23は、利用者端末装置1にて表示される画面の一例を示す。図23に示す画面は、図13の検索画面132において募集表示ボタン135が選択された場合に表示される。この場合、図23に示すように検索画面132には、利用者端末装置1が対応する利用者IDを抽出対象とした募集のリスト140が表示される。図23のリスト140では、利用者IDを抽出した募集の内、利用の条件として「目的地」及び「希望到着時刻」によって絞り込まれた募集のリストが表示されている。リスト140には、各募集に対し、いずれかを選択するためのボタン141が含まれている。ボタン141が選択されると、利用者端末装置1からの応募が受け付けられる。
図21のシーケンスに戻り説明を続ける。図23に示したリスト140にて選択のボタン141が選択されることで、利用者端末装置1の制御部10により応募の通知が通信部12から情報作成装置4へ送信される(ステップS213)。
情報作成装置4の制御部40は、応募を受け付け(S106)、受け付けた応募の内容をリクエスト元の提供者の提供者端末装置2へ通知する(S107)。
提供者端末装置2の制御部20は、応募の通知を受け付け(ステップS312)、応募の選定を受ける(ステップS313)。提供者端末装置2では、図17に示した検索画面233同様の画面に、リクエストに対して応募してきた利用者としての乗客の情報が、表示部23にリストとして表示され、ボタン235の選択によっていずれかの利用者が選定される。タクシーは、いずれかの利用者を選択し、応募してきた利用者の場所へ向かう。
図21のシーケンスに戻り説明を続ける。乗客として応募してきた利用者が選定されることで、提供者端末装置2の制御部20により選定結果が通信部22から情報作成装置4へ送信される(ステップS314)。
情報作成装置4では、制御部40が選定結果を受信することで選定を受け付け(S108)、選定された利用者の利用者端末装置1へ選定を通知する(S109)。
利用者端末装置1の制御部10は、選定通知を受信して(ステップS214)、確認を受け付け、情報作成装置4へ送信する(ステップS215)。
情報作成装置4の制御部40は、利用者端末装置1から確認を受け付ける(S110)。ステップS106にて複数の応募があった場合、選定されなかった利用者へは選定されなかった旨の通知がされるとよい。利用者端末装置1では、図23に示した画面の後に、応募が選定された旨の通知画面が表示され、通知画面に含まれる確認ボタンによって確認が受け付けられる。
情報作成装置4の制御部40は、選定された利用者の利用者IDをデジタル帳票DFに追記する(S112)。これにより、図22Bに示したように、デジタル帳票DFにおいて利用者の項目が埋まる。
制御部40は、その後、選定された利用者の利用者IDの利用者端末装置1が、リクエスト元のタクシーに乗車したか否か、及び予定時刻までにタクシーが到着したか否か等の進行状況を、逐次送信される位置情報、タクシーにおける乗車確認等の情報に基づいてモニタする(S113)。その後の処理は、第1のケースと同様である。そして図22Cに示したようにデジタル帳票DFにおいて全ての項目が埋まり、これに基づいて決済及び経費処理が可能になる。
[3.支払者からリクエスト発行]
第3のケースとして、支払者が提供者及び利用者を募る場合を例に説明する。以下、第3のケースにおけるデジタル帳票DFに基づく処理について説明する。
支払者端末装置3においても第1のケース又は第2のケースと同様にして、制御部30は、支払者IDと対応付けた端末用アプリケーションプログラム3Pに基づいて、利用者及び提供者が未定のデジタルチケットの発行リクエストを送信することができる。例えば、第1のケース及び第2のケースと同様に、支払者に対応する組織に属する利用者が業務上、特定の場所へタクシーで移動する必要がある場合に、利用者端末装置1からリクエストが送信されなくても同様にして利用者はキャッシュレスでサービスを受け、提供者は支払者から料金の支払いを受けることができる。支払者にとっての顧客の送迎で通常はタクシーチケットを配布して対応するような場合に、支払者端末装置3からのリクエストで発行されたデジタルチケットを、後に定まる利用者の利用者端末装置1へ向けて送信すればよい。
第3のケースにおける処理手順は、図11のフローチャート、図13及び図21のシーケンスを参照して説明できる。
支払者端末装置3の制御部30は、支払者IDが対応する端末用アプリケーションプログラム3Pに基づいて、タクシー及び乗客を募集するリクエストを通信部32から送信する。リクエストには例えば、タクシーというサービスの種別と、利用者を支払者の組織に属する利用者とする条件とが指定されている。また例えば、組織に属する利用者であって、移動が必要な業務中の特定の利用者の利用者IDが指定されていてもよい。リクエストには、支払者の支払者IDと、発行されるデジタル帳票DFに基づくデジタルチケットの所有者となる利用者(顧客)の利用者IDとが指定されてもよい。
第3ケースにおいて情報作成装置4の制御部40は、リクエストに基づいて支払者IDのみが決定したデジタル帳票DFを起票し(S102)、募集条件に対応する利用者及び提供者をいずれも抽出する(S104)。ここで、提供者の抽出は、特定の利用者IDの利用者端末装置1の位置情報に基づき、特定の利用者の近くに存在するタクシーが抽出されるとよい。抽出された利用者ID及び提供者IDには、リクエストに係る募集IDが対応付けられる(S105)。
これにより、提供者端末装置2において提供者が乗客を探索しようとすると、募集内容のリストが表示部23に表示され、提供者は支払者に対応する組織に属する利用者、又は支払者が指定する顧客を乗客とするタクシーとして応募することが可能になる。図24は、提供者端末装置2にて表示される画面例を示す図である。図24では、図16で示したメイン画面230に、支払者としてDEF商事に属するいずれかの社員を乗せるタクシーの募集内容が表示されており、募集に応募するためのボタン236が表示されている。
また第3のケースでは、利用者端末装置1の表示部13に表示される「発行済みのデジタルチケット」の一覧として募集内容のリストが表示されてもよい。図25は、利用者端末装置1にて表示される画面例を示す図である。図25では、図13で示した検索画面132に対し、支払者からのリクエストによって発行済みのデジタルチケットを選択するためのボタン142が追加されている。ボタン142が選択された場合、利用者が使用可能なタクシー用のデジタル帳票DFの取引IDを含むチケット一覧に基づき、いずれかのチケットの利用に対して応募ができる。
提供者又は利用者が募集に応募すると、情報作成装置4では応募を受け付けてマッチングする。制御部40は例えば、図24で応募してきた提供者であるタクシーのリストを、支払者端末装置3で選定できるようにしてもよいし、対象の利用者の利用者端末装置1で表示して選定できるようにしてもよい。同様にして、図25で応募してきた利用者のリストを、支払者端末装置3で選定できるようにしてもよいし、近くにいる提供者であるタクシーの提供者端末装置2で表示して選定できるようにしてもよい。制御部40は、タクシーの位置及び利用者の目的地に応じて自動的に両者をマッチングしてもよい。
利用者に対し、起票されたデジタル帳票DF(少なくとも支払者IDが確定済み)の取引IDを印刷出力した紙媒体が渡され、利用者によって選択された提供者が取引IDに基づいてデジタルチケットを検索し、これを利用することによって利用者、提供者、支払者がマッチングされるようにしてもよい。つまり、募集に対する応募は利用者端末装置1、提供者端末装置2、及び支払者端末装置3間での情報の授受に限られず、サービスの利用時の取引IDの提示であってもよい。
図26は、第3のケースにおけるデジタル帳票DFの概要図である。図26はA、B、Cの順にデジタル帳票DFの各項目が埋まる過程を示している。図26Aに示すように、情報作成装置4にて支払者端末装置3からのリクエストに基づいてデジタル帳票DFを発行する段階では、決済又は経費処理に必要な項目の内、(6)料金の支払者が定まることで(1)が採番されている状態である。このように、本開示におけるプラットフォームでは、利用者及び提供者が定まっていない段階で決済、経費処理の元となるデジタル帳票DFを発行する。例えば提供者が募集に応募すると、支払者にて選定された提供者が定まり、図25Bに示すように、デジタル帳票DFにおける提供者の情報が定まる。以後の処理は、第2のケース同様に、応募してきた利用者を、支払者又は提供者にて選定し、選定された利用者が提供者のタクシーに乗車したか否か等の進行状況をモニタし、料金が確定した場合に、図26Cに示すように全ての情報が定まってデジタル帳票DFが完成し、決済及び経費処理が可能となる。
このように、本開示におけるプラットフォームでは、利用者、提供者及び支払者の内の2つが定まっていない段階で決済、経費処理の元となるデジタル帳票DFを発行する。つまり利用者、提供者及び支払者のいずれもサービスのリクエストを出すことができる。情報作成システム100では、情報作成装置4が、リクエストにマッチするサービス提供者、支払者、又は利用者等を募集し、利用者、提供者及び支払者の情報及び料金が確定したデジタル帳票DFを完成させると、デジタル帳票DFに基づく決済及び経費処理が可能となる。
実施の形態1の説明では、交通機関の経費としてタクシーのみを説明したが、バス、電車、飛行機等の他の公共交通機関にも適用することは可能である。例えば、情報作成装置4では、募集に対する応募を受け付ける代わりに、目的地まで利用できるバス、電車、飛行機等の検索結果(特急列車や飛行機の場合は空きがある便等)を提供者端末装置2から夫々受け付け、検索結果から選定を受け付け、選定された提供者の提供者には利用する利用者の利用者IDを通知する。利用者が利用する時点で利用者IDを利用者端末装置1から提供者側で確認(認証)することができれば、その後は利用状況をモニタし、料金が確定した時点でデジタル帳票DFを確定することができる。利用者IDは、交通系ICカードと紐付けされていれば、交通系ICカードにおけるカード情報によって利用者の利用を確認することも可能である。
利用者は、複数の交通機関を乗り継いでいく間に、空きがある交通機関を利用者端末装置1にて表示される検索画面132にて検索し、夫々に対するリクエスト、又は既存のデジタル帳票DFに基づいて募集している中でマッチする交通機関を選定してもよい。
(実施の形態2)
実施の形態2では、プラットフォームを利用する多様なサービス提供者の内、タクシー事業者によるサービスについて説明する。実施の形態2におけるサービス提供者であるタクシー事業者は、プラットフォームを利用することによってタクシーの相乗りサービスを実現する。
実施の形態1で示したように、本開示のプラットフォームを使用することによって、料金が確定した時点で現金、クレジットカードによる支払がなくとも、サービスの内容即ち実績に基づいた支払者からサービス提供者への支払いが可能である。本開示のプラットフォームを利用した場合、1人の利用者が乗客としてタクシーを利用中に、出発地点又は終着地点が異なる他の利用者が乗客として乗ったとしても、各々の利用者のサービス内容(距離)が確定できれば、相乗りしている時間等によって事後的に割引等の精算が可能である。実施の形態2における構成及び実行される処理手順は、実施の形態1と同様であるから同一の符号を用いて以下、相乗りサービスの実現について説明する。
実施の形態2におけるタクシーの相乗りサービスを実現するためには、募集条件に、相乗りの可否、1回のリクエストにおける乗客の人数、タクシーにおける乗車可能な人数、乗客又は運転士の属性(例えば性別、用途)、並びにタクシーの種別の情報等が必要である。
図27は、実施の形態2における利用者端末装置1で表示される検索画面132の内容例を示す。実施の形態2では検索画面132で設定される「条件」に、「利用目的」、「業務番号」、「利用条件」、「支払方法」、及びリクエストの条件として「タクシー種別」に加え、相乗りの可否、乗客の人数、希望する乗客又は運転士の属性が設定されている。相乗りの可否は、「タクシー種別」にて「車種:ワンボックス」又は「福祉車両」が選択されている場合のみに選択可能な条件であってもよい。
図28−図30は、タクシーの相乗りを実現するデジタル帳票DFに関する処理手順の一例を示すシーケンス図である。図28−図30に示す処理手順の内、実施の形態1の図14のシーケンス、図11の情報作成装置4の処理手順と共通する手順については同一のステップ番号を付して詳細な説明を省略する。
図27に示した検索画面132にてリクエストのボタン134が選択された場合、利用者端末装置1から利用者を相乗り可の条件でのせるタクシーを募集するリクエストが情報作成装置4へ送信される(S201)。
情報作成装置4の制御部40は、最初の利用者の利用者端末装置1からのリクエストに対する処理S101−S105を実行する。制御部40は、相乗り可の条件込みで、ステップS303から送信された提供者端末装置2からの応募を利用者端末装置1へ通知する(S107)。
提供者端末装置2では、制御部20が、近くにいる利用者からの募集に自装置が対応付けられた場合に募集を取得し(S301)、応募を受け付ける(S302)。
ステップS302の応募の受け付けは、提供者端末装置2が音声にて操作を受け付ける構成とするとよい。図17の検索画面233にて、表示される募集内容のリスト234の夫々に、相乗りの可否の情報が追加され、相乗り可の募集内容が選択可能になる。ステップS302では既に乗客が乗っているタクシーの提供者端末装置2にて、相乗りを可としている募集が来ていることを音声で通知し、応募するか否かを音声認識によって受け付けてもよい(S302)。既に乗客が乗っているタクシーの提供者端末装置2では、別のデジタル帳票DFが起票されている。つまり、同一の時間にサービスが実行される、提供者IDが共通するデジタル帳票DFの存在が可能である。
ステップS302の応募の受け付けでは、既に乗客がいるタクシーの提供者端末装置2からの相乗り状態での応募か否か、相乗り乗客を更に募集をするか否かが選択されることが必須とされてよい。
情報作成装置4の制御部40は、提供者端末装置2からの応募をその条件(相乗り状態であるか、相乗り乗客を更に募集するか否か)と共にS101のリクエスト元の利用者端末装置1へ通知し(S107)、選定を受け付ける(S108)。ステップS108の選定のステップにおいて、相乗り乗客を更に募集をすることの可否の選択がされるとよい。
制御部40は、選定された提供者端末装置2へ選定を通知し(S109)、確認を受け付ける(S110)、これらの処理と前後して又は同時的に、以下のステップS121の処理を実行する(図28−図30ではS110の後に実行する)。
制御部40は、ステップS121にて、選定された提供者端末装置2からステップS106で受け付けた応募に、相乗り乗客を更に募集することが選択されているか、又はステップS108の選定を受け付けるステップで、相乗り乗客を更に募集をすることが可として選択されているか否かを判断する(ステップS121)。
相乗り乗客を更に募集をすることが選択されていないと判断された場合(S121:NO)、制御部40は、処理をステップS111へ進め、以後の処理を実行する。この場合、乗客は1人で選定されたタクシーの利用を開始するか、既に乗客がいるタクシーの利用を開始する。
相乗り乗客を更に募集をすることが選択されていると判断された場合(S121:YES)、制御部40は、選定された提供者端末装置2に対応する提供者IDのみを指定したデジタル帳票DFを起票する(ステップS122)。制御部40は、相乗り可の募集条件に合致する利用者の利用者IDを、利用者端末装置1から逐次受信している位置情報に基づいて抽出する(ステップS123)。制御部40は、抽出した利用者IDに対応付けて、ステップS103で記憶している募集条件の募集IDを対応付ける(ステップS124)。制御部40は、ステップS122の前に、新たな募集内容を、募集IDを付与して記憶し、ステップS124で対応付けてもよい。ステップS122−124、及び以後の処理は、リクエスト元の利用者のタクシーの乗車開始と並行して行なわれてよい。
制御部40はその後、図21のシーケンス図におけるステップS106に対応する処理(ステップS126)によって新たな同乗者の利用者からの応募を受け付け、提供者端末装置2又は元のリクエスト送信者の利用者の利用者端末装置1へ通知して(ステップS127)、選定を受け付ける(ステップS128)。
この間、利用者端末装置1及び/又は提供者端末装置2では、応募通知を受け付け(ステップS222、ステップS322)、選定を受け付けて(ステップS223、ステップS323)、選定を送信する(ステップS224、ステップS324)。
制御部40は、選定された利用者の利用者端末装置1へ選定を通知し(ステップS129)、確認を受け付ける(ステップS130)。
もう1つの利用者端末装置1では、ステップS124で対応付けられた募集を取得し(ステップS231)、応募を受け付け(ステップS232)、応募を送信する(ステップS233)。選定が通知された場合、この利用者端末装置1の制御部10は、選定通知を受け付け(ステップS234)、利用者からの確認を受け付けて送信する(ステップS235)。
情報作成装置4の制御部40は、以後ステップS111を実行し、ステップS102のデジタル帳票DFに提供者を追記すると共に、更なる乗客がいる場合にはステップS122のデジタル帳票DFに利用者を追記し(ステップS131)、デジタル帳票DFに対する進行状況をモニタする(ステップS132)。
制御部40は、相乗り中のいずれかの利用者が降車し、サービス提供が終了したことを検知すると(ステップS133)、降車した利用者の利用距離と、相乗り利用による割引を考慮した料金を算出し(ステップS134)、算出した料金を追記する(ステップS135)。ステップS134において制御部40は、相乗り区間における距離に応じた割引を適用してもよいし、相乗りを利用したことに対して利用区間全てについて割引を適用してもよい。
制御部40は、相乗りした利用者全てのサービス提供が完了したか否かを判断し(ステップS136)、サービス提供が完了していないと判断された場合(S136:NO)、処理をステップS132へ戻す。
ステップS136にてサービス提供が完了したと判断された場合(S136:YES)、制御部40は処理を終了する。
相乗りを実現するための処理は、これに限らず、例えばステップS104の時点で募集条件に合致する提供者のみならず、募集条件に合致する利用者も抽出してもよい。ステップS104における抽出では、リクエストに含まれるタクシーの利用経路の出発地点、経由可能な地点の周辺に情報作成装置4の制御部40はステップS105において、提供者端末装置2のみならず利用者の利用者端末装置1も対応付ける。そしてステップS106において、利用者端末装置1及び提供者端末装置2の両方から応募を受け付けてもよい。
提供者端末装置2は、タクシー車両毎、乗務員毎に使用する構成として説明したが、タクシーの事業所に設置される端末であってもよい。この場合、オペレータが各タクシー運転手と無線等によってタクシー及び乗客の手配を行ないながら提供者端末装置2を操作し、相乗りの乗客をマッチングしてもよい。
実施の形態1と同様に、提供者端末装置2からのリクエストを起点として、相乗りを可とする利用者を乗客として募集することによって相乗りを実現してもよい。図31は、実施の形態2において提供者端末装置2で表示される検索画面233の内容例を示す。実施の形態2の提供者端末装置2の検索画面233ではリクエストの「条件」として、乗客の位置、出発時間、乗客の最大人数、相乗りの可否、利用者の属性の設定が可能である。リクエストの条件の各項目の隣にドロップダウンメニューを表示するためのボタン237が含まれ、どのような条件とするかを設定することができる。利用者の属性としては、性別の指定が可能である。これにより、女性限定専用の相乗りタクシーを実現できる。ボタン237を選択した場合に表示されるドロップダウンメニュー内の選択によって相乗りの可否の設定が可能である。また提供者端末装置2からリクエストを送信する場合、又はリクエストに対して応募する場合に、ドロップダウンメニューから割引等の設定を選択することが可能である。
タクシーの車種が福祉車両であり、複数の利用者が乗ることができる車両である場合、車いすでの移動な必要な人の相乗り同乗者の募集が実現できる。
実施の形態2で示したように、本開示のプラットフォームの利用によって、相乗りタクシーにおける支払精算が可能になる。利用者にとっても相乗りを可としたことによる割引等を受けた上で実際に乗車した距離の分だけ、後に精算が可能である。経費処理のみならず個人利用も可能である。経費処理を選択した利用者と、個人利用を選択した利用者が同乗したとしても夫々のデジタル帳票DFに基づいて決済及び経費処理が可能である。このように本開示のプラットフォームを利用することによって、相乗りタクシー事業の実現が容易になる。
(実施の形態3)
実施の形態1及び2では、タクシー又は他の交通機関への適用を例に挙げて説明したが、他のサービス提供に対しても適用可能である。実施の形態3では、宿泊施設、飲食店のサービスに適用した場合について説明する。具体的には、提供者である宿泊施設から、その施設の近くに存在する利用者に対して宿泊客として募集することを例として説明する。以下に説明する利用者の募集の処理は、飲食店にて顧客を募集する処理にも適用可能である。
図32は、実施の形態3において提供者端末装置2に表示される画面の一例を示す。提供者端末装置2は、宿泊施設毎に設置されるパーソナルコンピュータに端末用アプリケーションプログラム2Pをインストールし、提供者IDに対応するアカウント情報に基づき使用されるものであり、施設の管理者が操作する。図32に示すメイン画面230には、宿泊施設向けに特化された宿泊管理アプリケーションに組み込まれた端末用アプリケーションプログラム2Pに基づき、当日の宿泊一覧と、宿泊客を募集するリクエストのためのボタン232を含む。リクエストには図32に示すように、当日の宿泊における宿泊人数、割引設定等をドロップダウンメニューのためのボタン237によって設定可能である。
図32に示されたリクエストのボタン232が選択された場合、提供者端末装置2の制御部20は、図21のシーケンス図に示したステップS311の宿泊客を募集するリクエストを通信部22から情報作成装置4へ送信する処理を実行する。
宿泊施設の提供者端末装置2から送信されたリクエストを起点とする処理手順は、実施の形態1の図21のシーケンス図に示したステップS311以降のシーケンスと同様であるから詳細な説明は省略する。図21のシーケンス図におけるタクシー事業者に係る処理は、宿泊施設における処理に代替される。
図33は、実施の形態3において利用者端末装置1に表示される画面の一例を示す。図33に示す画面例は、メイン画面130である。メイン画面130には、利用サービスのリストに加えて通知欄143が含まれる。通知欄143には、利用者端末装置1が対応する利用者IDを抽出対象とした募集のリスト144が表示される。図33のリスト144では例えば図32に示した提供者「Eホテル品川」にて品川駅1000m以内に存在する利用者を抽出した募集のリストが表示されている。過去に利用した履歴のある利用者、過去に支払履歴がある支払者の組織に属する利用者が優先して抽出されてもよい。リスト144には、各募集に対し、いずれかを選択するためのボタン145が含まれている。ボタン145が選択されると、募集内容の詳細と共に応募を受け付ける画面が表示される。
利用者は、応募時に経費処理なのか、個人負担であるのかの選択が可能である。経費処理である場合は、利用者が属する組織を支払者として、デジタル帳票DFが完成する。支払者の承認が得られれば、これに基づいて決済及び経費処理が可能になる。このようにして同様の処理手順によって、宿泊施設からの空き室の販売機会の増進を見込むことができると共に、経費処理も容易化され、利用者にとっても利便性が非常に高い。
(実施の形態4)
実施の形態4では、プラットフォームを利用する多様なサービス提供者の内、医療に関するサービスについて説明する。実施の形態4におけるサービス提供者である医療サービス事業者は、プラットフォームを利用することによって公的な補助がされる検診サービスを実現する。具体的には、支払者である自治体(若しくは国)から、特定の条件の利用者に対して医療機関への検診者として利用者を募集することを例として説明する。
図34は、実施の形態4において支払者端末装置3に表示される画面の一例を示す。支払者端末装置3は、自治体に設置されるパーソナルコンピュータに支払者IDと対応する端末用アプリケーションプログラム3Pをインストールしたものであり、自治体が支払者となるサービスに関する管理者が操作する。図34に示すメイン画面330には、自治体向けの画面に、検診の受診者を募集するリクエストのためのボタン332を含む。リクエストには図34に示すように、受診の対象者となる利用者を絞り込むための設定項目をドロップダウン用のボタン331によって設定可能である。図34で示すように、募集の条件として年齢、性別、補助内容が設定可能である。
図34に示されたリクエストのボタン332が選択された場合、支払者端末装置3の制御部30は、受診者を募集するリクエストを通信部32から情報作成装置4へ送信する。
自治体の支払者端末装置3から送信されたリクエストを起点とする処理手順は、実施の形態1の第3のケースで説明した処理手順と同様であるから詳細な説明を省略する。
図35は、実施の形態4において利用者端末装置1に表示される画面の一例を示す。図35に示す画面例は、端末用アプリケーションプログラム1Pに基づき表示されるメイン画面130である。メイン画面130に含まれる通知欄143に、利用者端末装置1が対応する利用者IDを抽出対象とした募集のリスト144が表示される。図35のリスト144では、図35に示した支払者「T市」が検診クーポンの対象とする利用者を抽出した募集のリストが表示されている。リスト144には、各募集に対し、いずれかを選択するためのボタン145が含まれている。ボタン145が選択されると、募集内容の詳細と共に応募を受け付ける画面が表示される。
本開示のプラットフォームは、上述したような検診クーポンのみならず、乳幼児医療、高齢者医療、ワクチン接種等の自治体による医療機関における費用の補助に適用することも可能である。このように本開示のプラットフォームでは、利用者による提供者からのサービスの提供完了によってデジタル帳票DFを完成させて決済、経費処理が可能となるので、利用者が実際に診療を受けたのか、検査を受けたのか等を、支払者が確認した上で経費処理が可能である。したがって利用者が医療機関で実際に予防接種、定期検診を受けたことのエビデンスを持って、利用者以外の支払者が実費を支払うこと、即ち受診をエビデンスとして経費支払が可能である。
上述のように開示された実施の形態は全ての点で例示であって、制限的なものではない。本発明の範囲は、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内での全ての変更が含まれる。