JP2004227490A - コミュニティ管理システムおよびその方法 - Google Patents

Abstract

【課題】共通の目的を持つユーザ同士がコミュニケーションをとることをサポートするコミュニティ管理システムおよびその方法を提供することを目的とする。
【解決手段】携帯電話１００は、ユーザの行動目的を含む第１エントリー情報をサービスサーバ３００に送信する。携帯電話１０２は、第２エントリー情報をサービスサーバ３００に送信する。サービスサーバ３００は、第１エントリー情報と第２エントリー情報とが適合するか否かを判断する。サービスサーバ３００は、携帯電話１００および１０２に対して、共通エントリー情報を送信する。あるいは、サービスサーバ３００は、携帯電話１０２に第１エントリー情報を送信するか、携帯電話１００に第２エントリー情報を送信する。あるいは、サービスサーバ３００は、携帯電話１００および１０２の間でのｅメール通信または電話通話を許可する。
【選択図】 図２

Description

【０００１】
【発明の属する技術分野】
この発明は、コミュニティ管理システムおよびその方法に関するものであり、特に、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることに関する。
【０００２】
【従来の技術】
携帯端末を利用した様々な情報の送受信を行うシステムが運営されている。例えば、携帯端末のユーザは、自分のいる場所に関する情報（買い物情報、飲食店情報、交通機関情報など）を受信することによって一定の利益を得ることができる。
【０００３】
ここで、従来のシステムでは、携帯端末のユーザが得る情報は、その情報を提供する業者によって作成・提供されるものであった。しかしながら、携帯端末のユーザにとっては、そのような業者からの情報だけではなく、その情報を利用して行動する他のユーザからの新しい情報（経験、感想、知識など）を要望する場合もある。
【０００４】
そのような要望を満たすため、情報端末装置から位置情報付きの情報を送受信することにより、他の情報端末装置をもつ所有者の情報（例えば、他の人がシステムに登録した経験や知識等）を得ることのできる技術がある。（例えば、特許文献１参照）。
【０００５】
【特許文献１】
特開２００１−２８５５２６号公報（第１図）
【発明が解決しようとする課題】
上記のような技術によれば、携帯端末ユーザは、業者によって作成されたコンテンツだけではなく、他の携帯端末ユーザからの情報を共有することができるという一定のメリットがある。
【０００６】
しかしながら、携帯端末ユーザにとっては、他のユーザとの情報の共有だけではなく、より積極的に他のユーザとコミュニケーションをとることを望むことも多い。具体的には、自分の居る場所や特定の場所において、目的を共通にする他のユーザと互いの情報をリアルタイムで交換したり、あるいは、目的を共通にする他のユーザと行動を共にすることを望む場合もある。例えば、共通の目的地にタクシー移動をする場合に他のユーザとの乗り合いを申し込んだり、あるいは、大量購入によって割引きのメリットを受けることのできる商品について他のユーザとの共同購入を申し込んだりする等の状況を挙げることができる。
【０００７】
本発明は、上記のような要求に鑑みて、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートするコミュニティ管理システムおよびその方法を提供することを目的とする。
【０００８】
【課題を解決するための手段および発明の効果】
１）本発明のコミュニティ管理システムは、
第１の端末装置および第２の端末装置と、当該端末装置と通信可能であって、当該端末装置からのエントリー情報を受け付けるサーバ装置とを備えたコミュニティ管理システムであって、
前記第１の端末装置は、第１のエントリー情報を送信し、
前記第２の端末装置は、第２のエントリー情報を送信し、
前記サーバ装置は、
前記第１のエントリー情報と第２のエントリー情報とにアクセス可能であり、
前記第１のエントリー情報と第２のエントリー情報とを取得し、
前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断する適合判断処理を行い、
前記適合部分を有すると判断した場合には、前記第１の端末装置と第２の端末装置とを関連づける関連処理を行うこと、
を特徴としている。
【０００９】
これらの特徴により、前記エントリー情報に適合部分を有する前記端末装置のユーザ同士は、前記関連処理によって関連づけられることができる。したがって、前記コミュニティ管理システムは、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。
【００１０】
４）本発明の前記サーバ装置の関連処理は、
前記第１の端末装置と第２の端末装置とに対して前記適合部分の内容に関する共通エントリー情報を送信することを含むこと、
を特徴としている。
【００１１】
この特徴により、前記端末装置のユーザ同士は、前記共通エントリー情報を共有することを介して関連づけられることができる。
【００１２】
５）本発明の前記サーバ装置の関連処理は、
前記第１の端末装置に対して前記第２のエントリー情報に関連する情報を送信すること、または、前記第２の端末装置に対して前記第１のエントリー情報に関連する情報を送信することの少なくともいずれかを含むこと、
を特徴としている。
【００１３】
この特徴により、前記端末装置のユーザ同士は、前記エントリー情報の送受信または交換をすることを介して関連づけられることができる。
【００１４】
６）本発明の前記サーバ装置の関連処理は、
前記第１の端末装置と第２の端末装置との間を通信可能状態にすることを含むこと、
を特徴としている。
【００１５】
この特徴により、前記端末装置のユーザ同士は、互いに通信することを介してコミュニケーションをとることができる。
【００１６】
７）本発明の前記サーバ装置の前記適合判断処理は、
前記第１のエントリー情報と第２のエントリー情報との共通部分の有無を判断することを含むこと、
を特徴としている。
【００１７】
この特徴により、前記端末装置のユーザは、前記エントリー情報に共通部分を含む他のユーザと関連づけられることができる。したがって、前記コミュニティ管理システムは、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。
【００１８】
８）本発明の前記エントリー情報は、当該エントリー情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第１の端末装置の端末位置情報と前記第２の端末装置の端末位置情報とが適合するか否かに基づいて、前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴としている。
【００１９】
この特徴により、前記端末装置のユーザは、前記端末位置情報が適合する他のユーザと関連づけられることができる。
【００２０】
９）本発明の前記エントリー情報は、当該エントリー情報を送信する前記端末装置のユーザのプロファイル情報を含んでおり、
前記サーバ装置の前記適合部分判断処理は、
前記第１の端末装置のプロファイル情報と前記第２の端末装置のプロファイル情報とが適合するか否かに基づいて、前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴としている。
【００２１】
この特徴により、前記端末装置のユーザは、前記プロファイル情報が適合する他のユーザと関連づけられることができる。
【００２２】
１０）本発明の前記エントリー情報は、前記端末装置のユーザが利用を希望する車両に関する車両予約情報を含んでおり、
前記共通エントリー情報は、前記第１の端末装置および第２の端末装置の両方のユーザが利用を予定する車両に関する乗合い車両予約情報を含むこと、
を特徴としている。
【００２３】
この特徴により、前記端末装置のユーザ同士は、前記乗合い車両予約情報を共有することを介して、前記車両の乗合いを行うことができる。
【００２４】
１１）本発明の前記車両予約情報は、
前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかを含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第１のエントリー情報に含まれる車両予約情報と前記第２のエントリー情報に含まれる車両予約情報とにおける、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかの共通部分の有無を判断することを含むこと、
を特徴としている。
【００２５】
この特徴により、前記端末装置のユーザは、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかが共通する他のユーザと、前記車両の乗合いをすることができる。
【００２６】
１２）本発明の前記乗合い車両予約情報は、
前記車両を利用するユーザ人数に関する車両利用人数、または、当該車両の利用に関して当該ユーザが負担する車両利用料金情報のいずれかの内容を含むこと、
を特徴としている。
【００２７】
この特徴により、前記端末装置のユーザは、前記乗合い車両予約情報に含まれる車両予約人数、または、車両利用料金情報により、前記車両の乗合いの予定を確認することができる。
【００２８】
１３）本発明の前記車両予約情報は、当該車両予約情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置は、さらに、
前記端末位置情報に基づいて、当該端末装置の位置から前記出発地までの経路に関する経路情報を当該端末装置に対して送信すること、
を特徴としている。
【００２９】
この特徴により、前記端末装置のユーザは、前記経路情報を利用することによって、前記出発地までの経路の選択を容易に決定することができる。
【００３０】
１４）本発明の前記サーバ装置は、さらに、
前記車両の位置に関する車両位置情報、または当該車両の空車状況に関する車両空車情報の少なくともいずれかに基づいて前記乗合い車両予約情報が対象とする車両を決定すること、
を特徴としている。
【００３１】
この特徴により、前記サーバ装置は、前記端末装置のユーザに対する車両の手配を効率的に行うことができる。
【００３２】
１５）本発明の前記エントリー情報は、前記端末装置のユーザが享受するサービスの申込みに関する情報であり、
前記サーバ装置は、さらに、
前記関連処理によって関連づけられた前記第１の端末装置および第２の端末装置の各ユーザが前記サービスの享受に関して負担する各サービス料金を、前記端末装置が前記エントリー情報を送信した順序、または当該サーバ装置が当該エントリー情報を取得した順序のいずれかに基づいて決定すること、
を特徴としている。
【００３３】
この特徴により、前記サーバ装置は、前記サービス料金を前記端末装置のユーザ毎に決定することができる。
【００３４】
１６）本発明の前記サーバ装置は、
前記第１の端末装置または第２の端末装置の中で、前記エントリー情報を先に送信した端末装置のユーザ、または当該サーバ装置が先に取得した前記エントリー情報に関する端末装置のユーザのサービス料金を、他の端末装置のユーザよりも低く決定すること、
を特徴としている。
【００３５】
この特徴により、前記サーバ装置は、よりアクセスの早かった前記端末装置のユーザの前記サービス料金の負担を、他のユーザよりも優遇することができる。したがって、前記携帯端末のユーザに対して、前記サーバ装置へのアクセスのインセンティブを増加させることができる。
【００３６】
以下、用語の定義について説明する。
【００３７】
この発明において、
「エントリー情報」とは、自分以外の他者との情報の共有または情報のやり取り、あるいは、サービスの共有またはやり取りを行うことを目的として利用する情報一般を含む概念である。例えば、他者との乗合いを目的としたタクシーの乗車予約の情報、または、他者との情報交換を目的としたコンサートや演劇などのイベントへの参加に関連する情報などが、この概念に含まれる。実施形態では、コミュニティリクエスト情報または予約リクエスト情報が、この「エントリー情報」に含まれる。
【００３８】
「プロファイル情報」とは、個人または団体の属性一般を含む概念である。例えば、個人の肩書き、または性別、または年齢（年齢層）、または団体の組織名などがこの概念に対応する。実施形態では、図９のコミュニティＤＢ４００に記録される「グループ」の情報（例えば、大学名、会社名、サークル名など）が、この「プロファイル情報」に含まれる。
【００３９】
「第１のエントリー情報と第２のエントリー情報との間の適合部分」とは、第１のエントリー情報と第２のエントリー情報との間で、情報が完全に一致する部分、または情報が部分一致する部分、または情報の属性が一致する部分、または情報の類似度が高い部分を含む概念である。実施形態では、図９に示すユーザ（メールアドレス「１２３＠ｃｏｍ．ｎｅ．ｊｐ」に対応）のコミュニティリクエスト情報と、ユーザ（メールアドレス「ａｉｕ＠ｚｍａｉｌ．ｎｅ．ｊｐ」に対応）のコミュニティリクエスト情報との間で一致する、「タイトル」および「通信開始希望日時」の各情報、または、情報の一致度の高い「ユーザ現在地」の情報が、この「第１のエントリー情報と第２のエントリー情報との間の適合部分」に含まれる。
【００４０】
【発明の実施の形態】
本発明のコミュニティ管理システムの実施形態としての「コミュニティシステム」について説明する。このコミュニティシステムは、共通の目的を持つ携帯端末ユーザ同士が、他のユーザとのコミュニケーションをとることをサポートするシステムである。
【００４１】
以下の説明では、第１実施形態として、本システムが、共通の目的を持つ携帯端末ユーザ同士のコミュニティを設定する処理を説明する。次に、第２実施形態として、本システムが、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約を設定する処理（タクシー乗り合わせ予約の処理）を説明する。
【００４２】
以下、コミュニティシステムの概略、装置のハードウェア構成、特許請求の範囲に記載した用語と実施形態との対応を説明し、次に各実施形態の説明等を行う。
目次
１．コミュニティシステムの概要
２．ハードウェア構成等
３．特許請求の範囲に記載した用語と実施形態との対応
４．第１実施形態（コミュニティ設定処理）
５．第１実施形態による効果
６．第２実施形態（タクシー共同予約設定処理）
７．第２実施形態による効果
８．その他の実施形態等
−−−−−−−−−−−−−−−−−−−
−−１．コミュニティシステムの概要−−
図１は、実施形態による、コミュニティ管理システムとしてのコミュニティシステムの概略である。コミュニティシステムは、ユーザが使用する携帯電話１００、１０２、１０４、およびＧＰＳ衛星２５０（ＧＰＳ＝Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ、全地球測位システム）、本システムのサービスを提供するサービスサーバ３００で構成される。さらに、第２実施形態においては、配車コントロールサーバ７００が、タクシー予約に対応するタクシーの配車を設定する。携帯電話１００、１０２、１０４、サービスサーバ３００、配車コントロールサーバ７００のそれぞれは、インターネット２００を介して接続可能である。
【００４３】
サービスサーバ３００は、第１実施形態による処理の際に利用するコミュニティデータベース（以下、データベースを「ＤＢ」とする）４００、第２実施形態による処理の際に利用するタクシー予約ＤＢ５００を記録する。配車コントロールサーバ７００は、配車スケジュールＤＢ６００を記録する。各データベースの記録内容については後述する。
【００４４】
なお、コミュニティＤＢ４００、タクシー予約ＤＢ５００、配車スケジュールＤＢ６００のそれぞれは、各サーバのハードディスクに記録するようにしてもよいし、あるいは、各サーバとは別のサーバに記録するようにしてもよい。携帯電話およびサーバの数、構成については例示であって、当業者に周知の手段によって変形可能である。
【００４５】
次に、図２に基づいてコミュニティシステムの処理の概要を説明する。携帯電話１００（第１の端末装置）は、ユーザの操作に応じて、そのユーザの行動目的を含む第１エントリー情報をサービスサーバ３００に送信する（１）。サービスサーバ３００は、受信した第１エントリー情報を記録する（２）。携帯電話１０２（第２の端末装置）は、ユーザの操作に応じて第２エントリー情報をサービスサーバ３００に送信する（３）。サービスサーバ３００は、受信した第２エントリー情報を記録する（４）。サービスサーバ３００は、第１エントリー情報と第２エントリー情報とが適合するか否かを判断する（５）。
【００４６】
これらの処理により、複数の携帯電話のユーザの中で、共通の行動目的を持つユーザの組み合わせが有るか否かが判断される。サービスサーバ３００は、第１エントリー情報と第２エントリー情報とが適合すると判断した場合には、記号６−Ａ、Ｂ、Ｃに記載するいずれか、あるいはそれらを組み合わせた処理を行い、共通の行動目的を持つユーザ同士のコミュニティを設定する。
【００４７】
具体的には、サービスサーバ３００は、携帯電話１００および１０２に対して、共通エントリー情報を送信する（記号６−Ａ）。あるいは、サービスサーバ３００は、携帯電話１０２（第２の端末装置）に第１エントリー情報を送信するか、携帯電話１００（第１の端末装置）に第２エントリー情報を送信する（６−Ｂ）。あるいは、サービスサーバ３００は、携帯電話１００および１０２の間でのｅメール通信または電話通話を許可する（６−Ｃ）。
【００４８】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士のコミュニティが設定される。第１実施形態におけるコミュニティの設定は、サービスサーバ３００が、携帯電話のユーザ同士のメール交換を可能とする例を採用する（図２記号６−Ｃ参照）。一方、第２実施形態におけるコミュニティの設定は、サービスサーバ３００が、タクシーの乗合いのための共通予約情報のメールを、その乗合いに参加するユーザの携帯電話に送信する例を採用する（図２記号６−Ａ参照）。なお、上記図２の各処理の詳細は、第１実施形態および第２実施形態において説明する。
【００４９】
−−２．ハードウェア構成等−−
２−１．機能ブロック
図３は、コミュニティシステムの機能ブロック図を示す。携帯電話１００（携帯電話１０２、１０４も同様）は、エントリー情報を送信するエントリー情報送信手段８０を備えている。
【００５０】
一方、サービスサーバ３００は、エントリー情報を受信するエントリー情報受信手段８２、エントリー情報を記録するエントリー情報記録部８４、エントリー情報適合判断手段８６、端末装置関連付け手段８８を備えている。エントリー情報適合判断手段８６は、複数のエントリー情報の間の適合部分の有無を判断する処理を行う。端末装置関連付け手段８８は、エントリー情報適合判断手段８６によって、複数のエントリー情報の間に適合部分が有ると判断した場合に、それら複数のエントリー情報を送信した端末装置同士を関連づける処理を行う。
【００５１】
２−２．携帯電話
図４は、図３の携帯電話１００（携帯電話１０２、１０４も同様）をＣＰＵを用いて実現した場合のハードウェア構成の一例である。携帯電話１００は、ＣＰＵ１０、ＲＡＭ１２、ＲＯＭ１４、ディスプレイ２２、入力部１８、スピーカ２０、インターネット２００に接続するための通信回路１６、ＧＰＳ衛星からの電波を受信するＧＰＳ受信機２１を備えている。ＣＰＵ１０は、携帯電話１００全体を制御する。ＲＡＭ１２は、ＣＰＵ１０のワーク領域等を提供する。ＲＯＭ１４には、ＣＰＵ１０を動作させるためのプログラムや、ウェブを閲覧するためのブラウザプログラムが記録されている。入力部１８の操作により生成される操作情報は、ＣＰＵ１０に入力され、ＣＰＵ１０が生成した画像情報及び音声情報は、ディスプレイ２２、スピーカ２０にそれぞれ出力される。なお、ブラウザプログラムは、ＥＺｗｅｂ（登録商標）、ｉ−ｍｏｄｅ（登録商標）等の通常のプログラムを使用すればよく、本システム専用のプログラム等は必要ではない。
【００５２】
２−３．サービスサーバ
図５は、図３のサービスサーバ３００をＣＰＵを用いて実現した場合のハードウェア構成の一例である。サービスサーバ３００は、ＣＰＵ３０、ハードディスク３４、メモリ３２、キーボード／マウス３８、ディスプレイ４０、スピーカ４２、インターネット２００に接続するための通信回路３６を備えている。ＣＰＵ３０は、サービスサーバ３００全体を制御する。メモリ３２は、ＣＰＵ３０のワーク領域等を提供する。キーボード／マウス３８の操作により生成される操作情報は、ＣＰＵ３０に入力され、ＣＰＵ３０が生成した画像情報及び音声情報は、ディスプレイ４０、スピーカ４２にそれぞれ出力される。ハードディスク３４には、コミュニティＤＢ４００、タクシー予約ＤＢ５００、本システムのコミュニティ設定プログラムが記録されている。なお、このプログラムによる本システムの運営は、ＥＺｗｅｂ（登録商標）、ｉ−ｍｏｄｅ（登録商標）等のサービスを利用して行えばよい。
【００５３】
２−４．配車コントロールサーバ
図６は、図３の配車コントロールサーバ７００をＣＰＵを用いて実現した場合のハードウェア構成の一例である。配車コントロールサーバ７００は、ＣＰＵ６０、ハードディスク６４、メモリ６２、キーボード／マウス６８、ディスプレイ７０、スピーカ７２、インターネット２００に接続するための通信回路６６を備えている。各ハードウェアの機能は、図５のサービスサーバ３００の場合と同様である。ハードディスク６４には、配車スケジュールＤＢ６００（図１４参照）と、本システムの配車コントロールプログラムが記録されている。
【００５４】
本実施形態では、サービスサーバ３００および配車コントロールサーバ７００のオペレーティングシステム（ＯＳ）の例として、マイクロソフト社のＷｉｎｄｏｗｓ（登録商標）ＸＰ、ＮＴ、２０００等を用いることとする。本実施形態のプログラムは、ＯＳと共働して各機能を実現しているが、これに限らず、プログラム単独で各機能を実現するようにしてもよい。
【００５５】
２−５．データベース
次に、本システムのデータベースの構成例について説明する。本システムでは、サービスサーバ３００が、コミュニティＤＢ４００およびタクシー予約ＤＢ５００を記録し、配車コントロールサーバ７００が、配車スケジュールＤＢ６００を記録する。
【００５６】
図９は、サービスサーバ３００が記録するコミュニティＤＢ４００の構成例である。コミュニティＤＢ４００には、携帯電話のユーザによって入力された各ユーザのコミュニティリクエスト情報が記録される。このコミュニティリクエスト情報は、携帯電話のユーザ同士のコミュニティを設定する際の判断材料になるものである。具体的には、コミュニティＤＢ４００には、コミュニティリクエスト情報が記録された日付（「Ｄａｔｅ」）、ユーザの「メールアドレス」、ユーザが使用する携帯端末の所在を示す「ユーザ現在地（Ｘ（緯度）、Ｙ（経度）、Ｚ（高度））」、ユーザが属する「グループ」、コミュニティリクエストの内容を示す「タイトル」、本システムを通じてコミュニティが設定される場合に、コミュニティに参加するメンバー同士でのメール交換の開始を希望する時間を示す「通信可能希望日時」の各情報が、ユーザ毎に記録される。
【００５７】
図１３は、サービスサーバ３００が記録するタクシー予約ＤＢ５００の構成例である。タクシー予約ＤＢ５００には、携帯電話のユーザによって入力された各ユーザの予約リクエスト情報が記録される。この予約リクエスト情報は、携帯電話のユーザ同士がタクシーの乗合い予約を設定する際の判断材料になるものである。具体的には、タクシー予約ＤＢ５００には、予約リクエスト情報を送信したユーザ毎に、そのユーザを特定する「ユーザメールアドレス」、サービスサーバ３００が設定したタクシー予約を特定する「予約スケジュールＮｏ．」、そのユーザが乗合いを許可するか否かの情報を示す「乗合い許可」、タクシーの乗合いがあった場合のユーザのタクシー料金の負担割合を示す「料金割合」、予約されたタクシーを特定する「タクシーＮｏ．」、ユーザが所有する携帯電話の現在地（すなわち、ユーザの現在地）を示す「現在地」、予約したタクシーの「乗車時刻」、「乗車地」、「目的地」の各情報が記録される。
【００５８】
図１４は、配車コントロールサーバ７００が記録する配車スケジュールＤＢ６００の構成例である。配車スケジュールＤＢ６００には、各タクシー毎の予約スケジュールが記録される。具体的には、配車スケジュールＤＢ６００には、タクシー毎に、タクシーを特定する「タクシーＮｏ．」、そのタクシーに割り当てられた予約スケジュールを特定する「予約スケジュールＮｏ．」、ユーザがそのタクシーに乗車する予定時刻である「乗車時刻」、ユーザがそのタクシーに乗車する場所を特定する「乗車地」、タクシー移動の目的場所を特定する「目的地」の各情報が記録される。
【００５９】
−−３．特許請求の範囲に記載した用語と実施形態との対応−−
特許請求の範囲に記載した用語と実施形態との対応は以下の通りである。
【００６０】
「第１の端末装置」は、携帯電話１００または１０２に対応し、「第２の端末装置」は、携帯電話１００または１０２に対応する。「エントリー情報」は、コミュニティリクエスト情報または予約リクエスト情報に対応する。「サーバ装置」は、サービスサーバ３００または配車コントロールサーバ７００に対応する。
【００６１】
「適合判断処理」は、図８ステップＳ８５２の処理または図１２ステップＳ１２０３の処理を行うＣＰＵ３０に対応する。「関連処理」は、図８ステップＳ８５９の処理または図１２ステップＳ１２１５の処理を行うＣＰＵ３０に対応する。「共通エントリー情報」は、コミュニティ設定情報に含まれる情報（図８ステップＳ８５９参照）、または予約確認メールに含まれる情報（図１２ステップＳ１２１５参照）に対応する。
【００６２】
「端末位置情報」は、図９のコミュニティＤＢ４００に記録される「ユーザ現在地」の情報、または図１３のタクシー予約ＤＢ５００に記録される「現在地」の情報に対応する。「プロファイル情報」は、コミュニティＤＢ４００に記録される「グループ」の情報に対応する。
【００６３】
「車両予約情報」および「サービスの申込みに関する情報」は、予約リクエスト情報に対応し、「乗合い車両予約情報」は、予約確認メールに含まれる情報（図１２ステップＳ１２１５参照）に対応する。「車両利用人数」は、図１５Ｂの画面表示例における「現在の乗合い人数」の情報に対応し、「車両利用料金情報」は、図１５Ｂの「お客様の料金負担割合」の情報に対応する。
【００６４】
「経路情報」は、図１５Ｂの画面表示例における「乗車位置までの最短経路のご案内」に含まれる情報に対応する。
【００６５】
−−４．第１実施形態（コミュニティ設定処理）−−
コミュニティシステムの第１実施形態として、共通の目的を持つ携帯端末ユーザ同士のコミュニティを設定する処理を説明する。第１実施形態におけるコミュニティの設定は、サービスサーバ３００が、携帯電話のユーザ同士のメール交換を可能とする例を採用する（図２記号６−Ｃ参照）。
【００６６】
４−１．第１実施形態（コミュニティ設定処理）の概要
図７は、コミュニティ設定処理の概要図である。携帯電話１００は、ユーザの操作に応じてコミュニティリクエスト情報をサービスサーバ３００に送信する（１）。サービスサーバ３００は、受信したコミュニティリクエスト情報を記録する（２）。
【００６７】
携帯電話１０２は、ユーザの操作に応じてコミュニティリクエスト情報をサービスサーバ３００に送信する（３）。サービスサーバ３００は、受信したコミュニティリクエスト情報を記録する（４）。サービスサーバ３００は、以上の処理により、複数のコミュニティリクエスト情報を記録した場合に、それらのコミュニティリクエスト情報についてデータマッチング処理（データ照合）を行う（５）。
【００６８】
サービスサーバ３００は、照合するコミュニティリクエスト情報が有ると判断した場合には、それらのコミュニティリクエスト情報を送信した携帯電話（図７では、携帯電話１００および携帯電話１０２を想定）のユーザ同士でのｅメール通信を許可するか否かを、それらの携帯電話のユーザに確認する処理を行う（６）。サービスサーバ３００は、ｅメール通信の許可の確認があった場合には、携帯電話１００および１０２のユーザ同士のｅメール通信を許可する処理を行う（７）。
【００６９】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士について、相互のメール交換を介したコミュニティが設定される。
【００７０】
４−２．第１実施形態（コミュニティ設定処理）のフローチャート
次に、図８に基づき、第１実施形態（コミュニティ設定処理）における各装置のＣＰＵが実行するプログラムのフローチャートを説明する。図８のフローチャートは、サービスサーバ３００のコミュニティＤＢ４００に既に複数の携帯電話のユーザからのコミュニティリクエスト情報が記録されている状態を前提として、携帯電話１００のユーザが、サービスサーバ３００に対して新たにコミュニティリクエスト情報を送信する例を説明するものである。ただし、以下に説明するフローチャートは例示であって、コミュニティ設定処理のプログラム、アルゴリズムは、当業者に周知の手法によって変形可能である。
【００７１】
携帯電話１００のＣＰＵ１０は、ユーザの操作に応じてブラウザプログラムを立ち上げてサービスサーバ３００にアクセスし、コミュニティリクエスト情報を送信する（図８ステップＳ８０１）。
【００７２】
ここで、本実施形態のコミュニティ設定処理における携帯電話のディスプレイ２２の画面表示例を図１０に示す。図１０Ａは、ステップＳ８０１における携帯電話１００の画面表示例である。図１０Ａには、携帯電話１００のユーザが入力したコミュニティリクエスト情報の内容が表示される。具体的には、コミュニティを設定する条件（キーワードなど）である「コミュニティタイトル」、コミュニティに参加するメンバー同士のメール交換の開始を希望する時間を示す「コミュニティ開始希望時間」、そのユーザが属するグループ名を示す「グループ」の各内容が入力される。なお、このコミュニティリクエスト情報の内容の入力は、例示として、「コミュニティ開始希望時間」は日付と時刻（１時間単位）を入力対象とし、「コミュニティタイトル」はあらゆる文字列（フリーキーワード）を対象するようにしているが、これに限られるものではない。その他の実施形態として、サービスサーバ３００側であらかじめ設定された文字列（選択キーワード）からユーザが選択するようにしてもよい。その他、コミュニティリクエスト情報の選択、入力は、当業者に周知の手段によって変形可能である。
【００７３】
サービスサーバ３００のＣＰＵ３０は、受信したコミュニティリクエスト情報をコミュニティＤＢ４００に記録する（図８ステップＳ８５１）。コミュニティＤＢ４００の記録内容（図９参照）は、項目２−５で上述したものであり、具体的には、図１０Ａの「コミュニティタイトル」は、ＤＢ４００中の「タイトル」に対応し、図１０Ａの「コミュニティ開始希望時間」は、ＤＢ４００中の「通信開始希望日時」に対応する。その他、ＤＢ４００には、携帯電話１００の「メールアドレス」、「ユーザ現在地」が記録される。
【００７４】
「ユーザ現在地」の情報については、サービスサーバ３００のＣＰＵ３０が、携帯電話１００の位置情報（「端末位置情報」に対応）を取得することによって記録する内容である。この位置情報の取得は、ＧＰＳの技術を利用すればよい。具体的には、携帯電話１００のＣＰＵ１０は、ＧＰＳ衛星２５０（一般的には４つの人工衛星）からの電波をＧＰＳ受信機２１を介して受信し、その携帯電話１００の位置を特定するＸ（緯度）、Ｙ（経度）、Ｚ（高度）などの各情報を演算する。そして、ＣＰＵ１０は、そのＧＰＳ位置データをサービスサーバ３００に送信する。ＧＰＳ位置データは、ＣＰＵ１０が、例えば図８ステップＳ８０１の処理においてコミュニティリクエスト情報と併せて送信すればよい。
【００７５】
図８ステップＳ８５１の処理により、本実施形態では、携帯電話１００のユーザの情報（ここでは、図９のメールアドレス「１２３＠ｃｏｍ．ｎｅ．ｊｐ」のユーザの情報とする）がコミュニティＤＢ４００に記録される。ＣＰＵ３０は、図９のコミュニティＤＢ４００に記録された情報を参照し、受信したコミュニティリクエスト情報に適合するコミュニティリクエスト情報を検索する（図８ステップＳ８５２）（「第１のエントリー情報と第２のエントリー情報との適合部分（共通部分）の有無を判断する」に対応）。なお、コミュニティＤＢ４００に記録される各コミュニティリクエスト情報は、所定の時間（例えば、図９の「通信開始希望日時」）を超過した場合に削除されるものとする。
【００７６】
ここで、適合するコミュニティリクエスト情報とは、本実施形態では、例示として、図９に記録された情報の中で「タイトル」および「通信開始希望日時」の各情報が一致（部分一致などを含む）し、かつ、「ユーザ現在地」の情報の一致度の高い（例えば、同一都道府県内、または、「ユーザ現在地」間の距離が５００メートル以内など）コミュニティリクエスト情報の組み合わせのことをいう。「ユーザ現在地」の情報の比較は、コミュニティリクエスト情報に含まれるＧＰＳ位置データ（Ｘ（緯度）、Ｙ（経度）、Ｚ（高度）の各情報）に基づいて行えばよい。その他、サービスサーバ３００は、ＧＰＳ位置データではなく（あるいはＧＰＳ位置データとともに）、携帯電話の位置を示す地域名データに基づいて「ユーザ現在地」の情報の比較を行うようにしてもよい。具体的には、サービスサーバ３００は、位置データ（Ｘ（緯度）、Ｙ（経度）、Ｚ（高度）の各情報）を地域名データに変換するための変換テーブルをハードディスク３４に記録しておく。そして、携帯電話からＧＰＳ位置データを受信すると、ＣＰＵ３０は、変換テーブルを利用してＧＰＳ位置データを地域名データに変換し、その地域名データを「ユーザ現在地」として記録する（図１３の「現在地」の情報参照）。
【００７７】
図９の例では、携帯電話１００のユーザ（メールアドレス「１２３＠ｃｏｍ．ｎｅ．ｊｐ」に対応）のコミュニティリクエスト情報と、ユーザ（メールアドレス「ａｉｕ＠ｚｍａｉｌ．ｎｅ．ｊｐ」に対応）のコミュニティリクエスト情報とが、適合するコミュニティリクエスト情報となる。以下、便宜上、ユーザ（メールアドレス「ａｉｕ＠ｚｍａｉｌ．ｎｅ．ｊｐ」に対応）の所有する携帯電話を携帯電話１０２とする。
【００７８】
ＣＰＵ３０は、図８ステップＳ８５２の処理の結果、受信したコミュニティリクエスト情報に適合するコミュニティリクエスト情報がコミュニティＤＢ４００に記録されているか否かを判断する（図８ステップＳ８５３）。適合するコミュニティリクエスト情報が無いと判断した場合には、ＣＰＵ３０は処理を終了する。
【００７９】
ＣＰＵ３０は、ステップＳ８５３の処理において適合するコミュニティリクエスト情報が有ると判断した場合には、その適合するコミュニティリクエスト情報を送信した携帯電話、すなわち、携帯電話１００および１０２に対してコミュニティ許可確認情報を送信する（図８ステップＳ８５５）。携帯電話１００のＣＰＵ１０は、コミュニティ許可確認情報を受信したか否かを判断し（ステップＳ８０３）、受信していない場合には処理を終了する。なお、ステップＳ８０３以降の処理は、携帯電話１０２についても同様に行われる。
【００８０】
ステップＳ８０３においてコミュニティ許可確認情報を受信したと判断した場合には、ＣＰＵ１０は、コミュニティ許可画面をディスプレイ２２に表示する（ステップＳ８０４）。図１０Ｂは、コミュニティ許可画面の画面例である。コミュニティ許可画面には、「コミュニティタイトル」と、コミュニティ設定の許可の有無を確認するコマンドが表示される。具体的には、ユーザが”はい許可します。”のコマンドを選択した場合は、ＣＰＵ１０は、後述するステップＳ８０７においてコミュニティ許可情報をサービスサーバ３００に送信することになる。
【００８１】
次に、ＣＰＵ１０は、ユーザによるコミュニティ許可情報の入力の有無を判断し（図８ステップＳ８０５）、入力がなければ処理を終了する。一方、ステップＳ８０５においてコミュニティ許可情報の入力が有ると判断した場合には、ＣＰＵ１０は、コミュニティ許可情報をサービスサーバ３００に送信する（ステップＳ８０７）。
【００８２】
ＣＰＵ３０は、コミュニティ設定の対象となるユーザの全てからコミュニティ許可情報を受信したか否かを判断し（ステップＳ８５７）、受信していないと判断した場合には処理を終了する。このステップＳ８５７の処理の判断は、本実施形態では、例として、コミュニティ設定の対象となるユーザのコミュニティ開始時刻（図９の「通信開始希望日時」に対応）までを期限として行うこととしている。
【００８３】
一方、ステップＳ８５７において、コミュニティ設定の対象となるユーザの全てから（ここでは、携帯電話１００および１０２のユーザ）、コミュニティ許可情報を受信したと判断した場合には、ＣＰＵ３０は、コミュニティに属する他のメンバーのメールアドレス（携帯電話用）を含むコミュニティ設定情報を送信し（「第１の端末装置と第２の端末装置との間を通信可能状態にする」に対応）、処理を終了する（ステップＳ８５９）。
【００８４】
ここでは、ＣＰＵ３０は、携帯電話１００に対して携帯電話１０２のメールアドレス（「ａｉｕ＠ｚｍａｉｌ．ｎｅ．ｊｐ」）を含むコミュニティ設定情報を送信する。一方、ＣＰＵ３０は、携帯電話１０２に対して携帯電話１００のメールアドレス（「１２３＠ｃｏｍ．ｎｅ．ｊｐ」）を含むコミュニティ設定情報を送信する（「第１の端末装置に対して前記第２のエントリー情報に関連する情報を送信すること、または、第２の端末装置に対して前記第１のエントリー情報に関連する情報を送信すること」に対応）。
【００８５】
ＣＰＵ１０は、コミュニティ設定情報を受信して、ディスプレイ２２にコミュニティ設定情報を表示する。図１０Ｃは、図９ステップＳ８０８の処理によってディスプレイ２２に表示されるコミュニティ設定画面の画面例である。コミュニティ設定画面には、「コミュニティタイトル」と、「コミュニティメンバーのメールアドレス」が表示される。
【００８６】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士について、相互のメール交換を介したコミュニティが設定される。具体的には、”Ｙ響コンサート（大阪）”を鑑賞するという共通の行動目的を持つユーザ同士が、相互のメール交換を開始することを可能としたコミュニティが設定されることになる。
【００８７】
なお、図８ステップＳ８５７、Ｓ８５９の処理では、ＣＰＵ３０は、コミュニティ設定の対象となるユーザの全てからコミュニティ許可情報を受信した場合に、コミュニティに属する他のメンバーのメールアドレスを含むコミュニティ設定情報を送信することとしたが、これに限られるものではない。その他の実施形態として、ＣＰＵ３０は、コミュニティ設定の対象となるユーザの全てではなく、一部のユーザからのコミュニティ許可情報を受信した場合にも、その一部のユーザに対してコミュニティ設定情報を送信するようにしてもよい。具体的には、例えばユーザＸ、ユーザＹの２人で構成されるコミュニティが設定されている場合に、ユーザＡが、そのコミュニティと同一のコミュニティリクエスト情報を送信したとする。この場合、図８ステップＳ８５５の処理により、ＣＰＵ３０は、Ｘ、Ｙ、Ａに対してコミュニティ許可確認情報を送信する。このとき、コミュニティ許可情報を送信したユーザがＸおよびＡであった場合（Ｙは非許可）には、ＣＰＵ３０は、一部のユーザであるＸおよびＡに対してコミュニティ設定情報を送信することになる。
【００８８】
−−５．第１実施形態による効果−−
第１実施形態によれば、共通の行動目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。これにより、目的を共通にする他のユーザと互いの情報をリアルタイムで交換したり、あるいは、目的を共通にする他のユーザと行動を共にすることができる。例えば、共通のイベントに参加する予定の他のユーザと連絡をとったり、あるいは情報交換をすることができる。その他、デパートや観光地など、共通の場所に存在するユーザ同士が話題を共有することも可能である。
【００８９】
第１実施形態では、コミュニティの設定として、ＣＰＵ３０が、他のメンバーのメールアドレス（携帯電話用）を含むコミュニティ設定情報を送信する例を示した。その他の実施形態として、他のユーザの電話番号（携帯電話用）を含むコミュニティ設定情報を送信するようにしてもよい。これにより、コミュニティリクエスト情報が共通するユーザ同士で、電話によるコミュニケーション（会話）を行うことができる。
【００９０】
図８ステップＳ８５９では、サービスサーバ３００のＣＰＵ３０は、携帯電話１００に対して携帯電話１０２のメールアドレスを含むコミュニティ設定情報を送信する一方で、携帯電話１０２に対して携帯電話１００のメールアドレスを含むコミュニティ設定情報を送信する例を示したが、これに限られるものではない。その他の実施形態として、コミュニティに属する全てのユーザに対してではなく、コミュニティに属する一部のユーザのみにコミュニティ設定情報を送信するようにしてもよい。
【００９１】
図８ステップＳ８５２の処理において、コミュニティリクエスト情報が適合する場合の例示として、図９のＤＢに記録された情報の中で「タイトル」および「通信開始希望日時」の各情報が一致し、かつ、「ユーザ現在地」の情報の一致度の高いコミュニティリクエスト情報の組み合わせを例示したが、これに限られるものではない。その他の実施形態として、図９に記録される「グループ」および「ユーザ現在地」の各情報の一致度が高いコミュニティリクエスト情報の組み合わせを、適合するコミュニティリクエスト情報として採用してもよい。
【００９２】
これにより、本システムは、大学や学校、会社、サークル等の組織が共通し、かつ、物理的に近くに居るメンバー同士がコミュニケーションをとることをサポートすることができる。したがって、知人またはグループの共通時間を増加させることができ、仕事上の会話や日常会話などの促進を通じて互いのコミュニケーションの改善を図ることが期待できる。
【００９３】
−−６．第２実施形態（タクシー共同予約設定処理）−−
コミュニティシステムの第２実施形態として、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約を設定する処理を説明する。第２実施形態におけるコミュニティの設定は、サービスサーバ３００が、タクシー乗合いを設定された携帯電話のユーザに対して、共通エントリー情報を送信する例を採用する（図２記号６−Ａ参照）。
【００９４】
６−１．第２実施形態（タクシー共同予約設定処理）の概要
図１１は、タクシー共同予約設定処理の概要図である。携帯電話１００は、ユーザの操作に応じて予約リクエスト情報をサービスサーバ３００に送信する（１）。サービスサーバ３００は、受信した予約リクエスト情報に基づいて予約スケジュールをタクシー予約ＤＢ５００に記録し（２）、その予約スケジュールを配車コントロールサーバ７００に送信する（３）。配車コントロールサーバ７００は、配車スケジュールＤＢ６００の記録内容を更新する（４）。サービスサーバ３００は、予約確認メールを携帯電話１００に送信する（５）。
【００９５】
携帯電話１０２は、ユーザの操作に応じて予約リクエスト情報をサービスサーバ３００に送信する（６）。サービスサーバ３００は、タクシー予約ＤＢ５００の中に、受信した予約リクエスト情報と合致する予約スケジュールが有るか否かを検索する（７）。この処理により、サービスサーバ３００は、タクシーの乗合いが可能か否かを判断する。
【００９６】
サービスサーバ３００は、合致する予約スケジュールが有ると判断した場合には、タクシーの乗合い用に設定された予約スケジュールを配車コントロールサーバ７００に送信する（８）。図では、携帯電話１００および１０２のユーザがタクシーの乗合いを設定されたこととしている。配車コントロールサーバ７００は、配車スケジュールＤＢ６００の記録内容を更新する（９）。サービスサーバ３００は、予約確認メールを携帯電話１００および１０２に送信する（１０）。
【００９７】
以上の処理により、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約が設定される。
【００９８】
６−２．第２実施形態（タクシー共同予約設定処理）のフローチャート
次に、図１２に基づき、第２実施形態（タクシー共同予約設定処理）における各装置のＣＰＵが実行するプログラムのフローチャートを説明する。図１２のフローチャートは、サービスサーバ３００のタクシー予約ＤＢ５００に、携帯電話１００のユーザの予約リクエスト情報を含む、複数の携帯電話のユーザからの予約リクエスト情報が記録されている状態を前提として、携帯電話１０２のユーザが、サービスサーバ３００に対して新たに予約リクエスト情報を送信する例を説明するものである。ただし、以下に説明するフローチャートは例示であって、タクシー共同予約設定処理のプログラム、アルゴリズムは、当業者に周知の手法によって変形可能である。
【００９９】
携帯電話１０２のＣＰＵ１０は、ユーザの操作に応じてブラウザプログラムを立ち上げてサービスサーバ３００にアクセスし、予約リクエスト情報を送信する（図１２ステップＳ１２０１）。
【０１００】
ここで、本実施形態のタクシー共同予約設定処理における携帯電話のディスプレイ２２の画面表示例を図１５に示す。図１５Ａは、ステップＳ１２０１における携帯電話１０２の画面表示例である。図１５Ａには、携帯電話１０２のユーザが入力した予約リクエスト情報の内容が表示される。具体的には、「タクシー予約内容」として、「乗車時刻」、「乗車場所」、「目的地」、乗合いを許可するか否かを示す「乗合い許可」の各内容が表示される。なお、この予約リクエスト情報の内容の入力は、例示として、「乗車時刻」は日付と時刻（１５分単位）を入力対象とし、「乗車場所」および「目的地」は、サービスサーバ３００側であらかじめ設定された文字列（選択キーワード）からユーザが選択するようにする。具体的には、「乗車場所」および「目的地」を示す文字列として、駅、施設、住所、会社名等をあらかじめサービスサーバ３００側で記録しておく。その他、予約リクエスト情報の選択、入力は、当業者に周知の手段によって変形可能である。
【０１０１】
サービスサーバ３００のＣＰＵ３０は、予約リクエスト情報を受信する（ステップＳ１２０２）。ＣＰＵ３０は、タクシー予約ＤＢ５００に記録された情報を参照し、受信した予約リクエスト情報に適合する予約スケジュールを検索する（図１２ステップＳ１２０３）（「第１のエントリー情報と第２のエントリー情報との間の適合部分（共通部分）の有無を判断する」に対応）。なお、タクシー予約ＤＢ５００に記録される各予約リクエスト情報は、所定の時間（例えば、図１３の「乗車時刻」）を超過した場合に削除されるものとする。
【０１０２】
ここで、予約リクエスト情報と予約スケジュールとが適合する場合とは、実施形態では、例示として、受信した予約リクエスト情報と、図１３のタクシー予約ＤＢ５００に記録された各予約スケジュールとについて、両者が「乗合い許可」しており、両者の「乗車地」、「目的地」、「乗車時刻」の各情報の一致度が高い場合をいう。「乗車地」および「目的地」の情報の一致度が高い場合とは、例えば、予約リクエスト情報における「乗車地」および予約スケジュールにおける「乗車地」が一致する場合をいい、「乗車時刻」が情報の一致度が高い場合とは、例えば、予約リクエスト情報における「乗車時刻」と予約スケジュールにおける「乗車時刻」との時間差が１５分以内の場合をいう。
【０１０３】
ＣＰＵ３０は、図１２ステップＳ１２０３の処理の結果、受信した予約リクエスト情報に適合する予約スケジュールがタクシー予約ＤＢ５００に記録されているか否かを判断する（ステップＳ１２０５）。
【０１０４】
以下、ＣＰＵ３０が、ステップＳ１２０５において、予約リクエスト情報に適合する予約スケジュールが無いと判断した場合を説明する。ＣＰＵ３０は、受信した予約リクエスト情報を配車コントロールサーバ７００に送信する（ステップＳ１２０７）。
【０１０５】
配車コントロールサーバ７００のＣＰＵ６０は、予約リクエスト情報を受信し、配車コントロールサーバ７００が管理するタクシーについての所定の情報を参照して、その予約リクエスト情報に対応する配車スケジュールを決定する（ステップＳ１２５０）。ここで、タクシーについて所定の情報とは、実施形態では、例示として、タクシーの位置情報（「車両位置情報」に対応）と、タクシーの空車情報（「車両空車情報」に対応）とを利用することとしている。これらの情報は、当業者に周知のＧＰＳ技術、タクシーと配車コントロールサーバ７００との間の通信技術を利用して、配車コントロールサーバ７００が収集すればよい。
【０１０６】
ＣＰＵ６０は、受信した予約リクエスト情報に基づいて決定した配車スケジュールを配車スケジュールＤＢ６００に記録する（ステップＳ１２５１）。配車スケジュールＤＢ６００の記録内容（図１４参照）は、項目２−５で上述したものであり、具体的には、図１３の「乗車時刻」は、ＤＢ６００中の「乗車時刻」に対応し、図１３の「乗車地」は、ＤＢ６００中の「乗車地」に対応し、図１３の「目的地」は、ＤＢ６００中の「目的地」に対応する。その他、ＤＢ６００には、各予約スケジュールを担当するタクシーを特定する「タクシーＮｏ．」、各予約スケジュールを特定する「予約スケジュールＮｏ．」が記録される。この「予約スケジュールＮｏ．」は、配車コントロールサーバ７００のＣＰＵ６０が自動採番することとする。
【０１０７】
配車コントロールサーバ７００のＣＰＵ６０は、ステップＳ１２５１で記録した配車スケジュールをサービスサーバ３００に送信し（ステップＳ１２５２）、処理を終了する。サービスサーバ３００のＣＰＵ３０は、ステップＳ１２０７においてサービスサーバ３００に送信した予約リクエスト情報と、ステップＳ１２５２の処理によって配車コントロールサーバ７００から送信された配車スケジュールとに基づいて、新規の予約スケジュールをタクシー予約ＤＢ５００に記録する（ステップＳ１２１１）。具体的には、図１３には、予約リクエスト情報に基づき、「ユーザメールアドレス」、「乗合い許可」、「現在地」、「乗車時刻」、「乗車地」、「目的地」が記録される。「現在地」の情報の取得については第１実施形態と同様にＧＰＳ位置データを利用する。具体的には、サービスサーバ３００は、位置データ（Ｘ（緯度）、Ｙ（経度）、Ｚ（高度）の各情報）を地域名データに変換するための変換テーブルをハードディスク３４に記録しておく。そして、携帯電話からＧＰＳ位置データを受信すると、ＣＰＵ３０は、変換テーブルを利用してＧＰＳ位置データを地域名データに変換し、その地域名データを「ユーザ現在地」として記録する。なお、「ユーザ現在地」の記録は、これに限らず、ＧＰＳ位置データ（Ｘ（緯度）、Ｙ（経度）、Ｚ（高度）の各情報）を記録するようにしてもよい（図９の「ユーザ現在地」の情報参照）。ＧＰＳ位置データは、ＣＰＵ１０が、例えば図１２ステップＳ１２０１の処理において予約リクエスト情報と併せて送信すればよい。
【０１０８】
また、図１３には、配車スケジュールに基づいて、「予約スケジュールＮｏ．」、「タクシーＮｏ．」が記録される。「料金割合」の情報については、後述の「８．その他の実施形態等」の項において説明する。なお、配車スケジュールＤＢ６００に記録される各配車スケジュールは、所定の時間（例えば、図１４の「乗車時刻」）を超過した場合に削除されるものとする。
【０１０９】
次に、ＣＰＵ３０が、ステップＳ１２０３において、タクシー予約ＤＢ５００の中に、予約リクエスト情報に適合する予約スケジュールが有ると判断した場合を説明する。ＣＰＵ３０は、受信した予約リクエスト情報に基づいて、共通予約スケジュールをタクシー予約ＤＢ５００に記録する（図１２ステップＳ１２０９）。
【０１１０】
ここでは、携帯電話１００のユーザの予約スケジュール（具体的には、図１３のメールアドレス「１２３＠ｃｏｍ．ｎｅ．ｊｐ」のユーザ用の予約スケジュールＮｏ．「ＸＹ０１５−１」）が先に記録されており、後に、その予約スケジュールに適合する、携帯電話１０２のユーザ（メールアドレス「ａｉｕ＠ｚｍａｉｌ．ｎｅ．ｊｐ」に対応）の予約リクエスト情報が送信された場合を例に挙げて説明する。この場合、携帯電話１００および１０２のユーザの予約内容は、「乗車時刻」、「乗車地」、「目的地」が一致する。したがって、図１２ステップＳ１２０５において、ＣＰＵ３０は、携帯電話１０２からの予約リクエスト情報は、携帯電話１００のユーザ用の予約スケジュール「ＸＹ０１５−１」に適合すると判断する。そして、ステップＳ１２０９の処理によって、ＣＰＵ３０は、携帯電話１０２のユーザ用の予約スケジュールを、「ＸＹ０１５−１」に共通する予約スケジュールであることを示す「ＸＹ０１５−２」としてタクシー予約ＤＢ５００に記録する。この場合、ＣＰＵ３０は、両方の予約スケジュールの親番号である「ＸＹ０１５」が一致することに基づいて、共通する予約スケジュールであることを判断する。
【０１１１】
ステップＳ１２１１またはステップＳ１２０９の処理の後、ＣＰＵ３０は、ユーザの現在地からタクシー乗車地までの最短経路の検索処理を行う（ステップＳ１２１３）。具体的には、ＣＰＵ３０は、ステップＳ１２０２の処理によって受信した予約リクエスト情報の送信元である携帯電話の現在地（図１３のタクシー予約ＤＢ５００に記録される「現在地」の情報）から、タクシー乗車地（タクシー予約ＤＢ５００に記録される「乗車地」の情報）までの最短経路の検索を行う。この検索処理は、位置情報、および鉄道・バスなどの公共交通機関に関する経路情報を利用した、当業者に周知の経路選択シミュレーションプログラムなどを利用して行えばよい。
【０１１２】
ステップＳ１２１３の処理の後、ＣＰＵ３０は、予約スケジュールに含まれる全てのユーザに対して予約確認メールを送信して処理を終了する（ステップＳ１２１５）。ここでは、ＣＰＵ３０は、予約スケジュールＮｏ．「ＸＹ０１５」に該当するユーザである携帯電話１００（メールアドレス「１２３＠ｃｏｍ．ｎｅ．ｊｐ」に対応）と、携帯電話１０２（メールアドレス「ａｉｕ＠ｚｍａｉｌ．ｎｅ．ｊｐ」に対応）とに予約確認メールを送信する。
【０１１３】
携帯電話１０２のＣＰＵ１０は、予約確認メールを受信する（ステップＳ１２１７）。ＣＰＵ１０は、予約確認メールをディスプレイ２２に表示して処理を終了する。
【０１１４】
図１５Ｂは、ステップＳ１２１９における携帯電話１０２の画面表示例である。図１５Ｂには、予約スケジュールの内容が表示される。具体的には、タクシー乗合い確認として、「現在の乗合い人数」、担当するタクシーを特定する「タクシー情報」、「タクシー予約内容」、図１２ステップＳ１２１３の検索処理に基づく情報である「乗車場所までの最短経路のご案内」の各情報が表示される。
【０１１５】
以上の処理により、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約が設定される。なお、実施形態では、携帯電話１００および１０２のユーザが、タクシーの乗合いを許可する例を説明した。しかしながら、乗合いを許可しないユーザの場合には、予約スケジュールは、その一人のユーザ用に設定されることになる。
【０１１６】
−−７．第２実施形態による効果−−
第２実施形態によれば、共通の目的地に移動する予定のあるユーザ同士が、車両の乗り合わせをする（コミュニティを設定する）ことをサポートすることができる。
【０１１７】
また、タクシーの乗り合わせの場合、運賃は、乗車人数の如何にかかわらず、タクシーの移動距離・時間に基づいて決定されるのが一般的である。したがって、例えば車両の乗合い人数が増加すると、乗合いする各ユーザのタクシー利用料金の負担割合が減少するという経済的な効果もある。
【０１１８】
第２実施形態では、サービスサーバ３００のＣＰＵ３０は、同一のタクシーへの乗合いを予定するユーザが追加される毎に、全てのユーザに対して予約確認メール（図１５Ｂ参照）を送信する（図１２ステップＳ１２１５参照）。これにより、本システムのユーザは、同一のタクシーへの「乗合い人数」を含む情報を受け取ることができる。したがって、各ユーザは、自分が乗車を予定しているタクシーへの「乗合い人数」の推移をゲーム感覚で楽しむことができる。
【０１１９】
第２実施形態では、配車コントロールサーバ７００のＣＰＵ６０は、タクシーの位置情報とタクシーの空車情報とを利用して、予約リクエスト情報に対応する配車スケジュールを決定する（図１２ステップＳ１２５０参照）。これにより、タクシーの配車を管理する事業者は、ユーザの乗車予定に合わせて配車予定を決定することができ、さらに、空車状態のタクシーを削減できるという効果も期待できる。一方、ユーザも、定刻通りの配車サービスを享受することができ、目的地への移動に対する時間の無駄を削減できる。
【０１２０】
図１２ステップＳ１２０３の処理において、予約リクエスト情報が適合する場合の例示として、複数の予約リクエスト情報の中で、「乗車地」、「目的地」、「乗車時刻」の各情報の一致度が高い予約リクエスト情報の組み合わせを例示したが、これに限られるものではない。その他の実施形態として、予約リクエスト情報が適合する条件として、「グループ」の情報の一致度が高い場合を追加してもよい。具体的には、第１実施形態と同様に、サービスサーバ３００は、携帯電話のユーザから「グループ」の情報を追加して要求し、その「グループ」の情報をタクシー予約ＤＢ５００に記録するようにすればよい（図９参照）。これにより、同一の目的地に移動する場合に、同じグループ（例えば、同じ会社）に属するユーザ同士でタクシーの乗り合わせをすることができる。この場合、同一グループに属するユーザ同士であるから、タクシーの乗り合わせというコミュニティを形成することで、ユーザ同士のコミュニケーションの増加も期待することができる。特に、同じ組織（会社、大学、サークルなど）に属するメンバーであれば、同時期に同一の目的地に移動する予定が重複する場合が多く、本システムの利用が好適である。
【０１２１】
第２実施形態では、車両の例示としてタクシーを挙げたが、これに限られるものではない。その他の実施形態として、本システムは、ユーザの要望に応じてユーザを乗せて走る車両一般に利用可能である（例えば、ハイヤーなど）。なお、本システムによってタクシーの乗り合わせの効率化を図ることにより、ガソリン・天然ガスなどの燃料資源の有効活用を実現するという効果も期待できる。
【０１２２】
ここで、第１実施形態では、大阪で開催される”Ｙ響コンサート”を鑑賞するという共通の行動目的を持ち、かつ、「ユーザ現在地」が近似するユーザ同士のコミュニティ（共同体）を設定する例を説明した。一方、第２実施形態では、目的地である”ＸＹＺ本社”に移動するという共通の行動目的を持ち、かつ、「乗車地」が近似するユーザ同士のタクシー乗り合わせグループ（共同体）を設定する例を説明した。すなわち、本発明の「エントリー情報」は、位置（場所）に関連づけて特定される情報であることを１つの特徴としている。したがって、本発明は、位置に関連づけて特定されるエントリー情報の共通性と、端末装置の位置に関する端末位置情報の共通性とを判断して、コミュニティを設定することを１つの特徴としている。
【０１２３】
−−８．その他の実施形態等−−
８−１．コミュニティリクエスト情報または予約リクエスト情報のバリエーション
第１実施形態では、コミュニティリクエスト情報として図９のコミュニティＤＢ４００の記録内容を例示し、第２実施形態では、予約リクエスト情報として図１３のタクシー予約ＤＢ５００の記録内容を例示したが、これらに限られるものではない。
【０１２４】
その他の実施形態として、第１実施形態および第２実施形態において、所定の条件を付加したリクエスト情報（条件付きエントリー情報）を採用してもよい。具体的には、例えば、３人以上のタクシー乗り合わせが設定された場合にタクシー乗り合わせを許可する、という条件付きの予約リクエスト情報を採用してもよい。また、３人以上のタクシー乗り合わせが設定される場合であれば乗車時刻を３０分遅延まで許可する、という条件付きの予約リクエスト情報を採用してもよい。
【０１２５】
その他、リクエスト情報の中の「グループ」の情報として、ユーザの性別または年齢を入力しておき、性別や年齢を条件としたリクエスト情報を採用してもよい。例えば、女性のユーザは、コミュニティの設定またはタクシーの乗り合わせの相手が「女性」であれば、そのコミュニティの設定またはタクシーの乗り合わせを許可する、という条件付きのリクエスト情報を採用してもよい。
【０１２６】
その他の実施形態として、第２実施形態において、携帯電話１００等のユーザによる「乗車地」の情報の入力を省略するようにしてもよい（図１２ステップＳ１２０１参照）。この場合、「現在地」の情報に基づいて、サービスサーバ３００のＣＰＵ３０が、あらかじめシステム内で設定された「乗車地」を選択するようにしてもよい。具体的には、ＣＰＵ３０は、ＧＰＳ技術に基づいて取得された情報である「現在地」に最も近い「乗車地」を選択し、その「乗車地」の情報を携帯電話１００等のユーザに提示するようにすればよい。これとは逆に、第２実施形態において、携帯電話１００等のユーザによる「現在地」に関する情報の処理を省略するようにしてもよい。この場合、ＣＰＵ３０による、図１２ステップＳ１２１３の処理は省略される。
【０１２７】
第２実施形態において、携帯電話１００等のユーザによる「乗車時刻」の情報の入力を省略するようにしてもよい（図１２ステップＳ１２０１参照）。この場合の乗車時刻は、早急に目的地に移動したい携帯電話のユーザのために、サービスサーバ３００のＣＰＵ３０が、「現在地」と「乗車地」と「最短経路」との情報に基づいて判断する。具体的には、ＣＰＵ３０は、ＧＰＳ技術に基づいて取得された情報である現在地から乗車地までを最短経路で移動した場合の移動時間を算出し、この移動時間を現在時刻に足した時間を「乗車時刻」として決定する。
【０１２８】
８−２．コミュニティリクエスト情報または予約リクエスト情報の適合判断処理のバリエーション
第１実施形態では、サービスサーバ３００のＣＰＵ３０が、コミュニティＤＢ４００に記録された情報を参照してコミュニティリクエスト情報の照合処理（検索処理、マッチング処理）を行う（図８ステップＳ８５２参照）。一方、第２実施形態では、ＣＰＵ３０が、タクシー予約ＤＢ５００に記録された情報を参照して予約リクエスト情報の照合処理を行う（図１２ステップＳ１２０３参照）。これらの照合処理の手法は例として説明したのであって、当業者に周知の手法によって変形可能である。例えば、各照合処理において、２以上のリクエスト情報が適合すると判断する場合の基準（キーワード、地名、時刻等の各情報の一致度、一致スコアの取り方など）は、変形可能である。
【０１２９】
第２実施形態では、予約リクエスト情報同士が適合する場合として、「乗車地」および「目的地」の各情報の一致度が高い場合を例示した（図１２ステップＳ１２０３）。その他の実施形態として、サービスサーバ３００は、一部のユーザの途中乗車または途中下車を考慮したタクシー乗合いを設定するようにしてもよい。具体的には、ＣＰＵ３０は、予約リクエスト情報の適合処理において、各情報の「乗車地」と「目的地」との間のタクシー経路の重複部分があるか否かを判断する。例えば、ユーザＸの予約リクエスト情報が、乗車地点Ｐ→地点Ｑ→目的地点Ｒのタクシー経路を予定しており、他方のユーザＹの予約リクエスト情報が、（イ）乗車地点Ｏ→地点Ｐ→目的地点Ｑのタクシー経路を予定している場合、または（ロ）乗車地点Ｑ→地点Ｒ→目的地点Ｓのタクシー経路を予定している場合には、ユーザＸとユーザＹのそれぞれのタクシー経路に重複部分があることになる。したがって、ＣＰＵ３０は、タクシー移動時間とユーザの乗車時間とを考慮して、両リクエスト情報を送信したユーザに対してタクシー乗合いを設定する。
【０１３０】
第１実施形態および第２実施形態では、サービスサーバ３００のＣＰＵ３０が、
携帯電話１００のユーザと携帯電話１０２のユーザとの間のコミュニティを設定する場合を例示した（図８ステップＳ８５９、図１２ステップＳ１２１５参照）。その他の実施形態として、ＣＰＵ３０は、図８または図１２のフローチャートに示す処理によって、３人以上のコミュニティを設定することもできる。
【０１３１】
その他、サービスサーバ３００によってコミュニティを設定する前に、携帯電話のユーザが複数のコミュニティの設定候補の中から希望のコミュニティを選択できるようにしてもよい。具体的には、ＣＰＵ３０は、図８ステップＳ８５２または図１２ステップＳ１２０３の検索処理により、受信したリクエスト情報に適合するリクエスト情報が複数記録されている場合には、それらをコミュニティ設定候補（またはタクシー乗合い候補）として携帯電話に送信する。そして、ＣＰＵ３０は、携帯電話のユーザの操作に応じて選択されたコミュニティについて、コミュニティを設定することとする。
【０１３２】
８−３．コミュニティシステムによる料金設定バリエーション
第２実施形態では、サービスサーバ３００のＣＰＵ３０が図１３のタクシー予約ＤＢ５００に記録する内容として、「料金割合」を例示した。この「料金割合」の情報は、タクシーの乗合いがあった場合のユーザのタクシー料金（「各ユーザがサービスの享受に関して負担する各サービス料金」に対応）の負担割合（Ｘ％）を示すものである。第２実施形態では、コミュニティシステムに対して、より先に予約リクエスト情報を登録したユーザの「料金割合」を、他のユーザよりも低くなるように設定している。具体的には、図１３に示すように、予約スケジュールＮｏ．「ＸＹ０１５」によってタクシー乗合いが設定されたユーザに関しては、携帯電話１００のユーザ（メールアドレス「１２３＠ｃｏｍ．ｎｅ．ｊｐ」に対応）がタクシー運賃の４５％を負担し、携帯電話１０２のユーザ（メールアドレス「ａｉｕ＠ｚｍａｉｌ．ｎｅ．ｊｐ」に対応）がタクシー運賃の５５％を負担する。このようにして設定された料金割合は、図１５Ｂの携帯電話のディスプレイ２２の画面例で示すように、「お客様の料金負担割合」として表示される。
【０１３３】
これらの料金割合による各ユーザのタクシー運賃は、サービスサーバ３００のＣＰＵ３０が演算したうえで、担当するタクシーに対して情報を送信することを介してユーザに知らせるようにしてもよい。なお、第２実施形態のタクシー乗合いに限らず、第１実施形態のコミュニティ設定に対して、以上のような処理を採用してもよい。例えば、設定されるコミュニティの内容が、団体で参加するイベントである場合に、その団体料金の負担割合を上記と同様の処理によって設定することもできる。
【０１３４】
以上のように、コミュニティシステムに先にリクエスト情報を登録したユーザに対して料金面での優遇を与えることにより、ユーザに対して、本システムに参加することの動機付けが与えられるという効果もある。なお、料金割合の設定は、上記の内容に限らず、当業者に周知の手法によって変形可能である。
【０１３５】
その他の実施形態として、コミュニティシステムを利用するユーザについて、料金決済の情報（例えば、クレジットカード番号など）を含むユーザ登録を要求することにより、例えばタクシー運賃の支払いを容易にすることも可能である。
【０１３６】
８−３．装置構成バリエーション
第２実施形態では、タクシー予約に対して配車するタクシーを設定する機能を備えた配車コントロールサーバ７００を例示した。これに限らず、サービスサーバ３００が、配車コントロールサーバ７００の機能を併せ持つようにしてもよい。その他、タクシーの予約に対して配車するタクシーの決定を、配車コントロールサーバ７００の管理者が行うようにしてもよい。
【０１３７】
実施形態では、端末装置として携帯電話１００等を例示したが、これに限られるものではなく、Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ（ＰＤＡ）やパーソナルコンピュータ等のその他の機器を利用してもよい。
【０１３８】
８−４．プログラム実行方法等の実施例
本実施形態では、ＣＰＵ１０、ＣＰＵ３０、ＣＰＵ３０６０の動作のためのプログラムを、それぞれＲＯＭ１４、ハードディスク３４、ハードディスク６４に記憶させているが、このプログラムは、プログラムが記憶されたＣＤ−ＲＯＭから読み出してハードディスク等にインストールすればよい。また、ＣＤ−ＲＯＭ以外に、ＤＶＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＩＣカード等のプログラムをコンピュータ可読の記録媒体からインストールするようにしてもよい。さらに、通信回線を用いてプログラムをダウンロードさせることもできる。また、ＣＤ−ＲＯＭからプログラムをインストールすることにより、ＣＤ−ＲＯＭに記憶させたプログラムを間接的にコンピュータに実行させるようにするのではなく、ＣＤ−ＲＯＭに記憶させたプログラムを直接的に実行するようにしてもよい。
【０１３９】
なお、コンピュータによって実行可能なプログラムとしては、ＣＰＵにより直接実行可能なプログラムだけではなく、ソース形式のプログラム、一旦他の形態等に変換が必要なもの（例えば、圧縮処理がされたプログラム、暗号化プログラム）、さらには、他のモジュール部分と組合して実行可能なプログラムも含む。
【０１４０】
上記各実施形態では、図３の各機能をＣＰＵおよびプログラムによって実現することとしているが、各機能の一部または全部をハードウェアロジック（論理回路）によって構成してもよい。
【図面の簡単な説明】
【図１】実施形態によるコミュニティシステムの全体図である。
【図２】実施形態によるコミュニティシステムの処理概要図である。
【図３】コミュニティシステムの機能ブロック図である。
【図４】携帯電話のハードウェア構成例を示す図である。
【図５】サービスサーバのハードウェア構成例を示す図である。
【図６】配車コントロールサーバのハードウェア構成例を示す図である。
【図７】コミュニティシステムの第１実施形態によるコミュニティ設定処理の概要図である。
【図８】第１実施形態によるコミュニティ設定処理のフローチャートである。
【図９】第１実施形態のコミュニティデータベースの構成例を示す図である。
【図１０】図１０Ａ、図１０Ｂ、図１０Ｃは、コミュニティ設定処理における携帯電話の画面表示例である。
【図１１】コミュニティシステムの第２実施形態によるタクシー共同予約設定処理の概要図である。
【図１２】第２実施形態によるタクシー共同予約設定処理のフローチャートである。
【図１３】第２実施形態のタクシー予約データベースの構成例を示す図である。
【図１４】第２実施形態の配車スケジュールデータベースの構成例を示す図である。
【図１５】図１５Ａ、図１５Ｂは、タクシー共同予約を利用する際の携帯電話の画面表示例である。
【符号の説明】
１００・・・携帯電話
１０２・・・携帯電話
１０４・・・携帯電話
２００・・・インターネット
３００・・・サービスサーバ
７００・・・配車コントロールサーバ
４００・・・コミュニティＤＢ
５００・・・タクシー予約ＤＢ
６００・・・配車スケジュールＤＢ

Claims (18)

1. 第１の端末装置および第２の端末装置と、当該端末装置と通信可能であって、当該端末装置からのエントリー情報を受け付けるサーバ装置とを備えたコミュニティ管理システムであって、
   前記第１の端末装置は、第１のエントリー情報を送信し、
   前記第２の端末装置は、第２のエントリー情報を送信し、
   前記サーバ装置は、
   前記第１のエントリー情報と第２のエントリー情報とにアクセス可能であり、
   前記第１のエントリー情報と第２のエントリー情報とを取得し、
   前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断する適合判断処理を行い、
   前記適合部分を有すると判断した場合には、前記第１の端末装置と第２の端末装置とを関連づける関連処理を行うこと、
   を特徴とするコミュニティ管理システム。
2. 端末装置からのエントリー情報を受け付けるサーバ装置であって、
   前記サーバ装置は、
   第１の端末装置が送信する第１のエントリー情報と第２の端末装置が送信する第２のエントリー情報とにアクセス可能であり、
   前記第１のエントリー情報と第２のエントリー情報とを取得し、
   前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断する適合判断処理を行い、
   前記適合部分を有すると判断した場合には、前記第１の端末装置と第２の端末装置とを関連づける関連処理を行うこと、
   を特徴とするサーバ装置。
3. コンピュータを、端末装置からのエントリー情報を受け付けるサーバ装置として機能させるための、コンピュータ読取可能なプログラムであって、
   前記プログラムは、
   第１の端末装置が送信する第１のエントリー情報と第２の端末装置が送信する第２のエントリー情報とを取得する処理、
   前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断する適合判断処理、
   前記適合部分を有すると判断した場合には、前記第１の端末装置と第２の端末装置とを関連づける関連処理、
   をコンピュータに実行させるためのプログラム。
4. 請求項１〜３のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
   前記サーバ装置の関連処理は、
   前記第１の端末装置と第２の端末装置とに対して前記適合部分の内容に関する共通エントリー情報を送信することを含むこと、
   を特徴とするもの。
5. 請求項１〜４のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
   前記サーバ装置の関連処理は、
   前記第１の端末装置に対して前記第２のエントリー情報に関連する情報を送信すること、または、前記第２の端末装置に対して前記第１のエントリー情報に関連する情報を送信することの少なくともいずれかを含むこと、
   を特徴とするもの。
6. 請求項１〜５のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
   前記サーバ装置の関連処理は、
   前記第１の端末装置と第２の端末装置との間を通信可能状態にすることを含むこと、
   を特徴とするもの。
7. 請求項１〜６のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
   前記サーバ装置の前記適合判断処理は、
   前記第１のエントリー情報と第２のエントリー情報との共通部分の有無を判断することを含むこと、
   を特徴とするもの。
8. 請求項１〜７のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
   前記エントリー情報は、当該エントリー情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
   前記サーバ装置の前記適合判断処理は、
   前記第１の端末装置の端末位置情報と前記第２の端末装置の端末位置情報とが適合するか否かに基づいて、前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断することを含むこと、
   を特徴とするもの。
9. 請求項１〜８のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
   前記エントリー情報は、当該エントリー情報を送信する前記端末装置のユーザのプロファイル情報を含んでおり、
   前記サーバ装置の前記適合部分判断処理は、
   前記第１の端末装置のプロファイル情報と前記第２の端末装置のプロファイル情報とが適合するか否かに基づいて、前記第１のエントリー情報と第２のエントリー情報との間の適合部分の有無を判断することを含むこと、
   を特徴とするもの。
10. 請求項１〜９のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
    前記エントリー情報は、前記端末装置のユーザが利用を希望する車両に関する車両予約情報を含んでおり、
    前記共通エントリー情報は、前記第１の端末装置および第２の端末装置の両方のユーザが利用を予定する車両に関する乗合い車両予約情報を含むこと、
    を特徴とするもの。
11. 請求項１０のコミュニティ管理システム、またはサーバ装置、またはプログラムのいずれかにおいて、
    前記車両予約情報は、
    前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかを含んでおり、
    前記サーバ装置の前記適合判断処理は、
    前記第１のエントリー情報に含まれる車両予約情報と前記第２のエントリー情報に含まれる車両予約情報とにおける、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかの共通部分の有無を判断することを含むこと、
    を特徴とするもの。
12. 請求項１０または１１のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
    前記乗合い車両予約情報は、
    前記車両を利用するユーザ人数に関する車両利用人数、または、当該車両の利用に関して当該ユーザが負担する車両利用料金情報のいずれかの内容を含むこと、
    を特徴とするもの。
13. 請求項１１または１２のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
    前記車両予約情報は、当該車両予約情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
    前記サーバ装置は、さらに、
    前記端末位置情報に基づいて、当該端末装置の位置から前記出発地までの経路に関する経路情報を当該端末装置に対して送信すること、
    を特徴とするもの。
14. 請求項１０〜１３のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
    前記サーバ装置は、さらに、
    前記車両の位置に関する車両位置情報、または当該車両の空車状況に関する車両空車情報の少なくともいずれかに基づいて前記乗合い車両予約情報が対象とする車両を決定すること、
    を特徴とするもの。
15. 請求項１〜１４のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
    前記エントリー情報は、前記端末装置のユーザが享受するサービスの申込みに関する情報であり、
    前記サーバ装置は、さらに、
    前記関連処理によって関連づけられた前記第１の端末装置および第２の端末装置の各ユーザが前記サービスの享受に関して負担する各サービス料金を、前記端末装置が前記エントリー情報を送信した順序、または当該サーバ装置が当該エントリー情報を取得した順序のいずれかに基づいて決定すること、
    を特徴とするもの。
16. 請求項１５のコミュニティ管理システム、またはサーバ装置、またはプログラムのいずれかにおいて、
    前記サーバ装置は、
    前記第１の端末装置または第２の端末装置の中で、前記エントリー情報を先に送信した端末装置のユーザ、または当該サーバ装置が先に取得した前記エントリー情報に関する端末装置のユーザのサービス料金を、他の端末装置のユーザよりも低く決定すること、
    を特徴とするもの。
17. コンピュータを用いて、ユーザからのエントリーを受け付けて当該ユーザのコミュニティを管理するコミュニティ管理方法であって、
    複数のユーザから個別にエントリーを受け付け、
    当該複数のユーザからのエントリー同士の適合部分の有無を判断し、
    前記適合部分を有すると判断した場合には、当該適合部分を有するエントリーを受け付けたユーザ同士を関連づけること、
    を特徴とするコミュニティ管理方法。
18. コンピュータを用いて、ユーザからの車両予約情報を受け付けて当該ユーザによる車両乗合い予約情報を決定する車両乗合い予約管理方法であって、
    前記車両予約情報は、
    前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかを含んでおり、
    複数のユーザから個別に前記車両利用情報を受け付け、
    当該車両予約情報に含まれる、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかの共通部分の有無を判断し、
    前記共通部分を有すると判断した場合には、当該共通部分を有する車両予約情報を受け付けたユーザに対して乗合い車両予約情報を送信すること、
    を特徴とする車両乗合い予約管理方法。

Images