JP2021196956A - 決済代行装置、決済代行システム、決済代行方法、及び決済代行プログラム - Google Patents

Abstract

【課題】決済サービスを利用可能なクライアント端末を持っていない人でも決済サービスを利用することが可能な決済代行装置、決済代行システム、決済代行方法、及び決済代行プログラムを提供することを目的とする。【解決手段】決済代行サーバ１１が、決済機能部４２、認証機能部４６、認証・決済処理部５０の機能を有し、認証・決済処理部５０が、決済機能を搭載して第１利用者が利用するクライアント端末１８から利用者情報を含む決済依頼を受け付けて、認証機能部４６による認証を行って、第１利用者とは異なる第２利用者が認証された場合には、第２利用者に対して決済機能部４２による決済処理を行うように処理する。【選択図】図３

Description

本発明は、決済を代行して行うことが可能な決済代行装置、決済代行システム、決済代行方法、及び決済代行プログラムに関する。

特許文献１には、プラスチックやペーパータイプメンバーシップカードの機能をスマートフォンに搭載して使用できる金額決済方法が提案されている。詳細には、特許文献１の金額決済方法は、販売者のスマートフォンが活性化するにつれポイント積立／使用機能選択のためのボタンを含む機能選択画面を表示する段階と、前記ポイント積立／使用機能を選択するにつれ、購買者のスマートフォンに表示する光学コードを認識する段階と、光学コードが認識されるにつれ、認識された光学コードに対応する保有ポイント、使用ポイントおよび決済金額入力のための画面を表示する段階と、販売者が決済金額を入力した後、適用するボタンを選択するにつれ、前記使用ポイントに基づいて差し引かれた決済金額が電子決済代行ＰＧシステムに提供されるように前記差し引かれた決済金額をモバイルウォレット管理システムに伝送する段階を含む。

特開２０１５−１７６４６９号公報

しかしながら、スマートフォンやタブレット端末などの決済サービスを利用可能な携帯端末等のクライアント端末を持っていない人は、決済サービスを利用することができないため、改善の余地がある。

本発明は、上記事実を考慮して成されたもので、決済サービスを利用可能なクライアント端末を持っていない人でも決済サービスを利用することが可能な決済代行装置、決済代行システム、決済代行方法、及び決済代行プログラムを提供することを目的とする。

上記目的を達成するために請求項１に記載の決済代行装置は、決済機能を搭載して第１利用者が利用するクライアント端末から利用者情報を受け付ける受付部と、前記受付部が受け付けた前記利用者情報に基づいて認証された利用者が、前記第１利用者とは異なる第２利用者である場合、前記第２利用者に対して決済処理を行う処理部と、を含む。

請求項１に記載の決済代行装置によれば、受付部では、決済機能を搭載して第１利用者が利用するクライアント端末から利用者情報を受け付ける。

そして、処理部では、受付部が受け付けた利用者情報に基づいて認証された利用者が、第１利用者とは異なる第２利用者である場合、第２利用者に対して決済処理が行われる。これにより、第２利用者が決済サービスを利用可能なクライアント端末を持っていなくても第１利用者のクライアント端末を用いて決済処理が可能となる。従って、決済サービスを利用可能なクライアント端末を持っていない人でも決済サービスを利用することが可能となる。

なお、前記受付部は、前記利用者情報を受け付ける際に、前記クライアント端末の位置情報を更に受け付けてもよい。これにより、決済時の履歴として利用者の位置を取得して、不正の追跡情報として利用することが可能となる。

また、前記クライアント端末は、前記処理部によって前記決済処理が行われた後に、前記第２利用者に関する履歴情報が削除されるようにしてもよい。これにより、個人情報を保護することが可能となる。

また、 前記処理部は、認証された利用者が前記第２利用者である場合、前記第１利用者に対して予め定めた還元を更に行ってもよい。第１利用者に対して、クライアント端末１８を貸し出して決済を代行した対価を提供することが可能となる。

また、前記クライアント端末は、撮影部を含み、前記受付部は、前記撮影部によって撮影された、利用者の生体情報または予め定めた認証用印刷物を前記利用者情報として受け付けてもよい。これにより、撮影するだけで利用者情報を入力できるので、文字入力よりも入力操作を簡単に行うことが可能となる。

また、利用者の認証登録後に、前記認証用印刷物を印刷するための認証用コードを生成し、生成した認証用コードの印刷を促す処理を行う前処理部を更に含んでもよい。これにより、認証用印刷物を持ち歩くことで、他の人のクライアント端末を用いて決済サービスを利用することが可能となる。

請求項７に記載の決済代行システムは、請求項１〜６の何れか１項に記載の決済代行装置と、予め定めたサービスを提供するサービス提供装置と、決済機能を搭載して前記第１利用者が利用する、前記サービスの提供を受ける利用者の前記利用者情報を入力するためのクライアント端末と、を含む。

請求項７に記載の決済代行システムによれば、サービス提供装置では、予め定めたサービスが提供される。

また、決済機能を搭載して第１利用者が利用するクライアント端末により、サービスの提供を受ける利用者の利用者情報を入力することでサービス提供装置が提供する予め定めたサービスを利用することができる。そして、決済代行装置によって決済サービスを利用可能なクライアント端末を持っていない人でも予め定めたサービスに対して決済サービスを利用することが可能となる。

なお、前記サービス提供装置は、配車に関する配車サービスを提供し、前記クライアント端末は、撮影部を含み、前記決済代行装置は、前記配車サービスを用いて配車を手配した場合、第２利用者が所持する予め印刷された認証用印刷物を前記撮影部によって撮影した撮影画像を用いて、本人確認を行ってもよい。

請求項９に記載の決済代行方法は、コンピュータが実行する決済代行方法であって、決済機能を搭載して第１利用者が利用するクライアント端末から利用者情報を受け付け、受け付けた前記利用者情報に基づいて利用者を認証する処理を行い、認証された利用者が前記第１利用者と異なる第２利用者である場合、前記第２利用者に対して決済処理を行う。

請求項９に記載の決済代行方法によれば、決済機能を搭載して第１利用者が利用するクライアント端末から利用者情報を受け付け、受け付けた前記利用者情報に基づいて利用者を認証する処理を行うことにより、利用者認証が行われる。そして、認証された利用者が第１利用者と異なる第２利用者である場合、第２利用者に対して決済処理を行う。これにより、第２利用者が決済サービスを利用可能なクライアント端末を持っていなくても第１利用者のクライアント端末を用いて決済処理が可能となる。従って、決済サービスを利用可能なクライアント端末を持っていない人でも決済サービスを利用することが可能となる。

なお、コンピュータを請求項１〜６の何れか１項に記載の決済代行装置の各部として機能させるための決済代行プログラムとしてもよい。

以上説明したように本発明によれば、決済サービスを利用可能なクライアント端末を持っていない人でも決済サービスを利用することが可能な決済代行装置、決済代行システム、決済代行方法、及び決済代行プログラムを提供できる、という効果がある。

第１実施形態に係る情報処理システムの概略構成を示す図である。 決済代行サーバ、配車計画サーバ、運行管理サーバ、クライアント端末、及び車両側端末の電気系の要部構成を示すブロック図である。 本実施形態に係る決済代行サーバの機能構成を示す機能ブロック図である。 本実施形態に係る配車計画サーバの機能構成を示す機能ブロック図である。 運行エリアの一例を説明するためのＡ〜Ｅ地域を示す図である。 本実施形態に係る情報処理システムの配車計画サーバで行われる処理の流れの一例を示すフローチャートである。 配車計画の一例の前提条件を説明するための図である。 配車候補の基準計画案を説明するための図である。 配車候補の第１案を説明するための図である。 配車候補の第２案を説明するための図である。 配車候補の第３案を説明するための図である。 配車候補の第４案を説明するための図である。 配車候補の計画基準案及び第１案〜第４案の各配送候補の詳細を計算した結果を示す図である。 第１実施形態に係る情報処理システムの決済代行サーバが提供するサービスを利用するために、クライアント端末で行われる利用者登録時の処理の流れの一例を示すフローチャートである。 第１実施形態に係る情報処理システムにおいて、クライアント端末により利用登録時の処理が行われた場合に、決済代行サーバで行われる利用者登録時の処理の流れの一例を示すフローチャートである。 第１述の本実施形態に係る情報処理システムの決済代行サーバが提供するサービスを利用する際の利用者登録時の処理の流れを示すシーケンス図である。 第１実施形態に係る情報処理システムにおいて、配車予約から決済を行う場合のクライアント端末で行われる処理の流れの一例を示すフローチャートである。 第１実施形態に係る情報処理システムにおいて、配車予約から決済を行う場合の配車計画サーバで行われる処理の流れの一例を示すフローチャートである。 第１実施形態に係る情報処理システムにおいて、配車予約から決済を行う場合の決済代行サーバで行われる処理の流れの一例を示すフローチャートである。 第１実施形態に係る情報処理システムにおいて、配車予約から決済を行う場合の処理の流れを示すシーケンス図である。 第１実施形態に係る情報処理システムにおいて、配車予約した車両への乗降時に車両側端末で行われる処理の流れの一例を示すフローチャートである。 第１実施形態に係る情報処理システムにおいて、配車予約した車両への乗降時に決済代行サーバで行われる処理の流れの一例を示すフローチャートである。 第１実施形態に係る情報処理システムにおいて、配車予約した車両に乗降する際に配車計画サーバで行われる処理の流れの一例を示すフローチャートである。 第１実施形態に係る情報処理システムにおいて、配車予約した車両への乗降時の処理の流れを示すシーケンス図である。 第２実施形態に係る情報処理システムの概略構成を示す図である。 買い物支援サーバ、商品管理サーバ、配送管理サーバ、及び買い物代行オペレータ端末の電気系の要部構成を示すブロック図である。 クライアント端末に予めインストールされたサポートアプリケーションにより表示される画面の一例としての初期画面、買い物項目選択画面、及び店舗選択画面を示す図である。 各店舗で買い物を行う際に表示される画面の一例としての買い物支援選択画面、ストリーミング画面、買い物リスト利用可否選択画面、買い物リスト画面を示す図である。 ストリーミング画面または買い物リスト画面で「レジに進む」が選択された場合に表示される画面の一例としての決済画面、配達画面、決済代行認証画面、認証確認画面を示す図である。

以下、図面を参照して本発明の実施の形態の一例を詳細に説明する。
（第１実施形態）
図１は、第１実施形態に係る情報処理システムの概略構成を示す図である。本実施形態は、複数のサーバを含む情報処理システム１０を決済代行システムの一例として説明する。

本実施形態に係る情報処理システム１０は、図１に示すように、決済代行装置としての決済代行サーバ１１、サービス提供装置としての配車計画サーバ１２、運行管理サーバ１４、クライアント端末１８、及び車両側端末２０を含む。そして、各々が通信ネットワーク２２に接続されている。

決済代行サーバ１１は、決済機能を搭載して第１利用者が利用するクライアント端末から利用者情報を受け付けて、利用者情報に基づいて認証された利用者が、第１利用者とは異なる第２利用者である場合、第２利用者に対して決済処理を行う。これにより、予め登録された利用者が決済可能な端末を所持していない場合であっても、代行者の端末を用いて、代行して決済を行うサービスを提供できる。例えば、スマートフォン等の携帯端末を持っていない人は、ネットワーク上で行われる決済サービスを利用することができない。そこで、決済代行サーバ１１は、携帯端末を持っていない人でも、利用者を予め登録しておくことにより、他の代行者の携帯端末を用いて決済の代行を可能とする処理を行う。

配車計画サーバ１２は、予め登録された利用者からの人や物を含む輸送対象を輸送するための配車依頼情報を受け付けて配車計画を作成し、配車する車両に対して、作成した配車計画を配信する処理等を行う。また、配車計画サーバ１２は、配車に関する種々の情報を収集してデータベースとして蓄積して配車を管理する。蓄積する種々の情報の一例としては、例えば、利用者から収集した情報や、車両から収集した車両情報などを蓄積する。利用者から収集した情報の一例としては、利用者データ、利用目的、予約データ（輸送元となる配車地点、輸送先となる目的地点、配車希望日時等を含む）、キャンセル実績（キャンセル日時等）、アンケート結果（満足度）などがある。利用者から収集した情報は、これらの中から収集可能な情報を収集して蓄積する。また、車両から収集した情報の一例としては、配車指示受信時間、配車地点、目的地点、乗車日時（配車完了日時）、降車日時（到着日時）等の運行実績などがある。車両から収集した情報は、これらの中から収集可能な情報を収集して蓄積する。

運行管理サーバ１４は、タクシー２６やバス２８等を車両から収集可能な種々の車両情報を収集してデータベースとして蓄積して運行状況を管理する。車両から収集する種々の車両情報の一例としては、車両の位置情報、行き先情報、貨客積載状況の情報、運行対象の地域を表す地域情報、走行データ、運転操作データ、残エネルギーデータ、ドア等設備動作データ等がある。車両情報は、これらの中から車両から収集可能な情報を収集して蓄積する。

クライアント端末１８は、各種サービスを提供するクラウドサーバ等のサーバにアクセスして、各サーバが提供する各種サービスを受けるためのインタフェースとして機能する。本実施形態では、配車計画サーバ１２及び決済代行サーバ１１にアクセスして、配車計画サーバが提供する配車サービス及び決済代行サーバ１１が提供する決済代行サービスを受けるためのインタフェースとして機能する。具体的には、配車計画サーバ１２に対して人や物の輸送の依頼等を行う。クライアント端末１８は、利用者の操作によって輸送元及び輸送先の各々の位置を含む輸送依頼情報を生成して配車計画サーバ１２に送信する。また、クライアント端末１８を利用する利用者の利用者が、配車を依頼した場合に、当該利用者に対して決済を行う処理を行う。クライアント端末１８は、例えば、図１に示すように、パーソナルコンピュータ１８ａを適用してもよいし、スマートフォンやタブレット端末等の携帯端末１８ｂを適用してもよいし、インターネットテレビ等を適用してもよい。携帯端末１８ｂを適用する場合には、無線中継局２４を介して通信ネットワーク２２に接続される。

車両側端末２０は、タクシー２６やバス２８等の配車対象の車両に搭載され、運行管理サーバ１４に車両の位置情報を含む車両情報を送信する機能や、配車計画サーバ１２が作成した配車計画を受信する機能等を有する。車両側端末２０は、例えば、図１に示すように、スマートフォンやタブレット端末等の携帯端末２０ａを適用してもよいし、通話機能や情報を送受信する通信機能等を備えた専用の車載器２０ｂを適用してもよい。専用の車載器２０ｂとしては、例えば、ＤＣＭ（Data Communication Module）と称される専用の車載器を適用してもよい。

続いて、本実施形態に係る情報処理システム１０における配車計画サーバ１２、決済代行サーバ１１、運行管理サーバ１４、クライアント端末１８、及び車両側端末２０の電気系の要部構成について説明する。

図２は、決済代行サーバ１１、配車計画サーバ１２、運行管理サーバ１４、クライアント端末１８、及び車両側端末２０の電気系の要部構成を示すブロック図である。なお、決済代行サーバ１１、配車計画サーバ１２、運行管理サーバ１４、クライアント端末１８、及び車両側端末２０は基本的には一般的なコンピュータの構成とされているので、ここでは決済代行サーバ１１を代表して説明する。

決済代行サーバ１１は、図２に示すように、ＣＰＵ（Central Processing Unit）１１Ａ、ＲＯＭ（Read Only Memory）１１Ｂ、ＲＡＭ（Random Access Memory）１１Ｃ、ストレージ１１Ｄ、操作部１１Ｅ、表示部１１Ｆ、及び通信Ｉ／Ｆ（インタフェース）部１１Ｇを備えている。

ＣＰＵ１１Ａは、受付部、処理部、及び前処理部として機能する中央演算処理ユニットであり、各種プログラムを実行することにより、装置の全体の動作を司る。ＲＯＭ１１Ｂは、各種制御プログラムや各種パラメータ等が予め記憶される。ＲＡＭ１１Ｃは、ＣＰＵ１１Ａによる各種プログラムの実行時のワークエリア等として用いられる。ストレージ１１Ｄは、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等の各種記憶部により構成され、各種データやアプリケーション・プログラム等が記憶される。操作部１１Ｅは、キーボードやマウス、タッチパネル等からなり、各種の情報を入力するために用いられる。表示部１１Ｆは、各種の情報を表示するために用いられる。通信Ｉ／Ｆ部１１Ｇは、ＬＡＮや、ＷＡＮ、インターネット等の各種ネットワーク等の通信ネットワーク２２に接続可能とされ、当該通信ネットワーク２２に接続された他の装置と各種データの送受信を行う。以上の決済代行サーバ１１の各部はシステムバス１１Ｈにより電気的に相互に接続されている。

以上の構成により、決済代行サーバ１１は、ＣＰＵ１１Ａにより、ＲＯＭ１１Ｂ、ＲＡＭ１１Ｃ、及びストレージ１１Ｄに対するアクセス、操作部１１Ｅを介した各種データの取得、表示部１１Ｆに対する各種情報の表示を各々実行する。また、決済代行サーバ１１は、ＣＰＵ１１Ａにより、通信Ｉ／Ｆ部１１Ｇを介した通信データの送受信の制御を実行する。

なお、クライアント端末１８や車両側端末２０については、図２の点線で示すように、撮影部としてのカメラ１８Ｉ、２０Ｉ、音声入出力部１８Ｊ、２０Ｊ、及び位置検出部１８Ｋ、２０Ｋ等を更に含む。

カメラ１８Ｉ、２０Ｉは、静止画像や動画像を撮影することによって、動画像または静止画像を表す画像データを生成する。

音声入出力部１８Ｊ、２０Ｊは、スピーカやヘッドフォン等から音声を出力し、マイク等により集音することにより音声を入力し、入力した音声を表す音声情報を生成する。

位置検出部１８Ｋ、２０Ｋは、クライアント端末１８や車両側端末２０の現在の位置情報を検出する。例えば、ＧＰＳ（Global Positioning System）衛星からの電波を受信し、３つ以上のＧＰＳ衛星からの距離に基づいて、空間上の一点の位置を測位することにより、位置を検出する。

続いて、決済代行サーバ１１のＣＰＵ１１ＡがＲＯＭ１１Ｂに記憶されたプログラムをＲＡＭ１１Ｃに展開して実行することにより実行される機能の一例について説明する。図３は、本実施形態に係る決済代行サーバ１１の機能構成を示す機能ブロック図である。

決済代行サーバ１１は、図３に示すように、登録部４０、決済機能部４２、利用者ＤＢ（データベース）４４、認証機能部４６、認証情報ＤＢ４８、及び認証・決済処理部５０の機能を有する。なお、認証・決済処理部５０は受付部及び処理部に対応する。

登録部４０は、決済代行サーバ１１が提供する決済代行サービスを利用するための利用者登録情報を受け付ける。例えば、クライアント端末１８を利用者が操作することによって入力された利用者登録情報を受け付ける。利用者登録情報としては、電子メールのメールアドレス、住所、氏名、年齢、性別、顔写真等の情報を受け付ける。また、登録部４０は、利用者登録情報を受け付けると、決済機能部４２に対して決済用登録を依頼し、登録後に利用者登録完了通知をクライアント端末１８に返信する処理等を行う。なお、認証用コードの一例としての二次元バーコードやバーコード等の認証用コードを用いて利用者の認証を行う場合には、クライアント端末１８に利用者登録完了通知を返信する際に、利用者を認証するための認証用コードを生成して利用者登録完了通知と共に返信する。

決済機能部４２は、登録部４０が利用者登録情報を受け付けて利用者の登録を行う場合、利用者登録情報を決済用利用者情報として利用者ＤＢ４４に格納する。また、決済機能部４２は、認証機能部４６に対して認証用情報の登録を依頼し、認証用登録の完了通知を受信したところで利用者完了通知を登録部４０に送信する処理を行う。また、決済機能部４２は、決済処理の依頼に対して利用者ＤＢ４４に登録された利用者であるか否かを利用者ＤＢ４４に格納された決済用利用者情報に基づいて特定し、特定した利用者に対する決済処理を行う。なお、本実施形態では、決済用利用者情報は、利用者情報を決済用利用者情報として利用者ＤＢに格納するが、利用者情報と決済用利用者情報は、異なるものであってもよい。例えば、電子メールのメールアドレス、住所、氏名、年齢、性別、顔写真等の情報のうち全てを決済用利用者情報と登録してもよいし、決済に必要な一部の情報を決済用利用者情報として登録してもよい。

認証機能部４６は、決済機能部４２から認証情報の登録が依頼されて利用者登録を行う場合、認証情報ＤＢ４８に認証情報を格納し、認証用登録の完了通知を決済機能部４２に送信する処理を行う。また、認証機能部４６は、認証依頼の利用者が認証情報ＤＢ４８に登録された利用者であるか否かの照合を行って認証結果を返信する処理等を行う。なお、認証情報は、利用者登録情報または決済用登録情報のうち認証に必要な利用者ＩＤや、顔写真等を登録する。

認証・決済処理部５０は、クライアント端末１８から利用者情報を含む決済依頼を受け付けて、認証機能部４６による認証を行って、認証された場合に決済機能部４２による決済処理を行うように処理する。本実施形態では、認証・決済処理部は、決済機能を搭載して第１利用者が利用するクライアント端末１８から利用者情報を受け付けて、第１利用者とは異なる第２利用者が認証された場合には、第２利用者に対して決済処理を行う。なお、認証・決済処理部５０は、クライアント端末１８から決済依頼を受け付ける際に、クライアント端末１８の位置情報を更に受け付けてもよい。これにより、決済時の履歴として利用者の位置を取得して、不正の追跡情報として利用することが可能となる。

続いて、配車計画サーバ１２のＣＰＵ１２ＡがＲＯＭ１２Ｂに記憶されたプログラムをＲＡＭ１２Ｃに展開して実行することにより実行される機能の一例について説明する。図４は、本実施形態に係る配車計画サーバ１２の機能構成を示す機能ブロック図である。

配車計画サーバ１２は、図４に示すように、配車受付部３０、車両情報収集部３２、配車候補導出部３４、配車計画決定部３６、及び配車計画配信部３８の機能を有する。そして、配車計画サーバ１２は、クライアント端末１８から貨客の輸送依頼を表す配車依頼情報を受け付けて、出発地点から目的地点までの複数の地域それぞれを網羅する複数の車両のそれぞれの配車計画を作成して各車両の配信する処理を行う。これにより、複数の地域を含むより広い範囲で人や物を運ぶことが可能となる。なお、タクシー２６や乗り合いのバス２８等の車両の運行エリアが複数あり、一部は接している、または重複し、運行エリアが業者毎に定められているような場合は、貨客の引継ぎ等を考慮して運行計画を作成する。具体的には、買い物した商品を配達する場合、利用者が配達を依頼した配達物を保管している店舗から配達先までに、タクシー２６やバス２８の複数の運行エリアが存在する場合、予め定めた時間範囲内（例えば、１６時〜１６時１０分等）に、その部分エリアで商品を受け渡すように配車計画を作成する。例えば、タクシー２６またはバス２８の運行エリアが図５に示すＡ〜Ｅ地域毎に予め定められているような場合、各地域の接する部分エリアで商品を受け渡すように配車計画を作成する。なお、タクシー２６の運行エリアについては、例えば、運行エリアを越えて往路は人を運び、復路は配達物を運ぶといったように、人流と物流を考慮して配車計画を決定してもよい。

配車受付部３０は、輸送元としての貨客の出発地点の位置、及び輸送先としての目的地点の位置を少なくとも含む配送依頼情報をクライアント端末１８から受け付ける。すなわち、利用者がクライアント端末１８を操作して入力された配送依頼情報を、通信ネットワーク２２を介して受信することにより配送依頼情報を受け付ける。

車両情報収集部３２は、運行管理サーバ１４を介して、予め登録された地域毎のタクシー会社やバス会社等の配車対象の車両の情報を収集する。すなわち、本実施形態では、運行管理サーバ１４が配車対象の各車両の車両情報を収集し、車両情報収集部３２は、運行管理サーバ１４が収集した車両情報を取得する。車両情報としては、車両の位置情報、行き先情報、貨客積載状況の情報、運行対象の地域を表す地域情報等の情報を運行管理サーバ１４から通信ネットワーク２２を介して取得する。

配車候補導出部３４は、配車受付部３０が受け付けた配送依頼情報、及び車両情報収集部３２によって収集された車両情報に基づいて、車両とルートを定めた配車候補を導出する。例えば、配車候補導出部３４は、配送依頼情報に含まれる出発地点から目的地点までの配送候補の車両と、配送候補のルートを全て配送候補として導出する。また、配送候補のそれぞれについて、走行距離や、完了時間などの配送候補を決定するための情報を導出する。なお、配車候補導出部３４は、配送候補の車両としてタクシー２６を適用する際には、輸送対象が物である場合は、輸送元の地域を越えて人を輸送し、当該タクシーが、輸送先から輸送元の地域に戻る場合は、輸送対象を物に限定して配車候補を導出してもよい。これにより、タクシー会社の運行エリアが決まっていても通常の業務と同様に人を運ぶことができると共に、物を広範囲に運ぶことが可能となる。

配車計画決定部３６は、配車候補導出部３４が導出した配車候補の中から、配車計画を決定する。詳細には、予め定めた時間範囲内に、複数の地域それぞれが接する部分領域に車両が位置するように配車計画を決定する。具体的には、タクシー２６やバス２８等のように運行エリアが定められているような車両を配送候補に含める場合、予め定めた時間範囲内に、複数の地域それぞれが接する部分領域に車両が位置するように配車計画を決定する。配車計画決定部３６は、配車候補導出部により複数の配車候補が導出された場合には、予め定めた条件を満たす配車候補を配車計画として決定する。

配車計画配信部３８は、配車計画決定部３６が決定した配車計画に含まれるタクシー２６やバス２８等の車両の車両側端末２０に対して配車計画を配信する。すなわち、配車対象の各車両に対して通信ネットワーク２２を介して配車計画を送信する。配車計画の配信は、配車計画サーバ１２から通信ネットワーク２２を介して各車両に直接配信してもよいし、運行管理サーバ１４を経由して各車両に配信してもよい。これにより、各車両の車両側端末２０で配車計画を受信して、各車両の運転者により、配車計画に従った運行が可能となる。なお、運行管理サーバ１４から各車両に配車計画を配信する場合は、通信ネットワーク２２経由以外に、無線等を利用して運転者に通知する形態としてもよい。

続いて、上述のように構成された本実施形態に係る情報処理システム１０の各部で行われる具体的な処理について説明する。

まず、配車計画サーバ１２で行われる具体的な処理について説明する。図６は、本実施形態に係る情報処理システム１０の配車計画サーバ１２で行われる処理の流れの一例を示すフローチャートである。なお、図６の処理は、例えば、予め定めた単位時間（例えば、１〜３時間等）が経過する毎に実行する。

ステップ１００では、ＣＰＵ１２Ａが、予め定めた単位時間内の配車依頼情報を取得してステップ１０２へ移行する。本実施形態では、配車計画サーバ１２は、配車依頼情報を受け付ける毎に配車計画を作成するのではなく、予め定めた単位時間（例えば、１〜３時間等）分の配車依頼を蓄積して単位時間毎の配車計画を作成するために、配車受付部３０が、単位時間内の配車依頼を取得する。

ステップ１０２では、ＣＰＵ１２Ａが、現在の車両位置を含む車両情報を収集してステップ１０４へ移行する。すなわち、車両情報収集部３２が、運行管理サーバ１４を介して、予め登録された地域毎のタクシー会社やバス会社等の配車対象の車両情報を収集する。本実施形態では、車両情報収集部３２は、運行管理サーバ１４が収集した車両情報を取得する。

ステップ１０４では、ＣＰＵ１２Ａが、全ての配車候補を導出してステップ１０６へ移行する。すなわち、配車候補導出部３４が、配車受付部３０が受け付けた配送依頼情報、及び車両情報収集部３２によって収集された車両情報に基づいて、配車候補を導出する。例えば、配車候補導出部３４は、配送依頼情報に含まれる出発地点から目的地点までの配送候補の車両と、配送候補のルートを全て配送候補として導出する。また、配送候補のそれぞれについて、走行距離や、完了時間などの配送候補を決定するための情報についても導出する。なお、配送候補の車両としてタクシー２６を適用して配車候補導出部３４が配送候補を導出する際には、タクシーが運行する輸送元の地域を越えて人を輸送し、当該タクシーが、輸送先から輸送元の地域に戻る場合は、輸送対象を物に限定して配車候補を導出するようにしてもよい。これにより、タクシー会社の運行エリアが決まっていても通常の業務と同様に人を運ぶことができると共に、物を広範囲に運ぶことが可能となる。

ステップ１０６では、ＣＰＵ１２Ａが、配車候補導出部３４によって導出された配車候補の中から配車計画を決定してステップ１０８へ移行する。すなわち、配車計画決定部３６が、配車候補導出部３４が導出した配車候補の中から、配車候補を決定することにより配車計画を決定する。例えば、配車候補のうちタクシー２６やバス２８等のように運行エリアが存在する場合は、予め定めた時間範囲内に、複数の地域それぞれが接する部分領域に車両が位置するように配車計画を作成する。また、配車計画決定部３６は、配車候補導出部により複数の配車候補が導出された場合には、予め定めた条件を満たす配車候補を配車計画として決定する。予め定めた条件は、配達時間が最短時間、配達距離が最短距離、配車台数が最小台数等を適用してもよい。

ステップ１０８では、ＣＰＵ１２Ａが、対応車両に配車計画を配信して一連の処理を終了する。すなわち、配車計画配信部３８が、配車計画決定部３６が決定した配車計画に含まれるタクシー２６やバス２８等の車両の車両側端末２０に対して配車計画を配信する。これにより、各車両の車両側端末２０で配車計画を受信して、各車両の運転者により、配車計画に従った運行が可能となる。これにより、複数の地域の車両を連携させて輸送することが可能となるので、広い範囲で人や物を運ぶことが可能となる。

なお、図６の処理では、配車計画サーバ１２は、予め定めた単位時間毎の配車依頼に対して配車計画を作成する例を説明したが、これに限るものではない。例えば、配車計画サーバ１２が配車依頼情報を受け付ける毎に配車計画を作成する形態としてもよい。

次に、本実施形態に係る情報処理システム１０の配車計画サーバ１２が行う配車計画について、一例を挙げて具体的に説明する。図７は、配車計画の一例の前提条件を説明するための図である。

例えば、図７に示すように、Ａ〜Ｅ地域を配車計画の対象として、商品を店舗から配達する場合について説明する。図７の例では、Ｄ地域の星印を、配送を開始する配送ポイントとし、Ｃ〜Ｅ地域が接する部分エリア、及びＡ〜Ｃ地域が接する部分エリアをそれぞれ受渡ポイント１、受渡ポイント２とする。

配車計画サーバ１２は、基本的には、Ａ〜Ｅ地域のそれぞれの地域の時間当たりの配達依頼分に合わせて配車を計画する。

また、輸送する荷物の量はＤ地域＞Ｃ地域＞Ａ地域、Ｂ地域、Ｅ地域となるため、輸送量に合わせて、Ｄ地域の区間ではＣ地域、Ｅ地域の車両を追加配車し、Ｃ地域の区間は、Ａ地域、Ｂ地域の区間の車両を追加配車する、といった調整を行う。これにより、輸送量の増減に柔軟に対応することができる。なお、出発地点以外の地域の車両を追加配車する場合は、各地域が接する部分エリアとしての受渡ポイントに予め定めた時刻範囲に位置するように、配車する車両の調整及び配送ポイントからの配送開始時間の調整を含めて調整する。

さらに、商品の配達を受け付ける際に、各地域の配達予約可能時間を調整することで、引継ぎ待ち時間を最適化できる。配達予測可能時間は、例えば、配車依頼情報を受け付ける際に、利用者に対して、地域毎の配達予約可能時間を提示することにより調整し、提示した配達予約可能時間より短い時間の配達依頼の受付を禁止する。例えば、図７の例であれば、Ｄ地域→Ｅ地域、Ｃ地域→Ａ地域、Ｂ地域という順が成立するように、各地域の配達予約可能時間を調整することで、各受渡ポイントでの引き継ぎでの待ち時間を少なくすることができる。

ここで、Ａ地域は４件の依頼、Ｂ地域は３件の依頼、Ｃ地域は３件の依頼、Ｄ地域は５件の依頼、Ｅ地域は２件の依頼があったとする。また、前提条件として、距離（区間主線路）は、Ｄ区間の距離を１として、Ａ区間は２、Ｂ区間は１．５、Ｃ区間は１．５、Ｅ区間は２．５とする。また、車両数は、利用可能台数を５台とし、１台当たりの最大輸送量は４席または８個口（２個口／１席）とする。また、１距離当たりの走行時間は３０とし、１個口当たりの配達時間（走行から渡すまでの時間）は１０とし、１個口当たりの受渡・引継時間は１とする。

また、利用制約として、利用者には配達依頼時に５台の車両を稼動可能な配達可能時間帯を通知し、配達可能時間帯以外の配達は受け付けないものとする。

このような予め定めた前提条件及び利用制約に応じて、配車計画サーバ１２の配車候補導出部３４が、輸送する車両とルートとを定めた複数の配車候補を導出する。

具体的には、配車候補導出部３４が、まず、配車候補の基準となる計画基準案として、受渡を行わず、かつ１車両で複数区間を配達しない配達計画を作成する。図８は、配車候補の基準計画案を説明するための図である。

計画基準案では、Ｄ地域、Ｃ地域、Ａ地域の順に配送する車両を１号車とし、１号車は配送ポイントで４個口を搭載してＡ地域で４個口を配達する。

また、Ｄ地域、Ｃ地域、Ｂ地域の順に配送する車両を２号車とし、２号車は配送ポイントで３個口を搭載してＢ地域で３個口を配達する。

また、Ｄ地域、Ｃ地域の順に配送する車両を３号車とし、３号車は配送ポイントで３個口を搭載してＣ地域で３個口を配達する。

また、Ｄ地域を配送する車両を４号車とし、４号車は配送ポイントで５個口を搭載してＤ地域で５個口を配達する。

そして、Ｄ地域、Ｅ地域の順に配送する車両を５号車とし、５号車は配送ポイントで２個口を搭載してＥ地域で２個口を配達する。

次に、配車候補導出部３４が、配車候補の第１案として、まずは区間内だけの輸送を行い、受渡ポイントで受渡を行う配車を計画する。図９は、配車候補の第１案を説明するための図である。

第１案では、Ａ地域を配送する車両を１号車とし、Ｂ地域を配送する車両を２号車とし、Ｃ地域を配送する車両を３号車とし、Ｄ地域を配送する車両を４号車とし、Ｅ地域を配送する車両を５号車とする。

１号車は、受渡ポイント２で３号車から４個口を引き継いでＡ地域で４個口を配達する。２号車は、受渡ポイント２で３号車から３個口を引き継いでＢ地域で３個口を配達する。３号車は、受渡ポイント１で４号車から１０個口を引き継いでＣ地域で３個口を配達しながら、受渡ポイント２へ移動して、１号車に４個口、２号車に３個口を受け渡す。４号車は、配送ポイントで１７個口を搭載し、Ｄ地域で５個口を配達しながら受渡ポイント１へ移動して、３号車に１０個口、５号車に２個口を受け渡す。５号車は、受渡ポイント１で４号車から２個口を引き継いでＥ地域で２個口を配達する。

第１案では、Ｄ地域の輸送合計が１７となり、１７／８＞２台となることから、この計画は不成立と分かる。また、輸送分担の合計量よりＤ地域の区間では３台以上での走行が、Ｃ地域の区間では２台以上での走行が必須と分かる。

次に、配車候補導出部３４が、配車候補の第２案として、第１案におけるＤ地域の隣接区間であるＥ地域の区間とＣ地域の区間の車両に、４号車の輸送分担を分配し、３号車の輸送分担もＣ地域の隣接区間のＢ地域の車両に分配する配車を計画する。図１０は、配車候補の第２案を説明するための図である。また、第２案では、隣接区間が複数の場合、全ての隣接区間で同様の分配を行う。但し、最大輸送量を超える場合は除外する。図１０のケースでは２号車に分配した例を示す。

第２案では、Ａ地域を配送する車両を１号車とし、Ｃ地域、Ｂ地域の順に配送する車両を２号車とし、Ｄ地域、Ｃ地域の順に配送する車両を３号車とし、Ｄ地域を配送する車両を４号車とし、Ｄ地域、Ｅ地域の順に配送する車両を５号車とする。

１号車は、受渡ポイント２で３号車から４個口を引き継いでＡ地域で４個口を配達する。２号車は、受渡ポイント１で５号車から３個口を引き継いでＢ地域で３個口を配達する。３号車は、配送ポイントで７個口を搭載し、Ｃ地域で３個口を配達しながら受渡ポイント１へ移動して、１号車に４個口を受け渡す。４号車は、配送ポイントで５個口を搭載してＤ地域で５個口を配達する。５号車は、配送ポイントで５個口を搭載して受渡ポイントへ移動して１号車に４個口を受け渡して、その後、Ｅ地域で２個口を配達する。

次に、配車候補導出部３４が、配車候補の第３案として、第２案と同様に、第１案におけるＤ地域の隣接区間であるＥ地域の区間とＣ地域の区間の車両に、４号車の輸送分担を分配し、３号車の輸送分担もＣ地域の隣接区間のＡ地域の車両に分配する配車を計画する。図１１は、配車候補の第３案を説明するための図である。

第３案では、Ｃ地域、Ａ地域の順に配送する車両を１号車とし、Ｂ地域を配送する車両を２号車とし、Ｄ地域、Ｃ地域の順に配送する車両を３号車とし、Ｄ地域を配送する車両を４号車とし、Ｄ地域、Ｅ地域の順に配送する車両を５号車とする。

１号車は、受渡ポイント１で５号車から４個口を引き継いでＡ地域で４個口を配達する。２号車は、受渡ポイント２で３号車から３個口を引き継いでＢ地域で３個口を配達する。３号車は、配送ポイントで６個口を搭載し、Ｃ地域で３個口を配達しながら受渡ポイント２へ移動して２号車に３個口を受け渡す。４号車は、配送ポイントで５個口を搭載してＤ地域で５個口を配達する。５号車は、配送ポイントで５個口を搭載して受渡ポイントへ移動して１号車に４個口を受け渡して、その後、Ｅ地域で２個口を配達する。

次に、配車候補導出部３４が、配車候補の第４案として、Ａ−Ｅ地域の全区間を少なくとも１回は通過し、受渡が１回も発生せず、各車両への分配結果が最大輸送量を超えず、かつ重複区間（Ｃ、Ｄ）のみの配達車両がない場合、があれば計画を立てる。図１２は、配車候補の第４案を説明するための図である。なお、図１２は一例であり、担当区間合計が最小となり、かつ最終配達完了時間の最大が最短となる配達分担である。

１号車は、配送ポイントで７個口を搭載して、Ｄ地域で５個口を配達し、Ｅ地域で２個口を配達する。２号車は、配送ポイントで４個口を搭載してＡ地域で４個口を配達する。３号車は、配送ポイントで６個口を搭載してＣ地域で３個口を配達し、Ｂ地域で３個口を配達する。

続いて、上述した前提条件に基づいて、配車候補導出部３４が、配送候補のそれぞれについて、走行距離や、完了時間などの配送候補を決定するための情報を導出する。一例として、計画基準案及び第１〜第４案の各配送候補の詳細を計算した結果を図１３に示す。図１３は、配車候補の計画基準案及び第１案〜第４案の各配送候補の詳細を計算した結果を示す図である。

図１３では、車両Ｎｏ．、計画ルート、通過受渡ポイント、走行距離、走行時間、配達分担、配達効率、輸送分担、走行開始ポイント、運行開始時間、最終配達完了時間を計算結果として示す。なお、配達分担は、Ａ〜Ｅの各地域の区間での配達量を示し、合計、時間、及び担当区間を示す。また、配達効率は、距離当たりの配達量を示し、計画案の評価指標の１つとする。また、輸送分担は、Ａ〜Ｅの各地域の受渡分を含めた輸送量を示し、合計、空席数、受渡回数、受渡個口、引継時間、及び成立の有無を示す。

詳細には、図１３に示すように、基準計画案の１号車は、計画ルートがＤ→Ｃ→Ａ、通過受渡ポイントが受渡ポイント１、２、走行距離が４．５、走行時間が１３５、配達分担は、Ａ地域が４で合計４、時間が４０、担当区間が１となる。輸送分担は、Ａ地域の４で合計が４、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１７５となる。

基準計画案の２号車は、計画ルートがＤ→Ｃ→Ｂ、通過受渡ポイントが受渡ポイント１、２、走行距離が４、走行時間が１２０、配達分担は、Ｂ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ｂ地域の３で合計が３、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１５０となる。

基準計画案の３号車は、計画ルートがＤ→Ｃ、通過受渡ポイントが受渡ポイント１、２、走行距離が２．５、走行時間が７５、配達分担は、Ｃ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ｃ地域の３で合計が３、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１０５となる。

基準計画案の４号車は、計画ルートがＤ、通過受渡ポイントが受渡ポイント１、走行距離が１、走行時間が３０、配達分担は、Ｄ地域が５で合計５、時間が５０、担当区間が１となる。輸送分担は、Ｄ地域の５で合計が５、空席数が１、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は８０となる。

基準計画案の５号車は、計画ルートがＤ→Ｅ、通過受渡ポイントが受渡ポイント１、走行距離が３．５、走行時間が１０５、配達分担は、Ｅ地域が２で合計２、時間が２０、担当区間が１となる。輸送分担は、Ｅ地域の２で合計が２、空席数が３、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１２５となる。

そして、基準計画案では、図１３に示すように、車両の合計が５台必要で、走行距離の合計が１５．５、走行時間の合計が４６５、配達分担のＡの合計が４、Ｂの合計が３、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、配達分担の全合計が１７、時間の全合計が１７０、担当区間の合計が５となり、配達効率が１．１０となる。また、輸送分担のＡの合計が４、Ｂの合計が３、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、輸送分担の全合計が１７となる。また、輸送分担の空席数の合計が１０、受渡回数の合計が０、受渡個口の合計が０、受渡時間の合計が０、引継回数の合計が０、引継個口の合計が０、引継時間の合計が０で成立し、最終配達完了時間は最大が１７５となる。

第１案の１号車は、計画ルートがＡ、通過受渡ポイントが受渡ポイント２、走行距離が２、走行時間が６０、配達分担は、Ａ地域が４で合計４、時間が４０、担当区間が１となる。輸送分担は、Ａ地域の４で合計が４、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が１、引継個口が４、引継時間が４で成立する。運行開始ポイントは受渡ポイント２、運行開始時間は１７４、最終配達完了時間は２７４となる。

第１案の２号車は、計画ルートがＢ、通過受渡ポイントが受渡ポイント２、走行距離が１．５、走行時間が４５、配達分担は、Ｂ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ｂ地域の３で合計が３、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が１、引継個口が３、引継時間が３で成立する。運行開始ポイントは受渡ポイント２、運行開始時間は１７４、最終配達完了時間は２４９となる。

第１案の３号車は、計画ルートがＣ、通過受渡ポイントが受渡ポイント１、２、走行距離が１．５、走行時間が４５、配達分担は、Ｃ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ａ地域が４、Ｂ地域が３、Ｃ地域が３で合計が１０、受渡回数が２、受渡個口が７、受渡時間が７、引継回数が１、引継個口が１０、引継時間が１０で不成立となる。運行開始ポイントは受渡ポイント１、運行開始時間は９２、最終配達完了時間は１７４となる。

第１案の４号車は、計画ルートがＤ、通過受渡ポイントが受渡ポイント１、走行距離が１、走行時間が３０、配達分担は、Ｄ地域が５で合計５、時間が５０、担当区間が１となる。輸送分担は、Ａ地域が４、Ｂ地域が３、Ｃ地域が３、Ｄ地域が５、Ｅ地域が２で合計が１７、受渡回数が２、受渡個口が１２、受渡時間が１２、引継回数が０、引継個口が０、引継時間が０で不成立となる。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は９２となる。

第１案の５号車は、計画ルートがＥ、通過受渡ポイントが受渡ポイント１、走行距離が２．５、走行時間が７５、配達分担は、Ｅ地域が２で合計２、時間が２０、担当区間が１となる。輸送分担は、Ｅ地域が２で合計が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が１、引継個口が２、引継時間が２で成立する。運行開始ポイントは受渡ポイント１、運行開始時間は９２、最終配達完了時間は１８７となる。

そして、第１案では、図１３に示すように、車両の合計が５台必要で、走行距離の合計が８．５、走行時間の合計が２５５、配達分担のＡの合計が４、Ｂの合計が３、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、配達分担の全合計が１７、時間の全合計が１７０、担当区間の合計が５となり、配達効率が２．００となる。また、輸送分担のＡの合計が１２、Ｂの合計が９、Ｃの合計が６、Ｄの合計が５、Ｅの合計が４となり、輸送分担の全合計が３６となる。また、輸送分担の受渡回数の合計が４、受渡個口の合計が１９、受渡時間の合計が１９、引継回数の合計が４、引継個口の合計が１９、引継時間の合計が１９で不成立となり、第１案は不成立となる。

また、第２案の１号車は、計画ルートがＡ、通過受渡ポイントが受渡ポイント２、走行距離が２、走行時間が６０、配達分担は、Ａ地域が４で合計４、時間が４０、担当区間が１となる。輸送分担は、Ａ地域の４で合計が４、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が１、引継個口が４、引継時間が４で成立する。運行開始ポイントは受渡ポイント２、運行開始時間は７９、最終配達完了時間は１７９となる。

第２案の２号車は、計画ルートがＣ→Ｂ、通過受渡ポイントが受渡ポイント１、走行距離が３、走行時間が９０、配達分担は、Ｂ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ｂ地域の３で合計が３、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が１、引継個口が３、引継時間が３で成立する。運行開始ポイントは受渡ポイント１、運行開始時間は３３、最終配達完了時間は１５３となる。

第２案の３号車は、計画ルートがＤ→Ｃ、通過受渡ポイントが受渡ポイント１、２、走行距離が２．５、走行時間が７５、配達分担は、Ｃ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ａ地域が４、Ｃ地域の３で合計が７、空席数が０、受渡回数が１、受渡個口が４、受渡時間が４、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１０９となる。

第２案の４号車は、計画ルートがＤ、通過受渡ポイントが受渡ポイント１、走行距離が１、走行時間が３０、配達分担は、Ｄ地域が５で合計５、時間が５０、担当区間が１となる。輸送分担は、Ｄ地域が５で合計が５、空席数が１、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は８０となる。

第２案の５号車は、計画ルートがＤ→Ｅ、通過受渡ポイントが受渡ポイント１、走行距離が３．５、走行時間が１０５、配達分担は、Ｅ地域が２で合計２、時間が２０、担当区間が１となる。輸送分担は、Ｂ地域が３、Ｅ地域が２で合計が５、空席数が１、受渡回数が１、受渡個口が３、受渡時間が３、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１２８となる。

そして、第２案では、図１３に示すように、車両の合計が５台必要で、走行距離の合計が１２、走行時間の合計が３６０、配達分担のＡの合計が４、Ｂの合計が３、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、配達分担の全合計が１７、時間の全合計が１７０、担当区間の合計が５となり、配達効率が１．４２となる。また、輸送分担のＡの合計が８、Ｂの合計が６、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、輸送分担の全合計が２４となる。また、輸送分担の空席数の合計が６、受渡回数の合計が２、受渡個口の合計が７、受渡時間の合計が７、引継回数の合計が２、引継個口の合計が７、引継時間の合計が７で成立し、最終配達完了時間は最大が１７９となる。

また、第３案の１号車は、計画ルートがＣ→Ａ、通過受渡ポイントが受渡ポイント１、２、走行距離が３．５、走行時間が１０５、配達分担は、Ａ地域が４で合計４、時間が４０、担当区間が１となる。輸送分担は、Ａ地域の４で合計が４、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が１、引継個口が４、引継時間が４で成立する。運行開始ポイントは受渡ポイント１、運行開始時間は３４、最終配達完了時間は１７９となる。

第３案の２号車は、計画ルートがＢ、通過受渡ポイントが受渡ポイント２、走行距離が１．５、走行時間が４５、配達分担は、Ｂ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ｂ地域の３で合計が３、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が１、引継個口が３、引継時間が３で成立する。運行開始ポイントは受渡ポイント２、運行開始時間は１０８、最終配達完了時間は１８３となる。

第３案の３号車は、計画ルートがＤ→Ｃ、通過受渡ポイントが受渡ポイント１、２、走行距離が２．５、走行時間が７５、配達分担は、Ｃ地域が３で合計３、時間が３０、担当区間が１となる。輸送分担は、Ｂ地域の３とＣ地域の３で合計が６、空席数が１、受渡回数が１、受渡個口が３、受渡時間が３、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１０８となる。

第３案の４号車は、計画ルートがＤ、通過受渡ポイントが受渡ポイント１、走行距離が１、走行時間が３０、配達分担は、Ｄ地域が５で合計５、時間が５０、担当区間が１となる。輸送分担は、Ｄ地域の５で合計が５、空席数が１、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は８０となる。

第３案の５号車は、計画ルートがＤ→Ｅ、通過受渡ポイントが受渡ポイント１、走行距離が３．５、走行時間が１０５、配達分担は、Ｅ地域が２で合計２、時間が２０、担当区間が１となる。輸送分担は、Ａ地域の４とＥ地域の２で合計が６、空席数が１、受渡回数が１、受渡個口が４、受渡時間が４、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１２９となる。

そして、第３案では、図１３に示すように、車両の合計が５台必要で、走行距離の合計が１２、走行時間の合計が３６０、配達分担のＡの合計が４、Ｂの合計が３、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、配達分担の全合計が１７、時間の全合計が１７０、担当区間の合計が５となり、配達効率が１．４２となる。また、輸送分担のＡの合計が８、Ｂの合計が６、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、輸送分担の全合計が２４となる。また、輸送分担の空席数の合計が７、受渡回数の合計が２、受渡個口の合計が７、受渡時間の合計が７、引継回数の合計が２、引継個口の合計が７、引継時間の合計が７で成立し、最終配達完了時間は最大が１８３となる。

また、第４案の１号車は、計画ルートがＤ→Ｅ、通過受渡ポイントが受渡ポイント１、走行距離が３．５、走行時間が１０５、配達分担は、Ｄ地域の５とＥ地域の２で合計７、時間が７０、担当区間が２となる。輸送分担は、Ｄ地域の５とＥ地域の２で合計が７、空席数が０、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１７５となる。

第４案の２号車は、計画ルートがＤ→Ｃ→Ａ、通過受渡ポイントが受渡ポイント１、２、走行距離が４．５、走行時間が１３５、配達分担は、Ａ地域の４で合計４、時間が４０、担当区間が１となる。輸送分担は、Ａ地域の４で合計が４、空席数が２、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１７５となる。

第４案の３号車は、計画ルートがＤ→Ｃ→Ｂ、通過受渡ポイントが受渡ポイント１、２、走行距離が４、走行時間が１２０、配達分担は、Ｂ地域の３とＣ地域の３で合計６、時間が６０、担当区間が２となる。輸送分担は、Ｂ地域の３とＣ地域の３で合計が６、空席数が１、受渡回数が０、受渡個口が０、受渡時間が０、引継回数が０、引継個口が０、引継時間が０で成立する。運行開始ポイントはＤ、運行開始時間は０、最終配達完了時間は１８０となる。

そして、第４案では、図１３に示すように、車両の合計が３台必要で、走行距離の合計が１２、走行時間の合計が３６０、配達分担のＡの合計が４、Ｂの合計が３、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、配達分担の全合計が１７、時間の全合計が１７０、担当区間の合計が５となり、配達効率が１．４２となる。また、輸送分担のＡの合計が４、Ｂの合計が３、Ｃの合計が３、Ｄの合計が５、Ｅの合計が２となり、輸送分担の全合計が１７となる。また、輸送分担の空席数の合計が１１、受渡回数の合計が０、受渡個口の合計が０、受渡時間の合計が０、引継回数の合計が０、引継個口の合計が０、引継時間の合計が０で成立し、最終配達完了時間は最大が１８０となる。

このように計算された配送候補を決定するための情報から、配車計画決定部３６が、計画基準案及び第１〜第４案の複数の配車候補から、予め定めた条件に基づいて配車候補を決定する。これにより、予め定めた条件に適した配車計画を作成することが可能となる。例えば、配車計画決定部３６は、予め定めた条件として、輸送効率としての配達効率及び輸送完了時間としての配達完了時間の少なくとも一方に基づいて配車計画とする配車候補を決定する。例えば、配達効率が最も高い配車候補を決定し、配達効率が同一の配送候補が複数ある場合は、配達完了時間が最短の配送候補を決定する。或いは、配達完了時間が最短の配車候補を決定し、同一の配達完了時間が複数ある場合は、配達効率が最も高い配送候補を決定して配車計画を作成してもよい。なお、輸送効率及び輸送完了時間以外の条件を予め定めた条件として適用してもよい。例えば、輸送する時間帯などの条件を更に考慮して配送候補を決定して配車計画を作成してもよい。

計画基準案及び第１〜第４案のように複数の配車候補から配車計画を選択する方法の一例としては、計画基準案に対して配達効率が上がっている案を選択する。計画基準案よりも配達効率が上がっている案がなければ、計画基準案を選択する。

また、人を運ぶ人流の乗車予約がある場合は、予約条件に該当する案を選択し、予約条件に該当する案が複数ある場合は、完了時間が最短となる案を選択する。

また、乗車予約の予約条件に該当する案がなければ第４案を選択して、空き車両を人流用に配車する。

次に、上述の配車計画サーバ１２が提供する配車サービス等のサービスに対して、決済代行サーバ１１が提供する決済代行サービスを利用する際の情報処理システム１０の各部で行われる具体的な処理について説明する。

図１４は、本実施形態に係る情報処理システム１０の決済代行サーバ１１が提供するサービスを利用するために、クライアント端末１８で行われる利用者登録時の処理の流れの一例を示すフローチャートである。図１４の処理は、例えば、クライアント端末１８の利用者や、利用者の代行者がクライアント端末１８を操作して、決済代行サーバ１１が提供するサービスの利用登録を指示する操作が行われた場合に開始する。

ステップ２００では、ＣＰＵ１８Ａが、予め定めた登録画面を表示部１８Ｆに表示してステップ２０２へ移行する。例えば、電子メールのメールアドレス、住所、氏名、年齢、性別、顔写真等の利用者登録情報を入力する登録画面を表示する。

ステップ２０２では、ＣＰＵ１８Ａが、利用者登録情報が操作部１８Ｅを介して入力されたか否かを判定する。該判定は、利用者または利用者の代行者が、決済代行サーバ１１が提供するサービスにログインするための登録情報が入力されたか否かを判定する。例えば、電子メールのメールアドレス、住所、氏名、年齢、性別、顔写真等の利用者登録情報が入力されたか否かを判定し、該判定が肯定されるまで待機してステップ２０４へ移行する。

ステップ２０４では、ＣＰＵ１８Ａが、利用者登録情報を決済代行サーバ１１に送信してステップ２０６へ移行する。

ステップ２０６では、ＣＰＵ１８Ａが、決済代行サーバ１１から登録完了通知を受信したか否かを判定する。該判定が肯定されるまで待機してステップ２０８へ移行する。

ステップ２０８では、ＣＰＵ１８Ａが、登録完了を表示部１８Ｆに表示してステップ２１０へ移行する。なお、登録完了を表示する際には、利用者を認証するための二次元バーコードやバーコード等の認証用コードも表示して、外出時に印刷して持っていくように通知してもよい。これにより、認証用コードが印刷された印刷物を持ち歩くことで、他の人のクライアント端末を用いて決済代行サーバ１１が提供する決済代行サービスを利用することが可能となる。本実施形態では、認証用コードの一例としての二次元バーコードが印刷された印刷物（以下、単に二次元バーコードと称する場合がある。）または利用者の顔を撮影することにより利用者を特定することが可能となる。

図１５は、本実施形態に係る情報処理システム１０において、クライアント端末１８により利用登録時の処理が行われた場合に、決済代行サーバ１１で行われる利用者登録時の処理の流れの一例を示すフローチャートである。図１５の処理は、例えば、クライアント端末１８から利用登録情報が送信された場合に開始する。

ステップ２５０では、ＣＰＵ１１Ａが、クライアント端末１８から送信された利用者登録情報を受信してステップ２５２へ移行する。すなわち、上述のステップ２０４で送信された利用者登録情報を受信することにより登録部４０が利用者登録情報を受け付ける。

ステップ２５２では、ＣＰＵ１１Ａが、決済用利用者登録を行ってステップ２５４へ移行する。すなわち、決済機能部４２が、クライアント端末１８から受信した利用者登録情報を、決済用利用者情報として利用者ＤＢ４４に格納する。

ステップ２５４では、ＣＰＵ１１Ａが、認証用情報登録を行ってステップ２５６へ移行する。すなわち、決済機能部４２が認証機能部４６に対して認証用情報の登録を依頼することにより、認証機能部４６が認証情報を認証情報ＤＢ４８に格納する。

ステップ２５６では、ＣＰＵ１１Ａが、利用者ＩＤ及び利用者ＩＤに対応する二次元バーコードを生成してステップ２５８へ移行する。

ステップ２５８では、ＣＰＵ１１Ａが、登録完了通知をクライアント端末１８に対して送信して一連の処理を終了する。これにより、上述のステップ２０６の判定が肯定される。また、ステップ２５６において、登録完了通知を送信する際に、二次元バーコードを含めて送信してもよい。これにより、クライアント端末１８において登録完了を表示する際に、二次元バーコードの印刷を促す情報を表示して、外出時に印刷して印刷物を持っていくよう促すことが可能となる。なお、この場合、ステップ２５６は前処理部に対応する。

上述のようにクライアント端末１８及び決済代行サーバ１１の処理が行われることにより、図１６に示すシーケンス図のように各部が動作する。図１６は、上述の本実施形態に係る情報処理システム１０の決済代行サーバ１１が提供するサービスを利用する際の利用者登録時の処理の流れを示すシーケンス図である。

すなわち、利用者登録を行う際には、クライアント端末１８（図１６の利用者端末）を操作して上述のステップ２００で表示された登録画面に対して利用者登録情報を入力して決済代行サーバ１１へ送信することにより利用登録を行う。

決済代行サーバ１１では、登録部４０が利用者登録情報を受け付けて決済機能部４２に対して決済用登録を行う。

決済機能部４２では、決済機能部４２が、クライアント端末１８から受信した利用者登録情報を、決済用利用者情報として利用者ＤＢ４４に格納することにより決済用登録を行う。

また、決済機能部４２は認証機能部４６に対して認証用情報登録を行う。認証機能部４６では、認証情報を認証情報ＤＢ４８に格納することによって認証用情報登録が行われる。

決済機能部４２は、認証機能部４６から認証登録完了を待って、利用者完了通知を登録部４０に利用者登録完了通知を行う。これにより、登録部４０が認証用の二次元バーコードを生成して利用者登録完了通知を利用者端末に返信することにより、利用者の登録が完了する。これにより、本実施形態では、利用者の顔または認証用の二次元バーコードを撮影することで利用者情報を入力して認証できるので、文字入力よりも認証の入力操作を簡単に行うことが可能となる。

このように、決済代行サーバ１１への利用者登録が行われると、本実施形態では、配車計画サーバ１２に対して配車予約を行って決済までの処理を行うことが可能となる。また、決済を行う際に、高齢者などの利用者が携帯端末１８ｂを所持していないような場合は、他の利用者を認識した状態の携帯端末１８ｂ等のクライアント端末１８を利用して配車予約及び決済までの処理を行うことができる。ここで、一例として配車予約から決済を行う場合に情報処理システム１０の各部で行われる具体的な処理について説明する。

まず、配車予約から決済を行う場合のクライアント端末１８で行われる処理について説明する。図１７は、本実施形態に係る情報処理システム１０において、配車予約から決済を行う場合のクライアント端末１８で行われる処理の流れの一例を示すフローチャートである。なお、図１７の処理は、例えば、利用者または代行者の携帯端末１８ｂ等のクライアント端末１８に予めインストールされたアプリケーションを操作して、配車計画サーバ１２が提供するサービスの利用が指示された場合に開始する。

ステップ３００では、ＣＰＵ１８Ａが、予め定めた配車予約画面を表示してステップ３０２へ移行する。例えば、本実施形態では、利用者情報として利用者の顔または二次元バーコードを撮影する撮影枠や、配車予約するために必要な出発地点、目的地、日時等の配車依頼情報としての予約情報を入力するための欄を含む配車予約画面を表示する。なお、予約情報に含む出発地点については、当該クライアント端末１８の現在の位置情報を適用してもよい。

ステップ３０２では、ＣＰＵ１８Ａが、利用者情報及び予約情報が入力されたか否かを判定する。該判定は、例えば、クライアント端末１８のカメラ１８Ｉによって利用者情報としての利用者の顔または二次元バーコードが撮影されて予約情報が入力されたか否かを判定する。該判定が肯定されるまで待機してステップ３０４へ移行する。

ステップ３０４では、ＣＰＵ１８Ａが、配車計画サーバ１２に対して配車予約情報を送信してステップ３０６へ移行する。すなわち、利用者情報及び予約情報を配車予約情報として配車計画サーバ１２に送信することで配車予約を行う。

ステップ３０６では、ＣＰＵ１８Ａが、配車計画サーバ１２から本人確認情報を受信したか否かを判定する。該判定は、本実施形態では、利用者がクライアント端末１８とは異なる利用者である場合があるので、本人を確認するための本人確認情報（例えば、氏名、年齢、顔写真等）を受信したか否かを判定する。該判定が肯定されるまで待機してステップ３０８へ移行する。

ステップ３０８では、ＣＰＵ１８Ａが、表示部１８Ｆに本人確認情報を表示してステップ３１０へ移行する。これにより、表示された本人確認情報により、利用者を確認することができ、クライアント端末１８の利用者とは異なる利用者の場合に利用者を確実に確認できる。

ステップ３１０では、ＣＰＵ１８Ａが、本人確認入力が行われたか否かを判定する。該判定は、例えば、操作部１８Ｅを操作して本人の確認結果を入力する操作が行われたか否かを判定する。該判定が肯定されるまで待機してステップ３１２へ移行する。

ステップ３１２では、ＣＰＵ１８Ａが、本人確認結果を配車計画サーバ１２に送信してステップ３１４へ移行する。

ステップ３１４では、ＣＰＵ１８Ａが、予約完了であるか否かを判定する。該判定は、本実施形態では、配車計画サーバ１２から決済＆予約完了通知を受信したか否かを判定する。決済＆予約完了通知ではなく、サービス利用不可が通知されて判定が否定された場合にはステップ３１６へ移行し、判定が肯定された場合にはステップ３１８へ移行する。

ステップ３１６では、ＣＰＵ１８Ａが、利用者情報の履歴（例えば、認証情報及びログ情報等の履歴情報）を削除して利用者情報の再入力を報知してステップ３００に戻って上述の処理を繰り返す。

ステップ３１８では、ＣＰＵ１８Ａが、決済＆予約完了通知を表示部１８Ｆに表示してステップ３２０へ移行する。

ステップ３２０では、ＣＰＵ１８Ａが、クライアント端末１８の利用者と異なる利用者であるか否かを判定する。該判定が肯定された場合にはステップ３２２へ移行し、否定された場合は一連の処理を終了する。

ステップ３２２では、ＣＰＵ１８Ａが、利用者情報の履歴を削除して一連の処理を終了する。これにより、クライアント端末１８の利用者とは異なる利用者の情報がクライアント端末１８から削除され、個人情報が保護される。

続いて、配車予約から決済を行う場合の配車計画サーバ１２で行われる処理について説明する。図１８は、本実施形態に係る情報処理システム１０において、配車予約から決済を行う場合の配車計画サーバ１２で行われる処理の流れの一例を示すフローチャートである。なお、図１８の処理は、例えば、上述のステップ３０４でクライアント端末１８から配車予約情報が送信された場合に開始する。

ステップ３５０では、ＣＰＵ１２Ａが、配車予約情報を受信してステップ３５２へ移行する。すなわち、配車受付部３０が、上述のステップ３０４でクライアント端末１８から送信された配車予約情報を受信することによって、配車予約情報を配送依頼情報として受け付ける。

ステップ３５２では、ＣＰＵ１２Ａが、決済代行サーバ１１に対して、認証・決済処理依頼を行ってステップ３５４へ移行する。すなわち、利用者情報を決済代行サーバ１１に送信することにより、認証・決済処理を依頼する。

ステップ３５４では、ＣＰＵ１２Ａが、決済代行サーバ１１から本人確認結果を受信したか否かを判定する。該判定は、決済代行サーバ１１から、本人確認結果として本人を確認するための本人確認情報（例えば、氏名、年齢、顔写真等）の通知を受けたか否かを判定する。登録された利用者として認証されなかった場合は否定されてステップ３５６へ移行し、肯定された場合にはステップ３５８へ移行する。

ステップ３５６では、ＣＰＵ１２Ａが、クライアント端末１８に対してサービス利用不可を通知して一連の処理を終了する。

ステップ３５８では、ＣＰＵ１２Ａが、本人確認情報をクライアント端末１８に送信してステップ３６０へ移行する。これにより、上述のステップ３０８において、クライアント端末１８では、本人確認情報が表示部１８Ｆに表示される。

ステップ３６０では、ＣＰＵ１２Ａが、クライアント端末１８から本人確認情報の確認結果を受信したか否かを判定し、該判定が肯定されるまで待機してステップ３６２へ移行する。

ステップ３６２では、ＣＰＵ１２Ａが、本人確認結果が本人であるか否かを判定する。該判定が否定された場合には上述のステップ３５６へ移行し、肯定された場合にはステップ３６４へ移行する。

ステップ３６４では、ＣＰＵ１２Ａが、配車の予約を行う予約処理を行ってステップ３６６へ移行する。なお、予約処理は、配車受付部３０が、配車予約情報を配車依頼情報として受け付けて、上述配車計画を行うと共に、決済代行サーバ１１に対して本人確認結果を通知して認証された利用者に対して決済するよう要求する。

ステップ３６６では、ＣＰＵ１２Ａが、決済＆完了通知を決済代行サーバ１１から受信したか否かを判定する。該判定が肯定されるまで待機してステップ３６８へ移行する。

ステップ３６８では、ＣＰＵ１２Ａが、決済＆予約完了通知をクライアント端末に送信して一連の処理を終了する。

続いて、配車予約から決済を行う場合の決済代行サーバ１１で行われる処理について説明する。図１９は、本実施形態に係る情報処理システム１０において、配車予約から決済を行う場合の決済代行サーバ１１で行われる処理の流れの一例を示すフローチャートである。なお、図１９の処理は、例えば、上述のステップ３５２で配車計画サーバ１２から認証・決済処理の依頼が行われた場合に開始する。

ステップ４００では、ＣＰＵ１１Ａが、配車計画サーバ１２から利用者情報を受信してステップ４０２へ移行する。すなわち、上述のステップ３５２で配車計画サーバ１２から、認証・決済処理の依頼で送信される利用者情報を受信する。

ステップ４０２では、ＣＰＵ１１Ａが、利用者情報に基づいて、利用者を確認してステップ４０４へ移行する。すなわち、認証・決済処理部５０が、認証機能部４６に対して利用者が登録されているか否かを問い合わせ、認証機能部４６が利用者の登録の有無を確認する。具体的には、利用者情報としての顔写真または二次元バーコードに対応する利用者が登録されているかを検索する。

ステップ４０４では、ＣＰＵ１１Ａが、利用者が認証されたか否かを判定する。該判定は、認証・決済処理部５０が、認証機能部４６から利用者の検索結果を表す本人確認結果の通知を受けて、登録された利用者であるか否かを判定する。該判定が否定された場合にはステップ４０６へ移行し、肯定された場合にはステップ４０８へ移行する。

ステップ４０６では、ＣＰＵ１１Ａが、配車計画サーバ１２に対してサービス利用不可を通知して一連の処理を終了する。

ステップ４０８では、ＣＰＵ１１Ａが、本人確認情報を配車計画サーバ１２に送信してステップ４１０へ移行する。

ステップ４１０では、ＣＰＵ１１Ａが、本人確認結果を受信したか否かを判定する。該判定は、クライアント端末１８から本人確認結果を受信したか否かを判定し、該判定が肯定されるまで待機してステップ４１２へ移行する。なお、本人確認結果は、配車計画サーバ１２を介して受信してもよい。また、本実施形態では、クライアント端末１８において、本人であるか否かを表す情報を本人確認結果として受信するが、個人属性（例えば、生年月日、電話番号等の予め登録した情報）を入力させて本人確認結果として受信して二段階認証を行うようにしてもよい。

ステップ４１２では、ＣＰＵ１１Ａが、本人確認結果が本人であるか否かを判定する。該判定が否定された場合には上述のステップ４０６へ移行し、肯定された場合にはステップ４１４へ移行する。

ステップ４１４では、ＣＰＵ１１Ａが、認証した利用者の決済として決済処理を行ってステップ４１６へ移行する。すなわち、決済機能部４２が、認証された利用者の決済として配車に対する清算を行うように処理する。これにより、決済サービスを利用可能な携帯端末１８ｂ等のクライアント端末１８を持っていない人でも決済代行サーバ１１が提供する決済サービスを利用することが可能となる。なお、決済機能部４２が決済処理行う際には、決済の履歴として利用者が利用したクライアント端末１８の位置情報を、配車計画サーバ１２を介して取得してもよい。これにより、不正の追跡情報として利用することが可能となる。また、ステップ４１４では、決済処理を行う際に、認証した利用者がクライアント端末１８を所有する利用者と異なる場合には、クライアント端末１８を所有する利用者に対して、予め定めたポイント等を付与してクライアント端末１８を貸し出して決済を代行した対価として還元してもよい。また、還元したポイント等は、クライアント端末１８に通知してもよい。

ステップ４１６では、ＣＰＵ１１Ａが、決済完了通知を配車計画サーバ１２に通知して一連の処理を終了する

上述のようにクライアント端末１８、配車計画サーバ１２、及び決済代行サーバ１１の処理が行われることにより、図２０に示すシーケンス図のように各部が動作する。図２０は、本実施形態に係る情報処理システム１０において、配車予約から決済を行う場合の処理の流れを示すシーケンス図である。図２０では、利用者がクライアント端末１８を所持していない場合に代行者の利用者端末を利用するケースを示す。

クライアント端末１８としての利用者端末（代行者）から予約情報と、利用者情報（配車計画サーバ１２に対して顔写真または二次元バーコードを撮影した撮影情報）を送信して配車予約を行う。

配車計画サーバ１２では、利用者端末から受信した利用者情報を決済代行サーバ１１の認証・決済処理部５０に送信することにより、認証・決済処理依頼を行う。

認証・決済処理部５０では、認証・決済処理依頼を受け付けて、認証機能部４６に対して利用者確認を行うことにより、認証機能部４６によって利用者が登録されているかの確認を行うことにより認証が行われ、認証結果通知が認証・決済処理部５０に返信される。

認証・決済処理部５０は、本人を確認するための本人確認情報を配車計画サーバ１２を介して利用者端末に送信して本人の確認を求める。

認証・決済処理部５０は、利用者端末から本人確認結果から本人が確認されたところで、配車計画サーバ１２を介して利用者端末に決済＆予約完了通知を行って配車予約から決済までの処理を終了する。このように処理を行うことにより、決済サービスを利用可能な携帯端末１８ｂ等を持っていない人でも決済サービスを利用することが可能となる。

続いて、このように配車予約した車両への乗降時に情報処理システム１０の各部で行われる処理について説明する。

まず、配車予約した車両に乗降する際に車両側端末２０で行われる処理について説明する。図２１は、本実施形態に係る情報処理システム１０において、配車予約した車両への乗降時に車両側端末２０で行われる処理の流れの一例を示すフローチャートである。なお、図２１の処理は、例えば、タクシー２６やバス２８の運転者が車両側端末２０を操作して利用者確認の指示が行われた場合に開始する。

ステップ４５０では、ＣＰＵ２０Ａが、予め定めた利用者確認用画面を表示部２０Ｆに表示してステップ４５２へ移行する。

ステップ４５２では、ＣＰＵ２０Ａが、利用者情報が入力されたか否かを判定する。該判定は、例えば、車両側端末２０を操作してカメラ２０Ｉによって利用者の顔または二次元バーコードが撮影されて、利用者情報として顔写真または二次元バーコードの撮影画像が取得されたか否かを判定する。該判定が肯定されるまで待機してステップ４５４へ移行する。

ステップ４５４では、ＣＰＵ２０Ａが、決済代行サーバ１１に対して利用者の認証依頼を行ってステップ４５６へ移行する。すなわち、利用者情報を決済代行サーバ１１に送信して利用者情報に対応する利用者の認証と予約の確認を依頼する。

ステップ４５６では、ＣＰＵ２０Ａが、決済代行サーバ１１から認証完了通知を受信したか否かを判定する。該判定は、決済代行サーバ１１から登録された利用者ではなくエラー通知を受信した場合には否定されてステップ４５８へ移行し、登録された利用者であると認証されて認証完了通知を受信した場合には肯定されてステップ４６０へ移行する。

ステップ４５８では、ＣＰＵ２０Ａが、エラーメッセージを表示部２０Ｆに表示して一連の処理を終了する。

ステップ４６０では、ＣＰＵ２０Ａが、認証及び予約の確認されたことを表示部２０Ｆに表示して一連の処理を終了する。これにより、利用者の認証と予約が確認されたことを運転者に通知することができる。

次に、配車予約した車両に乗降する際に決済代行サーバ１１で行われる処理について説明する。図２２は、本実施形態に係る情報処理システム１０において、配車予約した車両への乗降時に決済代行サーバ１１で行われる処理の流れの一例を示すフローチャートである。なお、図２２の処理は、例えば、車両側端末２０によって利用者の認証依頼が行われた場合に開始する。

ステップ５００では、ＣＰＵ１１Ａが、車両側端末２０から利用者情報を受信してステップ５０２へ移行する。すなわち、認証・決済処理部５０が、利用者情報を含む認証依頼を受け付ける。

ステップ５０２では、ＣＰＵ１１Ａが、利用者情報に基づいて、利用者を確認してステップ５０４へ移行する。すなわち、認証機能部４６が、利用者情報に対応する利用者が認証情報ＤＢ４８に登録されているかを検索することにより、利用者の認証を行う。

ステップ５０４では、ＣＰＵ１１Ａが、認証されたか否かを判定する。該判定は、認証・決済処理部５０が、認証機能部４６の認証結果から認証されたか否か、すなわち、利用者が登録された利用者であるか否かを判定する。該判定が否定された場合にはステップ５０６へ移行し、肯定された場合にはステップ５０８へ移行する。

ステップ５０６では、ＣＰＵ１１Ａが、エラー通知を車両側端末２０に返信して一連の処理を終了する。これにより、車両側端末２０では、上述のステップ４５６の判定が否定される。

ステップ５０８では、ＣＰＵ１１Ａが、配車計画サーバ１２に対して予約確認依頼を行ってステップ５１０へ移行する。予約確認依頼を行う際には、利用者を確認可能な利用者ＩＤ等の利用者情報を配車計画サーバ１２に通知する。

ステップ５１０では、ＣＰＵ１１Ａが、予約確認結果を配車計画サーバ１２から受信したか否かを判定する。該判定が肯定されるまで待機してステップ５１２へ移行する。

ステップ５１２では、ＣＰＵ１１Ａが、予約確認結果から利用者の予約があるか否かを判定する。該判定が否定された場合には上述のステップ５０６へ移行し、肯定された場合にはステップ５１４へ移行する。

ステップ５１４では、ＣＰＵ１１Ａが、認証完了通知を車両側端末２０に返信して一連の処理を終了する。これにより、車両側端末２０では、上述のステップ４５６の判定が肯定される。

次に、配車予約した車両に乗降する際に配車計画サーバ１２で行われる処理について説明する。図２３は、本実施形態に係る情報処理システム１０において、配車予約した車両に乗降する際に配車計画サーバ１２で行われる処理の流れの一例を示すフローチャートである。なお、図２３の処理は、例えば、決済代行サーバ１１から予約確認依頼された場合に開始する。

ステップ５５０では、ＣＰＵ１２Ａが、決済代行サーバ１１から利用者情報を受信してステップ５５２へ移行する。すなわち、上述のステップ５０８の予約確認依頼により送信される利用者情報を受信する。

ステップ５５２では、ＣＰＵ１２Ａが、決済代行サーバ１１で認証された利用者の予約を確認してステップ５５４へ移行する。例えば、予約利用者ＩＤと決済代行サーバ１１で認証された利用者ＩＤの合致を確認する。

ステップ５５４では、ＣＰＵ１２Ａが、予約確認結果を決済代行サーバ１１に通知して一連の処理を終了する。

上述のように車両側端末２０、決済代行サーバ１１、及び配車計画サーバ１２の処理が行われることにより、図２４に示すシーケンス図のように各部が動作する。図２４は、本実施形態に係る情報処理システム１０において、配車予約した車両に乗降する際の処理の流れを示すシーケンス図である。

運転者が車両側端末２０を操作して利用者の乗客の顔または二次元バーコードをカメラ２０Ｉによって撮影することにより、顔写真または二次元バーコードを利用者情報として取得する。そして、決済代行サーバ１１の認証・決済処理部５０に送信することにより、利用者の認証依頼を行う。

認証・決済処理部５０では、認証機能部４６に対して利用者情報を送信して利用者の確認を行う。

認証機能部４６では、利用者情報に対応する利用者が認証情報ＤＢ４８に登録されているか否かを検索することにより認証を行って、認証・決済処理部５０に確認結果通知を行う。

認証・決済処理部５０では、認証が確認された利用者の予約照合を配車計画サーバ１２が行って、予約の照合結果通知を受信する。

そして、認証・決済処理部５０は、予約が確認されたところで車両側端末２０に認証完了結果を通知する。これにより、予約利用者の本人確認が可能となる。

なお、配車計画サーバ１２が配車予約に対して計画した配車計画に乗り継ぎがある場合には、二次元バーコードを利用して各車両で利用者を認証することで本人確認を行いながら乗り継ぎが可能となる。

また、上記実施形態では、決済代行サーバ１１、配車計画サーバ１２、及び運行管理サーバ１４を別々のサーバとして説明したが、これに限るものではない。例えば、３つのサーバの機能を１つのサーバに設けた形態としてもよいし、これらのサーバの機能を必要に応じて複数のサーバに分配して複数のサーバで構成する形態としてもよい。例えば、決済代行サーバ１１の認証機能部４６は認証専門のサーバの機能としてもよい。

また、上記実施形態では、配車計画の対象の車両として、タクシー２６やバス２８を一例として挙げたが、これに限るものではない。例えば、予め登録した運送会社の車両や予め登録した一般の車両などでもよい。

（第２実施形態）
上記の実施形態では、配車予約した車両を利用する場合に利用者以外のクライアント端末１８を利用した決済方法を説明したが、第２実施形態では、利用者以外のクライアント端末１８を利用して買い物を行う場合に適用したものである。

図２５は、第２実施形態に係る情報処理システム１７の概略構成を示す図である。なお、第１実施形態と同一構成については同一符号を付して詳細な説明を省略する場合がある。

本実施形態に係る情報処理システム１７は、図２５に示すように、決済代行サーバ１１、サービス提供装置としての買い物支援サーバ１３、商品管理サーバ１５、配送管理サーバ１６、クライアント端末１８、及び買い物代行オペレータ端末２１を含む。そして、各々が通信ネットワーク２２に接続されている。

決済代行サーバ１１は、上記実施形態と同様に、予め登録された利用者が決済可能なクライアント端末１８を所持していない場合であっても、代行者のクライアント端末１８を用いて、代行して決済を行うサービスを提供する。

買い物支援サーバ１３は、予め登録された店での利用者の買い物を支援するサービスを提供する。本実施形態では、一例として、リアルタイムのストリーミング配信による買い物代行サービスや、利用者の過去の購入履歴や特売品等を含めて生成した買い物リストを提供するサービス等を買い物支援として行う。

商品管理サーバ１５は、商品情報や、利用者の購入履歴などの情報を蓄積するデータベースの機能を有し、買い物支援を行う際に、蓄積された情報を提供する。また、商品管理サーバ１５は、ＰＯＳ（Point of sale system）システム等の周知の技術を利用して、商品を管理する機能を有する。

配送管理サーバ１６は、買い物支援サーバ１３が提供するサービスを利用して購入した商品の配送手配等を行う。

クライアント端末１８は、上記実施形態と同様に、各種サービスを提供するクラウドサーバ等のサーバにアクセスして、各種サービスを受けるためのインタフェースとして機能する。本実施形態では、買い物支援サーバ１３にアクセスして、買い物支援サーバ１３が提供するサービスを受けるためのインタフェースとして機能する。クライアント端末１８は、例えば、上記実施形態と同様に、パーソナルコンピュータ１８ａを適用してもよいし、スマートフォン等の携帯端末１８ｂを適用してもよいし、インターネットテレビ等を適用してもよい。携帯端末１８ｂを適用する場合には、無線中継局２４等を介して通信ネットワーク２２に接続される。

買い物代行オペレータ端末２１は、買い物支援サーバ１３が提供する買い物代行を行う際のストリーミング映像を撮影する機能、及び利用者と通話する機能を有する。買い物代行オペレータ端末２１は、無線中継局２４を介して通信ネットワーク２２に接続される。また、買い物代行オペレータ端末２１は、例えば、図２５に示すように、スマートフォン等の携帯端末２１ａを適用してもよいし、ヘッドセットとカメラを含むウェアラブル端末２１ｂを適用してもよい。

通信ネットワーク２２は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、イントラネット等の各種のネットワークが適用され、接続された機器間の各種データの送受信を行う。

続いて、本実施形態に係る情報処理システム１７における買い物支援サーバ１３、商品管理サーバ１５、配送管理サーバ１６、及び買い物代行オペレータ端末２１の電気系の要部構成について説明する。

図２６は、買い物支援サーバ１３、商品管理サーバ１５、配送管理サーバ１６、及び買い物代行オペレータ端末２１の電気系の要部構成を示すブロック図である。なお、買い物支援サーバ１３、商品管理サーバ１５、配送管理サーバ１６、及び買い物代行オペレータ端末２１は基本的には一般的なコンピュータの構成とされているので、ここでは買い物支援サーバ１３を代表して説明する。

買い物支援サーバ１３は、決済代行サーバ１１と同様に、図２６に示すように、ＣＰＵ１３Ａ、ＲＯＭ１３Ｂ、ＲＡＭ１３Ｃ、ストレージ１３Ｄ、操作部１３Ｅ、表示部１３Ｆ、及び通信Ｉ／Ｆ部１３Ｇを備えている。

ＣＰＵ１３Ａは、中央演算処理ユニットであり、各種プログラムを実行することにより、装置の全体の動作を司る。ＲＯＭ１３Ｂは、各種制御プログラムや各種パラメータ等が予め記憶される。ＲＡＭ１３Ｃは、ＣＰＵ１３Ａによる各種プログラムの実行時のワークエリア等として用いられる。ストレージ１３Ｄは、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）、フラッシュメモリ等の各種記憶部により構成され、各種データやアプリケーション・プログラム等が記憶される。操作部１３Ｅは、キーボードやマウス、タッチパネル等からなり、各種の情報を入力するために用いられる。表示部１３Ｆは、各種の情報を表示するために用いられる。通信Ｉ／Ｆ部１３Ｇは、ＬＡＮや、ＷＡＮ、インターネット等の各種ネットワーク等の通信ネットワーク２２に接続可能とされ、当該通信ネットワーク２２に接続された他の装置と各種データの送受信を行う。以上の買い物支援サーバ１３の各部はシステムバス１３Ｈにより電気的に相互に接続されている。

以上の構成により、買い物支援サーバ１３は、ＣＰＵ１３Ａにより、ＲＯＭ１３Ｂ、ＲＡＭ１３Ｃ、及びストレージ１３Ｄに対するアクセス、操作部１３Ｅを介した各種データの取得、表示部１３Ｆに対する各種情報の表示を各々実行する。また、買い物支援サーバ１３は、ＣＰＵ１３Ａにより、通信Ｉ／Ｆ部１３Ｇを介した通信データの送受信の制御を実行する。

なお、上記実施形態のクライアント端末１８と同様に、買い物代行オペレータ端末２１については、図２６の点線で示すように、カメラ２１Ｉ、音声入出力部２１Ｊ、及び位置検出部２１Ｋ等を更に含む。

カメラ２１Ｉは、静止画像や動画像を撮影することによって、動画像または静止画像を表す画像データを生成する。本実施形態の買い物代行オペレータ端末２１では、カメラ２１Ｉによって撮影した映像をクライアント端末１８にリアルタイムでストリーミング配信する。

音声入出力部２１Ｊは、スピーカやヘッドフォン等から音声を出力し、マイク等により集音することにより音声を入力し、入力した音声を表す音声情報を生成する。本実施形態では、音声入出力部２１Ｊにより、買い物代行オペレータと利用者の会話が可能とされている。

位置検出部２１Ｋは、買い物代行オペレータ端末２１の現在の位置情報を検出する。例えば、ＧＰＳ（Global Positioning System）衛星からの電波を受信し、３つ以上のＧＰＳ衛星からの距離に基づいて、空間上の一点の位置を測位することにより、位置を検出する。

続いて、上述のように構成された本実施形態に係る情報処理システム１７の買い物支援サーバ１３が提供するサービスについて具体例を挙げて説明する。

図２７は、クライアント端末１８に予めインストールされたサポートアプリケーションにより表示される画面の一例としての初期画面、買い物項目選択画面、及び店舗選択画面を示す図である。なお、以下、サポートアプリケーションは、サポートアプリと称する場合がある。また、以下では、クライアント端末１８がスマートフォン等の携帯端末１８ｂである場合の画面例を示し、以降の各画面例は、携帯端末１８ｂの操作部１８Ｅを操作することで、表示部１８Ｆに表示される画面のボタン等の操作が行われる。

クライアント端末１８でサポートアプリを起動すると、図２７に示す初期画面３１が表示される。初期画面３１は、図２７の例では、「おでかけ支援」、「買い物支援」、「今日の情報」等を選択する選択ボタンが表示される。

また、初期画面３１の「買い物支援」が選択されると、買い物項目選択画面３３が表示される。買い物項目選択画面３３は、図２７の例では、「食料品・飲料」、「日用品・雑貨」、「よく使うモノ」、「宅配荷物」等を選択する選択ボタンが表示される。また、買い物項目選択画面３３には、「戻る」ボタンが表示され、選択されると、初期画面３１に戻る。

また、買い物項目選択画面３３の「食料品・飲料」が選択されると、店舗選択画面３５が表示される。店舗選択画面３５は、図２７の例では、「＊＊ストア○○店」、「▽▽マート○×店」、「＊マーケット○△店」等を選択する選択項目が表示される。選択項目中には、図２７の例では、「今日のチラシ」へのリンクが表示され、「今日のチラシ」が選択されると、お勧め情報として店舗の広告情報が表示可能とされている。なお、表示される各店舗は予め登録された店舗である。また、買い物代行が可能な店舗を区別可能なマーク（図２７では「＊」）が表示される。また、店舗選択画面３５には、「戻る」ボタンが表示され、選択されると、買い物項目選択画面３３に戻る。或いは、初期画面３１に戻ってもよい。

次に、店舗選択画面３５で買い物代行が可能な店舗が選択された場合に表示される各種画面について説明する。図２８は、各店舗で買い物を行う際に表示される画面の一例としての買い物支援選択画面、ストリーミング画面、買い物リスト利用可否選択画面、買い物リスト画面を示す図である。

店舗選択画面３５で買い物代行が可能な店舗が選択されと、買い物支援選択画面３７が表示される。買い物支援選択画面３７は、「買い物代行」、「買い物リスト」を選択する選択ボタンが表示される。このように、本実施形態では、「買い物代行」による買い物方法と「買い物リスト」による買い物方法の２つの選択ボタンが優先的に表示されるので、必要以上の情報を表示することによる利用者の混乱を抑制できる。なお、本実施形態では、２つの選択ボタンを優先的に表示する例として、２つの選択ボタンのみを表示する例を示すが、これに限るものではなく、スクロールして他の選択ボタンを表示可能としてもよい。他の選択ボタンの一例としては、一般的なネットショッピングのように、予め定めた順序で商品項目を表示して購入対象を選択する通常購入ボタン等を表示してもよい。

ストリーミング画面３９は、買い物代行オペレータが買い物代行オペレータ端末２１により撮影した映像をリアルタイムでストリーミング配信して、買い物代行オペレータと通話しながら買い物を行う画面である。図２８の例では、ストリーミング画面３９には、ストリーミング映像と、買い物かごの合計金額、選択された商品の分類、商品名、値段、会計するための「レジに進む」ボタン等が表示される。ストリーミング画面では、例えば、通話により利用者がオペレータに指示することにより、擬似的に買い物を行う。対象の商品が決定したら、買い物代行オペレータが買い物代行オペレータ端末２１を操作して買い物対象に登録することにより、図２８のストリーミング画面３９の買い物かごに追加される。買い物かごへの追加は、操作部２０Ｅを操作して追加する形態としてもよいし、商品のバーコード等をカメラ２０Ｉ等によって読み込むことによって追加する形態としてもよい。

一方、買い物支援選択画面３７で「買い物リスト」が選択されると、買い物リスト利用可否選択画面４１が表示される。買い物リスト利用可否選択画面４１は、利用者の過去の購入履歴から生成した買い物リストとしての「いつもの」リストを使った買い物を行うかを選択する画面である。図２８に示すように、可否を確認するメッセージ（「いつもの」リストを使いますか？）と、「はい」、「いいえ」を選択するボタンが表示される。

買い物リスト利用可否選択画面４１で「はい」が選択されると、買い物リスト画面４３が表示される。図２８の例では、買い物リスト画面４３には、買い物リストの写真付き商品メニュー、買い物かごの合計金額、選択された商品の分類、商品名、値段、会計するための「レジに進む」ボタン等が表示される。

次に、ストリーミング画面３９または買い物リスト画面４３で「レジに進む」が選択された場合に表示される各種画面について説明する。図２９は、ストリーミング画面３９または買い物リスト画面４３で「レジに進む」が選択された場合に表示される画面の一例としての決済画面、配達画面、決済代行認証画面、認証確認画面を示す図である。

決済画面４５は、買い物かごの中身として選択された商品の分類、商品名、値段、合計金額、決済方法を選択するメニューが表示される。決済方法を選択するメニューとしては、カード決済、振込み等の各種決済方法が一例として表示される。また、決済画面４５には、「決済＆配達」、「代理決済」、「戻る」等のボタンが表示される。

決済画面４５で「決済＆配達」が選択されると、配達画面４７が表示される。配達画面では、店からのメッセージ（図２９の例では、お買い上げありがとうございました。配達先を指定して配達開始を押してください。またのご利用をお待ちしております。）が表示される。また、配達画面４７では、配達先、時間帯等を選択・入力するメニューが表示されると共に、「配達開始」ボタンが表示される。ここで、配達先や時間帯が指定されて「配達開始」が選択されたところで買い物が終了する。購入された商品の配達は、配送管理サーバ１６によって手配される。

本実施形態においても、上記実施形態の決済代行サーバ１１による決済代行サービスが利用可能とされており、例えば、決済画面４５の「代理決済」が選択されると、決済代行認証画面４９が表示される。決済代行認証画面４９では、カメラ１８Ｉによって撮影する利用者または二次元バーコードの撮影画像が表示され、「撮影」が選択されると、表示された利用者の顔写真または二次元バーコードが利用者情報として取得される。

また、決済代行認証画面４９の「撮影」が選択されると、認証確認画面５１が表示される。認証確認画面５１では、決済代行サーバ１１によって認証した結果に基づいて、本人を確認するための本人確認情報（例えば、氏名、年齢、顔写真等）が図２９に示す認証確認情報の領域に表示され、本人確認が可能となる。

本実施形態では、決済代行認証画面４９が表示した状態で、利用者の顔または印刷された二次元バーコード等を撮影することで、上述の図２９に示す決済代行サーバ１１の処理と同様に処理すれば、決済代行サーバ１１による決済代行サービスを利用できる。例えば、高齢者等のようにクライアント端末１８の操作が難しい利用者が、代行業者等に依頼して、代行業者等のクライアント端末１８を利用して、買い物及び決済までの処理を行うことが可能となる。すなわち、買い物する利用者が、携帯端末１８ｂ等のクライアント端末１８を持っていなくても、他の人のクライアント端末１８を用いて、買い物を行って、決済代行サーバ１１が、買い物する利用者を認証して決済することができる。

なお、上記の第２実施形態では、店舗選択画面３５で店舗が選択された場合に、買い物支援選択画面３７を表示して、「買い物代行」または「買い物リスト」を利用者に選択させるようにしたが、予め定めた条件に応じて何れかを自動的に選択するようにしてもよい。例えば、利用者が店舗からの商品の通知を閲覧する場合、買い物リスト以外の商品に興味がある可能性が高く、「買い物代行」による買い物方法を選択する可能性が高くなる。そこで、利用者が、図２７に示す「今日のチラシ」や、特売の広告、おすすめ商品のお知らせ等の店舗からの通知を閲覧後に、店舗が選択された場合は、「買い物代行」を自動的に選択してもよい。これにより、「買い物代行」を選択する利用者の手間を省くことが可能となる。

また、上記の第２実施形態では、決済代行サーバ１１、買い物支援サーバ１３、商品管理サーバ１５、及び配送管理サーバ１６は、それぞれ別々のサーバとして説明したが、これに限るものではない。例えば、４つのサーバの機能を１つのサーバに設けた形態としてもよいし、これらのサーバの機能を必要に応じて複数のサーバに分配して複数のサーバで構成する形態としてもよい。例えば、決済サーバ１１の認証機能部４６は、認証専門のサーバの機能としてもよい。

また、上記の各実施形態では、決済代行サービスを利用する際に、生体認証の一例として顔認証を一例として挙げたが、生体認証としては、顔以外の指紋や、網膜、虹彩、音声等の人体の特徴的な生体情報を適用してもよい。

また、上記の各実施形態における情報処理システム１０、１７は、組み合わせて１つの情報処理システムとしてもよい。また、上記以外の他のサーバを更に含んで種種のクラウドサービスを提供する形態としてもよい。

また、第１実施形態では、予め定めたサービスとして配車サービスを適用し、第２実施形態では、買い物代行サービスを適用した例を説明したが、決済代行サービスの対象となるサービスはこれらに限定されるものではない。例えば、他の種々のクラウドサービス等に対して決済代行サービスを利用する形態としてもよい。

また、上記の各実施形態における情報処理システム１０、１７の各部で行われる処理は、プログラムを実行することにより行われるソフトウエア処理として説明したが、これに限るものではない。例えば、ＧＰＵ（Graphics Processing Unit）、ＡＳＩＣ（Application Specific Integrated Circuit）、及びＦＰＧＡ（Field-Programmable Gate Array）等のハードウエアで行う処理としてもよい。或いは、ソフトウエア及びハードウエアの双方を組み合わせた処理としてもよい。また、ソフトウエアの処理とした場合には、プログラムを各種記憶媒体に記憶して流通させるようにしてもよい。

さらに、本発明は、上記に限定されるものでなく、上記以外にも、その主旨を逸脱しない範囲内において種々変形して実施可能であることは勿論である。例えば、主旨を逸脱しない範囲内において不要なステップを削除したり、新たなステップを追加したり、処理順序を入れ替えたりしてもよい。

１０、１７ 情報処理システム
１１ 決済代行サーバ（決済代行装置）
１１Ａ ＣＰＵ（受付部、処理部、及び前処理部）
１２ 配車計画サーバ（サービス提供装置）
１３ 買い物支援サーバ（サービス提供装置）
１４ 運行管理サーバ
１８ クライアント端末
１８Ｉ カメラ（撮影部）
２０ 車両側端末
２２ 通信ネットワーク
４０ 登録部
４２ 決済機能部
４４ 利用者ＤＢ
４６ 認証機能部
４８ 認証情報ＤＢ
５０ 認証・決済処理部（受付部及び処理部）

Claims (10)

1. 決済機能を搭載して第１利用者が利用するクライアント端末から利用者情報を受け付ける受付部と、
   前記受付部が受け付けた前記利用者情報に基づいて認証された利用者が、前記第１利用者とは異なる第２利用者である場合、前記第２利用者に対して決済処理を行う処理部と、
   を含む決済代行装置。
2. 前記受付部は、前記利用者情報を受け付ける際に、前記クライアント端末の位置情報を更に受け付ける請求項１に記載の決済代行装置。
3. 前記クライアント端末は、前記処理部によって前記決済処理が行われた後に、前記第２利用者に関する履歴情報が削除される請求項１又は請求項２に記載の決済代行装置。
4. 前記処理部は、認証された利用者が前記第２利用者である場合、前記第１利用者に対して予め定めた還元を更に行う請求項１〜３の何れか１項に記載の決済代行装置。
5. 前記クライアント端末は、撮影部を含み、
   前記受付部は、前記撮影部によって撮影された、利用者の生体情報または予め定めた認証用印刷物を前記利用者情報として受け付ける請求項１〜４の何れか１項に記載の決済代行装置。
6. 利用者の認証登録後に、前記認証用印刷物を印刷するための認証用コードを生成し、生成した認証用コードの印刷を促す処理を行う前処理部を更に含む請求項５に記載の決済代行装置。
7. 請求項１〜６の何れか１項に記載の決済代行装置と、
   予め定めたサービスを提供するサービス提供装置と、
   決済機能を搭載して前記第１利用者が利用する、前記サービスの提供を受ける利用者の前記利用者情報を入力するためのクライアント端末と、
   を含む決済代行システム。
8. 前記サービス提供装置は、配車に関する配車サービスを提供し、
   前記クライアント端末は、撮影部を含み、
   前記決済代行装置は、前記配車サービスを用いて配車を手配した場合、第２利用者が所持する予め印刷された認証用印刷物を前記撮影部によって撮影した撮影画像を用いて、本人確認を行う請求項７に記載の決済代行システム。
9. コンピュータが実行する決済代行方法であって、
   決済機能を搭載して第１利用者が利用するクライアント端末から利用者情報を受け付け、
   受け付けた前記利用者情報に基づいて利用者を認証する処理を行い、
   認証された利用者が前記第１利用者と異なる第２利用者である場合、前記第２利用者に対して決済処理を行う決済代行方法。
10. コンピュータを請求項１〜６の何れか１項に記載の決済代行装置の各部として機能させるための決済代行プログラム。

Images