JP2016194854A - 相乗り支援システム、携帯端末、プログラム、相乗り支援方法、および賃貸借支援システム - Google Patents

Abstract

【課題】より簡単な操作で、自家用車の相乗りに対する課金をより確実に行う。【解決手段】相乗り支援システムは、自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングするマッチング手段と、前記運転者および前記同乗者が所定の範囲内に近づいたことを検知する検知手段と、前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断する判断手段と、前記同乗者が前記自家用車に同乗していると判断された後で、前記運転者および前記同乗者の少なくとも一方に課金する課金手段とを有する。【選択図】図２

Description

本発明は、自家用車の相乗りを支援する技術に関する。

自家用車の運転者と、その自家用車に相乗りを希望する希望者とをマッチングするシステムが知られている。特許文献１には、マッチングに際して識別コードを発行し、この識別コードを用いて本人確認および決済を行う技術が記載されている。また、特許文献２には、２つの移動体の位置情報から、両者の距離が許容範囲内かつ両者の移動速度の差が許容範囲内の場合に、これら２つの移動体のユーザが自動車に相乗りしていると判断する技術が記載されている。

特開２００２−１４０３９９号公報 特開２０１１−２３７８４２号公報

特許文献１の技術においては、相乗りが行われたことの確認のために運転者と相乗り希望者が識別コードを交換する必要があり、ユーザの操作が煩雑であるという問題があった。特許文献２の技術は、相乗りに対する課金を行うものではなかった。

これに対し本発明は、より簡単な操作で、自家用車の相乗りに対する課金をより確実に行う技術を提供する。

本発明は、自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングするマッチング手段と、前記運転者および前記同乗者が所定の範囲内に近づいたことを検知する検知手段と、前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断する判断手段と、前記同乗者が前記自家用車に同乗していると判断された後で、前記運転者および前記同乗者の少なくとも一方に課金する課金手段とを有する相乗り支援システムを提供する。

前記判断手段は、前記時間または前記移動距離がしきい値を超えた場合、前記同乗者が前記自家用車に同乗していると判断してもよい。

前記判断手段は、前記移動距離がしきい値距離に達していない場合において前記時間がしきい値を超えたときは、前記同乗者が前記自家用車に同乗していると判断してもよい。

この相乗り支援システムは、前記運転者に所有され、固有の識別信号を出力する識別信号出力装置を有し、前記検知手段は、前記運転者および前記同乗者が近づいたことを前記識別信号を用いて検知してもよい。

この相乗り支援システムは、前記同乗者に携帯され、情報を表示する表示手段を有する携帯端末を有し、前記同乗者が前記運転者に近づいたことが前記検知手段により検知された場合、前記表示手段は、当該運転者に固有の情報を表示してもよい。

この相乗り支援システムは、複数の自家用車について行き先を示す行き先情報を記憶する記憶手段を有するサーバを有し、前記携帯端末は、前記複数の自家用車の中から所望の自家用車を検索するための検索条件の入力を受け付ける受け付け手段を有し、前記表示手段は、前記複数の自家用車の中から抽出された、前記検索条件に適合する自家用車の一覧を表示してもよい。

前記記憶手段は、前記複数の自家用車の少なくとも一部の自家用車の現在位置を示す情報を記憶しており、前記表示手段は、前記現在位置を含む前記一覧を表示してもよい。

また、本発明は、自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングするマッチング手段を有するサーバから、当該マッチングの結果を受信する受信手段と、前記運転者および前記同乗者が所定の範囲内に近づいたことを検知する検知手段と、前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断する判断手段と、前記同乗者が前記自家用車に同乗していると判断されたことを前記サーバに通知する通知手段とを有する携帯端末を提供する。

さらに、本発明は、コンピュータに、自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングするマッチング手段を有するサーバから、当該マッチングの結果を受信するステップと、前記運転者および前記同乗者が所定の範囲内に近づいたことを検知するステップと、前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断するステップと、前記同乗者が前記自家用車に同乗していると判断されたことを前記サーバに通知するステップとを実行させるためのプログラムを提供する。

さらに、本発明は、自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングした結果を示すデータを受信するステップと、前記運転者および前記同乗者が所定の範囲内に近づいたことを検知するステップと、前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断するステップと、
前記同乗者が前記自家用車に同乗していると判断された後で、前記運転者および前記同乗者の少なくとも一方に課金するステップとを有する相乗り支援方法を提供する。

さらに、本発明は、賃貸借の目的物を所有する賃貸人および当該目的物を賃借する賃借人をマッチングするマッチング手段と、前記目的物および前記賃借人が所定の範囲内に近づいたことを検知する検知手段と、前記目的物および前記賃借人が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記賃貸借が行われているか判断する判断手段と、前記賃貸借が行われていると判断された後で、前記賃貸人および前記賃借人の少なくとも一方に課金する課金手段とを有する賃貸借支援システムを提供する。

本発明によれば、より簡単な操作で、自家用車の相乗りに対する課金をより確実に行うことができる。

一実施形態に係る相乗り支援システム１の概要を示す図 相乗り支援システム１の機能構成を示す図 サーバ１０のハードウェア構成を例示する図 携帯端末２０のハードウェア構成を例示する図 識別信号出力装置３０のハードウェア構成を例示する図 相乗り支援システム１における処理の概要を示すフローチャート マッチング処理の詳細を例示するシーケンスチャート 募集要項の入力画面を例示する図 目的の選択画面を例示する図 予約データベースのデータ構造を例示する図 絞り込み条件の入力画面を例示する図 募集要項の一覧表示画面を例示する図 募集要項の詳細表示画面を例示する図 相乗りから課金までの処理の詳細を例示するシーケンスチャート 自家用車に関する情報の表示例を示す図

１．構成
図１は、一実施形態に係る相乗り支援システム１の概要を示す図である。相乗り支援システム１は、自家用車の相乗り（同乗）を支援するためのサービス（以下「相乗り支援サービス」という）を提供するシステムである。自家用車とは、事業用自動車以外の、一般的な用途に使用される自動車をいう。自家用車はいわゆるマイカーであり、タクシーやハイヤーは含まない。ある統計によれば、自家用車の平均乗車人数は１台あたり１．３人である。仮に乗車定員を４人とすると、自家用車は平均で２．７人分の座席が空いた状態で走行していることになる。この空席を有効に利用することができれば、移動コストの低減や、環境負荷の低減、および駐車場不足や渋滞の解消などができることが期待される。

以下の説明においては、自家用車を所有するユーザを「運転者」といい、運転者が運転する自家用車に相乗り（同乗）するユーザまたは相乗りを希望するユーザを「同乗者」という。なお、相乗りを希望するユーザを相乗りするユーザと区別するときは特に「同乗希望者」という。

相乗り支援システム１は、サーバ１０および携帯端末２０を有する。サーバ１０は、運転者Ｄと同乗者Ａとのマッチングや、相乗りに関する情報提供を行う。携帯端末２０は、ユーザにより携帯されるクライアント端末であり、移動通信網やインターネット等の通信ネットワークＮを介して、サーバ１０と通信する。相乗り支援システム１において、携帯端末２０は、相乗りが行われているか否かの判断を自動的に行い、その結果をサーバ１０に通知する。サーバ１０は、この通知に応じてシステム利用料の課金を行う。

さらにこの例で、相乗り支援システム１は、サーバ１０および携帯端末２０に加え、識別信号出力装置３０を有する。識別信号出力装置３０は、自機の識別信号を出力する装置であり、運転者が所有する自家用車ＭＶに搭載される。運転者および同乗者は、それぞれ、携帯端末２０を所有している。

図２は、相乗り支援システム１の機能構成を示す図である。サーバ１０は、マッチング手段１１、通知手段１２、課金手段１３、および記憶手段１４を有する。携帯端末２０は、検知手段２１、判断手段２２、および通知手段２３を有する。記憶手段１４は、運転者および同乗者のプロフィール等、相乗り支援サービスに用いられる情報を記憶する。マッチング手段１１は、運転者と同乗者とをマッチングする。通知手段１２は、マッチングの結果を携帯端末２０に通知する。

検知手段２１は、運転者と同乗者とが所定の範囲内に近づいたことを検知する。判断手段２２は、運転者および同乗者が近接している状態が継続している時間およびその状態における移動距離の少なくとも一方に基づいて、同乗者が自家用車に同乗しているか判断する。同乗者が自家用車に同乗していると判断された場合、通知手段２３は、その旨をサーバ１０に通知する。この通知を受けると、課金手段１３は、運転者および同乗者の少なくとも一方に対して課金を行う。

図３は、サーバ１０のハードウェア構成を例示する図である。サーバ１０は、例えば汎用のコンピュータ装置であり、ＣＰＵ１００、ＲＯＭ１０１、ＲＡＭ１０２、ストレージ１０３、および通信ＩＦ１０４を有する。ＣＰＵ１００は、ストレージ１０３に記憶されているプログラムを実行し、各種の演算を行うプロセッサである。ＲＯＭ１０１は、サーバ１０の起動に用いられるプログラムおよびデータを記憶する不揮発性の記憶装置である。ＲＡＭ１０２は、ＣＰＵ１００がプログラムを実行する際のワークエリアとして機能する揮発性の記憶装置である。ストレージ１０３は、ＯＳやアプリケーションプログラムなど各種プログラムおよびデータを記憶する不揮発性の記憶装置である。通信ＩＦ１０４は、携帯端末２０等他の装置と通信を行うためのインターフェースである。

この例で、ストレージ１０３は、コンピュータ装置を相乗り支援システムにおけるサーバとして機能させるためのプログラムを記憶している。ＣＰＵ１００がこのプログラム（以下「サーバプログラム」という）を実行することにより、図２に示される機能がサーバ１０に実装される。さらに、ストレージ１０３は、相乗り支援システムにおいて用いられるデータが記録されたデータベースを記憶している。相乗り支援システムにおいて用いられるには、例えば、ユーザデータベースおよび予約データベースがある。これらの詳細は後述する。

サーバプログラムを実行しているＣＰＵ１００は、マッチング手段１１、通知手段１２、および課金手段１３の一例である。ストレージ１０３は、記憶手段１４の一例である。

図４は、携帯端末２０のハードウェア構成を例示する図である。携帯端末２０は、例えばスマートフォン、タブレット端末、または携帯電話機であり、ＣＰＵ２００、ＲＯＭ２０１、ＲＡＭ２０２、ストレージ２０３、通信ＩＦ２０４、表示装置２０５、入力装置２０６、およびＧＰＳ受信機２０７を有する。ＣＰＵ２００は、ストレージ２０３に記憶されているプログラムを実行し、各種の演算を行うプロセッサである。ＲＯＭ２０１は、携帯端末２０の起動に用いられるプログラムおよびデータを記憶する不揮発性の記憶装置である。ＲＡＭ２０２は、ＣＰＵ２００がプログラムを実行する際のワークエリアとして機能する揮発性の記憶装置である。ストレージ２０３は、ＯＳやアプリケーションプログラムなど各種プログラムおよびデータを記憶する不揮発性の記憶装置である。通信ＩＦ２０４は、他の装置と通信を行うためのインターフェースである。この例で、通信ＩＦ２０４は、各種の通信規格に従った無線通信を行う機能を有する。通信ＩＦ２０４は、複数の規格に対応した通信ユニットの集合体である。通信ＩＦ２０４が対応している規格には、例えば、移動通信網を介したデータ通信の規格（いわゆる３Ｇ、ＬＴＥ（Long Term Evolution）等）、いわゆるＷｉＦｉ等の無線ＬＡＮ（Local Area Network）の規格（例えばＩＥＥＥ８０２．１１ｘ）、ＢＬＥ（Bluetooth Low Energy：登録商標）等の無線ＰＡＮ（Personal Area Network）の規格がある。特に、通信ＩＦ２０４は、後述する識別信号出力装置３０が出力する識別信号を受信する機能を有する。

表示装置２０５は、情報を表示する装置であり、例えば液晶ディスプレイや有機ＥＬディスプレイを含む。入力装置２０６は、ユーザが携帯端末２０に対し指示や情報を入力するための装置であり、例えばタッチセンサー、キーパッド、およびボタンのうち少なくとも１つを含む。この例で、携帯端末２０はタッチスクリーンを有しており、表示装置２０５に表示されたＵＩ画像（ボタンやアイコン等）の上をユーザがタッチすることにより、携帯端末２０に対する指示が入力される。ＧＰＳ受信機２０７は、ＧＰＳ衛星から送信される信号を受信し、受信した信号を用いて自身の現在位置を特定する。

この例で、ストレージ２０３は、コンピュータ装置を相乗り支援システムにおけるクライアントとして機能させるためのプログラム（以下「クライアントアプリ」という）を記憶している。このクライアントプログラムがＯＳ等他のソフトウェアやハードウェア要素と協働することにより、図２に示される機能が携帯端末２０に実装される。

クライアントアプリを実行しているＣＰＵ２００は、検知手段２１、判断手段２２、および通知手段２３の一例である。

図５は、識別信号出力装置３０のハードウェア構成を例示する図である。識別信号出力装置３０は、例えばＢＬＥ（Bluetooth Low Energy）技術を用いたビーコン信号の発信機である。識別信号出力装置３０は、ＲＯＭ３００および発信器３０１を有する。ＲＯＭ３００は、識別信号出力装置３０に対して固有に割り当てられた識別番号を記憶した不揮発性の記憶装置である。発信器３０１は、所定の時間間隔で、ＲＯＭ３００に記憶されている識別番号を示す識別信号（ビーコン信号）を出力する。発信器３０１は、例えば電池（図示略）から供給される電力で動作する。

２．動作
相乗り支援システム１の動作について説明する。相乗り支援システム１は、相乗り支援サービスを提供する事業者に運営される。相乗り支援サービスを利用しようとするユーザは、事前にユーザ登録を行う。ユーザ登録時にはユーザ自身のプロフィール情報（固有情報）が入力される。プロフィール情報は、例えば、ユーザ名、パスワード、性別、年齢、居住地、メールアドレス、および顔写真を含む。なお、相乗り支援システム１において、ユーザ登録時には運転者および同乗者（同乗希望者）の区分は存在しないが、ここでは説明の便宜上、「運転者」および「同乗者（同乗希望者）」という語を用いる。運転者となるユーザのプロフィール情報はさらに、例えば、車種、年式、色、および外観写真など、所有している自家用車に関する情報を含む。これらのプロフィール情報は、サーバ１０のユーザデータベースに記録される。

相乗り支援サービスの提供事業者は、運転者となるユーザに対して識別信号出力装置３０を配布する。運転者は、配布された識別信号出力装置３０を、自身が所有する自家用車に搭載する。識別信号出力装置３０の識別番号と運転者との対応関係はサーバ１０のユーザデータベースに記録されている。すなわち、識別番号が与えられれば、サーバ１０は、その識別信号出力装置３０がどの運転者に配布されたものであるか特定することができる。

図６は、相乗り支援システム１における処理の概要を示すフローチャートである。相乗り支援システム１における処理は、マッチング（ステップＳ１）、相乗り（ステップＳ２）、および課金（ステップＳ３）という３つの段階を踏む。マッチングとは、運転者と同乗者とをマッチングする（引き合わせる）処理、すなわち相乗りの予約である。相乗りとは、同乗者が実際に運転者の運転する自家用車に乗る過程をいう。課金とは、相乗り支援サービスの利用料を運転者および同乗者の少なくとも一方に課金する処理をいう。

２−１．マッチング（相乗り予約）
図７は、マッチング処理の詳細を例示するシーケンスチャートである。この例で、マッチングは、まず運転者となるユーザがある旅程について同乗者を募集し、それに対し同乗者希望者であるユーザが応募（予約）することによって行われる。以下においては、運転者が所有する携帯端末２０を携帯端末２０Ｄといい、同乗者が所有する携帯端末２０を携帯端末２０Ａという。

運転者が旅程を登録する際、関連するコミュニティを指定することができる。コミュニティとは、特定のテーマに関する旅程の集合をいう。相乗り支援システム１においては、複数のコミュニティが設定されている。コミュニティは、あらかじめ設定されたテーマ（例えば、「サッカー観戦」、「夏フェス」、「帰省」など）に区分されている。

ステップＳ１０１において、運転者は、新たな旅程に係る同乗者の募集要項をサーバ１０に登録する。募集要項は、携帯端末２０Ｄを介してサーバ１０に登録される。

図８は、新規旅程に係る募集要項の入力画面を例示する図である。募集要項の項目には、例えば、目的、タイトル、出発日時、出発地、目的地、募集人数、および同乗者一人当たりの費用が含まれる。この例では、以下の情報が入力されている。
目的：サッカー観戦
タイトル：２／２８ 東京ｖｓ松本 観戦
出発日時：２０１５年２月２８日 ９：００
出発地：新宿駅西口
目的地：松本スタジアム
募集人数：３名
費用：２，０００円／人
運転者が「確定」ボタンを押すと、入力された募集要項のデータが、サーバ１０に送信される。ここで、「目的」の項は、上述のコミュニティに相当する。旅程の目的は、サーバ１０においてあらかじめ設定されている選択肢の中から、ユーザにより選択される。

図９は、旅程の目的の選択画面を例示する図である。この例では、サッカー観戦、野球観戦、夏フェス、帰省、および該当なしという５つの選択肢が示されている。運転者は、これらの選択肢の中から、今回新たに登録しようとする旅程に対応する目的を選択する。なお、この選択肢は、図８の入力画面と別ウインドウで表示されてもよいし、図８の入力画面においてプルダウンメニューで表示されてもよい。

再び図７を参照する。ステップＳ１０２において、サーバ１０のＣＰＵ１００は、携帯端末２０Ｄから受信した募集要項のデータを、予約データベースに記録する。予約データベースは、同乗者が募集されている旅程に関する情報が記録されたデータベースである。

図１０は、予約データベースのデータ構造を例示する図である。この例で、予約データベースは、旅程識別番号、運転者、デバイス識別番号、目的、出発日時、出発地、目的地、費用、および募集人数という項目を含む。「旅程識別番号」は、旅程を一意に特定するための識別番号を示す。「運転者」は対応する旅程を登録したユーザのユーザ名を示す。「デバイス識別番号」はその旅程を登録した運転者に対して配布された識別信号出力装置３０のＲＯＭ３００に記憶されている識別番号を示す。他の項目については、図９で説明したとおりである。なお、ここでは旅程の「タイトル」および予約済みの同乗者のユーザ名は省略されている。

再び図７を参照する。ステップＳ１０３において、携帯端末２０ＡのＣＰＵ２００は、旅程の一覧の送信要求を、同乗者の指示に応じてサーバ１０に送信する。この送信要求は、予約データベースに登録されている複数の旅程の中から表示するものを絞り込むための絞り込み条件を含んでいる。

図１１は、絞り込み条件の入力画面を例示する図である。この例では、以下の条件が指定されている。
目的：サッカー観戦
出発日時：２０１５年２月２８日
出発地：東京２３区内
目的地：松本市内
この絞り込み条件の一部は、メニュー等により階層化されていてもよい。例えば、旅程一覧のトップ画面に目的（コミュニティ）の一覧が表示され、そのうちの１つを選択すると、対応する旅程の一覧が表示されてもよい。例えば、トップ画面から「サッカー観戦」の項目を選択すると、サッカー観戦を目的とする旅程の一覧が表示される。

再び図７を参照する。ステップＳ１０４において、ＣＰＵ１００は、予約データベースの中から、携帯端末２０Ａから受信した送信要求に含まれる絞り込み条件に適合する旅程を抽出する。ＣＰＵ１００は、抽出した旅程の一覧を示すデータを、送信要求の送信元である携帯端末２０Ａに送信する。

ステップＳ１０５において、携帯端末２０ＡのＣＰＵ２００は、サーバ１０から受信したデータを用いて、旅程の一覧を表示する。

図１２は、旅程の一覧表示画面を例示する図である。この例で、一覧には、旅程の募集要項に含まれる情報の一部、具体的には、出発日時、出発地、目的地、および費用が含まれる。同乗希望者が一覧の中から興味ある旅程を選択すると、選択された旅程に係る募集要項の詳細が表示される。

図１３は、募集要項の詳細表示画面を例示する図である。ここでは、図９で例示した旅程に係る募集要項が例として記載されている。募集要項の詳細は、例えば、出発日時、出発地、目的地、費用、募集座席数、残席、および運転者情報を含む。例えば、「運転者」として表示されているユーザ名を選択する操作が行われると、その運転者のプロフィール情報が表示される。この旅程に対し相乗りを予約したいと考えた場合、同乗希望者は、「コンタクト」または「申請」ボタンを押す操作をする。

「コンタクト」ボタンは、同乗希望者が運転者とメッセージのやりとりを開始するためのボタンである。「コンタクト」ボタンが押されると、サーバ１０または外部の電子メールサーバを介したメッセージ送受信機能が呼び出される。同乗希望者は、この機能により運転者とメッセージのやりとり（ステップＳ１０６）をし、待ち合わせ場所や降車地について質問や打ち合わせをすることができる。

「申請」ボタンは、その旅程の予約を申請するためのボタンである。「申請」ボタンが押されると、携帯端末２０ＡのＣＰＵ２００は、その旨の通知をサーバ１０に送信する（ステップＳ１０７）。サーバ１０は、予約の申請があった旨を携帯端末２０Ｄに通知する（ステップＳ１０８）。この通知に応じて、携帯端末２０ＤのＣＰＵ２００は、予約の承認を促す画面（図示略）を表示する。この画面には、例えば予約を承認するための「承認」ボタンが含まれている。また、この画面は、予約を申請している同乗希望者のプロフィール情報へのリンクを含んでもよい。運転者が「承認」ボタンを押すと、携帯端末２０ＤのＣＰＵ２００は、その旨の通知をサーバ１０に送信する（ステップＳ１０９）。この通知には、旅程識別番号および同乗者のユーザ名が含まれている。

携帯端末２０Ｄから承認の通知を受けると、サーバ１０のＣＰＵ１００は、対応する旅程に対し、通知に含まれるユーザ名を同乗者としてデータベースに登録する（ステップＳ１１０）。ＣＰＵ１００は、さらに、この募集要項における残席を１つ減らす。残席がゼロになった場合、ＣＰＵ１００は、この募集要項に対して満席のフラグ（図１０では省略）をオンにする。満席のフラグがオンになると、一覧の送信要求に対して抽出される対象からは除外される。

ステップＳ１１１において、ＣＰＵ１００は、マッチング（予約）が成立した旨の通知を、携帯端末２０Ｄおよび携帯端末２０Ａに送信する。以下、この通知を、相乗りの予約を示す情報という意味において「予約情報」という。予約情報として送信される情報は、携帯端末２０Ｄと携帯端末２０Ａとで異なっている。携帯端末２０Ｄに送信される予約情報は、例えば、対象となる旅程のタイトルおよび同乗者のプロフィール情報を含んでいる。携帯端末２０Ａに送信される予約情報は、マッチングが成立した旅程の詳細情報（出発日時、出発地等）および運転者のプロフィール情報に加え、その運転者に対し配布された識別信号出力装置３０の識別番号を含んでいる。予約情報は、携帯端末２０Ｄおよび携帯端末２０Ａにおいて表示される。なお、予約が成立した旨の通知は、携帯端末２０Ｄおよび携帯端末２０Ａ以外の宛先（例えばあらかじめ登録された電子メールアドレス）に対して送信されてもよい。

以上で、マッチング処理は終了である。なお、図７の例では旅程の登録および相乗りの予約を携帯端末２０を介して行う例を説明した。これらの処理は、クライアントアプリを介して行われてもよいし、ウェブブラウザを介して行われてもよい。別の例で、これらの処理は、携帯端末２０とは別のコンピュータ装置からウェブサイトを介して行われてもよい。

２−２．相乗りおよび課金
図１４は、相乗りから課金までの処理の詳細を例示するシーケンスチャートである。予約した相乗りの出発日時が近づくと（例えば出発日時の１０分前になると）、携帯端末２０ＡのＯＳはクライアントアプリを起動させる（ステップＳ２０１）。

ステップＳ２０２において、クライアントアプリは、出発地を表した地図を表示する。この地図上に同乗者の現在位置を併せて表示してもよい。あるいは、この地図上に、出発地に代えてまたは加えて、運転者の現在位置を表示してもよい。この場合、出発地（待ち合わせ場所）に着いて停車すると、運転者は携帯端末２０Ｄを操作し、出発地に着いた旨を入力する。この入力を受けて、携帯端末２０Ｄは自身の現在位置を測定し、測定された現在位置を示す情報をサーバ１０に送信する。サーバ１０は、運転者の現在位置（すなわち待ち合わせ場所における詳細な停車位置）を、同乗者に送信する。

出発地の地図が表示されることで、例えば出発地が同乗者にとって不慣れな場所であっても、出発地をより的確に案内することができる。また、運転者の現在位置を表示する例によれば、例えば当日行ってみたら出発地に停車スペースが無く、急遽、募集要項に記載されていたのとは違う場所に停車したような場合でも、同乗者を運転者の位置まで案内することができる。

ステップＳ２０３において、クライアントアプリは、識別信号の照合を開始する。この例で、通信ＩＦ１０４のうち識別信号を受信するための機能は原則として常にアクティブである。ステップＳ２０３以降、識別信号を受信すると、クライアントアプリは、受信した識別信号に含まれる識別番号を、予約情報に含まれる識別番号と照合する。両者が一致した場合、クライアントアプリは、処理をステップＳ２４に移行する。両者が一致しない場合、クライアントアプリは、識別信号の照合を継続する。

ステップＳ２０４において、クライアントアプリは、予約情報に含まれる運転者のプロフィール情報の一部、例えば、所有する自家用車に関する情報（例えば、外観写真、車種、年式、色等）を表示する。

図１５は、自家用車に関する情報の表示例を示す図である。この例では、外観写真に加え、車種、年式、および色の情報が文字で示されている。例えば出発地が巨大駅の駅前や駐車場内のように多くの自家用車が停車しているような場所でも、表示されるプロフィール情報を基に、どれが待ち合わせ対象の自家用車であるか容易に特定することができる。また、この例では、携帯端末２０Ｄにおいて地図が表示された状態から、識別信号の到達範囲内に達すると運転者のプロフィール情報が表示される状態に切り替わる。したがって同乗者が出発地近辺で対象の自家用車を探しながら歩いているような場合でも、画面の遷移によって対象の自家用車に近づいたことを同乗者に通知することができる。

さらにここで、識別信号の信号強度に基づいて予約した車との距離に関する情報を同乗者に通知してもよい。この場合、例えば、「１０ｍ以内に予約した車がいます」等の情報が携帯端末２０Ａに表示される。あるいは、信号強度の変化に基づいて車との距離に関する情報を同乗者に通知してもよい。この場合、例えば、「予約した車に近づいています」「予約した車から遠ざかっています」等の情報が携帯端末２０Ａに表示される。

再び図１４を参照する。ステップＳ２０５において、クライアントアプリは、信号強度がしきい値より強い識別信号を継続して受信している時間の計測を開始する。予約情報に対応する識別信号を受信すると、携帯端末２０Ａのクライアントアプリは、定期的に、その識別信号をまだ受信しているか確認する。すなわち、携帯端末２０Ａは、自身が識別信号の到達範囲内にいるか定期的に確認する。このように、「識別信号を継続して受信している」状態とは、同一の識別信号を時間的に連続して（絶え間なく）受信している状態だけでなく、同一の識別信号を受信していることが定期的に確認できる状態をも含む。

ステップＳ２０６において、クライアントアプリは、相乗り判定に用いられる情報をサーバ１０に送信する。相乗り判定に用いられる情報は、例えば、予約情報に対応する識別信号を継続して受信している時間を含む。この情報は、さらに、ＧＰＳ受信機２０７により特定された現在位置を含んでもよい。また、この情報は、サーバ１０に定期的に送信されてもよいし、特定の条件が満たされた時（例えば、識別信号を継続して受信している時間がしきい値を超えた時）にサーバ１０に送信されてもよい。

また、運転者の携帯端末２０Ｄのクライアントアプリは、同乗者のクライアントアプリとは独立して、相乗り判定に用いられる情報をサーバ１０に送信する（ステップＳ２０７）。この情報は、例えば、ＧＰＳ受信機２０７により特定された現在位置を含む。この情報は、サーバ１０に定期的に送信されてもよいし、特定の条件が満たされた時（例えば、相乗り開始からの移動距離がしきい値を超えた時）にサーバ１０に送信されてもよい。なお、図１４では、運転者の携帯端末２０Ｄにおけるクライアントアプリの起動や、移動距離の計測開始については図示していないが、これは例えば以下のように行われる。予約した相乗りの出発日時が近づくと（例えば出発日時の１０分前になると）、携帯端末２０ＤのＯＳはクライアントアプリを起動させる。クライアントアプリは、この時点（例えば出発日時の１０分前）の現在位置をＧＰＳ受信機２０７から取得し、ＲＡＭ２０２に記憶する。これ以降、クライアントアプリは、ＧＰＳ受信機２０７から定期的に現在位置を取得する。

ステップＳ２０８において、サーバ１０のＣＰＵ１００は、相乗りの成立条件が満たされたか判断する。相乗りの成立条件としては、運転者および同乗者が所定範囲内（この例では信号強度がしきい値より強い識別信号の到達範囲内）に近づいている状態が継続している時間およびこの状態を保ったまま両者が移動した距離の少なくとも一方に関する条件が用いられる。具体的には、例えば以下（ａ）〜（ｃ）のうち少なくとも１つが用いられる。

（ａ）携帯端末２０Ａが同一の識別信号を継続して受信している時間がしきい値を超えた。
これはすなわち、運転者と同乗者とが識別信号の到達範囲内に近づいている状態がしきい値時間（例えば、１０分）継続したことを示す。運転者と同乗者とは基本的に見知らぬ人同士であるので、両者が偶然に接近する可能性は非常に低い。両者が識別信号の到達範囲内に近づき、さらにその状態が一定時間継続しているときは、待ち合わせが成功して相乗りが成立したと判断することが妥当である。

（ｂ）携帯端末２０Ａが同一の識別信号を受信したままの状態で移動した距離がしきい値を超えた。
例えば以下の例を考える。ある旅程について、２人の同乗者（同乗者ＡおよびＢという）が相乗りの予約をした。同乗者Ａは出発時刻の２０分前に出発地（待ち合わせ場所）に到着し、同乗者Ｂは出発時刻ギリギリに到着した。この例で、例えば上記の条件（ａ）で判定のしきい値が１５分に設定されていたとすると、同乗者Ａについては出発前に相乗り成立の判断がされてしまうことになる。後述するように相乗り成立は課金と関係してくるので、判定のしきい値の設定によってはユーザの不満を招く可能性がある。そこで、ここでは、携帯端末２０Ａが同一の識別信号を受信したままの状態（運転者と同乗者が近接したままの状態）で移動した距離がしきい値距離（例えば１０ｋｍ）を超えた場合に、相乗りが成立したと判断される。

なお、移動距離は、例えば、携帯端末２０Ａおよび携帯端末２０Ｄの少なくとも一方から受信した情報に含まれる位置情報を用いて計測される。

（ｃ）携帯端末２０Ａが同一の識別信号を受信したままの状態で移動を開始したが、移動を開始してからの距離がしきい値を超える前に移動を開始してからの時間がしきい値を超えた。
これは、例えば条件（ｂ）と組み合わせて使うと有効である。条件（ｂ）で相乗り成立が判断される場合において、例えば渋滞に遭遇してしまい出発して３０分経つのに５ｋｍしか移動していないときは、移動距離がしきい値を超えないので携帯端末２０Ａは移動距離を計測し続ける。測位手段による測位を継続し続けることは、消費電力の観点から好ましくない場合がある。そこで、条件（ｃ）では、原則として移動距離が第１しきい値（例えば１０ｋｍ）を超えた場合を相乗り成立としつつ、移動距離が第１しきい値に達していない場合であっても、移動開始後（すなわち移動距離が第２しきい値（第１しきい値より短い距離、例えば５００ｍ）を超えた後）の経過時間がしきい値時間（例えば２０分）を超えたときに、相乗りが成立したと判断される。

上記の（ａ）〜（ｃ）に加え、以下の条件（ｄ）が用いられてもよい。
（ｄ）ある旅程について複数の同乗者がいる場合に、同乗者全員が同一の識別信号を継続して受信している時間がしきい値を超えた。
サーバ１０は、ある旅程について複数の同乗者が予約されている場合において、識別信号を受信している旨の通知を、すべての同乗者から受信した場合、またはすべての同乗者からその通知を受信している状態がしきい値時間継続した場合、相乗りが成立したと判断する。なお、この条件において「同乗者全員が同一の識別信号を継続して受信している時間」という条件に代わり「同乗者のうち一定割合（例えば半分）以上が同一の識別信号を継続して受信している時間」という条件が用いられてもよい。

相乗りの成立条件が満たされたと判断された場合、ＣＰＵ１００は、処理をステップＳ２０９に移行する。相乗りの成立条件が満たされていないと判断されていない場合、ＣＰＵ１００は、相乗り判定を継続する。

ステップＳ２０９において、ＣＰＵ１００は、相乗りが成立したことを携帯端末２０Ｄおよび携帯端末２０Ａに通知する。この通知は、成立した相乗り予約の識別番号および同乗者のユーザ名を含む。この通知を受けると、携帯端末２０Ａのクライアントアプリは、識別信号の照合およびサーバ１０への情報の送信を停止する。また、この通知を受けると、携帯端末２０Ｄのクライアントアプリは、ＧＰＳ受信機２０７の機能を休止し、位置情報の取得およびサーバ１０への情報の送信を停止する。

ステップＳ２１０において、サーバ１０は、課金処理を行う。課金は、運転者および同乗者のうち少なくとも一方に対して行われる。ここでいう課金処理には、同乗者から運転者への費用の支払い、並びに運転者および同乗者からのシステム利用料の徴収がすべて含まれる。これらはすべてシステム側で行われる。例えば、同乗者の負担が２，０００円の旅程に対し２名の同乗者が同乗し、システム利用料が５％であった場合、運転者、同乗者、およびシステムの運営事業者に対する金銭の授受は以下のとおりとなる。
（１）運転者の受け取り金額
２，０００円／人×２人−２００円 ＝ ３，８００円
（２）同乗者の支払い金額
２，０００円＋１００円 ＝ ２，１００円
（３）運営事業者の受け取り金額
２００円＋１００円×２ ＝ ３００円

同乗者に対する課金は、例えば、あらかじめ登録されたクレジットカードによる決済、あらかじめ登録された銀行口座からの引き落とし、あらかじめ購入されたプリペイドポイントからの減殺等の処理により行われる。運転者に対する支払いは、例えば、あらかじめ登録された銀行口座への振り込み、運転者のユーザアカウントに対するプリペイドポイントの加算等の処理により行われる。なおここで説明した課金の形態はあくまで例示である。例えば、運転者および同乗者のいずれか一方のみからシステム利用料が徴収されてもよい。あるいは、相乗りの費用そのものは運転者と同乗者との間で現金による受け渡しとし、システム利用料のみをサーバ１０により課金してもよい。

本実施形態によれば、相乗りの成立を条件としてサーバ１０上で課金が行われるので、システム利用料を確実に徴収することができる。また、相乗り成立の条件としては、実際に相乗りが行われた高いものが用いられるので、例えば相乗りの前に課金されて同乗者に不満を与える可能性を低減することができる。

３．変形例
本発明は上述の実施形態に限定されるものではなく、種々の変形実施が可能である。以下、変形例をいくつか説明する。以下の変形例のうち２つ以上のものが組み合わせて用いられてもよい。

３−１．変形例１
相乗り判定を行う主体はサーバ１０に限定されない。例えば、同乗者の携帯端末２０Ａが相乗り判定を行ってもよい。この場合、携帯端末２０Ａは、相乗り判定に用いられる情報をサーバ１０に送信する必要はない。また、この場合、携帯端末２０Ａは、自身で取得可能な情報（例えば携帯端末２０Ａが同一の識別信号を継続して受信している時間、または携帯端末２０Ａが同一の識別信号を受信したままの状態で移動した距離）を用いて相乗り判定を行う。この例によれば、携帯端末２０Ａとサーバ１０との通信量を削減し、またサーバ１０における処理負荷を低減することができる。

３−２．変形例２
相乗りの成立条件は実施形態で例示したものに限定されない。実施形態で例示したものに変えて、または加えて、別の条件が用いられてもよい。例えば、以下の条件（ｅ）が用いられてもよい。
（ｅ）運転者および同乗者の現在位置と相乗りの予約情報により特定される経路とを対比し、両者と経路との距離がしきい値以下である。

３−３．変形例３
相乗りの成立条件におけるしきい値（時間のしきい値または距離のしきい値）は、各種の属性に応じて動的に変更されてもよい。例えば、これらのしきい値は、出発地と目的地との距離に応じて決められてもよい（例えば、出発地と目的地との距離の１０％をしきい値とする、等）。あるいは、出発日時に応じてしきい値が変動してもよい（例えば、夕方の時間帯は渋滞が予想されるのでしきい値を短く、等）。これらの場合、サーバ１０は、相乗りの募集要項が登録された後で、相乗り成立のためのしきい値を決定する。サーバ１０は、決定されたしきい値を予約情報に含めて、携帯端末２０Ａに送信する。別の例で、相乗りの成立条件として条件（ａ）が用いられる場合において、しきい値時間経過しても出発してからの移動距離がしきい値距離に満たないときは、クライアントアプリはしきい値時間を延長してもよい。

３−４．変形例４
相乗り実施の際、チェックイン処理が用いられてもよい。この場合、クライアントアプリの画面にチェックインボタンが設けられる。同乗者は、出発地（待ち合わせ場所）で運転者と会ったとき（または予約した同乗者が全員揃って出発したとき）に、チェックインボタンを押してチェックイン処理を行う。チェックイン処理が行われると、クライアントアプリは、チェックインが行われた旨をサーバ１０に通知する。チェックイン処理が行われると、クライアントアプリは、識別信号のサーチや位置情報の取得を停止してもよい。このチェックイン処理は、同乗者ではなく運転者に課してもよい。この場合、運転者は、同乗者が全員揃って出発する直前に携帯端末２０Ｄのクライアントアプリにより表示されたチェックインボタンを押してチェックイン処理を行う。

なお、チェックイン処理をユーザに確実に行わせるために、ユーザに何らかのインセンティブが与えられてもよい。例えば、チェックイン処理を行ったユーザに対してはシステム利用料を割り引いたり、ポイントを還元したりしてもよい。

また、チェックイン処理に代えて、または加えて、チェックアウト処理が用いられてもよい。この場合、クライアントアプリの画面にチェックアウトボタンが設けられる。同乗者は、乗っている自家用車が目的地に着いたときに、チェックアウトを押してチェックアウト処理を行う。

３−５．変形例５
実施形態においては相乗りの成立条件が満たされると課金が行われた。すなわち、課金の契機となる条件は相乗りの成立条件であった。しかし、課金の契機となる条件を相乗りの成立条件と異ならせてもよい。例えば、実施形態で説明した相乗りの成立条件に加え、チェックイン処理またはチェックアウト処理もしくはその両方が行われたことが、課金を行う条件として用いられてもよい。

別の例で、相乗りの予約成立時にサーバ１０がその予約に対してコードを発行し、このコードを運転者および同乗者の一方から他方に渡すことを課金の条件に加えてもよい。ここで用いられるコードは、文字列であってもよいし、画像（いわゆる２次元バーコード等）であってもよい。例えば、同乗者から運転者に２次元バーコードを渡すことが課金の条件として設定されていた場合、同乗者は、出発直前または到着後に、自身の携帯端末２０Ａにその２次元バーコードを表示させる。運転者は、自身の携帯端末２０Ｄにその２次元バーコードを読み取らせる。携帯端末２０Ｄは、読み取った２次元バーコードをサーバ１０に送信する。サーバ１０は、携帯端末２０Ｄから受信した２次元バーコードとデータベースに記録されているバーコードとを照合し、両者が一致すれば課金を行う。

３−６．変形例６
チェックイン処理またはチェックアウト処理が行われた場合、その時点における運転者または同乗者の位置が併せてサーバ１０に通知されてもよい。サーバ１０は、この位置情報を用いて、実際に相乗りが行われたことを検証してもよい。サーバ１０は、この位置情報をデータベースに記録してもよい。運転者の位置情報を記録しておけば、それはすなわち自家用車の位置情報を記録していることと等しい。例えば、チェックイン処理が行われたときの運転者の位置情報を記録しておけば、同乗者を運転者のところまで案内するための情報として用いることができる。あるいは、相乗りの目的地が広大な施設（遊園地、野球場、サッカー場、コンサートホールなど）であった場合においてチェックアウト処理が行われたときの運転者の位置情報を記録しておけば、目的地で用事を済ませた後の帰り、運転者を車の場所まで案内することができる。例えば広大な駐車場のうちどこに車を停めたのか覚えていなくても、運転者は、容易に自分の車まで到達することができる。

３−７．変形例７
相乗りの予約を行う際、旅程を検索する条件は実施形態で説明したものに限定されない。例えば、携帯端末２０Ａは、識別信号出力装置３０から出力される識別信号をキーとして、旅程の検索を行ってもよい。例えば、広大な駐車場に識別信号出力装置３０を搭載した自家用車が多数停まっているような状況においては、その駐車場にいる同乗希望者がクライアントアプリを起動して識別信号をサーチすれば、周囲に停車している自家用車のうち識別信号出力装置３０を搭載した自動車から、識別信号を検出することができる。１または複数の識別信号を検出すると、クライアントアプリは、検出した識別信号からそれぞれ識別番号を抽出する。クライアントアプリは、旅程の一覧の送信要求をサーバ１０に送信する。この要求には、識別信号から抽出された１または複数の識別番号が含まれている。サーバ１０は、予約データベースの中から、この識別番号に対応する運転者が作成した募集要項を抽出する。サーバ１０は、抽出した旅程の中から条件を満たすもの（例えば、出発日時当日であり、残席がゼロでないもの）を、要求の送信元である携帯端末２０Ａに送信する。

この例は、例えば以下のような利用シーンで有用である。あるユーザがサッカーの試合観戦やコンサート鑑賞のため、行きの旅程では相乗り支援サービスを利用したが、帰りの旅程については予約をしていない。サッカーの試合終了後またはコンサートの終演後、このユーザは、帰りの移動手段を確保していないことに気づき、駐車場でクライアントアプリを起動して帰りの相乗りを予約する。

なお、この例において、変形例６で説明したようにチェックアウト時の運転者の位置がデータベースに記録されていれば、サーバ１０は、識別番号により特定される旅程だけでなく、識別番号により特定される旅程に係る自家用車の近くに駐車している自家用車に係る旅程をも抽出し、抽出した旅程の一覧を相乗り希望者の携帯端末２０Ａに送信する。

３−８．変形例８
識別信号は、携帯端末２０とは別の識別信号出力装置３０から出力されるものに限定されない。運転者の所有する携帯端末２０Ｄ自身が、識別信号を出力してもよい。あるいは、カーナビゲーション装置やカーステレオ装置など、自家用車自体に取り付けられている装置が識別信号を出力してもよい。これらの場合は、識別信号出力装置３０は不要である。識別信号は、実施形態で説明したＢＬＥ技術によるビーコン信号に限定されず、ＢｌｕｅｔｏｏｔｈまたはＷｉＦｉ規格に準拠した信号、または音（例えばいわゆる音声すかしを用いたもの）による信号が用いられてもよい。

また、実施形態では識別信号出力装置３０を運転者に所有させたが、識別信号出力装置３０を同乗者に所有させてもよい。この場合、図１４で説明した携帯端末２０Ａの役割と携帯端末２０Ｄの役割とが入れ替わる。識別信号出力装置３０を用いない場合、携帯端末２０Ａが識別信号を出力してもよい。

３−９．変形例９
本発明の適用対象は自家用車の相乗りに限定されない。個人間の賃貸借に本発明が適用されてもよい。実施形態で説明した相乗り支援システム１は、自家用車の空席を賃貸借の目的物、運転者を賃貸人、同乗者を賃借人とする賃貸借支援システムとして一般化することができる。この場合、相乗り支援システム１は、賃貸借の目的物を所有する賃貸人およびこの目的物を賃借する賃借人をマッチングするマッチング手段と、目的物および賃借人が所定の範囲内に近づいたことを検知する検知手段と、目的物および同乗者が範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、賃貸借が行われているか判断する判断手段と、賃貸借が行われていると判断された後で、賃貸人および賃借人の少なくとも一方に課金する課金手段とを有する賃貸借支援システムの一例であるといえる。

この賃貸借支援システムは、例えば、自宅の駐車場の一時貸しに適用することができる。具体的には、賃貸人であるユーザは、実施形態で説明した旅程の登録と同様に、自宅の駐車場の空き予定をサーバに登録する。賃借人であるユーザは、サーバに記録されているデータベースから、自分の要求に合う募集要項を検索し、駐車場の使用予約をする。賃借人の自家用車には識別信号出力装置が搭載されており、賃貸人の自宅駐車場近辺には、識別信号出力装置からの識別信号を受信し、サーバとも通信する通信装置が設置されている。

賃借人であるユーザは、自分の自家用車を運転して目的の駐車場まで行き、そこに自家用車を停める。自家用車を停めた後は、賃借人であるユーザは、特別な操作をすることなくその場を立ち去ることができる。

賃借人の自家用車が駐車場に停車すると、賃貸人の通信装置は、この自家用車に搭載されている識別信号出力装置から、識別信号を受信する。この識別信号に基づいて、通信装置またはサーバは、賃貸借が実際に行われたことを検知することができる。例えば、識別信号を継続して受信している時間がしきい値を超えたとき（すなわち、賃借人の自家用車を所定の時間、賃貸人の自宅駐車場に停めたままにしておいたとき）賃貸借が成立したと判定される。賃貸借が成立したと判定すると、サーバは賃貸人および賃借人の少なくとも一方に対し課金する。

このように、変形例９によれば、より簡単な操作で、個人間の賃貸借に対して確実に課金をすることができる。

３−１０．他の変形例
相乗り支援システム１において、サーバとクライアントとの機能の分担は実施形態で説明したものに限定されない。実施形態においてサーバの機能として説明されたものの一部がクライアントに実装されてもよいし、クライアントの機能として説明されたものの一部がサーバに実装されてもよい。あるいは、同乗者の携帯端末２０Ａの機能の一部を運転者の携帯端末２０Ｄに実装してもよい。

マッチング処理の詳細は、図７で例示したものに限定されない。例えば、旅程の一覧を要求する際の絞り込み条件を、過去の履歴を参照してサーバ１０またはクライアントアプリが自動的に生成し、これをデフォルトの条件としてユーザに提示してもよい。あるいは、マッチング処理は、同乗者であるユーザの選択によるものではなく、サーバ１０により自動的に行われてもよい。

旅程が新規に登録される際、サーバ１０は、その旅程に係る募集要項が相乗り支援システムの利用規程に沿っているかチェックしてもよい。例えば、同乗者に請求できる機能が実費の範囲内と規定されているような場合に、出発地と目的地との距離、運転者が所有する自家用車の車種や年式の情報から基準となる実費（ガソリン代＋有料道路代）を募集人数で除した基準金額をサーバ１０が算出する。サーバ１０は、募集要項に入力された費用がこの基準金額から著しく乖離している場合（例えば１．５倍以上）、ユーザに警告を発し、登録を拒否してもよい。あるいは、サーバ１０は、上記のとおり算出された基準金額を、募集要項を入力しているユーザに対して提示してもよい。

相乗りの処理の詳細は図１４で例示したものに限定されない。例えば、運転者のプロフィール情報は予約情報と一緒に送られず、携帯端末２０が識別信号出力装置３０から識別信号を受信したときに、サーバ１０に対し問い合わせを行い、最新のプロフィール情報を受信してもよい。

サーバ１０、携帯端末２０、および識別信号出力装置３０のハードウェア構成は、実施形態において例示したものに限定されない。要求した機能を実現できるものであれば、これらの装置はどのようなハードウェア構成を有していてもよい。例えば、携帯端末２０は、ラップトップ型のＰＣ（Personal Computer）であってもよい。

サーバ１０または携帯端末２０において実行されるプログラムは、磁気記録媒体（磁気テープ、磁気ディスク（ＨＤＤ、ＦＤ（Flexible Disk））など）、光記録媒体（光ディスク（ＣＤ（Compact Disk）、ＤＶＤ（Digital Versatile Disk））など）、光磁気記録媒体、半導体メモリ（フラッシュＲＯＭなど）などのコンピュータ読取り可能な記録媒体に記憶した状態で提供されてもよい。また、このプログラムは、インターネットのようなネットワーク経由でダウンロードされてもよい。

１…相乗り支援システム、１０…サーバ、１１…マッチング手段、１２…通知手段、１３…課金手段、１４…記憶手段、２０…携帯端末、２１…検知手段、２２…判断手段、２３…通知手段、３０…識別信号出力装置、１００…ＣＰＵ、１０１…ＲＯＭ、１０２…ＲＡＭ、１０３…ストレージ、１０４…通信ＩＦ、２００…ＣＰＵ、２０１…ＲＯＭ、２０２…ＲＡＭ、２０３…ストレージ、２０４…通信ＩＦ、２０５…表示装置、２０６…入力装置、３００…ＲＯＭ、３０１…発信器

Claims (11)

1. 自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングするマッチング手段と、
   前記運転者および前記同乗者が所定の範囲内に近づいたことを検知する検知手段と、
   前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断する判断手段と、
   前記同乗者が前記自家用車に同乗していると判断された後で、前記運転者および前記同乗者の少なくとも一方に課金する課金手段と
   を有する相乗り支援システム。
2. 前記判断手段は、前記時間または前記移動距離がしきい値を超えた場合、前記同乗者が前記自家用車に同乗していると判断する
   ことを特徴とする請求項１に記載の相乗り支援システム。
3. 前記判断手段は、前記移動距離がしきい値距離に達していない場合において前記時間がしきい値を超えたときは、前記同乗者が前記自家用車に同乗していると判断する
   請求項２に記載の相乗り支援システム。
4. 前記運転者に所有され、固有の識別信号を出力する識別信号出力装置を有し、
   前記検知手段は、前記運転者および前記同乗者が近づいたことを前記識別信号を用いて検知する
   ことを特徴とする請求項１ないし３のいずれか一項に記載の相乗り支援システム。
5. 前記同乗者に携帯され、情報を表示する表示手段を有する携帯端末を有し、
   前記同乗者が前記運転者に近づいたことが前記検知手段により検知された場合、前記表示手段は、当該運転者に固有の情報を表示する
   ことを特徴とする請求項１ないし４のいずれか一項に記載の相乗り支援システム。
6. 複数の自家用車について行き先を示す行き先情報を記憶する記憶手段を有するサーバを有し、
   前記携帯端末は、前記複数の自家用車の中から所望の自家用車を検索するための検索条件の入力を受け付ける受け付け手段を有し、
   前記表示手段は、前記複数の自家用車の中から抽出された、前記検索条件に適合する自家用車の一覧を表示する
   ことを特徴とする請求項５に記載の相乗り支援システム。
7. 前記記憶手段は、前記複数の自家用車の少なくとも一部の自家用車の現在位置を示す情報を記憶しており、
   前記表示手段は、前記現在位置を含む前記一覧を表示する
   ことを特徴とする請求項６に記載の相乗り支援システム。
8. 自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングするマッチング手段を有するサーバから、当該マッチングの結果を受信する受信手段と、
   前記運転者および前記同乗者が所定の範囲内に近づいたことを検知する検知手段と、
   前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断する判断手段と、
   前記同乗者が前記自家用車に同乗していると判断されたことを前記サーバに通知する通知手段と
   を有する携帯端末。
9. コンピュータに、
   自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングするマッチング手段を有するサーバから、当該マッチングの結果を受信するステップと、
   前記運転者および前記同乗者が所定の範囲内に近づいたことを検知するステップと、
   前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断するステップと、
   前記同乗者が前記自家用車に同乗していると判断されたことを前記サーバに通知するステップと
   を実行させるためのプログラム。
10. 自家用車を運転する運転者および当該自家用車に同乗する同乗者をマッチングした結果を示すデータを受信するステップと、
    前記運転者および前記同乗者が所定の範囲内に近づいたことを検知するステップと、
    前記運転者および前記同乗者が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記同乗者が前記自家用車に同乗しているか判断するステップと、
    前記同乗者が前記自家用車に同乗していると判断された後で、前記運転者および前記同乗者の少なくとも一方に課金するステップと
    を有する相乗り支援方法。
11. 賃貸借の目的物を所有する賃貸人および当該目的物を賃借する賃借人をマッチングするマッチング手段と、
    前記目的物および前記賃借人が所定の範囲内に近づいたことを検知する検知手段と、
    前記目的物および前記賃借人が前記範囲内に近づいている状態が継続している時間および当該状態における移動距離の少なくとも一方に基づいて、前記賃貸借が行われているか判断する判断手段と、
    前記賃貸借が行われていると判断された後で、前記賃貸人および前記賃借人の少なくとも一方に課金する課金手段と
    を有する賃貸借支援システム。

Images