JP2021002408A - プログラムおよび情報処理方法 - Google Patents

Abstract

【課題】タクシーに相乗りすることにメリットのある乗客同士のマッチングを行なうプログラム等を提供すること。【解決手段】プログラムは、タクシーに相乗りする候補者、および、該候補者と相乗りする場合の算定費用を取得し、取得した前記候補者、および、前記算定費用を表示し、表示した前記候補者と相乗りするか否かの選択を受け付ける処理をコンピュータに実行させる。プログラムは、前記候補者が途中でタクシーから降りる途中下車者であるか否かを表示する。【選択図】図２Ｂ

Description

本発明は、プログラムおよび情報処理方法に関する。

知人同士ではない複数の乗客を一台の車両に相乗りさせて輸送する、いわゆる乗り合いタクシーが利用されている。乗り合いタクシーを利用する個々の乗客の乗車料金を、当該乗客の乗車地点と降車地点との間の直線距離に基づいて定める公共交通システムが提案されている。

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

しかしながら、特許文献１に開示されたシステムでは、相乗りすることにメリットのある乗客の組合せのマッチングを行なえない。

一つの側面では、タクシーに相乗りすることにメリットのある乗客同士のマッチングを行なうことを目的とする。

プログラムは、タクシーに相乗りする候補者、および、該候補者と相乗りする場合の算定費用を取得し、取得した前記候補者、および、前記算定費用を表示し、表示した前記候補者と相乗りするか否かの選択を受け付ける処理をコンピュータに実行させる。

一つの側面では、タクシーに相乗りすることにメリットのある乗客同士のマッチングを行なえる。

タクシー相乗りシステムの概要を説明する説明図である。 タクシー相乗りシステムの料金の概要を説明する説明図である。 タクシー相乗りシステムの料金の概要を説明する説明図である。 タクシー相乗りシステムの構成を示す説明図である。 ユーザＤＢのレコードレイアウトを説明する説明図である。 リクエストＤＢのレコードレイアウトを説明する説明図である。 マッチングＤＢのレコードレイアウトを説明する説明図である。 情報処理装置が表示する画面を示す説明図である。 情報処理装置が表示する画面を示す説明図である。 情報処理装置が表示する画面を示す説明図である。 情報処理装置が表示する画面を示す説明図である。 情報処理装置が表示する画面を示す説明図である。 情報処理装置が表示する画面を示す説明図である。 プログラムの処理の流れを説明するフローチャートである。 マッチングのサブルーチンの処理の流れを説明するフローチャートである。 情報処理装置が表示する通報画面を示す説明図である。 途中乗車する場合のタクシー相乗りシステムの料金の概要を説明する説明図である。 途中乗車する場合のタクシー相乗りシステムの料金の概要を説明する説明図である。 相乗り条件ＤＢのレコードレイアウトを説明する説明図である。 実施の形態２のマッチングのサブルーチンの処理の流れを説明するフローチャートである。 バックグラウンドでマッチングを行なう情報処理装置の変形例が表示する画面を示す説明図である。 実施の形態３のタクシー相乗りシステムの概要を説明する説明図である。 実施の形態３のタクシー相乗りシステムの概要を説明する説明図である。 実施の形態４の情報処理装置が表示する画面を示す説明図である。 実施の形態４の情報処理装置が表示する画面を示す説明図である。 実施の形態５の情報処理装置が表示部に表示する精算条件画面を示す説明図である。 実施の形態５のプログラムの処理の流れを説明するフローチャートである。 修正精算のサブルーチンの処理の流れを説明するフローチャートである。 実施の形態６のタクシー相乗りシステムの料金の概要を説明する説明図である。 実施の形態６のユーザＤＢのレコードレイアウトを説明する説明図である。 実施の形態６のプログラムの処理の流れを説明するフローチャートである。 実施の形態６のプログラムの処理の流れを説明するフローチャートである。 実施の形態７のタクシー相乗りシステムの料金の概要を説明する説明図である。 実施の形態７のプログラムの処理の流れを説明するフローチャートである。 条件ＤＢのレコードレイアウトを説明する説明図である。 実施の形態８の情報処理装置が表示する画面を示す説明図である。 実施の形態８の情報処理装置が表示する画面を示す説明図である。 実施の形態８のマッチングのサブルーチンの処理の流れを説明するフローチャートである。 実施の形態９のタクシー相乗りシステムの機能ブロック図である。 実施の形態１０のタクシー相乗りシステムの構成を示す説明図である。

［実施の形態１］
図１は、タクシー相乗りシステム１０の概要を説明する説明図である。図１においては、タクシー乗り場に多くの人が行列している。図中Ｉで示す人物は、「いちろう」のニックネームで登録された、本タクシー相乗りシステム１０のユーザＩである。図中Ｋで示す人物は、「Ｋｏ」のニックネームで登録された、本タクシー相乗りシステム１０のユーザＫである。ユーザＩとユーザＫとの間には、面識はなくてもよい。

各ユーザは、事前にタクシー相乗りシステム１０に登録を行ない、アカウントを保有する。タクシー相乗りシステム１０に記録されて各ユーザのアカウント情報には、ニックネームおよび、ユーザの保有する債権が記録されている。アカウント情報の詳細については後述する。

ユーザＩは、第１情報処理装置２０１（図３参照）に乗車地および下車地を入力する。第１情報処理装置２０１は、ユーザＩに固有に付与されたユーザＩＤ（Identifier）、乗車地および下車地を紹介サーバ４０に送信する。ユーザＫは、第２情報処理装置２０２に乗車地および下車地を入力する。第２情報処理装置２０２は、ユーザＫに固有に付与されたユーザＩＤ、乗車地および下車地を紹介サーバ４０に送信する。紹介サーバ４０には、図示しない他のユーザに関するユーザＩＤ、乗車地および下車地も随時送信される。なお、第１情報処理装置２０１および第２情報処理装置２０２は、ユーザが使用するスマートフォンまたはタブレット等の、汎用の携帯型情報処理装置である。

紹介サーバ４０は、ユーザのマッチング処理を行なう。具体的には紹介サーバ４０は、同じ乗車地から出発する二人のユーザの組合せを抽出する。紹介サーバ４０は、地図サーバ４９と連動して、抽出した各ユーザが単独でタクシーに乗車する場合と、タクシーに相乗りする場合との、それぞれの料金とを算出する。紹介サーバ４０は、相乗りすることによるメリットがあるか否かを判定する。

ここで、メリットがあるとは、たとえば相乗りする二人のユーザのそれぞれが支払う料金が、単独でタクシーに乗車する場合の予測費用を下回ることを意味する。予測費用は本実施の形態のタクシー相乗りシステム１０が算定する算定費用の一例である。以下の説明では、ユーザＩとユーザＫとが相乗りし、ユーザＩが途中下車することにより、両ユーザに費用面でのメリットがあると判定された場合について説明する。

紹介サーバ４０は、第１情報処理装置２０１および第２情報処理装置２０２に、マッチング相手に関する情報を送信する。第１情報処理装置２０１および第２情報処理装置２０２は、ユーザＩおよびユーザＫによる、マッチングに同意するか否かにかかる入力を取得して、紹介サーバ４０に送信する。

ユーザＩとユーザＫとの双方が相乗りに同意した場合について説明する。紹介サーバ４０は、双方のユーザがそれぞれ相手を特定するために必要な情報を第１情報処理装置２０１および第２情報処理装置２０２に送信する。二人のユーザが直接会い、実際に相乗りを行なうことに合意した場合、紹介サーバ４０は途中下車者であるユーザＩのアカウントから、ユーザＫのアカウントに、相乗り分の料金に相当する債権を移動する。

ユーザＩとユーザＫとは、乗車前に知り合った知人同士として、タクシーに相乗りする。途中下車者であるユーザＩは、タクシーのドライバに対してはタクシー料金を支払わずに下車する。なお、途中下車者であるユーザＩは、前述の通り相乗り分の料金に相当する債権をユーザＫに支払い済である。後から降りるユーザＫは、ユーザＩの途中下車のために迂回した分も含めたタクシー料金を支払う。

図２Ａおよび図２Ｂは、タクシー相乗りシステム１０の料金の概要を説明する説明図である。図２Ａおよび図２Ｂにおいて、料金および所要時間は、いずれも説明のための例示であり、これに限定されるものではない。

図２Ａは、ユーザＩおよびユーザＫが、それぞれ単独でタクシーに乗車する場合の料金および所要時間を示す。ユーザＩは、Ａ駅からＢ駅まで乗車する。タクシー料金は２５７０円、所要時間は２３分間である。ユーザＫはＡ駅からＣ駅まで乗車する。タクシー料金は２８９０円、所要時間は２５分間である。

図２Ｂは、ユーザＩおよびユーザＫが１台のタクシーに相乗りした場合の料金および所要時間を示す。タクシーはまず、Ａ駅からＢ駅まで走行し、ユーザＩがＢ駅で途中下車する。Ｂ駅までの所要時間は、ユーザＩが単独で乗車した場合と同様に、２３分間である。

紹介サーバ４０は、ユーザＩのアカウントから、単独で乗車した場合の料金２５７０円の５０％相当の第１タクシー料金である１２８５円に、ユーザＩにかかる手数料である第１手数料３２１円を加算した１６０６円に相当する債権を差し引く。すなわち、相乗りにおいてユーザＩが負担する第１費用は１６０６円であり、単独で乗車した場合の料金である２５７０円よりも安い。

手数料には、本タクシー相乗りシステム１０の利用手数料、ユーザＩとユーザＫとのマッチングを行なうマッチング手数料、決済手数料等、ユーザが本タクシー相乗りシステム１０の運営者に対して支払う種々の手数料が含まれる。ユーザは、クレジットカード会社等の決済代行会社を介して本タクシー相乗りシステム１０の運営者に手数料を支払っても良い。この場合、手数料にはユーザが決済代行会社に支払う手数料と、本タクシー相乗りシステム１０の運営者に支払う手数料とが含まれる。

紹介サーバ４０は、ユーザＩのアカウントから支払われた第１タクシー料金１２８５円から、ユーザＫにかかる手数料である第２手数料３２１円を差し引いた９６４円に相当する債権を、ユーザＫのアカウントに追加する。また、第２手数料３２１円は、ユーザＩの債権から差し引かれる。

タクシーはＢ駅からＣ駅まで走行する。ユーザＫは、Ｃ駅で下車する際に、Ａ駅からＢ駅を経由してＣ駅までの第２タクシー料金３５３０円を支払う。所要時間は、３２分間である。相乗りにおいてユーザＫが負担する第２費用は、第２タクシー料金３５３０円と、タクシー相乗りシステム１０を介してユーザＩから受け取った９６４円との差額の２５６６円であり、単独で乗車した場合の料金である２８９０円よりも安い。

以上により、相乗りにより、ユーザＩも、ユーザＫも、単独で乗車する場合に比べて安い料金でタクシーを利用できる。タクシー運転手から見ると、知人同士が一緒に乗車して、途中で一人が降りるだけであるため、乗り合いタクシーの認可等の手続は不要である。

タクシー相乗りシステム１０の運営者は、ユーザＩと、ユーザＫとから、それぞれ３２１円、合計６４２円の手数料収入を得る。なお、図２Ｂにおいては、ユーザＩが支払う第１タクシー料金の２５％が、それぞれのユーザが支払う手数料である。二人のユーザが支払うマッチング手数料は互いに異なっていても良い。手数料は、相乗り１回あたり３００円等の定額制であっても良い。

ユーザＩが支払う第１タクシー料金は、単独で乗車した場合の料金２５７０円の５０％相当に限定しない。ユーザＩとユーザＫとの双方にメリットが出る範囲で、任意の金額に定めることができる。第１タクシー料金の比率は、ユーザとのマッチングで最大利益が出るように、動的に調整されてもよい。

なお、以下の説明においてはユーザＩのように途中下車者であるユーザをライドフレンド、ユーザＫのように最終下車地まで乗車する最終下車者をライドリーダと呼ぶ場合がある。

図３は、タクシー相乗りシステム１０の構成を示す説明図である。タクシー相乗りシステム１０は、前述の通りネットワークを介して接続された紹介サーバ４０、第１情報処理装置２０１、第２情報処理装置２０２および地図サーバ４９を備える。

第１情報処理装置２０１は、第１ＣＰＵ（Central Processing Unit）２１１、主記憶装置２２１、補助記憶装置２３１、通信部２４１、タッチパネル２５１、ＧＰＳ（Global Positioning System）２８１、およびバスを備える。第１ＣＰＵ２１１は、本実施の形態のプログラムを実行する演算制御装置である。第１ＣＰＵ２１１には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。第１ＣＰＵ２１１は、バスを介して第１情報処理装置２０１を構成するハードウェア各部と接続されている。

主記憶装置２２１は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の記憶装置である。主記憶装置２２１には、第１ＣＰＵ２１１が行なう処理の途中で必要な情報および第１ＣＰＵ２１１で実行中のプログラムが一時的に保存される。

補助記憶装置２３１は、ＳＲＡＭ、フラッシュメモリまたはハードディスク等の記憶装置である。補助記憶装置２３１には、第１ＣＰＵ２１１に実行させるプログラム、およびプログラムの実行に必要な各種データが保存される。

通信部２４１は、第１情報処理装置２０１とネットワークとの間のデータ通信を行なうインターフェイスである。タッチパネル２５２は、液晶表示パネル等の表示部２６１と、表示部２６１に積層された入力部２７１とを備える。

ＧＰＳ２８１は、位置情報衛星の電波および基地局の電波等に基づいて測位を行ない、第１情報処理装置２０１の位置を示す測位情報を出力する。なお、本実施の形態においてはＧＰＳと記載するが、位置情報衛星は米国のＧＰＳ衛星に限定しない。ＥＵ（European Union）のガリレオ、ロシアのＧＬＯＮＡＳＳ（Global Navigation Satellite System）などの、全地球的公航法衛星システム（ＧＮＳＳ：Global Navigation Satellite System）、準天頂衛星みちびき等、任意の位置情報衛星を使用できる。また、これらの位置情報衛星の電波を組み合わせて使用することもできる。

第２情報処理装置２０２は、第２ＣＰＵ２１２、主記憶装置２２２、補助記憶装置２３２、通信部２４２、タッチパネル２５２、ＧＰＳ２８２、およびバスを備える。第２ＣＰＵ２１２は、本実施の形態のプログラムを実行する演算制御装置である。第２ＣＰＵ２１２には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。第２ＣＰＵ２１２は、バスを介して第２情報処理装置２０２を構成するハードウェア各部と接続されている。

主記憶装置２２２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等の記憶装置である。主記憶装置２２２には、第２ＣＰＵ２１２が行なう処理の途中で必要な情報および第２ＣＰＵ２１２で実行中のプログラムが一時的に保存される。

補助記憶装置２３２は、ＳＲＡＭ、フラッシュメモリまたはハードディスク等の記憶装置である。補助記憶装置２３２には、第２ＣＰＵ２１２に実行させるプログラム、およびプログラムの実行に必要な各種データが保存される。

通信部２４２は、第２情報処理装置２０２とネットワークとの間のデータ通信を行なうインターフェイスである。タッチパネル２５２は、液晶表示パネル等の表示部２６２と、表示部２６２に積層された入力部２７２とを備える。

ＧＰＳ２８２は、位置情報衛星の電波および基地局の電波等に基づいて測位を行ない、第２情報処理装置２０２の位置を示す測位情報を出力する。

なお、第１情報処理装置２０１および第２情報処理装置２０２は、タクシー相乗りシステム１０に含まれる多数の情報処理装置２０の例示である。以後の説明において、個々の情報処理装置２０を区別しない場合には、情報処理装置２０と記載する。同様に情報処理装置２０の各構成要素を、ＣＰＵ２１、主記憶装置２２、補助記憶装置２３、通信部２４、タッチパネル２５、表示部２６、入力部２７およびＧＰＳ２８と記載する。

紹介サーバ４０は、紹介ＣＰＵ４１、主記憶装置４２、補助記憶装置４３、通信部４４およびバスを備える。紹介ＣＰＵ４１は、本実施の形態のプログラムを実行する演算制御装置である。紹介ＣＰＵ４１には、一または複数のＣＰＵまたはマルチコアＣＰＵ等が使用される。紹介ＣＰＵ４１は、バスを介して紹介サーバ４０を構成するハードウェア各部と接続されている。

主記憶装置４２は、ＳＲＡＭ、ＤＲＡＭ、フラッシュメモリ等の記憶装置である。主記憶装置４２には、紹介ＣＰＵ４１が行なう処理の途中で必要な情報および紹介ＣＰＵ４１で実行中のプログラムが一時的に保存される。

補助記憶装置４３は、ＳＲＡＭ、フラッシュメモリ、ハードディスクまたは磁気テープ等の記憶装置である。補助記憶装置４３には、ユーザＤＢ（Database）５１、リクエストＤＢ５２、マッチングＤＢ５３、紹介ＣＰＵ４１に実行させるプログラム、およびプログラムの実行に必要な各種データが保存される。なお、ユーザＤＢ５１、リクエストＤＢ５２およびマッチングＤＢ５３は、紹介サーバ４０に接続された外部の大容量記憶装置等に保存されていても良い。

通信部４４は、紹介サーバ４０とネットワークとの間の通信を行なうインターフェイスである。紹介サーバ４０は、大型計算機上で動作する仮想マシンでも良い。紹介サーバ４０は、複数の複数のコンピュータまたはサーバマシンを組み合わせて構成されても良い。

図４は、ユーザＤＢ５１のレコードレイアウトを示す説明図である。ユーザＤＢ５１は、ユーザＩＤと、ニックネームと、登録情報と、保有債権と、利用履歴と評価とを関連づけた、アカウント情報を記録するＤＢである。

ユーザＤＢ５１は、ユーザＩＤフィールド、ニックネームフィールド、登録情報フィールド、保有債権フィールド、利用履歴フィールドおよび評価フィールドを有する。登録情報フィールドは、氏名フィールド、住所フィールド、電話番号フィールドおよび性別フィールドを有する。利用履歴フィールドは、総利用回数フィールドおよび総走行距離フィールドを有する。評価フィールドは、良フィールドおよび不良フィールドを有する。

ユーザＩＤフィールドには、ユーザＩＤが記録されている。ニックネームフィールドには、ユーザのニックネームが記録されている。氏名フィールドには、ユーザの氏名が記録されている。住所フィールドには、ユーザの住所が記録されている。電話番号フィールドには、ユーザの電話番号が記録されている。性別フィールドには、ユーザの性別が記録されている。

保有債権フィールドには、ユーザの保有する債権が記録されている。本実施の形態においては、債権の単位は日本円であるが、必ずしも日本円に限られることはなく、外国通貨や、タクシー相乗りシステム１０の運営者が発行するポイント等であってもよい。ユーザは、保有する債権をライドリーダへの支払および本タクシー相乗りシステム１０の手数料の支払に充当できる。

ユーザは、ライドリーダへの支払および本タクシー相乗りシステム１０の手数料の支払を、債権を用いて支払うことができる他、クレジットカードや決済代行者を介して支払っても良い。また、保有する債権が支払額に満たない場合には、ユーザは、債権を用いた決済をすることができないことから、クレジットカードや決済代行者を介して支払う。

ユーザは、保有債権フィールドに記録された債権を、自分の銀行口座等に振り込んで現金化できる。この場合、債権から振込手数料を差し引いた金額が、銀行口座に振り込まれる。

ユーザは、保有債権フィールドに記録された債権を、タクシー料金の支払に使用できても良い。このようにする場合には、紹介サーバ４０からタクシー会社の口座に対して直接に、または、他の決済システムを介して支払処理が行なわれる。

総利用回数フィールドには、ユーザがタクシー相乗りシステム１０を利用した回数が記録されている。総走行距離フィールドには、ユーザがタクシー相乗りシステム１０を利用して走行した距離が記録されている。良フィールドには、相乗り相手から「良」の評価を得た回数が記録されている。不良フィールドには、相乗り相手から「不良」の評価を得た回数が記録されている。ユーザＤＢ５１は、タクシー相乗りシステム１０を利用する１人または１組のユーザについて、１つのレコードを有する。

図５は、リクエストＤＢ５２のレコードレイアウトを説明する説明図である。リクエストＤＢ５２は、ユーザＩＤと、ニックネームと、相乗りを希望する乗車地および下車地と、リクエスト時刻と、単独で乗車する場合の料金および所要時間とが関連づけて記録されるＤＢである。

リクエストＤＢ５２は、ユーザＩＤフィールド、ニックネームフィールド、乗車地フィールド、下車地フィールド、リクエスト時刻フィールドおよび単独乗車フィールドを有する。単独乗車フィールドは、料金フィールドおよび所要時間フィールドを有する。

ユーザＩＤフィールドには、ユーザＩＤが記録されている。ニックネームフィールドには、ユーザのニックネームが記録されている。乗車地フィールドには、ユーザの乗車地が記録されている。下車地フィールドには、ユーザの下車地が記録されている。リクエスト時刻フィールドには、ユーザがタクシー相乗りシステム１０に相乗りのリクエストを送信した時刻が記録されている。

料金フィールドには、乗車地から下車地まで、ユーザが単独でタクシーに乗車した場合の時刻が記録されている。所要時間フィールドには、乗車地から下車地までのタクシーの所要時間が記録されている。紹介ＣＰＵ４１は、乗車地および下車地を地図サーバ４９に送信して、タクシー料金および所要時間を取得し、リクエストＤＢ５２に記録する。リクエストＤＢ５２は、相乗りを希望する一人のユーザについて、１つのレコードを有する。

図６は、マッチングＤＢ５３のレコードレイアウトを説明する説明図である。マッチングＤＢ５３は、相乗りによるメリットがある１組のユーザと、乗車経路と、債権の収受と、マッチングの状況とを関連づけて記録するＤＢである。

マッチングＤＢ５３は、ライドリーダフィールド、ライドフレンドフィールド、経路フィールド、債権フィールドおよび状況フィールドを有する。ライドリーダフィールドは、ユーザＩＤフィールドおよび現在地フィールドを有する。ライドフレンドフィールドは、ユーザＩＤフィールドおよび現在地フィールドを有する。経路フィールドは、乗車地フィールド、経由地フィールドおよび下車地フィールドを有する。債権フィールドは、フレンド債権フィールド、およびリーダ債権フィールドを有する。

ライドリーダフィールドのユーザＩＤフィールドには、下車地まで乗車するユーザのユーザＩＤが記録されている。ライドリーダフィールドの現在地フィールドには、ライドリーダの現在地が記録されている。現在地は、ライドリーダが使用する情報処理装置２０から内蔵するＧＰＳ２８により取得された情報が送信されて、随時更新される。

ライドフレンドフィールドのユーザＩＤフィールドには、経由地で下車するユーザのユーザＩＤが記録されている。ライドフレンドフィールドの現在地フィールドには、ライドフレンドの現在地が記録されている。

乗車地フィールドには、相乗りするユーザが乗車する場所が記録されている。経由地フィールドには、ライドフレンドが下車する場所が記録されている。下車地フィールドには、ライドリーダが下車する場所が記録されている。フレンド債権フィールドには、ライドフレンドが支払う債権が記録されている。リーダ債権フィールドには、ライドリーダが受け取る債権が記録されている。状況フィールドには、「確認中」「開始」等、マッチングの進捗状況が記録されている。

図７から図１２は、情報処理装置２０が表示する画面を示す説明図である。以下の説明においては、図１、図２Ａおよび図２Ｂを使用して説明したユーザＩが使用する第１情報処理装置２０１、または、ユーザＫが使用する第２情報処理装置２０２に表示される画面例を使用する。

図７は、ユーザＫが相乗りのマッチングを要求する前に、第２情報処理装置２０２の表示部２６２に表示される入力画面を示す。画面の上部に乗車地欄６１および下車地欄６２が表示されている。画面の上半分弱の範囲に、地図欄６３が表示されている。地図欄６３の下に乗車地名欄６１１が表示されている。乗車地名欄６１１の下にマッチング依頼ボタン７１１が表示されている。

乗車地欄６１および下車地欄６２は、ユーザによる乗車地および下車地の入力を受け付ける。ユーザから受け付けた乗車地および下車地を含む地図が、地図欄６３に表示される。地図上に、乗車地を示す乗車地マーク６４１、下車地を示す下車地マーク６４２、および、タクシーの通行経路を示す経路マーク６４６が表示される。相乗りを希望するユーザは、乗車地および下車地を入力した後に、マッチング依頼ボタン７１１を選択する。

ＣＰＵ２１は、ユーザＩＤ、乗車地、下車地等を紹介サーバ４０に送信する。紹介ＣＰＵ４１は、リクエストＤＢ５２に新しいレコードを作成し、受信したユーザＩＤ、乗車地、下車地等を記録する。

なお、ＣＰＵ２１は、乗車地欄６１の初期値にＧＰＳ２８を介して取得した情報処理装置２０の現在地を設定してもよい。タクシー乗り場で本実施の形態のプログラムを起動したユーザは、乗車地欄６１を入力する作業を省略できる。

ＣＰＵ２１は、下車地欄６２の初期値にユーザＤＢ５１に記録されたユーザの住所を設定してもよい。帰宅のためにタクシーを利用するユーザは、下車地欄６２を入力する作業を省略できる。

図８は、紹介ＣＰＵ４１から相乗り相手の候補、ユーザＩにかかる情報を受信した後に、第２情報処理装置２０２の表示部２６２に表示される紹介画面を示す。

地図欄６３に表示された地図上に、乗車地を示す乗車地マーク６４１、下車地を示す下車地マーク６４２、途中下車を行なう経由地を示す経由地マーク６４３、および、タクシーの通行経路を示す経路マーク６４６が表示されている。

乗車地マーク６４１の近傍に、ユーザＫの現在地、すなわち第２情報処理装置２０２の現在地を示す第２現在地マーク６４４が実線の小円で表示されている。同様に、ユーザＩの現在地、すなわち第１情報処理装置２０１の現在地を示す第１現在地マーク６４５が破線の小円で表示されている。

地図欄６３の下端に候補者アイコン欄６５１、総利用回数欄６５２および総走行距離欄６５３が表示されている。候補者アイコン欄６５１の外周は、第１現在地マーク６４５と同様に破線で表示されている。なお、第１現在地マーク６４５と、候補者アイコン欄６５１の外周とを、同じ色で示しても良い。

候補者アイコン欄６５１の中には、ユーザＤＢ５１に記録されたユーザＩの性別「男性」を示すアイコンが表示されている。なお、候補者アイコン欄６５１に、それぞれのユーザにより登録された顔写真等のアイコンが表示されても良い。このようにする場合、ユーザＤＢ５１はそれぞれのユーザのアイコンを記録するフィールドを有する。

総利用回数欄６５２には、ユーザＤＢ５１に記録されたユーザＩの総利用回数が表示されている。総走行距離欄６５３には、ユーザＤＢ５１に記録されたユーザＩの総走行距離が表示されている。候補者アイコン欄６５１の下に、ニックネーム欄６５７が表示されている。ニックネーム欄６５７には、ユーザＤＢ５１に記録されたユーザＩのニックネームが表示されている。なお、図８には表示されていないが、ニックネーム欄６５７の近傍に、ユーザの性別の情報を表示してもよい。

ニックネーム欄６５７の下に費用欄６５４および候補者地名欄６５５が表示されている。費用欄６５４には、ユーザＫが単独でタクシーに乗車した場合の所要時間および料金と、ユーザＫがユーザＩと相乗りした場合の所要時間および料金とが表示されている。候補者地名欄６５５には、ユーザＩの現在地が表示されている。候補者地名欄６５５に表示された地名が、ユーザＫの現在地から離れている場合には、タクシーの走行途中でユーザＩが合流することを意味する。

ユーザＫは、費用欄６５４および候補者地名欄６５５を見ることにより、ユーザＩとの相乗りに同意するか否かを判断できる。ユーザＩとの相乗りに同意する場合には、ユーザＫは候補承認ボタン７１２を選択する。ユーザＩとの相乗りに同意せず、別の候補とのマッチングを希望する場合には、ユーザＫは別候補ボタン７１３を選択する。相乗りのリクエストを取り下げる場合には、ユーザＫはキャンセルボタン７１４を選択する。

なお、所定の時間が経過してもいずれのボタンの選択も受け付けない場合、第２ＣＰＵ２１２は、キャンセルボタン７１４の選択を受け付けたと判定する。

なお、候補者アイコン欄６５１またはニックネーム欄６５７の選択を受け付けた場合に、候補者の自己紹介等を表示しても良い。ユーザは、自己紹介を確認することにより、安心して相乗りできるユーザであるか否かを判断しやすくなる。

紹介ＣＰＵ４１は、複数の相乗り相手の候補を抽出して、ユーザに提示しても良い。たとえば、図８に示す紹介画面で、ユーザがフリック操作等の操作を行なった場合に、次の相乗り相手の候補が表示される。ユーザは、候補承認ボタン７１２または別候補ボタン７１３を押す前に複数の候補を比較検討できる。

複数の候補が、一つの画面に一覧表示されても良い。たとえば、料金順、所要時間順、評価順等、任意の条件で複数の候補をソートできても良い。

紹介ＣＰＵ４１は、ユーザＤＢ５１の評価フィールドに基づいて、たとえば「良」の評価が多い順、または、「良」の評価から「不良」の評価を減算した値が大きい順等、評価の高いユーザから順に複数の候補を表示しても良い。評価の高いユーザのマッチングが優先的に成立するタクシー相乗りシステム１０を実現できる。

図９は、紹介サーバ４０を介して、第２情報処理装置２０２から相乗りに同意する旨を受信した場合に、第１情報処理装置２０１の表示部２６１に表示される確認画面を示す。図８と同様に、ユーザＫとのマッチングが行なわれたことを表示する画面に、マッチング相手であるユーザＫが相乗りに同意したことを示す確認窓６６がポップアップ表示されている。

確認窓６６内に、相乗りに表示するか否かを受け付けるボタンが表示されている。ユーザＩが、「はい」のボタンを選択した場合に、ユーザＫとユーザＩとの間の合意が成立する。

図１０は、ユーザＫとユーザＩとの間の合意が成立した場合に、第１情報処理装置２０１の表示部２６１に表示される成立画面を示す。

地図欄６３に表示された地図上に、乗車地を示す乗車地マーク６４１、下車地を示す下車地マーク６４２、途中下車を行なう経由地を示す経由地マーク６４３、タクシーの通行経路を示す経路マーク６４６、第１情報処理装置２０１の現在地を示す第１現在地マーク６４５、および、第２情報処理装置２０２の現在地を示す第２現在地マーク６４４が表示されている。図１を使用して説明したように、ユーザＩとユーザＫとは同じタクシー乗り場に並んでいるため、図１０においては乗車地マーク６４１、第１現在地マーク６４５および第２現在地マーク６４４は、ほぼ重なっている。

地図欄６３の下側に、相乗り相手のニックネームおよびユーザＩがライドフレンドであることを示す結果欄６５８が表示されている。結果欄６５８の下側に、現在地拡大ボタン７１５、チャット開始ボタン７１６および開始ボタン７１７が表示されている。

現在地拡大ボタン７１５の選択を受け付けた場合、第１ＣＰＵ２１１は、第１現在地マーク６４５を中心にし、第２現在地マーク６４４が第１現在地マーク６４５と分離して表示される程度の縮尺に拡大した地図を、地図欄６３に表示する。ユーザＩは、地図上でマッチング相手であるユーザＫの位置を確認できる。

なお、相乗り相手のユーザが情報処理装置２０における本実施の形態のプログラムの実行を停止した場合には、第１現在地マーク６４５は表示されない。このようにすることにより、相乗りが終了した後で、相乗り相手に対して自宅の場所等のプライバシー情報を開示することを避けられる。

チャット開始ボタン７１６の選択を受け付けた場合、第１情報処理装置２０１、第２情報処理装置２０２および紹介サーバ４０は、連動してユーザＩとユーザＫとの間のチャットを開始する。図１１は、チャット画面の例を示す。ユーザＫによるメッセージは画面左端からの吹き出しで、ユーザＩによるメッセージは右からの吹き出しでそれぞれ表示される。ユーザＫとユーザＩとは、チャットにより互いの位置を知り、合流場所を決定できる。ユーザ間のチャットを行なうシステムは、従来から使用されているため、処理の詳細については省略する。

チャット画面の下側には、チャット終了ボタン７１９および開始ボタン７１７が表示されている。チャット終了ボタン７１９の選択を受け付けた場合、第１ＣＰＵ２１１は図１０を使用して説明した画面に戻る。

なお、チャット開始ボタン７１６の代わりに、または、チャット開始ボタン７１６と共に通話開始ボタンが表示されていても良い。通話開始ボタンの選択を受け付けた場合、第１情報処理装置２０１、第２情報処理装置２０２および紹介サーバ４０は、連動してユーザＩとユーザＫとの間の音声通話を開始する。ユーザ間の音声通話を行なうシステムは、従来から使用されているため、処理の詳細については省略する。

図１０および図１１を使用して説明を続ける。図１０および図１１に示す画面の下端部に、キャンセルボタン７１４が表示されている。いずれかのユーザによるキャンセルボタン７１４の選択を受け付けた場合、ユーザＩとユーザＫとのマッチングはキャンセルされる。

図１０および図１１に示す開始ボタン７１７の選択を受け付けた場合、ＣＰＵ２１は相乗り乗車の開始を確定する確定画面を表示する。図１２は、ユーザＩによる開始ボタン７１７の選択を受け付けた場合に、第１情報処理装置２０１の表示部２６１に表示される画面を示す。ユーザＩが単独で乗車する場合の所要時間と料金、相乗りして途中下車する場合の所要時間と料金、および、料金の内訳が表示されている。料金の下に、ライドリーダであるユーザＫのアイコンおよびニックネームが表示されている。画面の下側に、承認ボタン７２０が表示されている。

なお、ユーザＫによる開始ボタン７１７の選択を受け付けた場合、第２情報処理装置２０２の表示部２６２には、同様にユーザＫにかかる料金が表示される。両方のユーザによる承認ボタン７２０の選択を受け付けた場合、図２Ｂを使用して説明したように、紹介ＣＰＵ４１はライドフレンドであるユーザＩのアカウントから１６０６円に相当する債権を差し引き、９６４円に相当する債権を、ライドリーダであるユーザＫのアカウントに追加する。

図１２を使用して説明した確認画面において、ユーザが相乗り相手へ支払う料金の変更を受け付けても良い。たとえば、ライドフレンドからはライドリーダへ支払う料金を増額する変更のみを受け付け、ライドリーダからはライドフレンドから受け取る料金を減額する変更のみを受け付けることで、相手方への再確認を行なわずに料金を確定できる。

ライドフレンドとライドリーダとの合意に基づいて、ライドフレンドからライドリーダに支払う料金、つまり、相乗りする区間の料金を、予測料金から、事後的に変更できるようにしても良い。たとえば、ライドフレンド降車時の、タクシーの料金が、予測費用と異なる場合、ライドリーダまたは、ライドフレンドの一方が、料金の変更の申請を情報処理装置２０に対し行ない、情報処理装置２０がこれを他方に通知し、当該他方がこれを承認することを情報処理装置２０に送信することにより、情報処理装置２０が料金の変更の合意があったものと判断して、予測費用の金額を変更しても良い。

また、以下のようにして変更しても良い。すなわち、ライドフレンドが降車する際のタクシーメータをライドフレンドとライドリーダの双方が確認する。確認した料金に基づいて、ライドフレンドの乗車料金を変更することを合意する。ライドフレンドおよびライドリーダは、合意した金額をそれぞれの情報処理装置２０を介して紹介ＣＰＵ４１に送信する。紹介ＣＰＵ４１は、両者から受信した金額が一致している場合に、債権を移動する。

マッチングを行なう際に算出したライドリーダの料金、または、ライドフレンドの料金の少なくともいずれか一方が実際の料金と異なる場合、紹介ＣＰＵ４１は両者の負担額を変更しても良い。この場合、紹介ＣＰＵ４１は、たとえばライドリーダが下車する際に支払うタクシー料金を取得して、ライドリーダとライドフレンドとの間の債権を移動する。

料金を事後的に変更する場合、変更後の料金と連動して手数料を変更しても良い。この場合、ＣＰＵ２１は手数料を自動的に算出して、表示部２６に表示することが望ましい。料金を事後的に変更する場合であっても、手数料は相乗り開始時に定めた金額のままであっても良い。この場合、手数料は相乗り開始時に確定する。

図１３は、プログラムの処理の流れを説明するフローチャートである。本実施の形態のプログラムは、それぞれの情報処理装置２０で個別に起動される。第１ＣＰＵ２１１は、図７を使用して説明した入力画面を介して、乗車地および下車地の条件を取得する（ステップＳ５０１）。

マッチング依頼ボタン７１１の選択を受け付けた場合、第１ＣＰＵ２１１は、紹介ＣＰＵ４１に紹介リクエストを送信する（ステップＳ５０２）。紹介ＣＰＵ４１は、紹介リクエストを割り込み処理で受け付ける。紹介ＣＰＵ４１は、乗車地から下車地まで単独でタクシーに乗車した場合の料金および所要時間を地図サーバ４９から取得する。紹介ＣＰＵ４１は、リクエストＤＢ５２に新規レコードを追加して、紹介リクエストの内容を記録する。

同様に第２ＣＰＵ２１２は、乗車地および下車地の条件を取得する（ステップＳ６０１）。マッチング依頼ボタン７１１の選択を受け付けた場合、第２ＣＰＵ２１２は、紹介ＣＰＵ４１に紹介リクエストを送信する（ステップＳ６０２）。紹介ＣＰＵ４１は、紹介リクエストを割り込み処理で受け付け、リクエストＤＢ５２に記録する。

紹介ＣＰＵ４１は、マッチングのサブルーチンを起動する（ステップＳ７０１）。マッチングのサブルーチンは、リクエストＤＢ５２に記録されたレコードから、相乗りすることによるメリットがあるユーザの組合せを抽出するサブルーチンである。マッチングのサブルーチンの処理の流れについては後述する。

以下の説明においては、マッチングのサブルーチンにおいて、第１情報処理装置２０１にかかるユーザがライドフレンドに、第２情報処理装置２０２にかかるユーザがライドリーダにそれぞれ選択された場合について説明する。紹介ＣＰＵ４１は、抽出した候補にかかる第１ＣＰＵ２１１および第２ＣＰＵ２１２に、候補ユーザを通知する（ステップＳ７０２）。第１ＣＰＵ２１１および第２ＣＰＵ２１２は、図８を使用して説明した紹介画面を表示する（ステップＳ５０３、ステップＳ６０３）。

第１ＣＰＵ２１１および第２ＣＰＵ２１２は、それぞれユーザによる回答を取得して、紹介ＣＰＵ４１に送信する（ステップＳ５０４、ステップＳ６０４）。紹介ＣＰＵ４１は、双方からの回答をそれぞれ受信する（ステップＳ７０３）。紹介ＣＰＵ４１は、双方のユーザが相乗りに同意して、マッチングが成立したか否かを判定する（ステップＳ７０４）。

マッチングが成立していないと判定した場合（ステップＳ７０４でＮＯ）、紹介ＣＰＵ４１はマッチングＤＢ５３の対応するレコードの状況フィールドに「不成立」を記録して、ステップＳ７０１に戻る。マッチングが成立したと判定した場合（ステップＳ７０４でＹＳＥ）、紹介ＣＰＵ４１は、第１ＣＰＵ２１１にライドフレンドである旨を、第２ＣＰＵ２１２にライドリーダである旨をそれぞれ通知する（ステップＳ７０５）。

第１ＣＰＵ２１１は、図１０を使用して説明した成立画面を表示し、ユーザＩがライドフレンドである旨を表示する（ステップＳ５０５）。同様に第２ＣＰＵ２１２は、図１０を使用して説明した成立画面の結果欄６５８に「いちろうさんとマッチしました あなたはライドリーダです」のように、ユーザＫがライドリーダである旨を表示する（ステップＳ６０５）。

第１ＣＰＵ２１１および第２ＣＰＵ２１２は、それぞれ開始ボタン７１７の選択を受け付けた旨を紹介ＣＰＵ４１に送信する（ステップＳ５０６、ステップＳ６０６）。紹介ＣＰＵ４１は、両方のユーザによる開始ボタン７１７の選択をそれぞれ受け付ける（ステップＳ７０６）。紹介ＣＰＵ４１は第１ＣＰＵ２１１および第２ＣＰＵ２１２に確認指示を送信する（ステップＳ７０７）。第１ＣＰＵ２１１および第２ＣＰＵ２１２は、図１２を使用して説明した確定画面を表示する（ステップＳ５０７、ステップＳ６０７）。

第１ＣＰＵ２１１および第２ＣＰＵ２１２は、それぞれ承認ボタン７２０の選択を受け付けた旨を紹介ＣＰＵ４１に送信する（ステップＳ５０８、ステップＳ６０８）。第１ＣＰＵ２１１および第２ＣＰＵ２１２は、処理を終了する。

両方のユーザによる承認ボタン７２０の選択を受け付けた後に、紹介ＣＰＵ４１は両ユーザのアカウントの債権を精算する（ステップＳ７０８）。具体的には、紹介ＣＰＵ４１は、ライドフレンドのアカウントから料金および紹介料の合計に相当する債権を差し引く。紹介ＣＰＵ４１は、ライドリーダのアカウントに、ライドフレンドが支払った料金から紹介料を差し引いた料金に相当する債権を加算する。紹介ＣＰＵ４１は、ステップＳ７０１に戻る。

なお、図１３に示すフローチャートにおいては、ライドリーダとライドフレンドの両者が合意して、マッチングが成立した時点で決済が行なわれるが、決済のタイミングはこれに限定しない。たとえば、両者の手数料は、マッチング時点や相乗り確定時点で決済をするが、ライドフレンドがライドリーダに支払う相乗り分の料金は、事後的（たとえば、ライドフレンドがタクシーを下車する時点）に支払ってもよい。この場合、紹介ＣＰＵ４１は、ステップＳ７０８の実行を保留し、ライドフレンドがタクシーを下車する際に債権の精算を実行しても良い。また、ライドリーダの手数料はマッチング時点や相乗り確定時点で決済をし、ライドフレンドの手数料および相乗り分の料金は、事後的にまとめて支払ってもよい。

図１４は、マッチングのサブルーチンの処理の流れを説明するフローチャートである。マッチングのサブルーチンは、リクエストＤＢ５２に記録されたレコードから、相乗りすることによるメリットがあるユーザの組合せを抽出するサブルーチンである。

地図サーバ４９が、「出発地点」、「経由地点」および「目的地点」を受け付けて、経路情報を出力する機能を有する場合を例にして説明する。

紹介ＣＰＵ４１は、リクエストＤＢ５２から、乗車地が同一または近接する２つのレコードを抽出する（ステップＳ７５１）。ここで紹介ＣＰＵ４１は、たとえばリクエスト時刻フィールドに記録された時刻が早いレコードを優先して抽出する。紹介ＣＰＵ４１は、レコードをランダムに抽出しても良い。

紹介ＣＰＵ４１は、抽出した２つのレコードのうちの第１レコードに対応するユーザがライドリーダであり、第２レコードに対応するユーザがライドフレンドであると判定する（ステップＳ７５２）。紹介ＣＰＵ４１は、ライドリーダおよびライドフレンドの現在地、両者の中間地点、または、中間地点から最寄りのタクシー乗り場等の任意の地点を、タクシーに乗車する地点である「出発地点」として設定する。紹介ＣＰＵ４１は、ライドフレンドの下車地を「経由地点」に設定する。紹介ＣＰＵ４１は、ライドリーダの下車地を「目的地点」に設定する。

紹介ＣＰＵ４１は、「出発地点」、「経由地点」および「目的地点」を地図サーバ４９に送信する（ステップＳ７５３）。紹介ＣＰＵ４１は、経路情報を地図サーバ４９から取得する（ステップＳ７５４）。経路情報には、地図上の経路と、「出発地点」から「経由地点」までのタクシー料金および所要時間と、「出発地点」から「目的地点」までのタクシー料金および所要時間とが含まれる。

紹介ＣＰＵ４１は、ライドフレンドおよびライドリーダがそれぞれ負担する費用を算出する（ステップＳ７５５）。紹介ＣＰＵ４１は、リクエストＤＢ５２の料金フィールドに記録されたライドリーダが単独乗車する場合の料金を取得する。紹介ＣＰＵ４１は、ステップＳ７５５で算出したライドリーダの負担する費用が、単独乗車する場合の料金よりも安いか否かを判定する（ステップＳ７５６）。

安いと判定した場合（ステップＳ７５６でＹＥＳ）、紹介ＣＰＵ４１は、リクエストＤＢ５２の料金フィールドに記録されたライドフレンドが単独乗車する場合の料金を取得する。紹介ＣＰＵ４１は、ステップＳ７５５で算出したライドフレンドの負担する費用が、単独乗車する場合の料金よりも安いか否かを判定する（ステップＳ７５７）。安いと判定した場合、紹介ＣＰＵ４１は処理を終了する。

ライドリーダの費用が安くならないと判定した場合（ステップＳ７５６でＮＯ）、または、ライドフレンドの費用が安くならないと判定した場合（ステップＳ７５７でＮＯ）、紹介ＣＰＵ４１は、第２レコードに対応するユーザがライドリーダであるか否かを判定する（ステップＳ７５８）。

ライドリーダでないと判定した場合（ステップＳ７５８でＮＯ）、紹介ＣＰＵ４１は、ステップＳ７５１で抽出した２つのレコードのうちの第２レコードに対応するユーザがライドリーダであり、第１レコードに対応するユーザがライドフレンドであると判定する（ステップＳ７５９）。紹介ＣＰＵ４１は、ステップＳ７５３に戻る。

ライドリーダであると判定した場合（ステップＳ７５８でＹＥＳ）、紹介ＣＰＵ４１はステップＳ７５１に戻る。

紹介ＣＰＵ４１は、相乗りが終了した後に、メール等の手段によりユーザにアンケートを行ない、相乗り相手に関する評価を取得して、ユーザＤＢ５１の評価フィールドに記録する。紹介ＣＰＵ４１は、相乗りが終了した後に、タッチパネル２５１およびタッチパネル２５２にアンケート画面を表示させてユーザにアンケートを行なっても良い。ユーザアンケートによる評価の取得は、従来から行なわれているため、詳細については省略する。

タクシー相乗りシステム１０は、相乗り相手に問題がある場合に通報する機能を有しても良い。図１５は、情報処理装置２０が表示する通報画面を示す説明図である。図１０を使用して説明した画面に、複数の通報ボタン６７が配置されたウィンドウがポップアップ表示されている。通報ボタン６７は、支払問題ボタン６７１、行動問題ボタン６７２、および、その他通報ボタン６７３を含む。

問題があると判断したユーザは、図示を省略するメニューボタンを操作して、通報ボタン６７を表示させる。ユーザは、通報ボタン６７を適宜操作して、問題に関する報告を入力できる。ＣＰＵ２１は、ユーザから入力された報告を取得して、紹介ＣＰＵ４１に送信する。紹介ＣＰＵ４１は、受信した報告を記録する。

タクシー相乗りシステム１０の運営者は、報告を閲覧して、関係者への事実確認、悪質なユーザの登録抹消等の、適切な対応を行なえる。また、報告機能があること自体が、ユーザにとっての抑止力となり、相乗り相手に不快感を与えることを防止できる。

本実施の形態によると、１台のタクシーに相乗りすることにメリットのある乗客同士のマッチングを行なうタクシー相乗りシステム１０を提供できる。相乗りするユーザ同士は、図１１を使用して説明したチャットまたは音声通話を介して、相互に相手を確認し、安全な相手であると判断した上で、１台のタクシーに相乗りできる。

本実施の形態によると、図１に示すように長蛇の列になったタクシー乗り場において、複数のユーザが１台のタクシーに相乗りすることにより、タクシー乗り場で並んでいる全乗客の平均待ち時間を削減できる。相乗りにより、タクシー１台ごとの走行距離は増加するため、タクシーの営業効率が高くなる。

タクシーに乗車する前に、相乗り相手とのマッチングおよび相手との合流を行なえるため、タクシー会社側およびドライバに負担を掛けずに、タクシー相乗りシステム１０を提供できる。

一方のユーザが乗車したタクシーに、他方のユーザが途中から乗車しても良い。途中乗車するユーザは、タクシー乗り場まで徒歩で移動せずに、タクシーに乗車できる。図１６Ａおよび図１６Ｂは、途中乗車する場合のタクシー相乗りシステム１０の料金の概要を説明する説明図である。図１６Ａおよび図１６Ｂにおいて、料金および所要時間は、いずれも説明のための例示であり、これに限定されるものではない。

なお、途中乗車する際のマッチングのタイミングとしては、両方のユーザが相乗りをする前にマッチングが完了し、その後、一方のユーザが先に乗車し、途中で他方のユーザが乗車する場合の他、一方のユーザが乗車中に、マッチングが成立し、他方のユーザが途中から相乗りをする場合の両方が含まれる。

図１６Ａは、ユーザＩおよびユーザＫが、それぞれ単独でタクシーに乗車する場合の料金および所要時間を示す。ユーザＩは、Ｄ社前からＢ駅まで乗車する。タクシー料金は２５７０円、所要時間は２３分間である。ユーザＫはＡ駅からＣ駅まで乗車する。タクシー料金は２８９０円、所要時間は２５分間である。

図１６Ｂは、ユーザＩおよびユーザＫが１台のタクシーに相乗りした場合の料金および所要時間を示す。ユーザＫを乗せたタクシーは、Ａ駅からＤ社前まで走行する。Ｄ社前で、ユーザＩが乗車する。Ｄ社前からＢ駅まで、ユーザＩとユーザＫとが相乗りする。ユーザＩがＢ駅で途中下車する。Ｄ社前からＢ駅までの所要時間は、ユーザＩが単独で乗車した場合と同様に、２３分間である。

紹介サーバ４０は、ユーザＩのアカウントから、相乗り区間に対応する第１タクシー料金である１２８５円に、ユーザＩにかかる手数料である第１手数料３２１円を加算した１６０６円に相当する債権を差し引く。すなわち、相乗りにおいてユーザＩが負担する第１費用は１６０６円であり、単独で乗車した場合の料金である２５７０円よりも安い。

紹介サーバ４０は、ユーザＩのアカウントから支払われた第１タクシー料金１２８５円をユーザＫのアカウントに追加するとともに、ユーザＫにかかる手数料である第２手数料３２１円をユーザＫのアカウントから差し引く。すなわち、紹介サーバ４０は、第１タクシー料金１２８５円から第２手数料３２１円を差し引いた９６４円に相当する債権を、ユーザＫのアカウントに追加する。

タクシーはＢ駅からＣ駅まで走行する。ユーザＫは、Ｃ駅で下車する際に、Ａ駅からＢ駅を経由してＣ駅までの第２タクシー料金３５３０円を支払う。所要時間は、３２分間である。相乗りにおいてユーザＫが負担する第２費用は、第２タクシー料金３５３０円と、タクシー相乗りシステム１０を介してユーザＩから受け取った９６４円との差額の２５６６円であり、単独で乗車した場合の料金である２８９０円よりも安い。

なお、先に乗車したユーザＫが、途中下車しても良い。ユーザＩとユーザＫとが、同じ場所で下車しても良い。

タクシーの乗車定員の範囲内で、３人以上のユーザが１台のタクシーに相乗りしても良い。それぞれのユーザが異なる場所で乗車および下車しても良い。この場合、相乗り開始後に追加で相乗りするユーザを受け入れる場合には、乗車中のユーザ全員の同意が必要である。

相乗りするユーザ同士の実名を開示せず、ニックネームでやりとりするため、ユーザ同士のプライバシーを守ることができる。また、ユーザ同士では現金をやりとりしないため、金銭トラブルの発生を防止できる。

紹介ＣＰＵ４１は、評価フィールドに蓄積したユーザの評価に基づいて、評価の高いユーザを優先的にマッチングしても良い。このようにすることにより、本システム自体の評価を高めて、ユーザを増やすことができる。

紹介ＣＰＵ４１は、評価フィールドに蓄積したユーザの評価に基づいて、評価の高いユーザの紹介料を安く、評価の低いユーザの紹介料を高く設定しても良い。各ユーザに、相乗り相手に対して好印象を与える動機付けが行なわれる。このようにすることにより、本システム自体の評価を高めて、ユーザを増やすことができる。

紹介ＣＰＵ４１は、評価の高いユーザと相乗りしたユーザの紹介料も安く設定しても良い。評価の高いユーザとのマッチングを積極的に受け入れる動機付けが行なわれる。

紹介ＣＰＵ４１は、評価の高いユーザが乗車した場合にタクシー料金が減額されるようにしても良い。たとえば、評価の高いユーザが相乗りをした場合に、紹介ＣＰＵ４１はタクシー料金が割引されるクーポンを発行する。評価の高いユーザに、優越感と満足感とを感じさせることにより、本システムを繰り返し利用する動機付けが行なわれる。

ライドフレンドのアカウントから債権を差し引く代わりに、第三者の決済サービスを介して、ライドフレンドから料金を徴収しても良い。このようにする場合、ユーザＤＢ５１は、各ユーザの口座情報等の決済情報を記録するフィールドを有する。ネットワークを介して即時決済を行なうサービスは公知であるため、詳細については省略する。

相乗りによるメリットは、タクシーに単独乗車する場合に比べて費用が安くなることに限定しない。紹介ＣＰＵ４１は、たとえば、タクシーの待ち時間が短くなること、タクシーの乗車経路が短くなること、または、タクシーの乗車時間が短くなることなどに基づいて、マッチングを行なうか否かを判定しても良い。

タクシー会社と、本実施の形態のタクシー相乗りシステム１０の運営者とが提携して、タクシー相乗りシステム１０の利用者が支払う料金を、タクシー相乗りシステム１０が算定する費用としても良い。たとえば、タクシー相乗りシステム１０が事前に算出した出発地からライドリーダの下車地までの予測費用を、ライドリーダが下車時に支払う確定費用に定めても良い。この場合、確定費用は、本実施の形態のタクシー相乗りシステム１０が算定する算定費用の一例である。

タクシードライバが経験・知識等を活かして地図サーバ４９が算出した経路よりも近道のルートで目的地に到着した場合、タクシードライバはメータ料金よりも高い確定料金の支払を受けられる。ライドリーダは、地図サーバ４９が算出したルートよりも早く目的地に到着できる。

ライドフレンドおよびライドリーダが、それぞれタクシー料金を直接支払っても良い。たとえば、ライドフレンドは図１２において「Ｋｏさんへ支払」と記載されたフレンド料金をタクシーに直接支払う。ライドリーダは、下車時に実際のタクシー料金からフレンド料金を差し引いた金額をタクシーに直接支払う。

前述の通り、タクシー会社と、本実施の形態のタクシー相乗りシステム１０の運営者とが提携して（タクシー会社はタクシー相乗りシステム１０が提示する金額がタクシー代として支払われることを了承する）、ライドリーダとライドフレンドとの双方がタクシー相乗りシステム１０が算定するそれぞれの負担する金額を、あるいはライドリーダーがタクシー相乗りシステム１０が算定するタクシー代全額を、支払っても良い。

ライドリーダおよびライドフレンドは、タクシー料金の支払いに現金、クレジットカードその他任意の支払手段を使用できる。ライドリーダとライドフレンドとが、それぞれ異なる支払手段を使用してもよい。

本実施の形態のタクシー相乗りシステム１０は、バス、自家用乗用車、トラック、オートバイ、または、自転車等の任意の乗り物の乗り合いに使用されても良い。その場合、たとえばガソリン代および高速料金等の乗り物運用コストを、タクシーの料金の代わりに使用する。ドライバの労力を任意の手法で算定してコストに加えても良い。乗り物の維持費を任意の手法で算定してコストに加えても良い。

紹介ＣＰＵ４１は、それぞれのユーザの降車地点または乗車地点に関する地域情報を、情報処理装置２０に送信しても良い。地域情報は、たとえば近所にある店舗のクーポン、観光スポット情報、天気予報または交通情報等の、地域に関連する任意の情報である。

たとえば、紹介ＣＰＵ４１は、ユーザが降車する直前に、降車地点に関する最新の地域情報を情報処理装置２０に送信する。ユーザは、タクシーを降車後に、受信した最新情報を活用できる。紹介ＣＰＵ４１は、ユーザが乗車した直後に地域情報を送信しても良い。ユーザは、タクシー乗車中に送信された情報を閲覧して、降車後の行動を計画できる。

［実施の形態２］
本実施の形態は、各ユーザが相乗りを拒否する条件を登録できるタクシー相乗りシステム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図１７は、相乗り条件ＤＢのレコードレイアウトを説明する説明図である。相乗り条件ＤＢは、ユーザＩＤフィールドおよび条件フィールドを有する。ユーザＩＤフィールドには、ユーザＩＤが記録されている。条件フィールドには、各ユーザが相乗りを拒否する条件、すなわち、相乗りする相手をフィルタリングする条件が記録されている。たとえば図１７の１番目のレコードに示すように、特定のユーザＩＤを条件フィールドに記録することにより、当該ユーザとのマッチングを避けることができる。ユーザは、性別、他のユーザからの評価、タクシー相乗りシステム１０の利用実績等に基づいて、不可条件を設定できる。

図１８は、実施の形態２のマッチングのサブルーチンの処理の流れを説明するフローチャートである。図１８に示すサブルーチンは、図１４を使用して説明したサブルーチンの代わりに使用されるサブルーチンである。

紹介ＣＰＵ４１は、リクエストＤＢ５２から、乗車地が同一または近接する２つのレコードを抽出する（ステップＳ７５１）。紹介ＣＰＵ４１は、ステップＳ７５１で抽出したレコードのユーザＩＤフィールドに記録されたユーザＩＤをキーとして相乗り条件ＤＢを検索し、抽出されるレコードの有無を判定する（ステップＳ７２１）。

一方のユーザＩＤについてレコードが抽出されたと判定した場合（ステップＳ７２１でＹＥＳ）、紹介ＣＰＵ４１は、他方のユーザＩＤにかかるユーザが条件フィールドに記録された条件に該当するか否かを判定する（ステップＳ７２２）。該当すると判定した場合（ステップＳ７２２でＹＥＳ）、紹介ＣＰＵ４１はステップＳ７５１に戻る。

相乗り条件ＤＢからレコードが抽出されないと判定した場合（ステップＳ７２１でＮＯ）、または、条件フィールドに記録された条件に該当しないと判定した場合（ステップＳ７２２でＮＯ）、紹介ＣＰＵ４１は、抽出した２つのレコードのうちの第１レコードに対応するユーザがライドリーダであり、第２レコードに対応するユーザがライドフレンドであると判定する（ステップＳ７５２）。以後の処理は、図１４を使用して説明したサブルーチンと同一であるため、説明を省略する。

本実施の形態によると、個々のユーザがマッチングを拒否する相手を設定できる。これにより、ユーザが安心して利用可能なタクシー相乗りシステム１０を提供できる。

マッチングをリクエストする都度、ユーザが不可条件の使用要否を設定できるようにしても良い。ユーザは、多くの人が並んでいてマッチングが成立する可能性が高いタクシー乗り場では不可条件を使用し、マッチングが成立する可能性が低い場所では不可条件を使用しない等、状況に応じて条件を変更できる。

マッチングをリクエストする都度、ユーザが不可条件を設定できるようにしても良い。ユーザは、その日の状況に応じて、適宜不可条件を変更できる。

相乗り条件ＤＢには、相乗り不可条件の代わりに、または、相乗り不可条件に加えて、相乗り希望条件が記録されていても良い。たとえば、年齢、性別、職業、趣味、または、お気に入りの場所等のユーザ属性に基づいて、相互の好みが合致する相手を優先的にマッチングすることができる。このようにする場合には、ユーザＤＢ５１にユーザ自身のユーザ属性を記録するフィールドが設けられる。

相乗り条件ＤＢおよびユーザＤＢ５１には、カレンダー情報、フライト情報、宿泊情報、勤務先情報または学校情報等のユーザ属性が記録されていても良い。たとえば、カレンダー情報に基づいて同じイベントに参加するユーザを優先的にマッチングできる。フライト情報に基づいて、同じフライトに登場するユーザを優先的にマッチングできる。

紹介ＣＰＵ４１は、ステップＳ７５６で効果ありと判定した場合にマッチングしたユーザの組合せを主記憶装置４２または補助記憶装置４３に一時的に保存し、ステップＳ７５１で一方のユーザを変更した組合せを抽出しても良い。一人のユーザに対して、複数の相乗り相手を抽出した後に、紹介ＣＰＵ４１は、たとえばユーザ間の距離、事前に登録したお気に入りの場所、過去の乗車履歴、または、ユーザ属性に基づいてそれぞれの相乗り相手を評価する。紹介ＣＰＵ４１は、評価の高いユーザの組合せをマッチングする。

たとえば、趣味の合うユーザ同士をマッチングすることにより、相乗り乗車中に会話が弾み、新たな交友関係を築けるマッチングシステムを提供できる。

前述のお気に入りの場所は、過去のユーザの乗車履歴に基づいて自動的に相乗り条件ＤＢに記録されても良い。

ユーザＤＢ５１には、ユーザの許容条件が記録されていても良い。たとえば、タクシーに乗車する場所または時刻を相乗り相手の意向に合わせる、相手の分の手数料を負担する等の条件が、ユーザＤＢ５１に追加するフィールドに記録される。

紹介ＣＰＵ４１は、相乗り相手が許容条件を受け入れた場合の条件で、相乗り相手を抽出する。許容条件を設定したユーザは、マッチングが成立しやすくなる。たとえば荒天でタクシー乗り場が混雑している場合に、ユーザは許容条件を設定することにより、早くマッチングが成立して、乗車できると期待できる。

本実施の形態のプログラムは、図７を使用して説明したマッチング依頼ボタン７１１の選択を待たずにバックグラウンドで動作しても良い。たとえば、紹介ＣＰＵ４１またはＣＰＵ２１は、ユーザの過去の乗車履歴、属性、現在地、現在時刻、曜日、天候、および、イベント情報等に基づいて、ＡＩ（Artificial Intelligence）によりタクシーの必要性を判定して、マッチングを行ない、表示部２６を介してユーザに通知しても良い。

たとえば、飲み屋で飲んでいて終電を逃しそうなユーザが、マッチングの通知を見てタクシーに乗ることにより、終電に間に合う時刻に駅に到着できる。また、終電を逃して残業をしているユーザが、マッチングの通知を見ることにより仕事を終えるきっかけとすることができる。

ＣＰＵ２１は、ユーザが情報処理装置２０を用いて購入したチケット等の情報に基づいてマッチングを行なっても良い。たとえば、チケットを購入した飛行機に乗って空港に到着したユーザに、自宅方面に向かうタクシーのマッチングが通知される。チケットを購入したサッカーの試合に行くユーザが、スタジアムの最寄り駅への到着する前後に、スタジアムに行くタクシーのマッチングが通知される。

ＣＰＵ２１は、ユーザが使用するスケジュール管理ソフトのデータ等に基づいてマッチングを行なっても良い。たとえば新幹線に乗る予定のユーザに、現在地から乗車駅に向かうタクシーのマッチング情報が通知される。

ＣＰＵ２１は、ユーザの過去の行動履歴と現在位置等に基づいてマッチングを行なっても良い。たとえば頻繁にサッカー観戦に行くユーザが、試合開催日にスタジアムの最寄り駅に到着する前後に、スタジアムに行くタクシーのマッチングが通知される。

マッチングに対するユーザの応答を蓄積して学習することにより、ユーザのニーズに精度良く予測して、自動的にマッチングを開始するＡＩを有するタクシー相乗りシステム１０を実現できる。

マッチング依頼ボタン７１１の選択を受け付けたが、所定の時間内にマッチングできなかったユーザを、マッチング相手の候補に加えても良い。この場合、ＣＰＵ２１は、ユーザからマッチングを待つ待ち時間の入力を受け付けても良い。待ち時間が長くなってもタクシーに安く乗りたいユーザの要望に対応するタクシー相乗りシステム１０を提供できる。

図１９は、バックグラウンドでマッチングを行なう情報処理装置２０の変形例が表示する画面を示す説明図である。図１９に示す画面は、図７を使用して説明した画面の代わりに第２情報処理装置２０２の表示部２６２に表示される入力画面を示す。

乗車地名欄６１１の代わりに、理由欄６１５が表示されている。ユーザは、理由欄６１５に表示された「Ｊ航空０１２便」でＨ空港に到着して、Ｃ駅までタクシーに相乗りすることを希望している。

紹介ＣＰＵ４１は、同じ飛行機でＨ空港に到着するユーザを優先してマッチングする。仮に、飛行機の到着時刻に遅れが生じた場合であっても、滞りなく相乗りできるタクシー相乗りシステム１０を提供できる。

紹介ＣＰＵ４１は空港から提供されているフライト情報を参照して、ユーザが搭乗するフライトの遅れ等を検出できる。仮に一方のユーザの到着時刻に遅れが生じた場合、紹介ＣＰＵ４１は予定通りに到着したユーザに対して、新たな相乗り相手を提示しても良い。

たとえば理由欄にスポーツの試合予定等が入力されてもよい。同じ試合を観戦中のユーザとマッチングされている場合、観戦中の試合終了時刻が予定よりも遅れた場合、または早まった場合であっても、滞りなく相乗りできるタクシー相乗りシステム１０を提供できる。

［実施の形態３］
本実施の形態は、相乗りする相手を拡張現実（ＡＲ：Augmented Reality）により表示するタクシー相乗りシステム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図２０Ａおよび図２０Ｂは、実施の形態３のタクシー相乗りシステム１０の概要を説明する説明図である。図２０Ａに示すタクシー乗り場の行列が、情報処理装置２０に設けられたカメラにより撮影されて、表示部２６に表示されている。紹介ＣＰＵ４１から取得したユーザＩの現在地の座標、および、情報処理装置２０に内蔵するＧＰＳ２８、傾きセンサ等の情報に基づいて、画像上のユーザＩに星型のマーカ７３が表示されている。リアルタイムで撮影した画像と、マーカ７３とを重畳して表示する方法については、公知であるため、説明を省略する。

本実施の形態によると、ユーザはマッチングされた相手を容易に発見して、合流できる。また、誤ってマッチング相手とは違う人に声を掛けてしまうトラブルを防止できる。

［実施の形態４］
本実施の形態は、タクシー乗り場以外の場所から相乗り乗車する場合に、タクシーを呼び出すタクシー相乗りシステム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図２１および図２２は、実施の形態４の情報処理装置２０が表示する画面を示す説明図である。図２１は、図１０の代わりに第１情報処理装置２０１の表示部２６１に表示される画面を示す。開始ボタン７１７の下に、迎車呼出ボタン７１８が表示されている。

図２２は、迎車呼出ボタン７１８が選択された場合に表示部２６に表示される画面を示す。「禁煙車」、「喫煙車」、「女性ドライバ」、「男性ドライバ」、「車椅子可」「Avairable in English（英語可）」、および、「有中文（中国語可）」等、乗りたいタクシーの属性（タクシードライバの属性を含んでもよい）を選択する属性ボタン７２１が複数配置されている。ユーザは、希望するタクシーの属性に対応する属性ボタン７２１を選択した後に送信ボタン７２３を選択する。

なお図２２に示す属性は一例である。図示する項目の他に、たとえば、ドライバの年齢、個人タクシーであるか否か、タクシー会社名、ドライバの趣味、社内のにおいの有無、希望する座席の指定、無線ＬＡＮ（Local Area Network）サービスの有無、軽食提供サービスの有無等を選択できるようにしても良い。

タクシー相乗りシステム１０は、ドライバに対するユーザからの評価を収集しても良い。ユーザからの評価を収集するシステムは、従来から使用されているため、説明を省略する。評価を収集する場合、過去に乗車したユーザからの評価点のレベルの高低を選択できるようにしても良い。

タクシー相乗りシステム１０は、ユーザに対するドライバからの評価を収集しても良い。ドライバによる評価は、たとえばユーザＤＢ５１の評価フィールドに記録される。他のユーザからの評価とドライバからの評価とが合算して記録されても良く、分けて記録されても良い。

第１ＣＰＵ２１１は、たとえばタクシー会社に設置された配車サーバに、乗車位置、ユーザＩの氏名、およびユーザが選択した属性を送信して、配車を要求する。配車サーバ、または、タクシー会社の配車オペレータは、指定された属性に適合するタクシーに対して、車両無線等を用いて乗車位置に向かうように指示する。

また、配車サーバは、属性に適合するタクシーが存在する場合に、直ちに、タクシーに対して乗車位置に向かうように指示するのではなく、次のようにしてもよい。すなわち、配車サーバは、ユーザＩに対し、属性に適合するタクシーの情報を送信し、ユーザＩは、当該タクシーの情報に基づいて、選択したタクシーの配車要求を配車サーバに送信し、配車サーバは、当該タクシーに対して、乗車位置に向かう指示を送信してもよい（配車サーバは、ユーザＩに対し、属性に適合するタクシーの情報を複数送信した場合、ユーザＩは、当該複数のタクシーの中から、選択したタクシーの配車要求を配車サーバに送信することとしてもよい。）。

ここで、属性に適合するタクシーの情報は、タクシーの属性を含んでもよい。また、ユーザＩの第１情報処理装置２０１の画面に、地図が表示され、当該地図上に、属性に適合するタクシーの位置に関する情報が表示され、ユーザＩが選択したタクシーの情報（位置以外の情報を含む）が更に表示されることとしてもよい。

指定された属性に適合するか否かは、あらかじめ配車サーバに記録されたデータベースに基づいて判定できる。データベースに、ドライバのＳＮＳ（Social Network System）のアカウントが登録されている場合、ＳＮＳのプロフィールに登録された事柄に基づいて、属性を判定しても良い。

第１情報処理装置２０１が通話機能を有する場合、第１ＣＰＵ２１１は、タクシー会社に電話を掛けて、音声合成により車位置、ユーザＩの氏名、およびユーザが選択した属性を伝達して、配車を要求しても良い。

本実施の形態によると、タクシー乗り場以外の場所からでも、容易に相乗りできるタクシー相乗りシステム１０を提供できる。

本実施の形態によると、好みに合うタクシーを呼び出して相乗りできるタクシー相乗りシステム１０を提供できる。

［実施の形態５］
本実施の形態は、相乗りを開始した後に、料金分担を修正できるタクシー相乗りシステム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図２３は、実施の形態５の情報処理装置２０が表示部２６に表示する精算条件画面を示す説明図である。図２３に示す画面は、相乗り乗車を開始した後に、ユーザが図示を省略するメニューボタン等を操作して、料金分担の修正を指示した場合に表示される画面である。

図２３の上側には、ライドフレンドが単独乗車した場合の予測費用、相乗り負担額、手数料およびライドフレンドが支払済の金額が表示されている。図２３の下側には、ライドリーダが単独乗車した場合の予測費用、相乗り負担額、手数料、受取済の金額、下車時の予測費用、および、ライドリーダの予測負担額が表示されている。

図２３の最下部には、修正中止ボタン７２４および修正承認ボタン７２５が表示されている。図２３においては、修正承認ボタン７２５は選択不可能である。

ユーザは、タッチパネル２５１を操作して、下線で示すライドフレンドの相乗り負担額およびライドリーダの下車時の予測費用を変更できる。ライドフレンドの相乗り負担額が変更された場合、斜体で示すライドフレンド項目の支払額、ライドリーダの項目の相乗り負担額、受取額、および予測負担額が自動的に再計算されて、表示される。ライドリーダの下車時料金が変更された場合、ライドリーダの予測負担額が自動的に再計算されて、表示される。

変更可能ないずれかの項目が変更された場合、修正承認ボタン７２５が選択可能な状態になる。一方のユーザが修正承認ボタン７２５を選択した場合、他方のユーザの表示部２６に修正後の情報が表示される。他方のユーザも修正承認ボタン７２５を選択した場合、ライドリーダのアカウントと、ライドフレンドのアカウントとの間で、精算済の金額との差額に対応する債権が移動する。以上により、乗車前に合意した分担を、相乗り開始後に変更できる。

図２４は、実施の形態５のプログラムの処理の流れを説明するフローチャートである。ステップＳ５０６およびステップＳ６０６までは、図１３を使用して説明した実施の形態１のフローチャートと同一であるため説明を省略する。

両方のユーザによる開始ボタン７１７の選択を受け付けた後に、紹介ＣＰＵ４１は両ユーザのアカウントの債権を精算する（ステップＳ７３１）。すなわち、本実施の形態においては、図１０および図１１を使用して説明した画面において開始ボタン７１７の選択を受け付けた後、図１２を使用して説明した画面を表示せずに、債権の精算を行なう。

第１ＣＰＵ２１１は、図示を省略する債権の修正を指示するボタンの選択を受け付けたか否かを判定する（ステップＳ５２１）。受け付けたと判定した場合（ステップＳ５２１でＹＥＳ）、第１ＣＰＵ２１１は修正計算のサブルーチンを起動する（ステップＳ５２２）。修正計算のサブルーチンは、ライドリーダとライドフレンドとの負担額を修正するサブルーチンである。修正計算のサブルーチンの処理の流れは後述する。

所定の時間、たとえば、ライドリーダが下車地に到着するまでの予測時間の数倍の時間が経過しても、修正を指示するボタンの選択を受け付けない場合（ステップＳ５２１でＮＯ）、第１ＣＰＵ２１１は処理を終了する。

第２ＣＰＵ２１２は、図示を省略する債権の修正を指示するボタンの選択を受け付けたか否かを判定する（ステップＳ６２１）。受け付けたと判定した場合（ステップＳ６２１でＹＥＳ）、第１ＣＰＵ２１１は修正計算のサブルーチンを起動する（ステップＳ６２２）。修正計算のサブルーチンは、ステップＳ５２２で起動するサブルーチンと同一のサブルーチンである。

所定の時間、たとえば、ライドリーダが下車地に到着するまでの予測時間の数倍の時間が経過しても、修正を指示するボタンの選択を受け付けない場合（ステップＳ６２１でＮＯ）、第２ＣＰＵ２１２は処理を終了する。

図２５は、修正精算のサブルーチンの処理の流れを説明するフローチャートである。修正計算のサブルーチンは、ライドリーダとライドフレンドとの負担額を修正するサブルーチンである。図２５においては、第１ＣＰＵ２１１が修正計算のサブルーチンを起動した場合を例にして説明する。

第１ＣＰＵ２１１は、表示部２６１に図２３を使用して説明した精算条件画面を表示する（ステップＳ５３１）。第１ＣＰＵ２１１は、図２３に下線で示す変更可能な項目の変更を受け付ける。第１ＣＰＵ２１１は、修正承認ボタン７２５の選択を取得する（ステップＳ５３２）。第１ＣＰＵ２１１は、紹介ＣＰＵ４１に修正内容を送信する（ステップＳ５３３）。なお、修正承認ボタン７２５より先に修正中止ボタン７２４の選択を取得した場合、第１ＣＰＵ２１１は処理を終了する。

紹介ＣＰＵ４１は修正内容を受信する（ステップＳ７４１）。紹介ＣＰＵ４１は、修正内容を第２ＣＰＵ２１２に送信する（ステップＳ７４２）。第２ＣＰＵ２１２は、修正内容を受信する（ステップＳ６３１）。第２ＣＰＵ２１２は、図２３を使用して説明した画面と同様の画面を表示部２６２に表示する。ただし、表示部２６２に表示される画面においては、金額の修正は受け付けられない。

第２ＣＰＵ２１２は、修正中止ボタン７２４または修正承認ボタン７２５の選択を受け付ける（ステップＳ６３２）。第２ＣＰＵ２１２は、受け付けた選択を紹介ＣＰＵ４１へ送信する（ステップＳ６３３）。紹介ＣＰＵ４１は、送信された選択を受信する（ステップＳ７４３）。

紹介ＣＰＵ４１は、修正の承認を受け付けたか否かを判定する（ステップＳ７４４）。承認を受け付けたと判定した場合（ステップＳ７４４でＹＥＳ）、紹介ＣＰＵ４１は両ユーザのアカウントの債権を精算する（ステップＳ７４５）。すなわち、ライドリーダのアカウントと、ライドフレンドのアカウントとの間で、乗車前に精算した債権と、図２３の画面で受け付けた債権との差額を移動する。紹介ＣＰＵ４１は、マッチングＤＢ５３の該当するレコードの債権フィールドを修正する。

ステップＳ７４５の終了後、または、修正の承認を受け付けないと判定した場合（ステップＳ７４４でＮＯ）、紹介ＣＰＵ４１は第１ＣＰＵ２１１に処理の終了を通知する（ステップＳ７４６）。第１ＣＰＵ２１１は、終了時の内容、すなわちステップＳ５３３で送信した修正が承認されたか否かを表示する（ステップＳ５３４）。

本実施の形態によると、道路状況の変化によりライドリーダとライドフレンドとの間の負担に不均衡が生じた場合に、双方の合意により負担額を修正できるタクシー相乗りシステム１０を提供できる。

［実施の形態６］
本実施の形態は、それぞれのユーザがタクシー会社に料金を支払うタクシー相乗りシステム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図２６は、実施の形態６のタクシー相乗りシステム１０の料金の概要を説明する説明図である。図２Ａを使用して説明した場合と同様に、ユーザＩがＡ駅からＢ駅まで単独で乗車する場合のタクシー料金は２５７０円であり、ユーザＫがＡ駅からＣ駅まで単独で乗車する場合のタクシー料金は２８９０円である。

図２Ｂを使用して説明した場合と同様に、ユーザＩおよびユーザＫがＡ駅から１台のタクシーに相乗りする。ユーザＩがＢ駅で途中下車し、その後ユーザＫがＣ駅まで単独で乗車する。Ａ駅からＢ駅を経由してＣ駅までの第２タクシー料金は３５３０円である。

ユーザＩは、単独で乗車した場合の料金２５７０円の５０％相当の第１タクシー料金である１２８５円をタクシー会社に、第１手数料３２１円を紹介サーバ４０の運営者にそれぞれ支払う。すなわち、相乗りにおいてユーザＩが負担する第１費用は実施の形態２と同様に１６０６円である。

ユーザＫは、Ａ駅からＣ駅までの第２タクシー料金からユーザＩが支払った第１タクシー料金を差し引いた２２４５円をタクシー会社に、第２手数料３２１円を紹介サーバ４０の運営者にそれぞれ支払う。すなわち、相乗りにおいてユーザＩが負担する第１費用は実施の形態２と同様に２５６６円である。

ユーザは、いずれの支払いにもスマートフォンを使用した決済システム、クレジットカード、銀行振り込み、または、現金等の任意の手段を使用できる。以下では、小額決済システムを使用する場合を例にして説明する。

ここで、小額決済システムの概要を説明する。小額決済システムは、クレジットカード決済または銀行振込等に比べて低額な手数料で、金銭のやりとりを行なえるシステムである。たとえば、ユーザが事前にチャージした金銭の中から、送金先に金銭を送るサービス、ユーザが事前に登録したクレジットカードまたは銀行口座から金銭を引き落として送金先に送るサービス等、様々なサービスが提供されている。

ユーザは、スマートフォンにインストールした小額決済サービスのアプリを使用して、または、小額決済サービスのＷＥＢサイトにログインした状態で、送金先のアカウントと送金額とを指定することにより送金を行なえる。

本実施の形態においては、後述するように送金先のアカウントと送金額とがユーザのスマートフォンに通知される。スマートフォンにインストールされた小額決済サービスのアプリをユーザが操作することにより、送金先のアカウントあてに送金が行なわれる。

図２７は、実施の形態６のユーザＤＢ５１のレコードレイアウトを説明する説明図である。本実施の形態のユーザＤＢ５１は、ユーザＩＤと、ニックネームと、登録情報と、決済情報と、利用履歴と評価とを関連づけた、アカウント情報を記録するＤＢである。

ユーザＤＢ５１は、ユーザＩＤフィールド、ニックネームフィールド、登録情報フィールド、決済情報フィールド、利用履歴フィールドおよび評価フィールドを有する。決済情報フィールド以外は、図４を使用して説明した実施の形態１のユーザＤＢ５１と同一であるため、説明を省略する。

決済情報フィールドには、ユーザが事前に登録した決済システムの名称、アカウント情報等が記録されている。決済情報フィールドに記録された情報は、登録時に認証が行なわれ、決済処理に使用できることを確認済である。

図２８および図２９は、実施の形態６のプログラムの処理の流れを説明するフローチャートである。ステップＳ５０７、ステップＳ７０７およびステップＳ６０７までは、図１３を使用して説明した実施の形態１のフローチャートと同一であるため説明を省略する。

相乗りに合意した両ユーザは、乗車するタクシーを見つけてシェアを開始する際に、図１２を使用して説明した画面の承認ボタン７２０を選択する。

第１ＣＰＵ２１１は、承認ボタン７２０の選択を受け付けた場合に、タクシー相乗りシステム１０の運営者宛てに第１手数料を送金する処理を行なう（ステップＳ５６１）。第１ＣＰＵ２１１と決済システムとの間で行なわれる処理については、説明を省略する。

第１ＣＰＵ２１１は、乗車したタクシーに固有に付与されたタクシーＩＤを取得する（ステップＳ５６２）。なお、タクシーＩＤには、タクシー会社を示す情報が含まれている。タクシーＩＤは、たとえば２次元バーコードでタクシー社内に掲示されている。ユーザは、第１情報処理装置２０１に搭載されたバーコードリーダ機能を用いて、第１ＣＰＵ２１１にタクシーＩＤを読み取らせる。

タクシーＩＤは、タクシーのナンバープレートに紐付けられていてもよい。ユーザは、タクシーに乗車する前に第１情報処理装置２０１に搭載されたカメラ機能を用いて、第１ＣＰＵ２１１にタクシーＩＤを読み取らせるか、または、手動で入力する。第１ＣＰＵ２１１は、タクシーＩＤを紹介サーバ４０に送信する（ステップＳ５６３）。

第２ＣＰＵ２１２は、承認ボタン７２０の選択を受け付けた場合に、タクシー相乗りシステム１０の運営者宛てに第２手数料を送金する処理を行なう（ステップＳ６６１）。第２ＣＰＵ２１２は、乗車したタクシーに固有に付与されたタクシーＩＤを取得する（ステップＳ６６２）。第２ＣＰＵ２１２は、タクシーＩＤを紹介サーバ４０に送信する（ステップＳ６６３）。

紹介ＣＰＵ４１は、それぞれのユーザＩＤとタクシーＩＤとを関連づけて、補助記憶装置４３に一時的に記録する（ステップＳ７６２）。

タクシーが、第１情報処理装置２０１を持つユーザＩの下車地点に到着する。第１ＣＰＵ２１１は、出発地からライドフレンドであるユーザＩの下車地までのフレンド料金を紹介サーバ４０に送信する（ステップＳ５６４）。

フレンド料金は、たとえばユーザＩがタクシーメータを見て、手動で第１情報処理装置２０１に入力する。ユーザＩが、第１情報処理装置２０１に搭載されたカメラ機能を用いて撮影したタクシーメータの写真を、第１ＣＰＵ２１１が紹介サーバ４０に送信しても良い。第１ＣＰＵ２１１は、ＮＦＣ（Near Field Communication：近距離無線通信）または無線ＬＡＮ等を介して、タクシーメータからフレンド料金を取得しても良い。

紹介ＣＰＵ４１は、ユーザＩのユーザＩＤと、タクシーＩＤと、フレンド料金とを関連づけて、補助記憶装置４３に一時的に記録する（ステップＳ７６３）。

タクシーが、第２情報処理装置２０２を持つユーザＫの下車地点に到着する。第２ＣＰＵ２１２は、出発地からライドリーダであるユーザＫの下車地までの第２タクシー料金を紹介サーバ４０に送信する（ステップＳ６６４）。第２ＣＰＵ２１２が第２タクシー料金を取得する方法は、前述のフレンド料金と同様であるため説明を省略する。

紹介ＣＰＵ４１は、ユーザＫのユーザＩＤと、タクシーＩＤと、第２タクシー料金とを関連づけて、補助記憶装置４３に一時的に記録する（ステップＳ７６４）。紹介ＣＰＵ４１は、ユーザＩとユーザＫとがそれぞれ分担するタクシー料金を算出する（ステップＳ７６５）。

分担は、実施の形態１と同様にライドフレンドがフレンド料金の半額を負担し、残りの料金をライドリーダが負担する方式であっても、その他任意の方式であっても良い。たとえば、タクシー乗車中にユーザＩとユーザＫとで分担割合または分担額を決めて、紹介サーバ４０に送信しておいても良い。

紹介ＣＰＵ４１は、第１情報処理装置２０１および第２情報処理装置２０２に、それぞれのユーザが支払う料金を通知する（ステップＳ７６６）。具体的には、紹介ＣＰＵ４１は、ユーザＤＢ５１の決済情報フィールドに記録された決済情報に基づいて、ユーザが登録した決済システムを利用した決済に必要な情報を、第１情報処理装置２０１および第２情報処理装置２０２に通知する。紹介ＣＰＵ４１は、ステップＳ７０１に戻る。

第１ＣＰＵ２１１は、タクシー会社宛にユーザＩが負担する料金を送金する処理を行なう（ステップＳ５６５）。具体的には、第１ＣＰＵ２１１は、紹介ＣＰＵ４１から受信した時情報に基づいて決済サービスのアプリを起動して、送金先のアカウントと送金額とを表示させる。ユーザが、たとえば承認用のコードを入力するなどの操作を行なうことにより、決済が実行される。

第１ＣＰＵ２１１は処理を終了する。第２ＣＰＵ２１２は、タクシー会社宛にユーザＫが負担する料金を送金する処理を行なう（ステップＳ６６５）。第２ＣＰＵ２１２は処理を終了する。

ステップＳ７６６において、紹介ＣＰＵ４１は決済サービスを介して情報処理装置２０に対して、決済に必要な情報を送信しても良い。決済に必要な情報が情報処理装置２０に送信される経路は、決済サービスごとに異なっていてもよい。

なお、ユーザは、小額決済サービスの代わりに、クレジットカードを使用しても良い。クレジットカードの使用を希望するユーザについては、ユーザＤＢ５１の決済情報フィールドにクレジットカード決済に関する情報が記録されている。

ユーザがクレジットカード決済を希望する場合、ステップＳ７６６において、紹介ＣＰＵ４１は、ユーザＤＢ５１の決済情報フィールドに記録された決済情報に基づいて、ユーザが登録したクレジットカード会社に対して決済に必要な情報を通知する。紹介ＣＰＵ４１は、クレジットカード支払いの処理をした旨と金額とを、クレジットカード支払いを希望するユーザが使用する情報処理装置２０に通知する。紹介ＣＰＵ４１は、ステップＳ７０１に戻る。

クレジットカード会社とタクシー会社との間の契約に基づいて、クレジットカード会社からタクシー会社に対して、タクシー料金が支払われる。所定の期日に、クレジットカード会社からユーザに対してクレジット代金が請求され、ユーザからクレジットカード会社への支払いが行なわれる。

決済情報フィールドには、複数の決済手段が記録されており、ユーザが、本タクシー相乗りシステム１０を使用する都度、使用する決済手段を選択できても良い。

ユーザＩは、下車時に現金またはクレジットカード等の任意の手段により自分の負担する料金をドライバに支払っても良い。そのようにする場合には、ステップＳ５６４において第１ＣＰＵ２１１はフレンド料金とユーザＩが支払済の金額とを紹介サーバ４０に送信する（ステップＳ５６４）。ステップＳ５６５は実行されない。

マッチング時に算定された金額に基づいて、ユーザからタクシー会社への料金支払いが行なわれても良い。このようにする場合、ステップＳ５６４、ステップＳ６６４、および、ステップＳ７６３からステップＳ７６６は実行されない。ステップＳ５６５およびステップＳ６６５において、それぞれのＣＰＵ２１はマッチング時に紹介ＣＰＵ４１から受信した料金をタクシー会社に料金を送金する処理を行なう。

本実施の形態によると、ライドリーダとライドフレンドとの間で金銭授受を行なわず、ライドリーダおよびライドフレンドが、直接または決済代行会社を介してタクシー会社に料金を支払えるタクシー相乗りシステム１０を実現できる。

［実施の形態７］
本実施の形態は、それぞれのユーザからタクシー料金を預かり、一括してタクシー会社に料金を支払うタクシー相乗りシステム１０に関する。実施の形態６と共通する部分については、説明を省略する。

図３０は、実施の形態７のタクシー相乗りシステム１０の料金の概要を説明する説明図である。ユーザＩは、単独で乗車した場合の料金２５７０円の５０％相当の第１タクシー料金である１２８５円と、第１手数料３２１円との合計金額である１６０６円を紹介サーバ４０の運営者に支払う。

ユーザＫは、Ａ駅からＣ駅までの第２タクシー料金からユーザＩが支払った第１タクシー料金を差し引いた２２４５円と、第２手数料３２１円との合計金額である２５５６円を紹介サーバ４０の運営者に支払う。紹介ＣＰＵ４１は、Ａ駅からＣ駅までの第２タクシー料金３５３０円をタクシー会社に送金する。

図３１は、実施の形態７のプログラムの処理の流れを説明するフローチャートである。本プログラムの前半は、図２８に示す実施の形態６のプログラムの前半部分と同一であるため、フローチャートおよび説明を省略する。

相乗りに合意した両ユーザは、乗車するタクシーを見つけてシェアを開始する際に、図１２を使用して説明した画面の承認ボタン７２０を選択する。

第１ＣＰＵ２１１は、承認ボタン７２０の選択を受け付ける（ステップＳ５７１）。第１ＣＰＵ２１１は、乗車したタクシーに固有に付与されたタクシーＩＤを取得する（ステップＳ５７２）。第１ＣＰＵ２１１は、タクシーＩＤを紹介サーバ４０に送信する（ステップＳ５７３）。

第２ＣＰＵ２１２は、承認ボタン７２０の選択を受け付ける（ステップＳ６７１）。第２ＣＰＵ２１２は、乗車したタクシーに固有に付与されたタクシーＩＤを取得する（ステップＳ６７２）。第２ＣＰＵ２１２は、タクシーＩＤを紹介サーバ４０に送信する（ステップＳ６７３）。

紹介ＣＰＵ４１は、それぞれのユーザＩＤとタクシーＩＤとを関連づけて、補助記憶装置４３に一時的に記録する（ステップＳ７７２）。

タクシーが、第１情報処理装置２０１を持つユーザＩの下車地点に到着する。第１ＣＰＵ２１１は、出発地からライドフレンドであるユーザＩの下車地までのフレンド料金を紹介サーバ４０に送信する（ステップＳ５７４）。

紹介ＣＰＵ４１は、ユーザＩのユーザＩＤと、タクシーＩＤと、フレンド料金とを関連づけて、補助記憶装置４３に一時的に記録する（ステップＳ７７３）。

タクシーが、第２情報処理装置２０２を持つユーザＫの下車地点に到着する。第２ＣＰＵ２１２は、出発地からライドリーダであるユーザＫの下車地までの第２タクシー料金を紹介サーバ４０に送信する（ステップＳ６７４）。

紹介ＣＰＵ４１は、ユーザＫのユーザＩＤと、タクシーＩＤと、第２タクシー料金とを関連づけて、補助記憶装置４３に一時的に記録する（ステップＳ７７４）。紹介ＣＰＵ４１は、ユーザＩとユーザＫとがそれぞれ分担するタクシー料金を算出する（ステップＳ７７５）。紹介ＣＰＵ４１は、第１情報処理装置２０１および第２情報処理装置２０２に、それぞれのユーザが支払う料金を通知する（ステップＳ７７６）。

第１ＣＰＵ２１１は、タクシー相乗りシステム１０の運営者宛にユーザＩが負担する料金および第１手数料を送金する処理を行なう（ステップＳ５７５）。第１ＣＰＵ２１１は処理を終了する。第２ＣＰＵ２１２は、タクシー相乗りシステム１０の運営者宛にユーザＫが負担する料金および第２手数料を送金する処理を行なう（ステップＳ６７５）。第２ＣＰＵ２１２は処理を終了する。

紹介ＣＰＵ４１は、それぞれのユーザが登録済の決済サービスを介して入金が行なわれたことを確認する（ステップＳ７７７）。紹介ＣＰＵ４１は、タクシー会社宛に第２タクシー料金を送金する処理を行なう（ステップＳ７７８）。紹介ＣＰＵ４１は、ステップＳ７０１に戻る。

なお、タクシー相乗りシステム１０の運営者と、タクシー会社との間の協議により、ステップＳ７７８の処理を行なわず、たとえば月末にまとめて決済してもよい。

ユーザは、小額決済サービスの代わりに、クレジットカードを使用しても良い。クレジットカードの使用を希望するユーザについては、ユーザＤＢ５１の決済情報フィールドにクレジットカード決済に関する情報が記録されている。

ユーザがクレジットカード決済を希望する場合、ステップＳ７７６において、紹介ＣＰＵ４１は、ユーザが登録したクレジットカード会社に対して決済に必要な情報を通知する。紹介ＣＰＵ４１は、クレジットカード支払いの処理をした旨と金額とを、クレジットカード支払いを希望するユーザが使用する情報処理装置２０に通知する。

ステップＳ７７７において、紹介ＣＰＵ４１はクレジットカード会社から利用承認が得られたことを確認し、ステップＳ７７８に進む。

本実施の形態によると、ライドリーダとライドフレンドとの間で金銭授受を行なわず、ライドリーダおよびライドフレンドが、直接または決済代行会社を介してタクシー会社に料金を支払えるタクシー相乗りシステム１０を実現できる。

［実施の形態８］
本実施の形態は、料金を多く負担する等の料金に関する条件をユーザが提示できるタクシー相乗りシステム１０に関する。実施の形態１と共通する部分については、説明を省略する。

図３２は、条件ＤＢのレコードレイアウトを説明する説明図である。条件ＤＢは、ユーザが許容可能な条件の名前と内容とを関連づけて記録するＤＢである。条件ＤＢは、条件名フィールド、費用フィールド、時間フィールドおよびその他フィールドを有する。

条件名フィールドには、ユーザに提示する条件名が記録されている。費用フィールドには、ユーザが支払う費用に関する条件が記録されている。時間フィールドには、所用時間に関する条件が記録されている。その他フィールドには、その他の条件が記録されている。「−」は、空欄であることを意味する。条件ＤＢは、一つの条件について一つのレコードを有する。

具体例を説明する。一番上の「設定なし」は、実施の形態１と同様に特段の条件が設定されていない場合を示す。手数料とタクシー料金とを合算してユーザが支払う費用が、通常のタクシー料金未満である場合に、マッチングが行なわれる。

２番目の「全額支払い可能」は、相乗り相手の費用を全額負担して相乗りする条件を示す。ユーザが支払う費用が、通常のタクシー料金の３倍以下で、所用時間が通常の所用時間と同等である場合に、マッチングが行なわれる。たとえば、タクシー乗り場が長蛇の列になっている場合に、行列の前の方にいるユーザとマッチングできれば、早く乗車できる。そのために、通常タクシー料金の３倍程度の費用を支払っても構わないと考えるユーザが選択する条件である。

３番目の「１０００円プラス」は、タクシー料金のうち１０００円を負担して、残りを実施の形態と同様に相乗り相手と負担する条件を示す。ユーザが支払う費用が、通常のタクシー料金未満で、所用時間が通常の１．１倍程度までである場合に、マッチングが行なわれる。

一番下の「女性限定全額支払い可能」は、相乗り相手が女性である場合には、相乗り相手の費用を全額負担して相乗りする条件を示す。ユーザが支払う費用が、通常のタクシー料金の３倍以下で、所用時間が通常の所用時間と同等であり、相手が女性である場合に、マッチングが行なわれる。

図３２に示す条件は、いずれも例示である。個々のユーザが、自分の好みの条件を作成できても良い。

図３３および図３４は、実施の形態８の情報処理装置２０が表示する画面を示す説明図である。図３３に示す画面は、図７を使用して説明した画面の代わりに第２情報処理装置２０２の表示部２６２に表示される入力画面を示す。乗車地名欄６１１とマッチング依頼ボタン７１１との間に、乗車希望時刻欄６１２、人数欄６１３および条件欄６１４が追加されている。

乗車希望時刻欄６１２は、ユーザによる乗車希望時刻の入力を受け付ける。人数欄６１３は、ユーザによる乗車人数の入力を受け付ける。条件欄６１４は、条件ＤＢに記録された条件のなかから、ユーザによる選択を受け付ける。なお、ユーザが詳細な条件や条件ＤＢに記録されていない任意の条件を適宜入力できても良い。相乗りを希望するユーザは、各項目の入力を完了した後にマッチング依頼ボタン７１１を選択する。

図３４に示す画面は、図９を使用して説明した画面の代わりに、第１情報処理装置２０１の表示部２６１に表示される紹介画面を示す。費用欄６５４には、ユーザＫと相乗りした場合には、自分の負担する費用は０円であることとが表示されている。確認窓６６にも、ユーザＫが費用を１００％負担する旨が表示されている。

図３５は、実施の形態８のマッチングのサブルーチンの処理の流れを説明するフローチャートである。図３５に示すサブルーチンは、図１４を使用して説明したサブルーチンの代わりに使用されるサブルーチンである。ステップＳ７５４までの処理は、図１４を使用して説明したサブルーチンと同一であるため、説明を省略する。

紹介ＣＰＵ４１は、それぞれのユーザが設定した料金に関する条件を用いて、ライドフレンドおよびライドリーダがそれぞれ負担する費用を算出する（ステップＳ７８１）。紹介ＣＰＵ４１は、ライドリーダの負担する費用および所用時間等が、ライドリーダが設定した条件を満たすか否かを判定する（ステップＳ７８２）。

満たすと判定した場合（ステップＳ７８２でＹＥＳ）、紹介ＣＰＵ４１は、ライドフレンドの負担する費用および所用時間等が、ライドフレンドが設定した条件を満たすか否かを判定する（ステップＳ７８３）。満たすと判定した場合、紹介ＣＰＵ４１は処理を終了する。

ライドリーダの条件を満たさないと判定した場合（ステップＳ７８２でＮＯ）、または、ライドフレンドの条件を満たさないと判定した場合（ステップＳ７８３でＮＯ）、紹介ＣＰＵ４１は、第２レコードに対応するユーザがライドリーダであるか否かを判定する（ステップＳ７５８）。以後の処理は、図１４を使用して説明したプログラムと同一であるため、説明を省略する。

本実施の形態によると、ユーザが希望する料金に関する条件でマッチングするタクシー相乗りシステム１０を提供できる。

本実施の形態のタクシー相乗りシステム１０は、タクシーに乗車する前に相乗りするユーザ同士をマッチングする場面においても、タクシーに乗車して移動中のユーザと他のユーザとをマッチングする場面においても使用できる。すなわち、図３３を使用して説明した画面を使用して料金に関する条件を提示するユーザは、タクシーに乗車中のユーザであっても、タクシーに乗車前のユーザであってもよい。

既にタクシーに乗車中のユーザが希望する料金に関する条件としては、例えば、「全額支払ってくれる」（タクシーに乗車中のユーザは、料金負担をせず、未だタクシーに乗車していないユーザが料金を全額負担すること）、あるいは、「１０００円多く支払ってくれる」（未だタクシーに乗車していないユーザが１０００円多く料金を負担すること）などであってもよい。

なお、料金に関する条件としては、これまでに述べたとおり、条件を提示するユーザが確定的に定めた条件を提示することとしてもよいが、条件を提示するユーザが定めた変動する条件を提示することとしてもよい。例えば、一方のユーザが「一番多い割合で料金を支払ってくれること」を料金に関する条件（変動する条件）として提示した場合、かかる条件は、提示を受けた他のユーザが、自らが負担可能な金額、例えば、「全額支払う」、「１０００円プラス」等（確定的に定めた条件）を提示し、当該一方のユーザは、当該他のユーザが提示した条件の中から、許容できる条件を提示したユーザを相乗りするユーザとして選択することによりマッチングが成立することとしてもよい。

［実施の形態９］
図３６は、実施の形態９のタクシー相乗りシステム１０の機能ブロック図である。タクシー相乗りシステム１０は、ネットワークを介して接続された紹介サーバ４０と、複数の情報処理装置２０とを備える。情報処理装置２０は、条件取得部８１と、条件送信部８２とを備える。条件取得部８１は、それぞれのユーザから乗車地および下車地を取得する。条件送信部８２は、条件取得部８１が取得した乗車地および下車地を送信する。

紹介サーバ４０は、条件受信部８６およびマッチング送信部８７を備える。条件受信部８６は、条件取得部８１から送信されたそれぞれのユーザの乗車地および下車地を受信する。マッチング送信部８７は、ユーザから抽出された第１ユーザおよび第２ユーザのそれぞれ関連づけられた情報処理装置２０に、他方のユーザに関する情報、および、タクシーに相乗りした場合の予測費用を送信する。

情報処理装置２０は、マッチング出力部８３、選択受付部８４および選択送信部８５を備える。マッチング出力部８３は、マッチング送信部８７から送信された他方のユーザに関する情報、および、予測費用を出力する。選択受付部８４は、ユーザから相乗りするか否かの選択を受け付ける。選択送信部８５は、選択受付部８４が受け付けた選択を紹介サーバ４０に送信する。

紹介サーバ４０は、費用徴収部８８および費用支払部８９を備える。費用徴収部８８は、第１ユーザおよび第２ユーザのそれぞれに関連づけられた情報処理装置２０の選択送信部８５から相乗りする旨の選択を受信した場合に、途中でタクシーから降りる第１ユーザから、当該第１ユーザにかかる費用を徴収する。費用支払部８９は、費用徴収部８８が徴収した費用から手数料を引いた費用を第２ユーザに支払う。

［実施の形態１０］
本実施の形態は、汎用のサーバコンピュータとプログラム９７とを組み合わせて動作させることにより、本実施の形態のタクシー相乗りシステム１０用の紹介サーバ４０を実現する形態に関する。図３７は、実施の形態１０のタクシー相乗りシステム１０の構成を示す説明図である。なお、実施の形態１と共通する部分の説明は省略する。

本実施の形態のタクシー相乗りシステム１０は、ネットワークを介して接続された多数の情報処理装置２０およびサーバコンピュータ９０を備える。サーバコンピュータ９０は、紹介ＣＰＵ４１、主記憶装置４２、補助記憶装置４３、通信部４４、読取部４５およびバスを備える。

プログラム９７は、可搬型記録媒体９６に記録されている。紹介ＣＰＵ４１は、読取部４５を介してプログラム９７を読み込み、補助記憶装置４３に保存する。また紹介ＣＰＵ４１は、サーバコンピュータ９０に実装されたフラッシュメモリ等の半導体メモリ９８に記憶されたプログラム９７を読出しても良い。さらに、紹介ＣＰＵ４１は、通信部４４および図示しないネットワークを介して接続される図示しない他のサーバコンピュータからプログラム９７をダウンロードして補助記憶装置４３に保存しても良い。

プログラム９７は、サーバコンピュータ９０の制御プログラムとしてインストールされ、主記憶装置４２にロードして実行される。これにより、サーバコンピュータ９０は上述した紹介サーバ４０として機能する。

それぞれの情報処理装置２０には、図示しないアプリケーション提供サーバからネットワークを介して補助記憶装置２３に本実施の形態のプログラムが転送される。プログラムは、情報処理装置２０の制御プログラムとしてインストールされ、主記憶装置２２にロードして実行される。以上によりサーバコンピュータ９０と情報処理装置２０とは連動して上述のタクシー相乗りシステム１０として機能する。

各実施例で記載されている技術的特徴（構成要件）はお互いに組合せ可能であり、組み合わせすることにより、新しい技術的特徴を形成することができる。
今回開示された実施の形態はすべての点で例示であって、制限的なものでは無いと考えられるべきである。本発明の範囲は、上記した意味では無く、請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

１０ タクシー相乗りシステム
２０ 情報処理装置
２０１ 第１情報処理装置
２０２ 第２情報処理装置
２１ ＣＰＵ
２１１ 第１ＣＰＵ
２１２ 第２ＣＰＵ
２２ 主記憶装置
２２１ 主記憶装置
２２２ 主記憶装置
２３ 補助記憶装置
２３１ 補助記憶装置
２３２ 補助記憶装置
２４ 通信部
２４１ 通信部
２４２ 通信部
２５ タッチパネル
２５１ タッチパネル
２５２ タッチパネル
２６ 表示部
２６１ 表示部
２６２ 表示部
２７ 入力部
２７１ 入力部
２７２ 入力部
２８ ＧＰＳ
２８１ ＧＰＳ
２８２ ＧＰＳ
４０ 紹介サーバ
４１ 紹介ＣＰＵ
４２ 主記憶装置
４３ 補助記憶装置
４４ 通信部
４５ 読取部
４９ 地図サーバ
５１ ユーザＤＢ
５２ リクエストＤＢ
５３ マッチングＤＢ
６１ 乗車地欄
６１１ 乗車地名欄
６１２ 乗車希望時刻欄
６１３ 人数欄
６１４ 条件欄
６１５ 理由欄
６２ 下車地欄
６３ 地図欄
６４１ 乗車地マーク
６４２ 下車地マーク
６４３ 経由地マーク
６４４ 第２現在地マーク
６４５ 第１現在地マーク
６４６ 経路マーク
６５１ 候補者アイコン欄
６５２ 総利用回数欄
６５３ 総走行距離欄
６５４ 費用欄
６５５ 候補者地名欄
６５７ ニックネーム欄
６５８ 結果欄
６６ 確認窓
６７ 通報ボタン
６７１ 支払問題ボタン
６７２ 行動問題ボタン
６７３ その他通報ボタン
７１１ マッチング依頼ボタン
７１２ 候補承認ボタン
７１３ 別候補ボタン
７１４ キャンセルボタン
７１５ 現在地拡大ボタン
７１６ チャット開始ボタン
７１７ 開始ボタン
７１８ 迎車呼出ボタン
７１９ チャット終了ボタン
７２０ 承認ボタン
７２１ 属性ボタン
７２３ 送信ボタン
７２４ 修正中止ボタン
７２５ 修正承認ボタン
７３ マーカ
８１ 条件取得部
８２ 条件送信部
８３ マッチング出力部
８４ 選択受付部
８５ 選択送信部
８６ 条件受信部
８７ マッチング送信部
８８ 費用徴収部
８９ 費用支払部
９０ サーバコンピュータ
９６ 可搬型記録媒体
９７ プログラム
９８ 半導体メモリ

Claims (15)

1. タクシーに相乗りする候補者、および、該候補者と相乗りする場合の算定費用を取得し、
   取得した前記候補者、および、前記算定費用を表示し、
   表示した前記候補者と相乗りするか否かの選択を受け付ける
   処理をコンピュータに実行させるプログラム。
2. 前記候補者が途中でタクシーから降りる途中下車者であるか否かを表示する
   請求項１に記載のプログラム。
3. 前記候補者が途中でタクシーから降りる途中下車者である場合、
   前記算定費用は前記途中下車者が相乗りする相手に支払う第１タクシー料金と、手数料とを含み、
   前記第１タクシー料金と手数料とを表示する
   請求項１または請求項２に記載のプログラム。
4. 前記候補者が最終下車地でタクシーから降りる最終下車者である場合、
   前記算定費用は、乗車地から最終下車地までの第２タクシー料金と、相乗りする相手から受け取る第１タクシー料金との差額と、手数料とを含み、
   前記第１タクシー料金と、前記第２タクシー料金と、手数料とを表示する
   請求項１から請求項３のいずれか一つに記載のプログラム。
5. 前記候補者宛のメッセージの入力を受け付けて送信し、
   前記候補者からのメッセージを取得して表示する
   請求項１から請求項４のいずれか一つに記載のプログラム。
6. 前記候補者の位置を取得し、
   取得した前記位置を地図上に表示する
   請求項１から請求項５のいずれか一つに記載のプログラム。
7. 前記候補者をフィルタリングする条件を受け付け、
   受け付けた前記条件を送信し、
   前記条件に基づいてフィルタリングされた前記候補者を取得する
   請求項１から請求項６のいずれか一つに記載のプログラム。
8. 乗車を希望するタクシーの属性の入力を受け付け、
   受け付けた属性に適合するタクシーの配車を要求する
   請求項１から請求項７のいずれか一つに記載のプログラム。
9. ユーザごとの乗車地および下車地を取得し、
   前記ユーザから抽出された第１ユーザおよび第２ユーザのそれぞれに、他方のユーザに関する情報、および、タクシーに相乗りした場合の算定費用を出力し、
   前記第１ユーザおよび前記第２ユーザから、相乗りするか否かの選択を受け付け
   前記第１ユーザおよび前記第２ユーザから相乗りする旨の選択を受け付けた場合に、
   途中でタクシーから降りる前記第１ユーザから、前記第１ユーザにかかる費用を徴収し、
   前記第２ユーザに、前記第１ユーザから徴収した費用から手数料を引いた費用を支払う
   処理をコンピュータに実行させるプログラム。
10. 前記第１ユーザに、前記第２ユーザに支払う第１タクシー料金と第１手数料とを含む第１費用を通知し、
    前記第２ユーザに、乗車地から最終下車地までの費用を予測した第２タクシー料金と前記第１タクシー料金との差額と、第２手数料とを含む第２費用を通知する
    請求項９に記載のプログラム。
11. 前記第１費用が、前記第１ユーザが単独でタクシーに乗車した場合に支払う算定費用を下回り、かつ、前記第２費用が、前記第２ユーザが単独でタクシーに乗車した場合に支払う算定費用を下回る場合に、
    前記第１ユーザに前記第２ユーザに関する情報、および、前記第１費用を出力し、
    前記第２ユーザに前記第１ユーザに関する情報、および、前記第２費用を出力する
    請求項１０に記載のプログラム。
12. 前記第１ユーザについて、前記第２ユーザが相乗りを拒否する条件を定めた第２条件を満たすか否かを判定し、
    前記第２ユーザについて、前記第１ユーザが相乗りを拒否する条件を定めた第１条件を満たすか否かを判定し、
    前記第１ユーザが前記第２条件を満たさず、かつ、前記第２ユーザが前記第１条件を満たない場合に、
    前記第１ユーザおよび前記第２ユーザのそれぞれに、他方のユーザに関する情報、および、タクシーに相乗りした場合の算定費用を出力する
    請求項９から請求項１１のいずれか一つに記載のプログラム。
13. 乗り物に相乗りする候補者、および、該候補者と相乗りする場合の算定費用を取得し、
    取得した前記候補者、および、前記算定費用を表示し、
    表示した前記候補者と相乗りするか否かの選択を受け付ける
    処理をコンピュータに実行させるプログラム。
14. タクシーに相乗りする候補者、および、該候補者と相乗りする場合の算定費用を取得し、
    取得した前記候補者、および、前記算定費用を表示し、
    表示した前記候補者と相乗りするか否かの選択を受け付ける
    処理をコンピュータに実行させる情報処理方法。
15. ユーザごとの乗車地および下車地を取得し、
    前記ユーザから抽出された第１ユーザおよび第２ユーザのそれぞれに、他方のユーザに関する情報、および、タクシーに相乗りした場合の算定費用を出力し、
    前記第１ユーザおよび前記第２ユーザから、相乗りするか否かの選択を受け付け
    前記第１ユーザおよび前記第２ユーザから相乗りする旨の選択を受け付けた場合に、
    途中でタクシーから降りる前記第１ユーザから、前記第１ユーザにかかる費用を徴収し、
    前記第２ユーザに、前記第１ユーザから徴収した費用から手数料を引いた費用を支払う
    処理をコンピュータに実行させる情報処理方法。

Images