JP2004227490A - コミュニティ管理システムおよびその方法 - Google Patents
コミュニティ管理システムおよびその方法 Download PDFInfo
- Publication number
- JP2004227490A JP2004227490A JP2003017517A JP2003017517A JP2004227490A JP 2004227490 A JP2004227490 A JP 2004227490A JP 2003017517 A JP2003017517 A JP 2003017517A JP 2003017517 A JP2003017517 A JP 2003017517A JP 2004227490 A JP2004227490 A JP 2004227490A
- Authority
- JP
- Japan
- Prior art keywords
- information
- terminal device
- entry information
- vehicle
- community
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 68
- 230000008569 process Effects 0.000 claims description 57
- 238000007726 management method Methods 0.000 claims description 27
- 238000004891 communication Methods 0.000 abstract description 29
- 230000009471 action Effects 0.000 abstract description 11
- 238000012790 confirmation Methods 0.000 description 14
- 238000010586 diagram Methods 0.000 description 13
- 230000000694 effects Effects 0.000 description 8
- 230000006870 function Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 7
- 238000006243 chemical reaction Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 230000029305 taxis Effects 0.000 description 4
- 230000008901 benefit Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- VNWKTOKETHGBQD-UHFFFAOYSA-N methane Chemical compound C VNWKTOKETHGBQD-UHFFFAOYSA-N 0.000 description 2
- 230000008520 organization Effects 0.000 description 2
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000007423 decrease Effects 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 230000033001 locomotion Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 239000003345 natural gas Substances 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Transfer Between Computers (AREA)
- Traffic Control Systems (AREA)
Abstract
【課題】共通の目的を持つユーザ同士がコミュニケーションをとることをサポートするコミュニティ管理システムおよびその方法を提供することを目的とする。
【解決手段】携帯電話100は、ユーザの行動目的を含む第1エントリー情報をサービスサーバ300に送信する。携帯電話102は、第2エントリー情報をサービスサーバ300に送信する。サービスサーバ300は、第1エントリー情報と第2エントリー情報とが適合するか否かを判断する。サービスサーバ300は、携帯電話100および102に対して、共通エントリー情報を送信する。あるいは、サービスサーバ300は、携帯電話102に第1エントリー情報を送信するか、携帯電話100に第2エントリー情報を送信する。あるいは、サービスサーバ300は、携帯電話100および102の間でのeメール通信または電話通話を許可する。
【選択図】 図2
【解決手段】携帯電話100は、ユーザの行動目的を含む第1エントリー情報をサービスサーバ300に送信する。携帯電話102は、第2エントリー情報をサービスサーバ300に送信する。サービスサーバ300は、第1エントリー情報と第2エントリー情報とが適合するか否かを判断する。サービスサーバ300は、携帯電話100および102に対して、共通エントリー情報を送信する。あるいは、サービスサーバ300は、携帯電話102に第1エントリー情報を送信するか、携帯電話100に第2エントリー情報を送信する。あるいは、サービスサーバ300は、携帯電話100および102の間でのeメール通信または電話通話を許可する。
【選択図】 図2
Description
【0001】
【発明の属する技術分野】
この発明は、コミュニティ管理システムおよびその方法に関するものであり、特に、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることに関する。
【0002】
【従来の技術】
携帯端末を利用した様々な情報の送受信を行うシステムが運営されている。例えば、携帯端末のユーザは、自分のいる場所に関する情報(買い物情報、飲食店情報、交通機関情報など)を受信することによって一定の利益を得ることができる。
【0003】
ここで、従来のシステムでは、携帯端末のユーザが得る情報は、その情報を提供する業者によって作成・提供されるものであった。しかしながら、携帯端末のユーザにとっては、そのような業者からの情報だけではなく、その情報を利用して行動する他のユーザからの新しい情報(経験、感想、知識など)を要望する場合もある。
【0004】
そのような要望を満たすため、情報端末装置から位置情報付きの情報を送受信することにより、他の情報端末装置をもつ所有者の情報(例えば、他の人がシステムに登録した経験や知識等)を得ることのできる技術がある。(例えば、特許文献1参照)。
【0005】
【特許文献1】
特開2001−285526号公報(第1図)
【発明が解決しようとする課題】
上記のような技術によれば、携帯端末ユーザは、業者によって作成されたコンテンツだけではなく、他の携帯端末ユーザからの情報を共有することができるという一定のメリットがある。
【0006】
しかしながら、携帯端末ユーザにとっては、他のユーザとの情報の共有だけではなく、より積極的に他のユーザとコミュニケーションをとることを望むことも多い。具体的には、自分の居る場所や特定の場所において、目的を共通にする他のユーザと互いの情報をリアルタイムで交換したり、あるいは、目的を共通にする他のユーザと行動を共にすることを望む場合もある。例えば、共通の目的地にタクシー移動をする場合に他のユーザとの乗り合いを申し込んだり、あるいは、大量購入によって割引きのメリットを受けることのできる商品について他のユーザとの共同購入を申し込んだりする等の状況を挙げることができる。
【0007】
本発明は、上記のような要求に鑑みて、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートするコミュニティ管理システムおよびその方法を提供することを目的とする。
【0008】
【課題を解決するための手段および発明の効果】
1)本発明のコミュニティ管理システムは、
第1の端末装置および第2の端末装置と、当該端末装置と通信可能であって、当該端末装置からのエントリー情報を受け付けるサーバ装置とを備えたコミュニティ管理システムであって、
前記第1の端末装置は、第1のエントリー情報を送信し、
前記第2の端末装置は、第2のエントリー情報を送信し、
前記サーバ装置は、
前記第1のエントリー情報と第2のエントリー情報とにアクセス可能であり、
前記第1のエントリー情報と第2のエントリー情報とを取得し、
前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断する適合判断処理を行い、
前記適合部分を有すると判断した場合には、前記第1の端末装置と第2の端末装置とを関連づける関連処理を行うこと、
を特徴としている。
【0009】
これらの特徴により、前記エントリー情報に適合部分を有する前記端末装置のユーザ同士は、前記関連処理によって関連づけられることができる。したがって、前記コミュニティ管理システムは、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。
【0010】
4)本発明の前記サーバ装置の関連処理は、
前記第1の端末装置と第2の端末装置とに対して前記適合部分の内容に関する共通エントリー情報を送信することを含むこと、
を特徴としている。
【0011】
この特徴により、前記端末装置のユーザ同士は、前記共通エントリー情報を共有することを介して関連づけられることができる。
【0012】
5)本発明の前記サーバ装置の関連処理は、
前記第1の端末装置に対して前記第2のエントリー情報に関連する情報を送信すること、または、前記第2の端末装置に対して前記第1のエントリー情報に関連する情報を送信することの少なくともいずれかを含むこと、
を特徴としている。
【0013】
この特徴により、前記端末装置のユーザ同士は、前記エントリー情報の送受信または交換をすることを介して関連づけられることができる。
【0014】
6)本発明の前記サーバ装置の関連処理は、
前記第1の端末装置と第2の端末装置との間を通信可能状態にすることを含むこと、
を特徴としている。
【0015】
この特徴により、前記端末装置のユーザ同士は、互いに通信することを介してコミュニケーションをとることができる。
【0016】
7)本発明の前記サーバ装置の前記適合判断処理は、
前記第1のエントリー情報と第2のエントリー情報との共通部分の有無を判断することを含むこと、
を特徴としている。
【0017】
この特徴により、前記端末装置のユーザは、前記エントリー情報に共通部分を含む他のユーザと関連づけられることができる。したがって、前記コミュニティ管理システムは、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。
【0018】
8)本発明の前記エントリー情報は、当該エントリー情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第1の端末装置の端末位置情報と前記第2の端末装置の端末位置情報とが適合するか否かに基づいて、前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴としている。
【0019】
この特徴により、前記端末装置のユーザは、前記端末位置情報が適合する他のユーザと関連づけられることができる。
【0020】
9)本発明の前記エントリー情報は、当該エントリー情報を送信する前記端末装置のユーザのプロファイル情報を含んでおり、
前記サーバ装置の前記適合部分判断処理は、
前記第1の端末装置のプロファイル情報と前記第2の端末装置のプロファイル情報とが適合するか否かに基づいて、前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴としている。
【0021】
この特徴により、前記端末装置のユーザは、前記プロファイル情報が適合する他のユーザと関連づけられることができる。
【0022】
10)本発明の前記エントリー情報は、前記端末装置のユーザが利用を希望する車両に関する車両予約情報を含んでおり、
前記共通エントリー情報は、前記第1の端末装置および第2の端末装置の両方のユーザが利用を予定する車両に関する乗合い車両予約情報を含むこと、
を特徴としている。
【0023】
この特徴により、前記端末装置のユーザ同士は、前記乗合い車両予約情報を共有することを介して、前記車両の乗合いを行うことができる。
【0024】
11)本発明の前記車両予約情報は、
前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかを含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第1のエントリー情報に含まれる車両予約情報と前記第2のエントリー情報に含まれる車両予約情報とにおける、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかの共通部分の有無を判断することを含むこと、
を特徴としている。
【0025】
この特徴により、前記端末装置のユーザは、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかが共通する他のユーザと、前記車両の乗合いをすることができる。
【0026】
12)本発明の前記乗合い車両予約情報は、
前記車両を利用するユーザ人数に関する車両利用人数、または、当該車両の利用に関して当該ユーザが負担する車両利用料金情報のいずれかの内容を含むこと、
を特徴としている。
【0027】
この特徴により、前記端末装置のユーザは、前記乗合い車両予約情報に含まれる車両予約人数、または、車両利用料金情報により、前記車両の乗合いの予定を確認することができる。
【0028】
13)本発明の前記車両予約情報は、当該車両予約情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置は、さらに、
前記端末位置情報に基づいて、当該端末装置の位置から前記出発地までの経路に関する経路情報を当該端末装置に対して送信すること、
を特徴としている。
【0029】
この特徴により、前記端末装置のユーザは、前記経路情報を利用することによって、前記出発地までの経路の選択を容易に決定することができる。
【0030】
14)本発明の前記サーバ装置は、さらに、
前記車両の位置に関する車両位置情報、または当該車両の空車状況に関する車両空車情報の少なくともいずれかに基づいて前記乗合い車両予約情報が対象とする車両を決定すること、
を特徴としている。
【0031】
この特徴により、前記サーバ装置は、前記端末装置のユーザに対する車両の手配を効率的に行うことができる。
【0032】
15)本発明の前記エントリー情報は、前記端末装置のユーザが享受するサービスの申込みに関する情報であり、
前記サーバ装置は、さらに、
前記関連処理によって関連づけられた前記第1の端末装置および第2の端末装置の各ユーザが前記サービスの享受に関して負担する各サービス料金を、前記端末装置が前記エントリー情報を送信した順序、または当該サーバ装置が当該エントリー情報を取得した順序のいずれかに基づいて決定すること、
を特徴としている。
【0033】
この特徴により、前記サーバ装置は、前記サービス料金を前記端末装置のユーザ毎に決定することができる。
【0034】
16)本発明の前記サーバ装置は、
前記第1の端末装置または第2の端末装置の中で、前記エントリー情報を先に送信した端末装置のユーザ、または当該サーバ装置が先に取得した前記エントリー情報に関する端末装置のユーザのサービス料金を、他の端末装置のユーザよりも低く決定すること、
を特徴としている。
【0035】
この特徴により、前記サーバ装置は、よりアクセスの早かった前記端末装置のユーザの前記サービス料金の負担を、他のユーザよりも優遇することができる。したがって、前記携帯端末のユーザに対して、前記サーバ装置へのアクセスのインセンティブを増加させることができる。
【0036】
以下、用語の定義について説明する。
【0037】
この発明において、
「エントリー情報」とは、自分以外の他者との情報の共有または情報のやり取り、あるいは、サービスの共有またはやり取りを行うことを目的として利用する情報一般を含む概念である。例えば、他者との乗合いを目的としたタクシーの乗車予約の情報、または、他者との情報交換を目的としたコンサートや演劇などのイベントへの参加に関連する情報などが、この概念に含まれる。実施形態では、コミュニティリクエスト情報または予約リクエスト情報が、この「エントリー情報」に含まれる。
【0038】
「プロファイル情報」とは、個人または団体の属性一般を含む概念である。例えば、個人の肩書き、または性別、または年齢(年齢層)、または団体の組織名などがこの概念に対応する。実施形態では、図9のコミュニティDB400に記録される「グループ」の情報(例えば、大学名、会社名、サークル名など)が、この「プロファイル情報」に含まれる。
【0039】
「第1のエントリー情報と第2のエントリー情報との間の適合部分」とは、第1のエントリー情報と第2のエントリー情報との間で、情報が完全に一致する部分、または情報が部分一致する部分、または情報の属性が一致する部分、または情報の類似度が高い部分を含む概念である。実施形態では、図9に示すユーザ(メールアドレス「123@com.ne.jp」に対応)のコミュニティリクエスト情報と、ユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)のコミュニティリクエスト情報との間で一致する、「タイトル」および「通信開始希望日時」の各情報、または、情報の一致度の高い「ユーザ現在地」の情報が、この「第1のエントリー情報と第2のエントリー情報との間の適合部分」に含まれる。
【0040】
【発明の実施の形態】
本発明のコミュニティ管理システムの実施形態としての「コミュニティシステム」について説明する。このコミュニティシステムは、共通の目的を持つ携帯端末ユーザ同士が、他のユーザとのコミュニケーションをとることをサポートするシステムである。
【0041】
以下の説明では、第1実施形態として、本システムが、共通の目的を持つ携帯端末ユーザ同士のコミュニティを設定する処理を説明する。次に、第2実施形態として、本システムが、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約を設定する処理(タクシー乗り合わせ予約の処理)を説明する。
【0042】
以下、コミュニティシステムの概略、装置のハードウェア構成、特許請求の範囲に記載した用語と実施形態との対応を説明し、次に各実施形態の説明等を行う。
目次
1.コミュニティシステムの概要
2.ハードウェア構成等
3.特許請求の範囲に記載した用語と実施形態との対応
4.第1実施形態(コミュニティ設定処理)
5.第1実施形態による効果
6.第2実施形態(タクシー共同予約設定処理)
7.第2実施形態による効果
8.その他の実施形態等
−−−−−−−−−−−−−−−−−−−
−−1.コミュニティシステムの概要−−
図1は、実施形態による、コミュニティ管理システムとしてのコミュニティシステムの概略である。コミュニティシステムは、ユーザが使用する携帯電話100、102、104、およびGPS衛星250(GPS=Global Positioning System、全地球測位システム)、本システムのサービスを提供するサービスサーバ300で構成される。さらに、第2実施形態においては、配車コントロールサーバ700が、タクシー予約に対応するタクシーの配車を設定する。携帯電話100、102、104、サービスサーバ300、配車コントロールサーバ700のそれぞれは、インターネット200を介して接続可能である。
【0043】
サービスサーバ300は、第1実施形態による処理の際に利用するコミュニティデータベース(以下、データベースを「DB」とする)400、第2実施形態による処理の際に利用するタクシー予約DB500を記録する。配車コントロールサーバ700は、配車スケジュールDB600を記録する。各データベースの記録内容については後述する。
【0044】
なお、コミュニティDB400、タクシー予約DB500、配車スケジュールDB600のそれぞれは、各サーバのハードディスクに記録するようにしてもよいし、あるいは、各サーバとは別のサーバに記録するようにしてもよい。携帯電話およびサーバの数、構成については例示であって、当業者に周知の手段によって変形可能である。
【0045】
次に、図2に基づいてコミュニティシステムの処理の概要を説明する。携帯電話100(第1の端末装置)は、ユーザの操作に応じて、そのユーザの行動目的を含む第1エントリー情報をサービスサーバ300に送信する(1)。サービスサーバ300は、受信した第1エントリー情報を記録する(2)。携帯電話102(第2の端末装置)は、ユーザの操作に応じて第2エントリー情報をサービスサーバ300に送信する(3)。サービスサーバ300は、受信した第2エントリー情報を記録する(4)。サービスサーバ300は、第1エントリー情報と第2エントリー情報とが適合するか否かを判断する(5)。
【0046】
これらの処理により、複数の携帯電話のユーザの中で、共通の行動目的を持つユーザの組み合わせが有るか否かが判断される。サービスサーバ300は、第1エントリー情報と第2エントリー情報とが適合すると判断した場合には、記号6−A、B、Cに記載するいずれか、あるいはそれらを組み合わせた処理を行い、共通の行動目的を持つユーザ同士のコミュニティを設定する。
【0047】
具体的には、サービスサーバ300は、携帯電話100および102に対して、共通エントリー情報を送信する(記号6−A)。あるいは、サービスサーバ300は、携帯電話102(第2の端末装置)に第1エントリー情報を送信するか、携帯電話100(第1の端末装置)に第2エントリー情報を送信する(6−B)。あるいは、サービスサーバ300は、携帯電話100および102の間でのeメール通信または電話通話を許可する(6−C)。
【0048】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士のコミュニティが設定される。第1実施形態におけるコミュニティの設定は、サービスサーバ300が、携帯電話のユーザ同士のメール交換を可能とする例を採用する(図2記号6−C参照)。一方、第2実施形態におけるコミュニティの設定は、サービスサーバ300が、タクシーの乗合いのための共通予約情報のメールを、その乗合いに参加するユーザの携帯電話に送信する例を採用する(図2記号6−A参照)。なお、上記図2の各処理の詳細は、第1実施形態および第2実施形態において説明する。
【0049】
−−2.ハードウェア構成等−−
2−1.機能ブロック
図3は、コミュニティシステムの機能ブロック図を示す。携帯電話100(携帯電話102、104も同様)は、エントリー情報を送信するエントリー情報送信手段80を備えている。
【0050】
一方、サービスサーバ300は、エントリー情報を受信するエントリー情報受信手段82、エントリー情報を記録するエントリー情報記録部84、エントリー情報適合判断手段86、端末装置関連付け手段88を備えている。エントリー情報適合判断手段86は、複数のエントリー情報の間の適合部分の有無を判断する処理を行う。端末装置関連付け手段88は、エントリー情報適合判断手段86によって、複数のエントリー情報の間に適合部分が有ると判断した場合に、それら複数のエントリー情報を送信した端末装置同士を関連づける処理を行う。
【0051】
2−2.携帯電話
図4は、図3の携帯電話100(携帯電話102、104も同様)をCPUを用いて実現した場合のハードウェア構成の一例である。携帯電話100は、CPU10、RAM12、ROM14、ディスプレイ22、入力部18、スピーカ20、インターネット200に接続するための通信回路16、GPS衛星からの電波を受信するGPS受信機21を備えている。CPU10は、携帯電話100全体を制御する。RAM12は、CPU10のワーク領域等を提供する。ROM14には、CPU10を動作させるためのプログラムや、ウェブを閲覧するためのブラウザプログラムが記録されている。入力部18の操作により生成される操作情報は、CPU10に入力され、CPU10が生成した画像情報及び音声情報は、ディスプレイ22、スピーカ20にそれぞれ出力される。なお、ブラウザプログラムは、EZweb(登録商標)、i−mode(登録商標)等の通常のプログラムを使用すればよく、本システム専用のプログラム等は必要ではない。
【0052】
2−3.サービスサーバ
図5は、図3のサービスサーバ300をCPUを用いて実現した場合のハードウェア構成の一例である。サービスサーバ300は、CPU30、ハードディスク34、メモリ32、キーボード/マウス38、ディスプレイ40、スピーカ42、インターネット200に接続するための通信回路36を備えている。CPU30は、サービスサーバ300全体を制御する。メモリ32は、CPU30のワーク領域等を提供する。キーボード/マウス38の操作により生成される操作情報は、CPU30に入力され、CPU30が生成した画像情報及び音声情報は、ディスプレイ40、スピーカ42にそれぞれ出力される。ハードディスク34には、コミュニティDB400、タクシー予約DB500、本システムのコミュニティ設定プログラムが記録されている。なお、このプログラムによる本システムの運営は、EZweb(登録商標)、i−mode(登録商標)等のサービスを利用して行えばよい。
【0053】
2−4.配車コントロールサーバ
図6は、図3の配車コントロールサーバ700をCPUを用いて実現した場合のハードウェア構成の一例である。配車コントロールサーバ700は、CPU60、ハードディスク64、メモリ62、キーボード/マウス68、ディスプレイ70、スピーカ72、インターネット200に接続するための通信回路66を備えている。各ハードウェアの機能は、図5のサービスサーバ300の場合と同様である。ハードディスク64には、配車スケジュールDB600(図14参照)と、本システムの配車コントロールプログラムが記録されている。
【0054】
本実施形態では、サービスサーバ300および配車コントロールサーバ700のオペレーティングシステム(OS)の例として、マイクロソフト社のWindows(登録商標)XP、NT、2000等を用いることとする。本実施形態のプログラムは、OSと共働して各機能を実現しているが、これに限らず、プログラム単独で各機能を実現するようにしてもよい。
【0055】
2−5.データベース
次に、本システムのデータベースの構成例について説明する。本システムでは、サービスサーバ300が、コミュニティDB400およびタクシー予約DB500を記録し、配車コントロールサーバ700が、配車スケジュールDB600を記録する。
【0056】
図9は、サービスサーバ300が記録するコミュニティDB400の構成例である。コミュニティDB400には、携帯電話のユーザによって入力された各ユーザのコミュニティリクエスト情報が記録される。このコミュニティリクエスト情報は、携帯電話のユーザ同士のコミュニティを設定する際の判断材料になるものである。具体的には、コミュニティDB400には、コミュニティリクエスト情報が記録された日付(「Date」)、ユーザの「メールアドレス」、ユーザが使用する携帯端末の所在を示す「ユーザ現在地(X(緯度)、Y(経度)、Z(高度))」、ユーザが属する「グループ」、コミュニティリクエストの内容を示す「タイトル」、本システムを通じてコミュニティが設定される場合に、コミュニティに参加するメンバー同士でのメール交換の開始を希望する時間を示す「通信可能希望日時」の各情報が、ユーザ毎に記録される。
【0057】
図13は、サービスサーバ300が記録するタクシー予約DB500の構成例である。タクシー予約DB500には、携帯電話のユーザによって入力された各ユーザの予約リクエスト情報が記録される。この予約リクエスト情報は、携帯電話のユーザ同士がタクシーの乗合い予約を設定する際の判断材料になるものである。具体的には、タクシー予約DB500には、予約リクエスト情報を送信したユーザ毎に、そのユーザを特定する「ユーザメールアドレス」、サービスサーバ300が設定したタクシー予約を特定する「予約スケジュールNo.」、そのユーザが乗合いを許可するか否かの情報を示す「乗合い許可」、タクシーの乗合いがあった場合のユーザのタクシー料金の負担割合を示す「料金割合」、予約されたタクシーを特定する「タクシーNo.」、ユーザが所有する携帯電話の現在地(すなわち、ユーザの現在地)を示す「現在地」、予約したタクシーの「乗車時刻」、「乗車地」、「目的地」の各情報が記録される。
【0058】
図14は、配車コントロールサーバ700が記録する配車スケジュールDB600の構成例である。配車スケジュールDB600には、各タクシー毎の予約スケジュールが記録される。具体的には、配車スケジュールDB600には、タクシー毎に、タクシーを特定する「タクシーNo.」、そのタクシーに割り当てられた予約スケジュールを特定する「予約スケジュールNo.」、ユーザがそのタクシーに乗車する予定時刻である「乗車時刻」、ユーザがそのタクシーに乗車する場所を特定する「乗車地」、タクシー移動の目的場所を特定する「目的地」の各情報が記録される。
【0059】
−−3.特許請求の範囲に記載した用語と実施形態との対応−−
特許請求の範囲に記載した用語と実施形態との対応は以下の通りである。
【0060】
「第1の端末装置」は、携帯電話100または102に対応し、「第2の端末装置」は、携帯電話100または102に対応する。「エントリー情報」は、コミュニティリクエスト情報または予約リクエスト情報に対応する。「サーバ装置」は、サービスサーバ300または配車コントロールサーバ700に対応する。
【0061】
「適合判断処理」は、図8ステップS852の処理または図12ステップS1203の処理を行うCPU30に対応する。「関連処理」は、図8ステップS859の処理または図12ステップS1215の処理を行うCPU30に対応する。「共通エントリー情報」は、コミュニティ設定情報に含まれる情報(図8ステップS859参照)、または予約確認メールに含まれる情報(図12ステップS1215参照)に対応する。
【0062】
「端末位置情報」は、図9のコミュニティDB400に記録される「ユーザ現在地」の情報、または図13のタクシー予約DB500に記録される「現在地」の情報に対応する。「プロファイル情報」は、コミュニティDB400に記録される「グループ」の情報に対応する。
【0063】
「車両予約情報」および「サービスの申込みに関する情報」は、予約リクエスト情報に対応し、「乗合い車両予約情報」は、予約確認メールに含まれる情報(図12ステップS1215参照)に対応する。「車両利用人数」は、図15Bの画面表示例における「現在の乗合い人数」の情報に対応し、「車両利用料金情報」は、図15Bの「お客様の料金負担割合」の情報に対応する。
【0064】
「経路情報」は、図15Bの画面表示例における「乗車位置までの最短経路のご案内」に含まれる情報に対応する。
【0065】
−−4.第1実施形態(コミュニティ設定処理)−−
コミュニティシステムの第1実施形態として、共通の目的を持つ携帯端末ユーザ同士のコミュニティを設定する処理を説明する。第1実施形態におけるコミュニティの設定は、サービスサーバ300が、携帯電話のユーザ同士のメール交換を可能とする例を採用する(図2記号6−C参照)。
【0066】
4−1.第1実施形態(コミュニティ設定処理)の概要
図7は、コミュニティ設定処理の概要図である。携帯電話100は、ユーザの操作に応じてコミュニティリクエスト情報をサービスサーバ300に送信する(1)。サービスサーバ300は、受信したコミュニティリクエスト情報を記録する(2)。
【0067】
携帯電話102は、ユーザの操作に応じてコミュニティリクエスト情報をサービスサーバ300に送信する(3)。サービスサーバ300は、受信したコミュニティリクエスト情報を記録する(4)。サービスサーバ300は、以上の処理により、複数のコミュニティリクエスト情報を記録した場合に、それらのコミュニティリクエスト情報についてデータマッチング処理(データ照合)を行う(5)。
【0068】
サービスサーバ300は、照合するコミュニティリクエスト情報が有ると判断した場合には、それらのコミュニティリクエスト情報を送信した携帯電話(図7では、携帯電話100および携帯電話102を想定)のユーザ同士でのeメール通信を許可するか否かを、それらの携帯電話のユーザに確認する処理を行う(6)。サービスサーバ300は、eメール通信の許可の確認があった場合には、携帯電話100および102のユーザ同士のeメール通信を許可する処理を行う(7)。
【0069】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士について、相互のメール交換を介したコミュニティが設定される。
【0070】
4−2.第1実施形態(コミュニティ設定処理)のフローチャート
次に、図8に基づき、第1実施形態(コミュニティ設定処理)における各装置のCPUが実行するプログラムのフローチャートを説明する。図8のフローチャートは、サービスサーバ300のコミュニティDB400に既に複数の携帯電話のユーザからのコミュニティリクエスト情報が記録されている状態を前提として、携帯電話100のユーザが、サービスサーバ300に対して新たにコミュニティリクエスト情報を送信する例を説明するものである。ただし、以下に説明するフローチャートは例示であって、コミュニティ設定処理のプログラム、アルゴリズムは、当業者に周知の手法によって変形可能である。
【0071】
携帯電話100のCPU10は、ユーザの操作に応じてブラウザプログラムを立ち上げてサービスサーバ300にアクセスし、コミュニティリクエスト情報を送信する(図8ステップS801)。
【0072】
ここで、本実施形態のコミュニティ設定処理における携帯電話のディスプレイ22の画面表示例を図10に示す。図10Aは、ステップS801における携帯電話100の画面表示例である。図10Aには、携帯電話100のユーザが入力したコミュニティリクエスト情報の内容が表示される。具体的には、コミュニティを設定する条件(キーワードなど)である「コミュニティタイトル」、コミュニティに参加するメンバー同士のメール交換の開始を希望する時間を示す「コミュニティ開始希望時間」、そのユーザが属するグループ名を示す「グループ」の各内容が入力される。なお、このコミュニティリクエスト情報の内容の入力は、例示として、「コミュニティ開始希望時間」は日付と時刻(1時間単位)を入力対象とし、「コミュニティタイトル」はあらゆる文字列(フリーキーワード)を対象するようにしているが、これに限られるものではない。その他の実施形態として、サービスサーバ300側であらかじめ設定された文字列(選択キーワード)からユーザが選択するようにしてもよい。その他、コミュニティリクエスト情報の選択、入力は、当業者に周知の手段によって変形可能である。
【0073】
サービスサーバ300のCPU30は、受信したコミュニティリクエスト情報をコミュニティDB400に記録する(図8ステップS851)。コミュニティDB400の記録内容(図9参照)は、項目2−5で上述したものであり、具体的には、図10Aの「コミュニティタイトル」は、DB400中の「タイトル」に対応し、図10Aの「コミュニティ開始希望時間」は、DB400中の「通信開始希望日時」に対応する。その他、DB400には、携帯電話100の「メールアドレス」、「ユーザ現在地」が記録される。
【0074】
「ユーザ現在地」の情報については、サービスサーバ300のCPU30が、携帯電話100の位置情報(「端末位置情報」に対応)を取得することによって記録する内容である。この位置情報の取得は、GPSの技術を利用すればよい。具体的には、携帯電話100のCPU10は、GPS衛星250(一般的には4つの人工衛星)からの電波をGPS受信機21を介して受信し、その携帯電話100の位置を特定するX(緯度)、Y(経度)、Z(高度)などの各情報を演算する。そして、CPU10は、そのGPS位置データをサービスサーバ300に送信する。GPS位置データは、CPU10が、例えば図8ステップS801の処理においてコミュニティリクエスト情報と併せて送信すればよい。
【0075】
図8ステップS851の処理により、本実施形態では、携帯電話100のユーザの情報(ここでは、図9のメールアドレス「123@com.ne.jp」のユーザの情報とする)がコミュニティDB400に記録される。CPU30は、図9のコミュニティDB400に記録された情報を参照し、受信したコミュニティリクエスト情報に適合するコミュニティリクエスト情報を検索する(図8ステップS852)(「第1のエントリー情報と第2のエントリー情報との適合部分(共通部分)の有無を判断する」に対応)。なお、コミュニティDB400に記録される各コミュニティリクエスト情報は、所定の時間(例えば、図9の「通信開始希望日時」)を超過した場合に削除されるものとする。
【0076】
ここで、適合するコミュニティリクエスト情報とは、本実施形態では、例示として、図9に記録された情報の中で「タイトル」および「通信開始希望日時」の各情報が一致(部分一致などを含む)し、かつ、「ユーザ現在地」の情報の一致度の高い(例えば、同一都道府県内、または、「ユーザ現在地」間の距離が500メートル以内など)コミュニティリクエスト情報の組み合わせのことをいう。「ユーザ現在地」の情報の比較は、コミュニティリクエスト情報に含まれるGPS位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)に基づいて行えばよい。その他、サービスサーバ300は、GPS位置データではなく(あるいはGPS位置データとともに)、携帯電話の位置を示す地域名データに基づいて「ユーザ現在地」の情報の比較を行うようにしてもよい。具体的には、サービスサーバ300は、位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)を地域名データに変換するための変換テーブルをハードディスク34に記録しておく。そして、携帯電話からGPS位置データを受信すると、CPU30は、変換テーブルを利用してGPS位置データを地域名データに変換し、その地域名データを「ユーザ現在地」として記録する(図13の「現在地」の情報参照)。
【0077】
図9の例では、携帯電話100のユーザ(メールアドレス「123@com.ne.jp」に対応)のコミュニティリクエスト情報と、ユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)のコミュニティリクエスト情報とが、適合するコミュニティリクエスト情報となる。以下、便宜上、ユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)の所有する携帯電話を携帯電話102とする。
【0078】
CPU30は、図8ステップS852の処理の結果、受信したコミュニティリクエスト情報に適合するコミュニティリクエスト情報がコミュニティDB400に記録されているか否かを判断する(図8ステップS853)。適合するコミュニティリクエスト情報が無いと判断した場合には、CPU30は処理を終了する。
【0079】
CPU30は、ステップS853の処理において適合するコミュニティリクエスト情報が有ると判断した場合には、その適合するコミュニティリクエスト情報を送信した携帯電話、すなわち、携帯電話100および102に対してコミュニティ許可確認情報を送信する(図8ステップS855)。携帯電話100のCPU10は、コミュニティ許可確認情報を受信したか否かを判断し(ステップS803)、受信していない場合には処理を終了する。なお、ステップS803以降の処理は、携帯電話102についても同様に行われる。
【0080】
ステップS803においてコミュニティ許可確認情報を受信したと判断した場合には、CPU10は、コミュニティ許可画面をディスプレイ22に表示する(ステップS804)。図10Bは、コミュニティ許可画面の画面例である。コミュニティ許可画面には、「コミュニティタイトル」と、コミュニティ設定の許可の有無を確認するコマンドが表示される。具体的には、ユーザが”はい許可します。”のコマンドを選択した場合は、CPU10は、後述するステップS807においてコミュニティ許可情報をサービスサーバ300に送信することになる。
【0081】
次に、CPU10は、ユーザによるコミュニティ許可情報の入力の有無を判断し(図8ステップS805)、入力がなければ処理を終了する。一方、ステップS805においてコミュニティ許可情報の入力が有ると判断した場合には、CPU10は、コミュニティ許可情報をサービスサーバ300に送信する(ステップS807)。
【0082】
CPU30は、コミュニティ設定の対象となるユーザの全てからコミュニティ許可情報を受信したか否かを判断し(ステップS857)、受信していないと判断した場合には処理を終了する。このステップS857の処理の判断は、本実施形態では、例として、コミュニティ設定の対象となるユーザのコミュニティ開始時刻(図9の「通信開始希望日時」に対応)までを期限として行うこととしている。
【0083】
一方、ステップS857において、コミュニティ設定の対象となるユーザの全てから(ここでは、携帯電話100および102のユーザ)、コミュニティ許可情報を受信したと判断した場合には、CPU30は、コミュニティに属する他のメンバーのメールアドレス(携帯電話用)を含むコミュニティ設定情報を送信し(「第1の端末装置と第2の端末装置との間を通信可能状態にする」に対応)、処理を終了する(ステップS859)。
【0084】
ここでは、CPU30は、携帯電話100に対して携帯電話102のメールアドレス(「aiu@zmail.ne.jp」)を含むコミュニティ設定情報を送信する。一方、CPU30は、携帯電話102に対して携帯電話100のメールアドレス(「123@com.ne.jp」)を含むコミュニティ設定情報を送信する(「第1の端末装置に対して前記第2のエントリー情報に関連する情報を送信すること、または、第2の端末装置に対して前記第1のエントリー情報に関連する情報を送信すること」に対応)。
【0085】
CPU10は、コミュニティ設定情報を受信して、ディスプレイ22にコミュニティ設定情報を表示する。図10Cは、図9ステップS808の処理によってディスプレイ22に表示されるコミュニティ設定画面の画面例である。コミュニティ設定画面には、「コミュニティタイトル」と、「コミュニティメンバーのメールアドレス」が表示される。
【0086】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士について、相互のメール交換を介したコミュニティが設定される。具体的には、”Y響コンサート(大阪)”を鑑賞するという共通の行動目的を持つユーザ同士が、相互のメール交換を開始することを可能としたコミュニティが設定されることになる。
【0087】
なお、図8ステップS857、S859の処理では、CPU30は、コミュニティ設定の対象となるユーザの全てからコミュニティ許可情報を受信した場合に、コミュニティに属する他のメンバーのメールアドレスを含むコミュニティ設定情報を送信することとしたが、これに限られるものではない。その他の実施形態として、CPU30は、コミュニティ設定の対象となるユーザの全てではなく、一部のユーザからのコミュニティ許可情報を受信した場合にも、その一部のユーザに対してコミュニティ設定情報を送信するようにしてもよい。具体的には、例えばユーザX、ユーザYの2人で構成されるコミュニティが設定されている場合に、ユーザAが、そのコミュニティと同一のコミュニティリクエスト情報を送信したとする。この場合、図8ステップS855の処理により、CPU30は、X、Y、Aに対してコミュニティ許可確認情報を送信する。このとき、コミュニティ許可情報を送信したユーザがXおよびAであった場合(Yは非許可)には、CPU30は、一部のユーザであるXおよびAに対してコミュニティ設定情報を送信することになる。
【0088】
−−5.第1実施形態による効果−−
第1実施形態によれば、共通の行動目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。これにより、目的を共通にする他のユーザと互いの情報をリアルタイムで交換したり、あるいは、目的を共通にする他のユーザと行動を共にすることができる。例えば、共通のイベントに参加する予定の他のユーザと連絡をとったり、あるいは情報交換をすることができる。その他、デパートや観光地など、共通の場所に存在するユーザ同士が話題を共有することも可能である。
【0089】
第1実施形態では、コミュニティの設定として、CPU30が、他のメンバーのメールアドレス(携帯電話用)を含むコミュニティ設定情報を送信する例を示した。その他の実施形態として、他のユーザの電話番号(携帯電話用)を含むコミュニティ設定情報を送信するようにしてもよい。これにより、コミュニティリクエスト情報が共通するユーザ同士で、電話によるコミュニケーション(会話)を行うことができる。
【0090】
図8ステップS859では、サービスサーバ300のCPU30は、携帯電話100に対して携帯電話102のメールアドレスを含むコミュニティ設定情報を送信する一方で、携帯電話102に対して携帯電話100のメールアドレスを含むコミュニティ設定情報を送信する例を示したが、これに限られるものではない。その他の実施形態として、コミュニティに属する全てのユーザに対してではなく、コミュニティに属する一部のユーザのみにコミュニティ設定情報を送信するようにしてもよい。
【0091】
図8ステップS852の処理において、コミュニティリクエスト情報が適合する場合の例示として、図9のDBに記録された情報の中で「タイトル」および「通信開始希望日時」の各情報が一致し、かつ、「ユーザ現在地」の情報の一致度の高いコミュニティリクエスト情報の組み合わせを例示したが、これに限られるものではない。その他の実施形態として、図9に記録される「グループ」および「ユーザ現在地」の各情報の一致度が高いコミュニティリクエスト情報の組み合わせを、適合するコミュニティリクエスト情報として採用してもよい。
【0092】
これにより、本システムは、大学や学校、会社、サークル等の組織が共通し、かつ、物理的に近くに居るメンバー同士がコミュニケーションをとることをサポートすることができる。したがって、知人またはグループの共通時間を増加させることができ、仕事上の会話や日常会話などの促進を通じて互いのコミュニケーションの改善を図ることが期待できる。
【0093】
−−6.第2実施形態(タクシー共同予約設定処理)−−
コミュニティシステムの第2実施形態として、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約を設定する処理を説明する。第2実施形態におけるコミュニティの設定は、サービスサーバ300が、タクシー乗合いを設定された携帯電話のユーザに対して、共通エントリー情報を送信する例を採用する(図2記号6−A参照)。
【0094】
6−1.第2実施形態(タクシー共同予約設定処理)の概要
図11は、タクシー共同予約設定処理の概要図である。携帯電話100は、ユーザの操作に応じて予約リクエスト情報をサービスサーバ300に送信する(1)。サービスサーバ300は、受信した予約リクエスト情報に基づいて予約スケジュールをタクシー予約DB500に記録し(2)、その予約スケジュールを配車コントロールサーバ700に送信する(3)。配車コントロールサーバ700は、配車スケジュールDB600の記録内容を更新する(4)。サービスサーバ300は、予約確認メールを携帯電話100に送信する(5)。
【0095】
携帯電話102は、ユーザの操作に応じて予約リクエスト情報をサービスサーバ300に送信する(6)。サービスサーバ300は、タクシー予約DB500の中に、受信した予約リクエスト情報と合致する予約スケジュールが有るか否かを検索する(7)。この処理により、サービスサーバ300は、タクシーの乗合いが可能か否かを判断する。
【0096】
サービスサーバ300は、合致する予約スケジュールが有ると判断した場合には、タクシーの乗合い用に設定された予約スケジュールを配車コントロールサーバ700に送信する(8)。図では、携帯電話100および102のユーザがタクシーの乗合いを設定されたこととしている。配車コントロールサーバ700は、配車スケジュールDB600の記録内容を更新する(9)。サービスサーバ300は、予約確認メールを携帯電話100および102に送信する(10)。
【0097】
以上の処理により、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約が設定される。
【0098】
6−2.第2実施形態(タクシー共同予約設定処理)のフローチャート
次に、図12に基づき、第2実施形態(タクシー共同予約設定処理)における各装置のCPUが実行するプログラムのフローチャートを説明する。図12のフローチャートは、サービスサーバ300のタクシー予約DB500に、携帯電話100のユーザの予約リクエスト情報を含む、複数の携帯電話のユーザからの予約リクエスト情報が記録されている状態を前提として、携帯電話102のユーザが、サービスサーバ300に対して新たに予約リクエスト情報を送信する例を説明するものである。ただし、以下に説明するフローチャートは例示であって、タクシー共同予約設定処理のプログラム、アルゴリズムは、当業者に周知の手法によって変形可能である。
【0099】
携帯電話102のCPU10は、ユーザの操作に応じてブラウザプログラムを立ち上げてサービスサーバ300にアクセスし、予約リクエスト情報を送信する(図12ステップS1201)。
【0100】
ここで、本実施形態のタクシー共同予約設定処理における携帯電話のディスプレイ22の画面表示例を図15に示す。図15Aは、ステップS1201における携帯電話102の画面表示例である。図15Aには、携帯電話102のユーザが入力した予約リクエスト情報の内容が表示される。具体的には、「タクシー予約内容」として、「乗車時刻」、「乗車場所」、「目的地」、乗合いを許可するか否かを示す「乗合い許可」の各内容が表示される。なお、この予約リクエスト情報の内容の入力は、例示として、「乗車時刻」は日付と時刻(15分単位)を入力対象とし、「乗車場所」および「目的地」は、サービスサーバ300側であらかじめ設定された文字列(選択キーワード)からユーザが選択するようにする。具体的には、「乗車場所」および「目的地」を示す文字列として、駅、施設、住所、会社名等をあらかじめサービスサーバ300側で記録しておく。その他、予約リクエスト情報の選択、入力は、当業者に周知の手段によって変形可能である。
【0101】
サービスサーバ300のCPU30は、予約リクエスト情報を受信する(ステップS1202)。CPU30は、タクシー予約DB500に記録された情報を参照し、受信した予約リクエスト情報に適合する予約スケジュールを検索する(図12ステップS1203)(「第1のエントリー情報と第2のエントリー情報との間の適合部分(共通部分)の有無を判断する」に対応)。なお、タクシー予約DB500に記録される各予約リクエスト情報は、所定の時間(例えば、図13の「乗車時刻」)を超過した場合に削除されるものとする。
【0102】
ここで、予約リクエスト情報と予約スケジュールとが適合する場合とは、実施形態では、例示として、受信した予約リクエスト情報と、図13のタクシー予約DB500に記録された各予約スケジュールとについて、両者が「乗合い許可」しており、両者の「乗車地」、「目的地」、「乗車時刻」の各情報の一致度が高い場合をいう。「乗車地」および「目的地」の情報の一致度が高い場合とは、例えば、予約リクエスト情報における「乗車地」および予約スケジュールにおける「乗車地」が一致する場合をいい、「乗車時刻」が情報の一致度が高い場合とは、例えば、予約リクエスト情報における「乗車時刻」と予約スケジュールにおける「乗車時刻」との時間差が15分以内の場合をいう。
【0103】
CPU30は、図12ステップS1203の処理の結果、受信した予約リクエスト情報に適合する予約スケジュールがタクシー予約DB500に記録されているか否かを判断する(ステップS1205)。
【0104】
以下、CPU30が、ステップS1205において、予約リクエスト情報に適合する予約スケジュールが無いと判断した場合を説明する。CPU30は、受信した予約リクエスト情報を配車コントロールサーバ700に送信する(ステップS1207)。
【0105】
配車コントロールサーバ700のCPU60は、予約リクエスト情報を受信し、配車コントロールサーバ700が管理するタクシーについての所定の情報を参照して、その予約リクエスト情報に対応する配車スケジュールを決定する(ステップS1250)。ここで、タクシーについて所定の情報とは、実施形態では、例示として、タクシーの位置情報(「車両位置情報」に対応)と、タクシーの空車情報(「車両空車情報」に対応)とを利用することとしている。これらの情報は、当業者に周知のGPS技術、タクシーと配車コントロールサーバ700との間の通信技術を利用して、配車コントロールサーバ700が収集すればよい。
【0106】
CPU60は、受信した予約リクエスト情報に基づいて決定した配車スケジュールを配車スケジュールDB600に記録する(ステップS1251)。配車スケジュールDB600の記録内容(図14参照)は、項目2−5で上述したものであり、具体的には、図13の「乗車時刻」は、DB600中の「乗車時刻」に対応し、図13の「乗車地」は、DB600中の「乗車地」に対応し、図13の「目的地」は、DB600中の「目的地」に対応する。その他、DB600には、各予約スケジュールを担当するタクシーを特定する「タクシーNo.」、各予約スケジュールを特定する「予約スケジュールNo.」が記録される。この「予約スケジュールNo.」は、配車コントロールサーバ700のCPU60が自動採番することとする。
【0107】
配車コントロールサーバ700のCPU60は、ステップS1251で記録した配車スケジュールをサービスサーバ300に送信し(ステップS1252)、処理を終了する。サービスサーバ300のCPU30は、ステップS1207においてサービスサーバ300に送信した予約リクエスト情報と、ステップS1252の処理によって配車コントロールサーバ700から送信された配車スケジュールとに基づいて、新規の予約スケジュールをタクシー予約DB500に記録する(ステップS1211)。具体的には、図13には、予約リクエスト情報に基づき、「ユーザメールアドレス」、「乗合い許可」、「現在地」、「乗車時刻」、「乗車地」、「目的地」が記録される。「現在地」の情報の取得については第1実施形態と同様にGPS位置データを利用する。具体的には、サービスサーバ300は、位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)を地域名データに変換するための変換テーブルをハードディスク34に記録しておく。そして、携帯電話からGPS位置データを受信すると、CPU30は、変換テーブルを利用してGPS位置データを地域名データに変換し、その地域名データを「ユーザ現在地」として記録する。なお、「ユーザ現在地」の記録は、これに限らず、GPS位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)を記録するようにしてもよい(図9の「ユーザ現在地」の情報参照)。GPS位置データは、CPU10が、例えば図12ステップS1201の処理において予約リクエスト情報と併せて送信すればよい。
【0108】
また、図13には、配車スケジュールに基づいて、「予約スケジュールNo.」、「タクシーNo.」が記録される。「料金割合」の情報については、後述の「8.その他の実施形態等」の項において説明する。なお、配車スケジュールDB600に記録される各配車スケジュールは、所定の時間(例えば、図14の「乗車時刻」)を超過した場合に削除されるものとする。
【0109】
次に、CPU30が、ステップS1203において、タクシー予約DB500の中に、予約リクエスト情報に適合する予約スケジュールが有ると判断した場合を説明する。CPU30は、受信した予約リクエスト情報に基づいて、共通予約スケジュールをタクシー予約DB500に記録する(図12ステップS1209)。
【0110】
ここでは、携帯電話100のユーザの予約スケジュール(具体的には、図13のメールアドレス「123@com.ne.jp」のユーザ用の予約スケジュールNo.「XY015−1」)が先に記録されており、後に、その予約スケジュールに適合する、携帯電話102のユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)の予約リクエスト情報が送信された場合を例に挙げて説明する。この場合、携帯電話100および102のユーザの予約内容は、「乗車時刻」、「乗車地」、「目的地」が一致する。したがって、図12ステップS1205において、CPU30は、携帯電話102からの予約リクエスト情報は、携帯電話100のユーザ用の予約スケジュール「XY015−1」に適合すると判断する。そして、ステップS1209の処理によって、CPU30は、携帯電話102のユーザ用の予約スケジュールを、「XY015−1」に共通する予約スケジュールであることを示す「XY015−2」としてタクシー予約DB500に記録する。この場合、CPU30は、両方の予約スケジュールの親番号である「XY015」が一致することに基づいて、共通する予約スケジュールであることを判断する。
【0111】
ステップS1211またはステップS1209の処理の後、CPU30は、ユーザの現在地からタクシー乗車地までの最短経路の検索処理を行う(ステップS1213)。具体的には、CPU30は、ステップS1202の処理によって受信した予約リクエスト情報の送信元である携帯電話の現在地(図13のタクシー予約DB500に記録される「現在地」の情報)から、タクシー乗車地(タクシー予約DB500に記録される「乗車地」の情報)までの最短経路の検索を行う。この検索処理は、位置情報、および鉄道・バスなどの公共交通機関に関する経路情報を利用した、当業者に周知の経路選択シミュレーションプログラムなどを利用して行えばよい。
【0112】
ステップS1213の処理の後、CPU30は、予約スケジュールに含まれる全てのユーザに対して予約確認メールを送信して処理を終了する(ステップS1215)。ここでは、CPU30は、予約スケジュールNo.「XY015」に該当するユーザである携帯電話100(メールアドレス「123@com.ne.jp」に対応)と、携帯電話102(メールアドレス「aiu@zmail.ne.jp」に対応)とに予約確認メールを送信する。
【0113】
携帯電話102のCPU10は、予約確認メールを受信する(ステップS1217)。CPU10は、予約確認メールをディスプレイ22に表示して処理を終了する。
【0114】
図15Bは、ステップS1219における携帯電話102の画面表示例である。図15Bには、予約スケジュールの内容が表示される。具体的には、タクシー乗合い確認として、「現在の乗合い人数」、担当するタクシーを特定する「タクシー情報」、「タクシー予約内容」、図12ステップS1213の検索処理に基づく情報である「乗車場所までの最短経路のご案内」の各情報が表示される。
【0115】
以上の処理により、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約が設定される。なお、実施形態では、携帯電話100および102のユーザが、タクシーの乗合いを許可する例を説明した。しかしながら、乗合いを許可しないユーザの場合には、予約スケジュールは、その一人のユーザ用に設定されることになる。
【0116】
−−7.第2実施形態による効果−−
第2実施形態によれば、共通の目的地に移動する予定のあるユーザ同士が、車両の乗り合わせをする(コミュニティを設定する)ことをサポートすることができる。
【0117】
また、タクシーの乗り合わせの場合、運賃は、乗車人数の如何にかかわらず、タクシーの移動距離・時間に基づいて決定されるのが一般的である。したがって、例えば車両の乗合い人数が増加すると、乗合いする各ユーザのタクシー利用料金の負担割合が減少するという経済的な効果もある。
【0118】
第2実施形態では、サービスサーバ300のCPU30は、同一のタクシーへの乗合いを予定するユーザが追加される毎に、全てのユーザに対して予約確認メール(図15B参照)を送信する(図12ステップS1215参照)。これにより、本システムのユーザは、同一のタクシーへの「乗合い人数」を含む情報を受け取ることができる。したがって、各ユーザは、自分が乗車を予定しているタクシーへの「乗合い人数」の推移をゲーム感覚で楽しむことができる。
【0119】
第2実施形態では、配車コントロールサーバ700のCPU60は、タクシーの位置情報とタクシーの空車情報とを利用して、予約リクエスト情報に対応する配車スケジュールを決定する(図12ステップS1250参照)。これにより、タクシーの配車を管理する事業者は、ユーザの乗車予定に合わせて配車予定を決定することができ、さらに、空車状態のタクシーを削減できるという効果も期待できる。一方、ユーザも、定刻通りの配車サービスを享受することができ、目的地への移動に対する時間の無駄を削減できる。
【0120】
図12ステップS1203の処理において、予約リクエスト情報が適合する場合の例示として、複数の予約リクエスト情報の中で、「乗車地」、「目的地」、「乗車時刻」の各情報の一致度が高い予約リクエスト情報の組み合わせを例示したが、これに限られるものではない。その他の実施形態として、予約リクエスト情報が適合する条件として、「グループ」の情報の一致度が高い場合を追加してもよい。具体的には、第1実施形態と同様に、サービスサーバ300は、携帯電話のユーザから「グループ」の情報を追加して要求し、その「グループ」の情報をタクシー予約DB500に記録するようにすればよい(図9参照)。これにより、同一の目的地に移動する場合に、同じグループ(例えば、同じ会社)に属するユーザ同士でタクシーの乗り合わせをすることができる。この場合、同一グループに属するユーザ同士であるから、タクシーの乗り合わせというコミュニティを形成することで、ユーザ同士のコミュニケーションの増加も期待することができる。特に、同じ組織(会社、大学、サークルなど)に属するメンバーであれば、同時期に同一の目的地に移動する予定が重複する場合が多く、本システムの利用が好適である。
【0121】
第2実施形態では、車両の例示としてタクシーを挙げたが、これに限られるものではない。その他の実施形態として、本システムは、ユーザの要望に応じてユーザを乗せて走る車両一般に利用可能である(例えば、ハイヤーなど)。なお、本システムによってタクシーの乗り合わせの効率化を図ることにより、ガソリン・天然ガスなどの燃料資源の有効活用を実現するという効果も期待できる。
【0122】
ここで、第1実施形態では、大阪で開催される”Y響コンサート”を鑑賞するという共通の行動目的を持ち、かつ、「ユーザ現在地」が近似するユーザ同士のコミュニティ(共同体)を設定する例を説明した。一方、第2実施形態では、目的地である”XYZ本社”に移動するという共通の行動目的を持ち、かつ、「乗車地」が近似するユーザ同士のタクシー乗り合わせグループ(共同体)を設定する例を説明した。すなわち、本発明の「エントリー情報」は、位置(場所)に関連づけて特定される情報であることを1つの特徴としている。したがって、本発明は、位置に関連づけて特定されるエントリー情報の共通性と、端末装置の位置に関する端末位置情報の共通性とを判断して、コミュニティを設定することを1つの特徴としている。
【0123】
−−8.その他の実施形態等−−
8−1.コミュニティリクエスト情報または予約リクエスト情報のバリエーション
第1実施形態では、コミュニティリクエスト情報として図9のコミュニティDB400の記録内容を例示し、第2実施形態では、予約リクエスト情報として図13のタクシー予約DB500の記録内容を例示したが、これらに限られるものではない。
【0124】
その他の実施形態として、第1実施形態および第2実施形態において、所定の条件を付加したリクエスト情報(条件付きエントリー情報)を採用してもよい。具体的には、例えば、3人以上のタクシー乗り合わせが設定された場合にタクシー乗り合わせを許可する、という条件付きの予約リクエスト情報を採用してもよい。また、3人以上のタクシー乗り合わせが設定される場合であれば乗車時刻を30分遅延まで許可する、という条件付きの予約リクエスト情報を採用してもよい。
【0125】
その他、リクエスト情報の中の「グループ」の情報として、ユーザの性別または年齢を入力しておき、性別や年齢を条件としたリクエスト情報を採用してもよい。例えば、女性のユーザは、コミュニティの設定またはタクシーの乗り合わせの相手が「女性」であれば、そのコミュニティの設定またはタクシーの乗り合わせを許可する、という条件付きのリクエスト情報を採用してもよい。
【0126】
その他の実施形態として、第2実施形態において、携帯電話100等のユーザによる「乗車地」の情報の入力を省略するようにしてもよい(図12ステップS1201参照)。この場合、「現在地」の情報に基づいて、サービスサーバ300のCPU30が、あらかじめシステム内で設定された「乗車地」を選択するようにしてもよい。具体的には、CPU30は、GPS技術に基づいて取得された情報である「現在地」に最も近い「乗車地」を選択し、その「乗車地」の情報を携帯電話100等のユーザに提示するようにすればよい。これとは逆に、第2実施形態において、携帯電話100等のユーザによる「現在地」に関する情報の処理を省略するようにしてもよい。この場合、CPU30による、図12ステップS1213の処理は省略される。
【0127】
第2実施形態において、携帯電話100等のユーザによる「乗車時刻」の情報の入力を省略するようにしてもよい(図12ステップS1201参照)。この場合の乗車時刻は、早急に目的地に移動したい携帯電話のユーザのために、サービスサーバ300のCPU30が、「現在地」と「乗車地」と「最短経路」との情報に基づいて判断する。具体的には、CPU30は、GPS技術に基づいて取得された情報である現在地から乗車地までを最短経路で移動した場合の移動時間を算出し、この移動時間を現在時刻に足した時間を「乗車時刻」として決定する。
【0128】
8−2.コミュニティリクエスト情報または予約リクエスト情報の適合判断処理のバリエーション
第1実施形態では、サービスサーバ300のCPU30が、コミュニティDB400に記録された情報を参照してコミュニティリクエスト情報の照合処理(検索処理、マッチング処理)を行う(図8ステップS852参照)。一方、第2実施形態では、CPU30が、タクシー予約DB500に記録された情報を参照して予約リクエスト情報の照合処理を行う(図12ステップS1203参照)。これらの照合処理の手法は例として説明したのであって、当業者に周知の手法によって変形可能である。例えば、各照合処理において、2以上のリクエスト情報が適合すると判断する場合の基準(キーワード、地名、時刻等の各情報の一致度、一致スコアの取り方など)は、変形可能である。
【0129】
第2実施形態では、予約リクエスト情報同士が適合する場合として、「乗車地」および「目的地」の各情報の一致度が高い場合を例示した(図12ステップS1203)。その他の実施形態として、サービスサーバ300は、一部のユーザの途中乗車または途中下車を考慮したタクシー乗合いを設定するようにしてもよい。具体的には、CPU30は、予約リクエスト情報の適合処理において、各情報の「乗車地」と「目的地」との間のタクシー経路の重複部分があるか否かを判断する。例えば、ユーザXの予約リクエスト情報が、乗車地点P→地点Q→目的地点Rのタクシー経路を予定しており、他方のユーザYの予約リクエスト情報が、(イ)乗車地点O→地点P→目的地点Qのタクシー経路を予定している場合、または(ロ)乗車地点Q→地点R→目的地点Sのタクシー経路を予定している場合には、ユーザXとユーザYのそれぞれのタクシー経路に重複部分があることになる。したがって、CPU30は、タクシー移動時間とユーザの乗車時間とを考慮して、両リクエスト情報を送信したユーザに対してタクシー乗合いを設定する。
【0130】
第1実施形態および第2実施形態では、サービスサーバ300のCPU30が、
携帯電話100のユーザと携帯電話102のユーザとの間のコミュニティを設定する場合を例示した(図8ステップS859、図12ステップS1215参照)。その他の実施形態として、CPU30は、図8または図12のフローチャートに示す処理によって、3人以上のコミュニティを設定することもできる。
【0131】
その他、サービスサーバ300によってコミュニティを設定する前に、携帯電話のユーザが複数のコミュニティの設定候補の中から希望のコミュニティを選択できるようにしてもよい。具体的には、CPU30は、図8ステップS852または図12ステップS1203の検索処理により、受信したリクエスト情報に適合するリクエスト情報が複数記録されている場合には、それらをコミュニティ設定候補(またはタクシー乗合い候補)として携帯電話に送信する。そして、CPU30は、携帯電話のユーザの操作に応じて選択されたコミュニティについて、コミュニティを設定することとする。
【0132】
8−3.コミュニティシステムによる料金設定バリエーション
第2実施形態では、サービスサーバ300のCPU30が図13のタクシー予約DB500に記録する内容として、「料金割合」を例示した。この「料金割合」の情報は、タクシーの乗合いがあった場合のユーザのタクシー料金(「各ユーザがサービスの享受に関して負担する各サービス料金」に対応)の負担割合(X%)を示すものである。第2実施形態では、コミュニティシステムに対して、より先に予約リクエスト情報を登録したユーザの「料金割合」を、他のユーザよりも低くなるように設定している。具体的には、図13に示すように、予約スケジュールNo.「XY015」によってタクシー乗合いが設定されたユーザに関しては、携帯電話100のユーザ(メールアドレス「123@com.ne.jp」に対応)がタクシー運賃の45%を負担し、携帯電話102のユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)がタクシー運賃の55%を負担する。このようにして設定された料金割合は、図15Bの携帯電話のディスプレイ22の画面例で示すように、「お客様の料金負担割合」として表示される。
【0133】
これらの料金割合による各ユーザのタクシー運賃は、サービスサーバ300のCPU30が演算したうえで、担当するタクシーに対して情報を送信することを介してユーザに知らせるようにしてもよい。なお、第2実施形態のタクシー乗合いに限らず、第1実施形態のコミュニティ設定に対して、以上のような処理を採用してもよい。例えば、設定されるコミュニティの内容が、団体で参加するイベントである場合に、その団体料金の負担割合を上記と同様の処理によって設定することもできる。
【0134】
以上のように、コミュニティシステムに先にリクエスト情報を登録したユーザに対して料金面での優遇を与えることにより、ユーザに対して、本システムに参加することの動機付けが与えられるという効果もある。なお、料金割合の設定は、上記の内容に限らず、当業者に周知の手法によって変形可能である。
【0135】
その他の実施形態として、コミュニティシステムを利用するユーザについて、料金決済の情報(例えば、クレジットカード番号など)を含むユーザ登録を要求することにより、例えばタクシー運賃の支払いを容易にすることも可能である。
【0136】
8−3.装置構成バリエーション
第2実施形態では、タクシー予約に対して配車するタクシーを設定する機能を備えた配車コントロールサーバ700を例示した。これに限らず、サービスサーバ300が、配車コントロールサーバ700の機能を併せ持つようにしてもよい。その他、タクシーの予約に対して配車するタクシーの決定を、配車コントロールサーバ700の管理者が行うようにしてもよい。
【0137】
実施形態では、端末装置として携帯電話100等を例示したが、これに限られるものではなく、Personal Digital Assistant(PDA)やパーソナルコンピュータ等のその他の機器を利用してもよい。
【0138】
8−4.プログラム実行方法等の実施例
本実施形態では、CPU10、CPU30、CPU3060の動作のためのプログラムを、それぞれROM14、ハードディスク34、ハードディスク64に記憶させているが、このプログラムは、プログラムが記憶されたCD−ROMから読み出してハードディスク等にインストールすればよい。また、CD−ROM以外に、DVD−ROM、フレキシブルディスク(FD)、ICカード等のプログラムをコンピュータ可読の記録媒体からインストールするようにしてもよい。さらに、通信回線を用いてプログラムをダウンロードさせることもできる。また、CD−ROMからプログラムをインストールすることにより、CD−ROMに記憶させたプログラムを間接的にコンピュータに実行させるようにするのではなく、CD−ROMに記憶させたプログラムを直接的に実行するようにしてもよい。
【0139】
なお、コンピュータによって実行可能なプログラムとしては、CPUにより直接実行可能なプログラムだけではなく、ソース形式のプログラム、一旦他の形態等に変換が必要なもの(例えば、圧縮処理がされたプログラム、暗号化プログラム)、さらには、他のモジュール部分と組合して実行可能なプログラムも含む。
【0140】
上記各実施形態では、図3の各機能をCPUおよびプログラムによって実現することとしているが、各機能の一部または全部をハードウェアロジック(論理回路)によって構成してもよい。
【図面の簡単な説明】
【図1】実施形態によるコミュニティシステムの全体図である。
【図2】実施形態によるコミュニティシステムの処理概要図である。
【図3】コミュニティシステムの機能ブロック図である。
【図4】携帯電話のハードウェア構成例を示す図である。
【図5】サービスサーバのハードウェア構成例を示す図である。
【図6】配車コントロールサーバのハードウェア構成例を示す図である。
【図7】コミュニティシステムの第1実施形態によるコミュニティ設定処理の概要図である。
【図8】第1実施形態によるコミュニティ設定処理のフローチャートである。
【図9】第1実施形態のコミュニティデータベースの構成例を示す図である。
【図10】図10A、図10B、図10Cは、コミュニティ設定処理における携帯電話の画面表示例である。
【図11】コミュニティシステムの第2実施形態によるタクシー共同予約設定処理の概要図である。
【図12】第2実施形態によるタクシー共同予約設定処理のフローチャートである。
【図13】第2実施形態のタクシー予約データベースの構成例を示す図である。
【図14】第2実施形態の配車スケジュールデータベースの構成例を示す図である。
【図15】図15A、図15Bは、タクシー共同予約を利用する際の携帯電話の画面表示例である。
【符号の説明】
100・・・携帯電話
102・・・携帯電話
104・・・携帯電話
200・・・インターネット
300・・・サービスサーバ
700・・・配車コントロールサーバ
400・・・コミュニティDB
500・・・タクシー予約DB
600・・・配車スケジュールDB
【発明の属する技術分野】
この発明は、コミュニティ管理システムおよびその方法に関するものであり、特に、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることに関する。
【0002】
【従来の技術】
携帯端末を利用した様々な情報の送受信を行うシステムが運営されている。例えば、携帯端末のユーザは、自分のいる場所に関する情報(買い物情報、飲食店情報、交通機関情報など)を受信することによって一定の利益を得ることができる。
【0003】
ここで、従来のシステムでは、携帯端末のユーザが得る情報は、その情報を提供する業者によって作成・提供されるものであった。しかしながら、携帯端末のユーザにとっては、そのような業者からの情報だけではなく、その情報を利用して行動する他のユーザからの新しい情報(経験、感想、知識など)を要望する場合もある。
【0004】
そのような要望を満たすため、情報端末装置から位置情報付きの情報を送受信することにより、他の情報端末装置をもつ所有者の情報(例えば、他の人がシステムに登録した経験や知識等)を得ることのできる技術がある。(例えば、特許文献1参照)。
【0005】
【特許文献1】
特開2001−285526号公報(第1図)
【発明が解決しようとする課題】
上記のような技術によれば、携帯端末ユーザは、業者によって作成されたコンテンツだけではなく、他の携帯端末ユーザからの情報を共有することができるという一定のメリットがある。
【0006】
しかしながら、携帯端末ユーザにとっては、他のユーザとの情報の共有だけではなく、より積極的に他のユーザとコミュニケーションをとることを望むことも多い。具体的には、自分の居る場所や特定の場所において、目的を共通にする他のユーザと互いの情報をリアルタイムで交換したり、あるいは、目的を共通にする他のユーザと行動を共にすることを望む場合もある。例えば、共通の目的地にタクシー移動をする場合に他のユーザとの乗り合いを申し込んだり、あるいは、大量購入によって割引きのメリットを受けることのできる商品について他のユーザとの共同購入を申し込んだりする等の状況を挙げることができる。
【0007】
本発明は、上記のような要求に鑑みて、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートするコミュニティ管理システムおよびその方法を提供することを目的とする。
【0008】
【課題を解決するための手段および発明の効果】
1)本発明のコミュニティ管理システムは、
第1の端末装置および第2の端末装置と、当該端末装置と通信可能であって、当該端末装置からのエントリー情報を受け付けるサーバ装置とを備えたコミュニティ管理システムであって、
前記第1の端末装置は、第1のエントリー情報を送信し、
前記第2の端末装置は、第2のエントリー情報を送信し、
前記サーバ装置は、
前記第1のエントリー情報と第2のエントリー情報とにアクセス可能であり、
前記第1のエントリー情報と第2のエントリー情報とを取得し、
前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断する適合判断処理を行い、
前記適合部分を有すると判断した場合には、前記第1の端末装置と第2の端末装置とを関連づける関連処理を行うこと、
を特徴としている。
【0009】
これらの特徴により、前記エントリー情報に適合部分を有する前記端末装置のユーザ同士は、前記関連処理によって関連づけられることができる。したがって、前記コミュニティ管理システムは、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。
【0010】
4)本発明の前記サーバ装置の関連処理は、
前記第1の端末装置と第2の端末装置とに対して前記適合部分の内容に関する共通エントリー情報を送信することを含むこと、
を特徴としている。
【0011】
この特徴により、前記端末装置のユーザ同士は、前記共通エントリー情報を共有することを介して関連づけられることができる。
【0012】
5)本発明の前記サーバ装置の関連処理は、
前記第1の端末装置に対して前記第2のエントリー情報に関連する情報を送信すること、または、前記第2の端末装置に対して前記第1のエントリー情報に関連する情報を送信することの少なくともいずれかを含むこと、
を特徴としている。
【0013】
この特徴により、前記端末装置のユーザ同士は、前記エントリー情報の送受信または交換をすることを介して関連づけられることができる。
【0014】
6)本発明の前記サーバ装置の関連処理は、
前記第1の端末装置と第2の端末装置との間を通信可能状態にすることを含むこと、
を特徴としている。
【0015】
この特徴により、前記端末装置のユーザ同士は、互いに通信することを介してコミュニケーションをとることができる。
【0016】
7)本発明の前記サーバ装置の前記適合判断処理は、
前記第1のエントリー情報と第2のエントリー情報との共通部分の有無を判断することを含むこと、
を特徴としている。
【0017】
この特徴により、前記端末装置のユーザは、前記エントリー情報に共通部分を含む他のユーザと関連づけられることができる。したがって、前記コミュニティ管理システムは、共通の目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。
【0018】
8)本発明の前記エントリー情報は、当該エントリー情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第1の端末装置の端末位置情報と前記第2の端末装置の端末位置情報とが適合するか否かに基づいて、前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴としている。
【0019】
この特徴により、前記端末装置のユーザは、前記端末位置情報が適合する他のユーザと関連づけられることができる。
【0020】
9)本発明の前記エントリー情報は、当該エントリー情報を送信する前記端末装置のユーザのプロファイル情報を含んでおり、
前記サーバ装置の前記適合部分判断処理は、
前記第1の端末装置のプロファイル情報と前記第2の端末装置のプロファイル情報とが適合するか否かに基づいて、前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴としている。
【0021】
この特徴により、前記端末装置のユーザは、前記プロファイル情報が適合する他のユーザと関連づけられることができる。
【0022】
10)本発明の前記エントリー情報は、前記端末装置のユーザが利用を希望する車両に関する車両予約情報を含んでおり、
前記共通エントリー情報は、前記第1の端末装置および第2の端末装置の両方のユーザが利用を予定する車両に関する乗合い車両予約情報を含むこと、
を特徴としている。
【0023】
この特徴により、前記端末装置のユーザ同士は、前記乗合い車両予約情報を共有することを介して、前記車両の乗合いを行うことができる。
【0024】
11)本発明の前記車両予約情報は、
前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかを含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第1のエントリー情報に含まれる車両予約情報と前記第2のエントリー情報に含まれる車両予約情報とにおける、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかの共通部分の有無を判断することを含むこと、
を特徴としている。
【0025】
この特徴により、前記端末装置のユーザは、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかが共通する他のユーザと、前記車両の乗合いをすることができる。
【0026】
12)本発明の前記乗合い車両予約情報は、
前記車両を利用するユーザ人数に関する車両利用人数、または、当該車両の利用に関して当該ユーザが負担する車両利用料金情報のいずれかの内容を含むこと、
を特徴としている。
【0027】
この特徴により、前記端末装置のユーザは、前記乗合い車両予約情報に含まれる車両予約人数、または、車両利用料金情報により、前記車両の乗合いの予定を確認することができる。
【0028】
13)本発明の前記車両予約情報は、当該車両予約情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置は、さらに、
前記端末位置情報に基づいて、当該端末装置の位置から前記出発地までの経路に関する経路情報を当該端末装置に対して送信すること、
を特徴としている。
【0029】
この特徴により、前記端末装置のユーザは、前記経路情報を利用することによって、前記出発地までの経路の選択を容易に決定することができる。
【0030】
14)本発明の前記サーバ装置は、さらに、
前記車両の位置に関する車両位置情報、または当該車両の空車状況に関する車両空車情報の少なくともいずれかに基づいて前記乗合い車両予約情報が対象とする車両を決定すること、
を特徴としている。
【0031】
この特徴により、前記サーバ装置は、前記端末装置のユーザに対する車両の手配を効率的に行うことができる。
【0032】
15)本発明の前記エントリー情報は、前記端末装置のユーザが享受するサービスの申込みに関する情報であり、
前記サーバ装置は、さらに、
前記関連処理によって関連づけられた前記第1の端末装置および第2の端末装置の各ユーザが前記サービスの享受に関して負担する各サービス料金を、前記端末装置が前記エントリー情報を送信した順序、または当該サーバ装置が当該エントリー情報を取得した順序のいずれかに基づいて決定すること、
を特徴としている。
【0033】
この特徴により、前記サーバ装置は、前記サービス料金を前記端末装置のユーザ毎に決定することができる。
【0034】
16)本発明の前記サーバ装置は、
前記第1の端末装置または第2の端末装置の中で、前記エントリー情報を先に送信した端末装置のユーザ、または当該サーバ装置が先に取得した前記エントリー情報に関する端末装置のユーザのサービス料金を、他の端末装置のユーザよりも低く決定すること、
を特徴としている。
【0035】
この特徴により、前記サーバ装置は、よりアクセスの早かった前記端末装置のユーザの前記サービス料金の負担を、他のユーザよりも優遇することができる。したがって、前記携帯端末のユーザに対して、前記サーバ装置へのアクセスのインセンティブを増加させることができる。
【0036】
以下、用語の定義について説明する。
【0037】
この発明において、
「エントリー情報」とは、自分以外の他者との情報の共有または情報のやり取り、あるいは、サービスの共有またはやり取りを行うことを目的として利用する情報一般を含む概念である。例えば、他者との乗合いを目的としたタクシーの乗車予約の情報、または、他者との情報交換を目的としたコンサートや演劇などのイベントへの参加に関連する情報などが、この概念に含まれる。実施形態では、コミュニティリクエスト情報または予約リクエスト情報が、この「エントリー情報」に含まれる。
【0038】
「プロファイル情報」とは、個人または団体の属性一般を含む概念である。例えば、個人の肩書き、または性別、または年齢(年齢層)、または団体の組織名などがこの概念に対応する。実施形態では、図9のコミュニティDB400に記録される「グループ」の情報(例えば、大学名、会社名、サークル名など)が、この「プロファイル情報」に含まれる。
【0039】
「第1のエントリー情報と第2のエントリー情報との間の適合部分」とは、第1のエントリー情報と第2のエントリー情報との間で、情報が完全に一致する部分、または情報が部分一致する部分、または情報の属性が一致する部分、または情報の類似度が高い部分を含む概念である。実施形態では、図9に示すユーザ(メールアドレス「123@com.ne.jp」に対応)のコミュニティリクエスト情報と、ユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)のコミュニティリクエスト情報との間で一致する、「タイトル」および「通信開始希望日時」の各情報、または、情報の一致度の高い「ユーザ現在地」の情報が、この「第1のエントリー情報と第2のエントリー情報との間の適合部分」に含まれる。
【0040】
【発明の実施の形態】
本発明のコミュニティ管理システムの実施形態としての「コミュニティシステム」について説明する。このコミュニティシステムは、共通の目的を持つ携帯端末ユーザ同士が、他のユーザとのコミュニケーションをとることをサポートするシステムである。
【0041】
以下の説明では、第1実施形態として、本システムが、共通の目的を持つ携帯端末ユーザ同士のコミュニティを設定する処理を説明する。次に、第2実施形態として、本システムが、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約を設定する処理(タクシー乗り合わせ予約の処理)を説明する。
【0042】
以下、コミュニティシステムの概略、装置のハードウェア構成、特許請求の範囲に記載した用語と実施形態との対応を説明し、次に各実施形態の説明等を行う。
目次
1.コミュニティシステムの概要
2.ハードウェア構成等
3.特許請求の範囲に記載した用語と実施形態との対応
4.第1実施形態(コミュニティ設定処理)
5.第1実施形態による効果
6.第2実施形態(タクシー共同予約設定処理)
7.第2実施形態による効果
8.その他の実施形態等
−−−−−−−−−−−−−−−−−−−
−−1.コミュニティシステムの概要−−
図1は、実施形態による、コミュニティ管理システムとしてのコミュニティシステムの概略である。コミュニティシステムは、ユーザが使用する携帯電話100、102、104、およびGPS衛星250(GPS=Global Positioning System、全地球測位システム)、本システムのサービスを提供するサービスサーバ300で構成される。さらに、第2実施形態においては、配車コントロールサーバ700が、タクシー予約に対応するタクシーの配車を設定する。携帯電話100、102、104、サービスサーバ300、配車コントロールサーバ700のそれぞれは、インターネット200を介して接続可能である。
【0043】
サービスサーバ300は、第1実施形態による処理の際に利用するコミュニティデータベース(以下、データベースを「DB」とする)400、第2実施形態による処理の際に利用するタクシー予約DB500を記録する。配車コントロールサーバ700は、配車スケジュールDB600を記録する。各データベースの記録内容については後述する。
【0044】
なお、コミュニティDB400、タクシー予約DB500、配車スケジュールDB600のそれぞれは、各サーバのハードディスクに記録するようにしてもよいし、あるいは、各サーバとは別のサーバに記録するようにしてもよい。携帯電話およびサーバの数、構成については例示であって、当業者に周知の手段によって変形可能である。
【0045】
次に、図2に基づいてコミュニティシステムの処理の概要を説明する。携帯電話100(第1の端末装置)は、ユーザの操作に応じて、そのユーザの行動目的を含む第1エントリー情報をサービスサーバ300に送信する(1)。サービスサーバ300は、受信した第1エントリー情報を記録する(2)。携帯電話102(第2の端末装置)は、ユーザの操作に応じて第2エントリー情報をサービスサーバ300に送信する(3)。サービスサーバ300は、受信した第2エントリー情報を記録する(4)。サービスサーバ300は、第1エントリー情報と第2エントリー情報とが適合するか否かを判断する(5)。
【0046】
これらの処理により、複数の携帯電話のユーザの中で、共通の行動目的を持つユーザの組み合わせが有るか否かが判断される。サービスサーバ300は、第1エントリー情報と第2エントリー情報とが適合すると判断した場合には、記号6−A、B、Cに記載するいずれか、あるいはそれらを組み合わせた処理を行い、共通の行動目的を持つユーザ同士のコミュニティを設定する。
【0047】
具体的には、サービスサーバ300は、携帯電話100および102に対して、共通エントリー情報を送信する(記号6−A)。あるいは、サービスサーバ300は、携帯電話102(第2の端末装置)に第1エントリー情報を送信するか、携帯電話100(第1の端末装置)に第2エントリー情報を送信する(6−B)。あるいは、サービスサーバ300は、携帯電話100および102の間でのeメール通信または電話通話を許可する(6−C)。
【0048】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士のコミュニティが設定される。第1実施形態におけるコミュニティの設定は、サービスサーバ300が、携帯電話のユーザ同士のメール交換を可能とする例を採用する(図2記号6−C参照)。一方、第2実施形態におけるコミュニティの設定は、サービスサーバ300が、タクシーの乗合いのための共通予約情報のメールを、その乗合いに参加するユーザの携帯電話に送信する例を採用する(図2記号6−A参照)。なお、上記図2の各処理の詳細は、第1実施形態および第2実施形態において説明する。
【0049】
−−2.ハードウェア構成等−−
2−1.機能ブロック
図3は、コミュニティシステムの機能ブロック図を示す。携帯電話100(携帯電話102、104も同様)は、エントリー情報を送信するエントリー情報送信手段80を備えている。
【0050】
一方、サービスサーバ300は、エントリー情報を受信するエントリー情報受信手段82、エントリー情報を記録するエントリー情報記録部84、エントリー情報適合判断手段86、端末装置関連付け手段88を備えている。エントリー情報適合判断手段86は、複数のエントリー情報の間の適合部分の有無を判断する処理を行う。端末装置関連付け手段88は、エントリー情報適合判断手段86によって、複数のエントリー情報の間に適合部分が有ると判断した場合に、それら複数のエントリー情報を送信した端末装置同士を関連づける処理を行う。
【0051】
2−2.携帯電話
図4は、図3の携帯電話100(携帯電話102、104も同様)をCPUを用いて実現した場合のハードウェア構成の一例である。携帯電話100は、CPU10、RAM12、ROM14、ディスプレイ22、入力部18、スピーカ20、インターネット200に接続するための通信回路16、GPS衛星からの電波を受信するGPS受信機21を備えている。CPU10は、携帯電話100全体を制御する。RAM12は、CPU10のワーク領域等を提供する。ROM14には、CPU10を動作させるためのプログラムや、ウェブを閲覧するためのブラウザプログラムが記録されている。入力部18の操作により生成される操作情報は、CPU10に入力され、CPU10が生成した画像情報及び音声情報は、ディスプレイ22、スピーカ20にそれぞれ出力される。なお、ブラウザプログラムは、EZweb(登録商標)、i−mode(登録商標)等の通常のプログラムを使用すればよく、本システム専用のプログラム等は必要ではない。
【0052】
2−3.サービスサーバ
図5は、図3のサービスサーバ300をCPUを用いて実現した場合のハードウェア構成の一例である。サービスサーバ300は、CPU30、ハードディスク34、メモリ32、キーボード/マウス38、ディスプレイ40、スピーカ42、インターネット200に接続するための通信回路36を備えている。CPU30は、サービスサーバ300全体を制御する。メモリ32は、CPU30のワーク領域等を提供する。キーボード/マウス38の操作により生成される操作情報は、CPU30に入力され、CPU30が生成した画像情報及び音声情報は、ディスプレイ40、スピーカ42にそれぞれ出力される。ハードディスク34には、コミュニティDB400、タクシー予約DB500、本システムのコミュニティ設定プログラムが記録されている。なお、このプログラムによる本システムの運営は、EZweb(登録商標)、i−mode(登録商標)等のサービスを利用して行えばよい。
【0053】
2−4.配車コントロールサーバ
図6は、図3の配車コントロールサーバ700をCPUを用いて実現した場合のハードウェア構成の一例である。配車コントロールサーバ700は、CPU60、ハードディスク64、メモリ62、キーボード/マウス68、ディスプレイ70、スピーカ72、インターネット200に接続するための通信回路66を備えている。各ハードウェアの機能は、図5のサービスサーバ300の場合と同様である。ハードディスク64には、配車スケジュールDB600(図14参照)と、本システムの配車コントロールプログラムが記録されている。
【0054】
本実施形態では、サービスサーバ300および配車コントロールサーバ700のオペレーティングシステム(OS)の例として、マイクロソフト社のWindows(登録商標)XP、NT、2000等を用いることとする。本実施形態のプログラムは、OSと共働して各機能を実現しているが、これに限らず、プログラム単独で各機能を実現するようにしてもよい。
【0055】
2−5.データベース
次に、本システムのデータベースの構成例について説明する。本システムでは、サービスサーバ300が、コミュニティDB400およびタクシー予約DB500を記録し、配車コントロールサーバ700が、配車スケジュールDB600を記録する。
【0056】
図9は、サービスサーバ300が記録するコミュニティDB400の構成例である。コミュニティDB400には、携帯電話のユーザによって入力された各ユーザのコミュニティリクエスト情報が記録される。このコミュニティリクエスト情報は、携帯電話のユーザ同士のコミュニティを設定する際の判断材料になるものである。具体的には、コミュニティDB400には、コミュニティリクエスト情報が記録された日付(「Date」)、ユーザの「メールアドレス」、ユーザが使用する携帯端末の所在を示す「ユーザ現在地(X(緯度)、Y(経度)、Z(高度))」、ユーザが属する「グループ」、コミュニティリクエストの内容を示す「タイトル」、本システムを通じてコミュニティが設定される場合に、コミュニティに参加するメンバー同士でのメール交換の開始を希望する時間を示す「通信可能希望日時」の各情報が、ユーザ毎に記録される。
【0057】
図13は、サービスサーバ300が記録するタクシー予約DB500の構成例である。タクシー予約DB500には、携帯電話のユーザによって入力された各ユーザの予約リクエスト情報が記録される。この予約リクエスト情報は、携帯電話のユーザ同士がタクシーの乗合い予約を設定する際の判断材料になるものである。具体的には、タクシー予約DB500には、予約リクエスト情報を送信したユーザ毎に、そのユーザを特定する「ユーザメールアドレス」、サービスサーバ300が設定したタクシー予約を特定する「予約スケジュールNo.」、そのユーザが乗合いを許可するか否かの情報を示す「乗合い許可」、タクシーの乗合いがあった場合のユーザのタクシー料金の負担割合を示す「料金割合」、予約されたタクシーを特定する「タクシーNo.」、ユーザが所有する携帯電話の現在地(すなわち、ユーザの現在地)を示す「現在地」、予約したタクシーの「乗車時刻」、「乗車地」、「目的地」の各情報が記録される。
【0058】
図14は、配車コントロールサーバ700が記録する配車スケジュールDB600の構成例である。配車スケジュールDB600には、各タクシー毎の予約スケジュールが記録される。具体的には、配車スケジュールDB600には、タクシー毎に、タクシーを特定する「タクシーNo.」、そのタクシーに割り当てられた予約スケジュールを特定する「予約スケジュールNo.」、ユーザがそのタクシーに乗車する予定時刻である「乗車時刻」、ユーザがそのタクシーに乗車する場所を特定する「乗車地」、タクシー移動の目的場所を特定する「目的地」の各情報が記録される。
【0059】
−−3.特許請求の範囲に記載した用語と実施形態との対応−−
特許請求の範囲に記載した用語と実施形態との対応は以下の通りである。
【0060】
「第1の端末装置」は、携帯電話100または102に対応し、「第2の端末装置」は、携帯電話100または102に対応する。「エントリー情報」は、コミュニティリクエスト情報または予約リクエスト情報に対応する。「サーバ装置」は、サービスサーバ300または配車コントロールサーバ700に対応する。
【0061】
「適合判断処理」は、図8ステップS852の処理または図12ステップS1203の処理を行うCPU30に対応する。「関連処理」は、図8ステップS859の処理または図12ステップS1215の処理を行うCPU30に対応する。「共通エントリー情報」は、コミュニティ設定情報に含まれる情報(図8ステップS859参照)、または予約確認メールに含まれる情報(図12ステップS1215参照)に対応する。
【0062】
「端末位置情報」は、図9のコミュニティDB400に記録される「ユーザ現在地」の情報、または図13のタクシー予約DB500に記録される「現在地」の情報に対応する。「プロファイル情報」は、コミュニティDB400に記録される「グループ」の情報に対応する。
【0063】
「車両予約情報」および「サービスの申込みに関する情報」は、予約リクエスト情報に対応し、「乗合い車両予約情報」は、予約確認メールに含まれる情報(図12ステップS1215参照)に対応する。「車両利用人数」は、図15Bの画面表示例における「現在の乗合い人数」の情報に対応し、「車両利用料金情報」は、図15Bの「お客様の料金負担割合」の情報に対応する。
【0064】
「経路情報」は、図15Bの画面表示例における「乗車位置までの最短経路のご案内」に含まれる情報に対応する。
【0065】
−−4.第1実施形態(コミュニティ設定処理)−−
コミュニティシステムの第1実施形態として、共通の目的を持つ携帯端末ユーザ同士のコミュニティを設定する処理を説明する。第1実施形態におけるコミュニティの設定は、サービスサーバ300が、携帯電話のユーザ同士のメール交換を可能とする例を採用する(図2記号6−C参照)。
【0066】
4−1.第1実施形態(コミュニティ設定処理)の概要
図7は、コミュニティ設定処理の概要図である。携帯電話100は、ユーザの操作に応じてコミュニティリクエスト情報をサービスサーバ300に送信する(1)。サービスサーバ300は、受信したコミュニティリクエスト情報を記録する(2)。
【0067】
携帯電話102は、ユーザの操作に応じてコミュニティリクエスト情報をサービスサーバ300に送信する(3)。サービスサーバ300は、受信したコミュニティリクエスト情報を記録する(4)。サービスサーバ300は、以上の処理により、複数のコミュニティリクエスト情報を記録した場合に、それらのコミュニティリクエスト情報についてデータマッチング処理(データ照合)を行う(5)。
【0068】
サービスサーバ300は、照合するコミュニティリクエスト情報が有ると判断した場合には、それらのコミュニティリクエスト情報を送信した携帯電話(図7では、携帯電話100および携帯電話102を想定)のユーザ同士でのeメール通信を許可するか否かを、それらの携帯電話のユーザに確認する処理を行う(6)。サービスサーバ300は、eメール通信の許可の確認があった場合には、携帯電話100および102のユーザ同士のeメール通信を許可する処理を行う(7)。
【0069】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士について、相互のメール交換を介したコミュニティが設定される。
【0070】
4−2.第1実施形態(コミュニティ設定処理)のフローチャート
次に、図8に基づき、第1実施形態(コミュニティ設定処理)における各装置のCPUが実行するプログラムのフローチャートを説明する。図8のフローチャートは、サービスサーバ300のコミュニティDB400に既に複数の携帯電話のユーザからのコミュニティリクエスト情報が記録されている状態を前提として、携帯電話100のユーザが、サービスサーバ300に対して新たにコミュニティリクエスト情報を送信する例を説明するものである。ただし、以下に説明するフローチャートは例示であって、コミュニティ設定処理のプログラム、アルゴリズムは、当業者に周知の手法によって変形可能である。
【0071】
携帯電話100のCPU10は、ユーザの操作に応じてブラウザプログラムを立ち上げてサービスサーバ300にアクセスし、コミュニティリクエスト情報を送信する(図8ステップS801)。
【0072】
ここで、本実施形態のコミュニティ設定処理における携帯電話のディスプレイ22の画面表示例を図10に示す。図10Aは、ステップS801における携帯電話100の画面表示例である。図10Aには、携帯電話100のユーザが入力したコミュニティリクエスト情報の内容が表示される。具体的には、コミュニティを設定する条件(キーワードなど)である「コミュニティタイトル」、コミュニティに参加するメンバー同士のメール交換の開始を希望する時間を示す「コミュニティ開始希望時間」、そのユーザが属するグループ名を示す「グループ」の各内容が入力される。なお、このコミュニティリクエスト情報の内容の入力は、例示として、「コミュニティ開始希望時間」は日付と時刻(1時間単位)を入力対象とし、「コミュニティタイトル」はあらゆる文字列(フリーキーワード)を対象するようにしているが、これに限られるものではない。その他の実施形態として、サービスサーバ300側であらかじめ設定された文字列(選択キーワード)からユーザが選択するようにしてもよい。その他、コミュニティリクエスト情報の選択、入力は、当業者に周知の手段によって変形可能である。
【0073】
サービスサーバ300のCPU30は、受信したコミュニティリクエスト情報をコミュニティDB400に記録する(図8ステップS851)。コミュニティDB400の記録内容(図9参照)は、項目2−5で上述したものであり、具体的には、図10Aの「コミュニティタイトル」は、DB400中の「タイトル」に対応し、図10Aの「コミュニティ開始希望時間」は、DB400中の「通信開始希望日時」に対応する。その他、DB400には、携帯電話100の「メールアドレス」、「ユーザ現在地」が記録される。
【0074】
「ユーザ現在地」の情報については、サービスサーバ300のCPU30が、携帯電話100の位置情報(「端末位置情報」に対応)を取得することによって記録する内容である。この位置情報の取得は、GPSの技術を利用すればよい。具体的には、携帯電話100のCPU10は、GPS衛星250(一般的には4つの人工衛星)からの電波をGPS受信機21を介して受信し、その携帯電話100の位置を特定するX(緯度)、Y(経度)、Z(高度)などの各情報を演算する。そして、CPU10は、そのGPS位置データをサービスサーバ300に送信する。GPS位置データは、CPU10が、例えば図8ステップS801の処理においてコミュニティリクエスト情報と併せて送信すればよい。
【0075】
図8ステップS851の処理により、本実施形態では、携帯電話100のユーザの情報(ここでは、図9のメールアドレス「123@com.ne.jp」のユーザの情報とする)がコミュニティDB400に記録される。CPU30は、図9のコミュニティDB400に記録された情報を参照し、受信したコミュニティリクエスト情報に適合するコミュニティリクエスト情報を検索する(図8ステップS852)(「第1のエントリー情報と第2のエントリー情報との適合部分(共通部分)の有無を判断する」に対応)。なお、コミュニティDB400に記録される各コミュニティリクエスト情報は、所定の時間(例えば、図9の「通信開始希望日時」)を超過した場合に削除されるものとする。
【0076】
ここで、適合するコミュニティリクエスト情報とは、本実施形態では、例示として、図9に記録された情報の中で「タイトル」および「通信開始希望日時」の各情報が一致(部分一致などを含む)し、かつ、「ユーザ現在地」の情報の一致度の高い(例えば、同一都道府県内、または、「ユーザ現在地」間の距離が500メートル以内など)コミュニティリクエスト情報の組み合わせのことをいう。「ユーザ現在地」の情報の比較は、コミュニティリクエスト情報に含まれるGPS位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)に基づいて行えばよい。その他、サービスサーバ300は、GPS位置データではなく(あるいはGPS位置データとともに)、携帯電話の位置を示す地域名データに基づいて「ユーザ現在地」の情報の比較を行うようにしてもよい。具体的には、サービスサーバ300は、位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)を地域名データに変換するための変換テーブルをハードディスク34に記録しておく。そして、携帯電話からGPS位置データを受信すると、CPU30は、変換テーブルを利用してGPS位置データを地域名データに変換し、その地域名データを「ユーザ現在地」として記録する(図13の「現在地」の情報参照)。
【0077】
図9の例では、携帯電話100のユーザ(メールアドレス「123@com.ne.jp」に対応)のコミュニティリクエスト情報と、ユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)のコミュニティリクエスト情報とが、適合するコミュニティリクエスト情報となる。以下、便宜上、ユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)の所有する携帯電話を携帯電話102とする。
【0078】
CPU30は、図8ステップS852の処理の結果、受信したコミュニティリクエスト情報に適合するコミュニティリクエスト情報がコミュニティDB400に記録されているか否かを判断する(図8ステップS853)。適合するコミュニティリクエスト情報が無いと判断した場合には、CPU30は処理を終了する。
【0079】
CPU30は、ステップS853の処理において適合するコミュニティリクエスト情報が有ると判断した場合には、その適合するコミュニティリクエスト情報を送信した携帯電話、すなわち、携帯電話100および102に対してコミュニティ許可確認情報を送信する(図8ステップS855)。携帯電話100のCPU10は、コミュニティ許可確認情報を受信したか否かを判断し(ステップS803)、受信していない場合には処理を終了する。なお、ステップS803以降の処理は、携帯電話102についても同様に行われる。
【0080】
ステップS803においてコミュニティ許可確認情報を受信したと判断した場合には、CPU10は、コミュニティ許可画面をディスプレイ22に表示する(ステップS804)。図10Bは、コミュニティ許可画面の画面例である。コミュニティ許可画面には、「コミュニティタイトル」と、コミュニティ設定の許可の有無を確認するコマンドが表示される。具体的には、ユーザが”はい許可します。”のコマンドを選択した場合は、CPU10は、後述するステップS807においてコミュニティ許可情報をサービスサーバ300に送信することになる。
【0081】
次に、CPU10は、ユーザによるコミュニティ許可情報の入力の有無を判断し(図8ステップS805)、入力がなければ処理を終了する。一方、ステップS805においてコミュニティ許可情報の入力が有ると判断した場合には、CPU10は、コミュニティ許可情報をサービスサーバ300に送信する(ステップS807)。
【0082】
CPU30は、コミュニティ設定の対象となるユーザの全てからコミュニティ許可情報を受信したか否かを判断し(ステップS857)、受信していないと判断した場合には処理を終了する。このステップS857の処理の判断は、本実施形態では、例として、コミュニティ設定の対象となるユーザのコミュニティ開始時刻(図9の「通信開始希望日時」に対応)までを期限として行うこととしている。
【0083】
一方、ステップS857において、コミュニティ設定の対象となるユーザの全てから(ここでは、携帯電話100および102のユーザ)、コミュニティ許可情報を受信したと判断した場合には、CPU30は、コミュニティに属する他のメンバーのメールアドレス(携帯電話用)を含むコミュニティ設定情報を送信し(「第1の端末装置と第2の端末装置との間を通信可能状態にする」に対応)、処理を終了する(ステップS859)。
【0084】
ここでは、CPU30は、携帯電話100に対して携帯電話102のメールアドレス(「aiu@zmail.ne.jp」)を含むコミュニティ設定情報を送信する。一方、CPU30は、携帯電話102に対して携帯電話100のメールアドレス(「123@com.ne.jp」)を含むコミュニティ設定情報を送信する(「第1の端末装置に対して前記第2のエントリー情報に関連する情報を送信すること、または、第2の端末装置に対して前記第1のエントリー情報に関連する情報を送信すること」に対応)。
【0085】
CPU10は、コミュニティ設定情報を受信して、ディスプレイ22にコミュニティ設定情報を表示する。図10Cは、図9ステップS808の処理によってディスプレイ22に表示されるコミュニティ設定画面の画面例である。コミュニティ設定画面には、「コミュニティタイトル」と、「コミュニティメンバーのメールアドレス」が表示される。
【0086】
以上の処理により、共通の行動目的を持つ携帯電話のユーザ同士について、相互のメール交換を介したコミュニティが設定される。具体的には、”Y響コンサート(大阪)”を鑑賞するという共通の行動目的を持つユーザ同士が、相互のメール交換を開始することを可能としたコミュニティが設定されることになる。
【0087】
なお、図8ステップS857、S859の処理では、CPU30は、コミュニティ設定の対象となるユーザの全てからコミュニティ許可情報を受信した場合に、コミュニティに属する他のメンバーのメールアドレスを含むコミュニティ設定情報を送信することとしたが、これに限られるものではない。その他の実施形態として、CPU30は、コミュニティ設定の対象となるユーザの全てではなく、一部のユーザからのコミュニティ許可情報を受信した場合にも、その一部のユーザに対してコミュニティ設定情報を送信するようにしてもよい。具体的には、例えばユーザX、ユーザYの2人で構成されるコミュニティが設定されている場合に、ユーザAが、そのコミュニティと同一のコミュニティリクエスト情報を送信したとする。この場合、図8ステップS855の処理により、CPU30は、X、Y、Aに対してコミュニティ許可確認情報を送信する。このとき、コミュニティ許可情報を送信したユーザがXおよびAであった場合(Yは非許可)には、CPU30は、一部のユーザであるXおよびAに対してコミュニティ設定情報を送信することになる。
【0088】
−−5.第1実施形態による効果−−
第1実施形態によれば、共通の行動目的を持つユーザ同士がコミュニケーションをとることをサポートすることができる。これにより、目的を共通にする他のユーザと互いの情報をリアルタイムで交換したり、あるいは、目的を共通にする他のユーザと行動を共にすることができる。例えば、共通のイベントに参加する予定の他のユーザと連絡をとったり、あるいは情報交換をすることができる。その他、デパートや観光地など、共通の場所に存在するユーザ同士が話題を共有することも可能である。
【0089】
第1実施形態では、コミュニティの設定として、CPU30が、他のメンバーのメールアドレス(携帯電話用)を含むコミュニティ設定情報を送信する例を示した。その他の実施形態として、他のユーザの電話番号(携帯電話用)を含むコミュニティ設定情報を送信するようにしてもよい。これにより、コミュニティリクエスト情報が共通するユーザ同士で、電話によるコミュニケーション(会話)を行うことができる。
【0090】
図8ステップS859では、サービスサーバ300のCPU30は、携帯電話100に対して携帯電話102のメールアドレスを含むコミュニティ設定情報を送信する一方で、携帯電話102に対して携帯電話100のメールアドレスを含むコミュニティ設定情報を送信する例を示したが、これに限られるものではない。その他の実施形態として、コミュニティに属する全てのユーザに対してではなく、コミュニティに属する一部のユーザのみにコミュニティ設定情報を送信するようにしてもよい。
【0091】
図8ステップS852の処理において、コミュニティリクエスト情報が適合する場合の例示として、図9のDBに記録された情報の中で「タイトル」および「通信開始希望日時」の各情報が一致し、かつ、「ユーザ現在地」の情報の一致度の高いコミュニティリクエスト情報の組み合わせを例示したが、これに限られるものではない。その他の実施形態として、図9に記録される「グループ」および「ユーザ現在地」の各情報の一致度が高いコミュニティリクエスト情報の組み合わせを、適合するコミュニティリクエスト情報として採用してもよい。
【0092】
これにより、本システムは、大学や学校、会社、サークル等の組織が共通し、かつ、物理的に近くに居るメンバー同士がコミュニケーションをとることをサポートすることができる。したがって、知人またはグループの共通時間を増加させることができ、仕事上の会話や日常会話などの促進を通じて互いのコミュニケーションの改善を図ることが期待できる。
【0093】
−−6.第2実施形態(タクシー共同予約設定処理)−−
コミュニティシステムの第2実施形態として、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約を設定する処理を説明する。第2実施形態におけるコミュニティの設定は、サービスサーバ300が、タクシー乗合いを設定された携帯電話のユーザに対して、共通エントリー情報を送信する例を採用する(図2記号6−A参照)。
【0094】
6−1.第2実施形態(タクシー共同予約設定処理)の概要
図11は、タクシー共同予約設定処理の概要図である。携帯電話100は、ユーザの操作に応じて予約リクエスト情報をサービスサーバ300に送信する(1)。サービスサーバ300は、受信した予約リクエスト情報に基づいて予約スケジュールをタクシー予約DB500に記録し(2)、その予約スケジュールを配車コントロールサーバ700に送信する(3)。配車コントロールサーバ700は、配車スケジュールDB600の記録内容を更新する(4)。サービスサーバ300は、予約確認メールを携帯電話100に送信する(5)。
【0095】
携帯電話102は、ユーザの操作に応じて予約リクエスト情報をサービスサーバ300に送信する(6)。サービスサーバ300は、タクシー予約DB500の中に、受信した予約リクエスト情報と合致する予約スケジュールが有るか否かを検索する(7)。この処理により、サービスサーバ300は、タクシーの乗合いが可能か否かを判断する。
【0096】
サービスサーバ300は、合致する予約スケジュールが有ると判断した場合には、タクシーの乗合い用に設定された予約スケジュールを配車コントロールサーバ700に送信する(8)。図では、携帯電話100および102のユーザがタクシーの乗合いを設定されたこととしている。配車コントロールサーバ700は、配車スケジュールDB600の記録内容を更新する(9)。サービスサーバ300は、予約確認メールを携帯電話100および102に送信する(10)。
【0097】
以上の処理により、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約が設定される。
【0098】
6−2.第2実施形態(タクシー共同予約設定処理)のフローチャート
次に、図12に基づき、第2実施形態(タクシー共同予約設定処理)における各装置のCPUが実行するプログラムのフローチャートを説明する。図12のフローチャートは、サービスサーバ300のタクシー予約DB500に、携帯電話100のユーザの予約リクエスト情報を含む、複数の携帯電話のユーザからの予約リクエスト情報が記録されている状態を前提として、携帯電話102のユーザが、サービスサーバ300に対して新たに予約リクエスト情報を送信する例を説明するものである。ただし、以下に説明するフローチャートは例示であって、タクシー共同予約設定処理のプログラム、アルゴリズムは、当業者に周知の手法によって変形可能である。
【0099】
携帯電話102のCPU10は、ユーザの操作に応じてブラウザプログラムを立ち上げてサービスサーバ300にアクセスし、予約リクエスト情報を送信する(図12ステップS1201)。
【0100】
ここで、本実施形態のタクシー共同予約設定処理における携帯電話のディスプレイ22の画面表示例を図15に示す。図15Aは、ステップS1201における携帯電話102の画面表示例である。図15Aには、携帯電話102のユーザが入力した予約リクエスト情報の内容が表示される。具体的には、「タクシー予約内容」として、「乗車時刻」、「乗車場所」、「目的地」、乗合いを許可するか否かを示す「乗合い許可」の各内容が表示される。なお、この予約リクエスト情報の内容の入力は、例示として、「乗車時刻」は日付と時刻(15分単位)を入力対象とし、「乗車場所」および「目的地」は、サービスサーバ300側であらかじめ設定された文字列(選択キーワード)からユーザが選択するようにする。具体的には、「乗車場所」および「目的地」を示す文字列として、駅、施設、住所、会社名等をあらかじめサービスサーバ300側で記録しておく。その他、予約リクエスト情報の選択、入力は、当業者に周知の手段によって変形可能である。
【0101】
サービスサーバ300のCPU30は、予約リクエスト情報を受信する(ステップS1202)。CPU30は、タクシー予約DB500に記録された情報を参照し、受信した予約リクエスト情報に適合する予約スケジュールを検索する(図12ステップS1203)(「第1のエントリー情報と第2のエントリー情報との間の適合部分(共通部分)の有無を判断する」に対応)。なお、タクシー予約DB500に記録される各予約リクエスト情報は、所定の時間(例えば、図13の「乗車時刻」)を超過した場合に削除されるものとする。
【0102】
ここで、予約リクエスト情報と予約スケジュールとが適合する場合とは、実施形態では、例示として、受信した予約リクエスト情報と、図13のタクシー予約DB500に記録された各予約スケジュールとについて、両者が「乗合い許可」しており、両者の「乗車地」、「目的地」、「乗車時刻」の各情報の一致度が高い場合をいう。「乗車地」および「目的地」の情報の一致度が高い場合とは、例えば、予約リクエスト情報における「乗車地」および予約スケジュールにおける「乗車地」が一致する場合をいい、「乗車時刻」が情報の一致度が高い場合とは、例えば、予約リクエスト情報における「乗車時刻」と予約スケジュールにおける「乗車時刻」との時間差が15分以内の場合をいう。
【0103】
CPU30は、図12ステップS1203の処理の結果、受信した予約リクエスト情報に適合する予約スケジュールがタクシー予約DB500に記録されているか否かを判断する(ステップS1205)。
【0104】
以下、CPU30が、ステップS1205において、予約リクエスト情報に適合する予約スケジュールが無いと判断した場合を説明する。CPU30は、受信した予約リクエスト情報を配車コントロールサーバ700に送信する(ステップS1207)。
【0105】
配車コントロールサーバ700のCPU60は、予約リクエスト情報を受信し、配車コントロールサーバ700が管理するタクシーについての所定の情報を参照して、その予約リクエスト情報に対応する配車スケジュールを決定する(ステップS1250)。ここで、タクシーについて所定の情報とは、実施形態では、例示として、タクシーの位置情報(「車両位置情報」に対応)と、タクシーの空車情報(「車両空車情報」に対応)とを利用することとしている。これらの情報は、当業者に周知のGPS技術、タクシーと配車コントロールサーバ700との間の通信技術を利用して、配車コントロールサーバ700が収集すればよい。
【0106】
CPU60は、受信した予約リクエスト情報に基づいて決定した配車スケジュールを配車スケジュールDB600に記録する(ステップS1251)。配車スケジュールDB600の記録内容(図14参照)は、項目2−5で上述したものであり、具体的には、図13の「乗車時刻」は、DB600中の「乗車時刻」に対応し、図13の「乗車地」は、DB600中の「乗車地」に対応し、図13の「目的地」は、DB600中の「目的地」に対応する。その他、DB600には、各予約スケジュールを担当するタクシーを特定する「タクシーNo.」、各予約スケジュールを特定する「予約スケジュールNo.」が記録される。この「予約スケジュールNo.」は、配車コントロールサーバ700のCPU60が自動採番することとする。
【0107】
配車コントロールサーバ700のCPU60は、ステップS1251で記録した配車スケジュールをサービスサーバ300に送信し(ステップS1252)、処理を終了する。サービスサーバ300のCPU30は、ステップS1207においてサービスサーバ300に送信した予約リクエスト情報と、ステップS1252の処理によって配車コントロールサーバ700から送信された配車スケジュールとに基づいて、新規の予約スケジュールをタクシー予約DB500に記録する(ステップS1211)。具体的には、図13には、予約リクエスト情報に基づき、「ユーザメールアドレス」、「乗合い許可」、「現在地」、「乗車時刻」、「乗車地」、「目的地」が記録される。「現在地」の情報の取得については第1実施形態と同様にGPS位置データを利用する。具体的には、サービスサーバ300は、位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)を地域名データに変換するための変換テーブルをハードディスク34に記録しておく。そして、携帯電話からGPS位置データを受信すると、CPU30は、変換テーブルを利用してGPS位置データを地域名データに変換し、その地域名データを「ユーザ現在地」として記録する。なお、「ユーザ現在地」の記録は、これに限らず、GPS位置データ(X(緯度)、Y(経度)、Z(高度)の各情報)を記録するようにしてもよい(図9の「ユーザ現在地」の情報参照)。GPS位置データは、CPU10が、例えば図12ステップS1201の処理において予約リクエスト情報と併せて送信すればよい。
【0108】
また、図13には、配車スケジュールに基づいて、「予約スケジュールNo.」、「タクシーNo.」が記録される。「料金割合」の情報については、後述の「8.その他の実施形態等」の項において説明する。なお、配車スケジュールDB600に記録される各配車スケジュールは、所定の時間(例えば、図14の「乗車時刻」)を超過した場合に削除されるものとする。
【0109】
次に、CPU30が、ステップS1203において、タクシー予約DB500の中に、予約リクエスト情報に適合する予約スケジュールが有ると判断した場合を説明する。CPU30は、受信した予約リクエスト情報に基づいて、共通予約スケジュールをタクシー予約DB500に記録する(図12ステップS1209)。
【0110】
ここでは、携帯電話100のユーザの予約スケジュール(具体的には、図13のメールアドレス「123@com.ne.jp」のユーザ用の予約スケジュールNo.「XY015−1」)が先に記録されており、後に、その予約スケジュールに適合する、携帯電話102のユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)の予約リクエスト情報が送信された場合を例に挙げて説明する。この場合、携帯電話100および102のユーザの予約内容は、「乗車時刻」、「乗車地」、「目的地」が一致する。したがって、図12ステップS1205において、CPU30は、携帯電話102からの予約リクエスト情報は、携帯電話100のユーザ用の予約スケジュール「XY015−1」に適合すると判断する。そして、ステップS1209の処理によって、CPU30は、携帯電話102のユーザ用の予約スケジュールを、「XY015−1」に共通する予約スケジュールであることを示す「XY015−2」としてタクシー予約DB500に記録する。この場合、CPU30は、両方の予約スケジュールの親番号である「XY015」が一致することに基づいて、共通する予約スケジュールであることを判断する。
【0111】
ステップS1211またはステップS1209の処理の後、CPU30は、ユーザの現在地からタクシー乗車地までの最短経路の検索処理を行う(ステップS1213)。具体的には、CPU30は、ステップS1202の処理によって受信した予約リクエスト情報の送信元である携帯電話の現在地(図13のタクシー予約DB500に記録される「現在地」の情報)から、タクシー乗車地(タクシー予約DB500に記録される「乗車地」の情報)までの最短経路の検索を行う。この検索処理は、位置情報、および鉄道・バスなどの公共交通機関に関する経路情報を利用した、当業者に周知の経路選択シミュレーションプログラムなどを利用して行えばよい。
【0112】
ステップS1213の処理の後、CPU30は、予約スケジュールに含まれる全てのユーザに対して予約確認メールを送信して処理を終了する(ステップS1215)。ここでは、CPU30は、予約スケジュールNo.「XY015」に該当するユーザである携帯電話100(メールアドレス「123@com.ne.jp」に対応)と、携帯電話102(メールアドレス「aiu@zmail.ne.jp」に対応)とに予約確認メールを送信する。
【0113】
携帯電話102のCPU10は、予約確認メールを受信する(ステップS1217)。CPU10は、予約確認メールをディスプレイ22に表示して処理を終了する。
【0114】
図15Bは、ステップS1219における携帯電話102の画面表示例である。図15Bには、予約スケジュールの内容が表示される。具体的には、タクシー乗合い確認として、「現在の乗合い人数」、担当するタクシーを特定する「タクシー情報」、「タクシー予約内容」、図12ステップS1213の検索処理に基づく情報である「乗車場所までの最短経路のご案内」の各情報が表示される。
【0115】
以上の処理により、共通の内容のタクシー予約を行う携帯端末ユーザ同士について、タクシー共同予約が設定される。なお、実施形態では、携帯電話100および102のユーザが、タクシーの乗合いを許可する例を説明した。しかしながら、乗合いを許可しないユーザの場合には、予約スケジュールは、その一人のユーザ用に設定されることになる。
【0116】
−−7.第2実施形態による効果−−
第2実施形態によれば、共通の目的地に移動する予定のあるユーザ同士が、車両の乗り合わせをする(コミュニティを設定する)ことをサポートすることができる。
【0117】
また、タクシーの乗り合わせの場合、運賃は、乗車人数の如何にかかわらず、タクシーの移動距離・時間に基づいて決定されるのが一般的である。したがって、例えば車両の乗合い人数が増加すると、乗合いする各ユーザのタクシー利用料金の負担割合が減少するという経済的な効果もある。
【0118】
第2実施形態では、サービスサーバ300のCPU30は、同一のタクシーへの乗合いを予定するユーザが追加される毎に、全てのユーザに対して予約確認メール(図15B参照)を送信する(図12ステップS1215参照)。これにより、本システムのユーザは、同一のタクシーへの「乗合い人数」を含む情報を受け取ることができる。したがって、各ユーザは、自分が乗車を予定しているタクシーへの「乗合い人数」の推移をゲーム感覚で楽しむことができる。
【0119】
第2実施形態では、配車コントロールサーバ700のCPU60は、タクシーの位置情報とタクシーの空車情報とを利用して、予約リクエスト情報に対応する配車スケジュールを決定する(図12ステップS1250参照)。これにより、タクシーの配車を管理する事業者は、ユーザの乗車予定に合わせて配車予定を決定することができ、さらに、空車状態のタクシーを削減できるという効果も期待できる。一方、ユーザも、定刻通りの配車サービスを享受することができ、目的地への移動に対する時間の無駄を削減できる。
【0120】
図12ステップS1203の処理において、予約リクエスト情報が適合する場合の例示として、複数の予約リクエスト情報の中で、「乗車地」、「目的地」、「乗車時刻」の各情報の一致度が高い予約リクエスト情報の組み合わせを例示したが、これに限られるものではない。その他の実施形態として、予約リクエスト情報が適合する条件として、「グループ」の情報の一致度が高い場合を追加してもよい。具体的には、第1実施形態と同様に、サービスサーバ300は、携帯電話のユーザから「グループ」の情報を追加して要求し、その「グループ」の情報をタクシー予約DB500に記録するようにすればよい(図9参照)。これにより、同一の目的地に移動する場合に、同じグループ(例えば、同じ会社)に属するユーザ同士でタクシーの乗り合わせをすることができる。この場合、同一グループに属するユーザ同士であるから、タクシーの乗り合わせというコミュニティを形成することで、ユーザ同士のコミュニケーションの増加も期待することができる。特に、同じ組織(会社、大学、サークルなど)に属するメンバーであれば、同時期に同一の目的地に移動する予定が重複する場合が多く、本システムの利用が好適である。
【0121】
第2実施形態では、車両の例示としてタクシーを挙げたが、これに限られるものではない。その他の実施形態として、本システムは、ユーザの要望に応じてユーザを乗せて走る車両一般に利用可能である(例えば、ハイヤーなど)。なお、本システムによってタクシーの乗り合わせの効率化を図ることにより、ガソリン・天然ガスなどの燃料資源の有効活用を実現するという効果も期待できる。
【0122】
ここで、第1実施形態では、大阪で開催される”Y響コンサート”を鑑賞するという共通の行動目的を持ち、かつ、「ユーザ現在地」が近似するユーザ同士のコミュニティ(共同体)を設定する例を説明した。一方、第2実施形態では、目的地である”XYZ本社”に移動するという共通の行動目的を持ち、かつ、「乗車地」が近似するユーザ同士のタクシー乗り合わせグループ(共同体)を設定する例を説明した。すなわち、本発明の「エントリー情報」は、位置(場所)に関連づけて特定される情報であることを1つの特徴としている。したがって、本発明は、位置に関連づけて特定されるエントリー情報の共通性と、端末装置の位置に関する端末位置情報の共通性とを判断して、コミュニティを設定することを1つの特徴としている。
【0123】
−−8.その他の実施形態等−−
8−1.コミュニティリクエスト情報または予約リクエスト情報のバリエーション
第1実施形態では、コミュニティリクエスト情報として図9のコミュニティDB400の記録内容を例示し、第2実施形態では、予約リクエスト情報として図13のタクシー予約DB500の記録内容を例示したが、これらに限られるものではない。
【0124】
その他の実施形態として、第1実施形態および第2実施形態において、所定の条件を付加したリクエスト情報(条件付きエントリー情報)を採用してもよい。具体的には、例えば、3人以上のタクシー乗り合わせが設定された場合にタクシー乗り合わせを許可する、という条件付きの予約リクエスト情報を採用してもよい。また、3人以上のタクシー乗り合わせが設定される場合であれば乗車時刻を30分遅延まで許可する、という条件付きの予約リクエスト情報を採用してもよい。
【0125】
その他、リクエスト情報の中の「グループ」の情報として、ユーザの性別または年齢を入力しておき、性別や年齢を条件としたリクエスト情報を採用してもよい。例えば、女性のユーザは、コミュニティの設定またはタクシーの乗り合わせの相手が「女性」であれば、そのコミュニティの設定またはタクシーの乗り合わせを許可する、という条件付きのリクエスト情報を採用してもよい。
【0126】
その他の実施形態として、第2実施形態において、携帯電話100等のユーザによる「乗車地」の情報の入力を省略するようにしてもよい(図12ステップS1201参照)。この場合、「現在地」の情報に基づいて、サービスサーバ300のCPU30が、あらかじめシステム内で設定された「乗車地」を選択するようにしてもよい。具体的には、CPU30は、GPS技術に基づいて取得された情報である「現在地」に最も近い「乗車地」を選択し、その「乗車地」の情報を携帯電話100等のユーザに提示するようにすればよい。これとは逆に、第2実施形態において、携帯電話100等のユーザによる「現在地」に関する情報の処理を省略するようにしてもよい。この場合、CPU30による、図12ステップS1213の処理は省略される。
【0127】
第2実施形態において、携帯電話100等のユーザによる「乗車時刻」の情報の入力を省略するようにしてもよい(図12ステップS1201参照)。この場合の乗車時刻は、早急に目的地に移動したい携帯電話のユーザのために、サービスサーバ300のCPU30が、「現在地」と「乗車地」と「最短経路」との情報に基づいて判断する。具体的には、CPU30は、GPS技術に基づいて取得された情報である現在地から乗車地までを最短経路で移動した場合の移動時間を算出し、この移動時間を現在時刻に足した時間を「乗車時刻」として決定する。
【0128】
8−2.コミュニティリクエスト情報または予約リクエスト情報の適合判断処理のバリエーション
第1実施形態では、サービスサーバ300のCPU30が、コミュニティDB400に記録された情報を参照してコミュニティリクエスト情報の照合処理(検索処理、マッチング処理)を行う(図8ステップS852参照)。一方、第2実施形態では、CPU30が、タクシー予約DB500に記録された情報を参照して予約リクエスト情報の照合処理を行う(図12ステップS1203参照)。これらの照合処理の手法は例として説明したのであって、当業者に周知の手法によって変形可能である。例えば、各照合処理において、2以上のリクエスト情報が適合すると判断する場合の基準(キーワード、地名、時刻等の各情報の一致度、一致スコアの取り方など)は、変形可能である。
【0129】
第2実施形態では、予約リクエスト情報同士が適合する場合として、「乗車地」および「目的地」の各情報の一致度が高い場合を例示した(図12ステップS1203)。その他の実施形態として、サービスサーバ300は、一部のユーザの途中乗車または途中下車を考慮したタクシー乗合いを設定するようにしてもよい。具体的には、CPU30は、予約リクエスト情報の適合処理において、各情報の「乗車地」と「目的地」との間のタクシー経路の重複部分があるか否かを判断する。例えば、ユーザXの予約リクエスト情報が、乗車地点P→地点Q→目的地点Rのタクシー経路を予定しており、他方のユーザYの予約リクエスト情報が、(イ)乗車地点O→地点P→目的地点Qのタクシー経路を予定している場合、または(ロ)乗車地点Q→地点R→目的地点Sのタクシー経路を予定している場合には、ユーザXとユーザYのそれぞれのタクシー経路に重複部分があることになる。したがって、CPU30は、タクシー移動時間とユーザの乗車時間とを考慮して、両リクエスト情報を送信したユーザに対してタクシー乗合いを設定する。
【0130】
第1実施形態および第2実施形態では、サービスサーバ300のCPU30が、
携帯電話100のユーザと携帯電話102のユーザとの間のコミュニティを設定する場合を例示した(図8ステップS859、図12ステップS1215参照)。その他の実施形態として、CPU30は、図8または図12のフローチャートに示す処理によって、3人以上のコミュニティを設定することもできる。
【0131】
その他、サービスサーバ300によってコミュニティを設定する前に、携帯電話のユーザが複数のコミュニティの設定候補の中から希望のコミュニティを選択できるようにしてもよい。具体的には、CPU30は、図8ステップS852または図12ステップS1203の検索処理により、受信したリクエスト情報に適合するリクエスト情報が複数記録されている場合には、それらをコミュニティ設定候補(またはタクシー乗合い候補)として携帯電話に送信する。そして、CPU30は、携帯電話のユーザの操作に応じて選択されたコミュニティについて、コミュニティを設定することとする。
【0132】
8−3.コミュニティシステムによる料金設定バリエーション
第2実施形態では、サービスサーバ300のCPU30が図13のタクシー予約DB500に記録する内容として、「料金割合」を例示した。この「料金割合」の情報は、タクシーの乗合いがあった場合のユーザのタクシー料金(「各ユーザがサービスの享受に関して負担する各サービス料金」に対応)の負担割合(X%)を示すものである。第2実施形態では、コミュニティシステムに対して、より先に予約リクエスト情報を登録したユーザの「料金割合」を、他のユーザよりも低くなるように設定している。具体的には、図13に示すように、予約スケジュールNo.「XY015」によってタクシー乗合いが設定されたユーザに関しては、携帯電話100のユーザ(メールアドレス「123@com.ne.jp」に対応)がタクシー運賃の45%を負担し、携帯電話102のユーザ(メールアドレス「aiu@zmail.ne.jp」に対応)がタクシー運賃の55%を負担する。このようにして設定された料金割合は、図15Bの携帯電話のディスプレイ22の画面例で示すように、「お客様の料金負担割合」として表示される。
【0133】
これらの料金割合による各ユーザのタクシー運賃は、サービスサーバ300のCPU30が演算したうえで、担当するタクシーに対して情報を送信することを介してユーザに知らせるようにしてもよい。なお、第2実施形態のタクシー乗合いに限らず、第1実施形態のコミュニティ設定に対して、以上のような処理を採用してもよい。例えば、設定されるコミュニティの内容が、団体で参加するイベントである場合に、その団体料金の負担割合を上記と同様の処理によって設定することもできる。
【0134】
以上のように、コミュニティシステムに先にリクエスト情報を登録したユーザに対して料金面での優遇を与えることにより、ユーザに対して、本システムに参加することの動機付けが与えられるという効果もある。なお、料金割合の設定は、上記の内容に限らず、当業者に周知の手法によって変形可能である。
【0135】
その他の実施形態として、コミュニティシステムを利用するユーザについて、料金決済の情報(例えば、クレジットカード番号など)を含むユーザ登録を要求することにより、例えばタクシー運賃の支払いを容易にすることも可能である。
【0136】
8−3.装置構成バリエーション
第2実施形態では、タクシー予約に対して配車するタクシーを設定する機能を備えた配車コントロールサーバ700を例示した。これに限らず、サービスサーバ300が、配車コントロールサーバ700の機能を併せ持つようにしてもよい。その他、タクシーの予約に対して配車するタクシーの決定を、配車コントロールサーバ700の管理者が行うようにしてもよい。
【0137】
実施形態では、端末装置として携帯電話100等を例示したが、これに限られるものではなく、Personal Digital Assistant(PDA)やパーソナルコンピュータ等のその他の機器を利用してもよい。
【0138】
8−4.プログラム実行方法等の実施例
本実施形態では、CPU10、CPU30、CPU3060の動作のためのプログラムを、それぞれROM14、ハードディスク34、ハードディスク64に記憶させているが、このプログラムは、プログラムが記憶されたCD−ROMから読み出してハードディスク等にインストールすればよい。また、CD−ROM以外に、DVD−ROM、フレキシブルディスク(FD)、ICカード等のプログラムをコンピュータ可読の記録媒体からインストールするようにしてもよい。さらに、通信回線を用いてプログラムをダウンロードさせることもできる。また、CD−ROMからプログラムをインストールすることにより、CD−ROMに記憶させたプログラムを間接的にコンピュータに実行させるようにするのではなく、CD−ROMに記憶させたプログラムを直接的に実行するようにしてもよい。
【0139】
なお、コンピュータによって実行可能なプログラムとしては、CPUにより直接実行可能なプログラムだけではなく、ソース形式のプログラム、一旦他の形態等に変換が必要なもの(例えば、圧縮処理がされたプログラム、暗号化プログラム)、さらには、他のモジュール部分と組合して実行可能なプログラムも含む。
【0140】
上記各実施形態では、図3の各機能をCPUおよびプログラムによって実現することとしているが、各機能の一部または全部をハードウェアロジック(論理回路)によって構成してもよい。
【図面の簡単な説明】
【図1】実施形態によるコミュニティシステムの全体図である。
【図2】実施形態によるコミュニティシステムの処理概要図である。
【図3】コミュニティシステムの機能ブロック図である。
【図4】携帯電話のハードウェア構成例を示す図である。
【図5】サービスサーバのハードウェア構成例を示す図である。
【図6】配車コントロールサーバのハードウェア構成例を示す図である。
【図7】コミュニティシステムの第1実施形態によるコミュニティ設定処理の概要図である。
【図8】第1実施形態によるコミュニティ設定処理のフローチャートである。
【図9】第1実施形態のコミュニティデータベースの構成例を示す図である。
【図10】図10A、図10B、図10Cは、コミュニティ設定処理における携帯電話の画面表示例である。
【図11】コミュニティシステムの第2実施形態によるタクシー共同予約設定処理の概要図である。
【図12】第2実施形態によるタクシー共同予約設定処理のフローチャートである。
【図13】第2実施形態のタクシー予約データベースの構成例を示す図である。
【図14】第2実施形態の配車スケジュールデータベースの構成例を示す図である。
【図15】図15A、図15Bは、タクシー共同予約を利用する際の携帯電話の画面表示例である。
【符号の説明】
100・・・携帯電話
102・・・携帯電話
104・・・携帯電話
200・・・インターネット
300・・・サービスサーバ
700・・・配車コントロールサーバ
400・・・コミュニティDB
500・・・タクシー予約DB
600・・・配車スケジュールDB
Claims (18)
- 第1の端末装置および第2の端末装置と、当該端末装置と通信可能であって、当該端末装置からのエントリー情報を受け付けるサーバ装置とを備えたコミュニティ管理システムであって、
前記第1の端末装置は、第1のエントリー情報を送信し、
前記第2の端末装置は、第2のエントリー情報を送信し、
前記サーバ装置は、
前記第1のエントリー情報と第2のエントリー情報とにアクセス可能であり、
前記第1のエントリー情報と第2のエントリー情報とを取得し、
前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断する適合判断処理を行い、
前記適合部分を有すると判断した場合には、前記第1の端末装置と第2の端末装置とを関連づける関連処理を行うこと、
を特徴とするコミュニティ管理システム。 - 端末装置からのエントリー情報を受け付けるサーバ装置であって、
前記サーバ装置は、
第1の端末装置が送信する第1のエントリー情報と第2の端末装置が送信する第2のエントリー情報とにアクセス可能であり、
前記第1のエントリー情報と第2のエントリー情報とを取得し、
前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断する適合判断処理を行い、
前記適合部分を有すると判断した場合には、前記第1の端末装置と第2の端末装置とを関連づける関連処理を行うこと、
を特徴とするサーバ装置。 - コンピュータを、端末装置からのエントリー情報を受け付けるサーバ装置として機能させるための、コンピュータ読取可能なプログラムであって、
前記プログラムは、
第1の端末装置が送信する第1のエントリー情報と第2の端末装置が送信する第2のエントリー情報とを取得する処理、
前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断する適合判断処理、
前記適合部分を有すると判断した場合には、前記第1の端末装置と第2の端末装置とを関連づける関連処理、
をコンピュータに実行させるためのプログラム。 - 請求項1〜3のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記サーバ装置の関連処理は、
前記第1の端末装置と第2の端末装置とに対して前記適合部分の内容に関する共通エントリー情報を送信することを含むこと、
を特徴とするもの。 - 請求項1〜4のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記サーバ装置の関連処理は、
前記第1の端末装置に対して前記第2のエントリー情報に関連する情報を送信すること、または、前記第2の端末装置に対して前記第1のエントリー情報に関連する情報を送信することの少なくともいずれかを含むこと、
を特徴とするもの。 - 請求項1〜5のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記サーバ装置の関連処理は、
前記第1の端末装置と第2の端末装置との間を通信可能状態にすることを含むこと、
を特徴とするもの。 - 請求項1〜6のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記サーバ装置の前記適合判断処理は、
前記第1のエントリー情報と第2のエントリー情報との共通部分の有無を判断することを含むこと、
を特徴とするもの。 - 請求項1〜7のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記エントリー情報は、当該エントリー情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第1の端末装置の端末位置情報と前記第2の端末装置の端末位置情報とが適合するか否かに基づいて、前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴とするもの。 - 請求項1〜8のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記エントリー情報は、当該エントリー情報を送信する前記端末装置のユーザのプロファイル情報を含んでおり、
前記サーバ装置の前記適合部分判断処理は、
前記第1の端末装置のプロファイル情報と前記第2の端末装置のプロファイル情報とが適合するか否かに基づいて、前記第1のエントリー情報と第2のエントリー情報との間の適合部分の有無を判断することを含むこと、
を特徴とするもの。 - 請求項1〜9のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記エントリー情報は、前記端末装置のユーザが利用を希望する車両に関する車両予約情報を含んでおり、
前記共通エントリー情報は、前記第1の端末装置および第2の端末装置の両方のユーザが利用を予定する車両に関する乗合い車両予約情報を含むこと、
を特徴とするもの。 - 請求項10のコミュニティ管理システム、またはサーバ装置、またはプログラムのいずれかにおいて、
前記車両予約情報は、
前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかを含んでおり、
前記サーバ装置の前記適合判断処理は、
前記第1のエントリー情報に含まれる車両予約情報と前記第2のエントリー情報に含まれる車両予約情報とにおける、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかの共通部分の有無を判断することを含むこと、
を特徴とするもの。 - 請求項10または11のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記乗合い車両予約情報は、
前記車両を利用するユーザ人数に関する車両利用人数、または、当該車両の利用に関して当該ユーザが負担する車両利用料金情報のいずれかの内容を含むこと、
を特徴とするもの。 - 請求項11または12のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記車両予約情報は、当該車両予約情報を送信する前記端末装置の位置に関する端末位置情報を含んでおり、
前記サーバ装置は、さらに、
前記端末位置情報に基づいて、当該端末装置の位置から前記出発地までの経路に関する経路情報を当該端末装置に対して送信すること、
を特徴とするもの。 - 請求項10〜13のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記サーバ装置は、さらに、
前記車両の位置に関する車両位置情報、または当該車両の空車状況に関する車両空車情報の少なくともいずれかに基づいて前記乗合い車両予約情報が対象とする車両を決定すること、
を特徴とするもの。 - 請求項1〜14のいずれかのコミュニティ管理システム、またはサーバ装置、またはプログラムにおいて、
前記エントリー情報は、前記端末装置のユーザが享受するサービスの申込みに関する情報であり、
前記サーバ装置は、さらに、
前記関連処理によって関連づけられた前記第1の端末装置および第2の端末装置の各ユーザが前記サービスの享受に関して負担する各サービス料金を、前記端末装置が前記エントリー情報を送信した順序、または当該サーバ装置が当該エントリー情報を取得した順序のいずれかに基づいて決定すること、
を特徴とするもの。 - 請求項15のコミュニティ管理システム、またはサーバ装置、またはプログラムのいずれかにおいて、
前記サーバ装置は、
前記第1の端末装置または第2の端末装置の中で、前記エントリー情報を先に送信した端末装置のユーザ、または当該サーバ装置が先に取得した前記エントリー情報に関する端末装置のユーザのサービス料金を、他の端末装置のユーザよりも低く決定すること、
を特徴とするもの。 - コンピュータを用いて、ユーザからのエントリーを受け付けて当該ユーザのコミュニティを管理するコミュニティ管理方法であって、
複数のユーザから個別にエントリーを受け付け、
当該複数のユーザからのエントリー同士の適合部分の有無を判断し、
前記適合部分を有すると判断した場合には、当該適合部分を有するエントリーを受け付けたユーザ同士を関連づけること、
を特徴とするコミュニティ管理方法。 - コンピュータを用いて、ユーザからの車両予約情報を受け付けて当該ユーザによる車両乗合い予約情報を決定する車両乗合い予約管理方法であって、
前記車両予約情報は、
前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかを含んでおり、
複数のユーザから個別に前記車両利用情報を受け付け、
当該車両予約情報に含まれる、前記車両の出発地、または出発時間、または前記車両の到着地、または到着時間のいずれかの共通部分の有無を判断し、
前記共通部分を有すると判断した場合には、当該共通部分を有する車両予約情報を受け付けたユーザに対して乗合い車両予約情報を送信すること、
を特徴とする車両乗合い予約管理方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003017517A JP2004227490A (ja) | 2003-01-27 | 2003-01-27 | コミュニティ管理システムおよびその方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003017517A JP2004227490A (ja) | 2003-01-27 | 2003-01-27 | コミュニティ管理システムおよびその方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004227490A true JP2004227490A (ja) | 2004-08-12 |
Family
ID=32904652
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2003017517A Pending JP2004227490A (ja) | 2003-01-27 | 2003-01-27 | コミュニティ管理システムおよびその方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004227490A (ja) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006072771A (ja) * | 2004-09-02 | 2006-03-16 | Brother Ind Ltd | 情報検索システム、情報入出力装置およびプログラム |
JP2007107938A (ja) * | 2005-10-12 | 2007-04-26 | Hitachi Ltd | ナビゲーション装置およびシステム |
JP2015092327A (ja) * | 2013-09-30 | 2015-05-14 | 株式会社日本総合研究所 | 外出スケジュール自動作成装置及びその方法 |
JP2016157185A (ja) * | 2015-02-23 | 2016-09-01 | Line株式会社 | 乗り合い支援装置及び乗り合いを支援するプログラム |
JP2016192049A (ja) * | 2015-03-31 | 2016-11-10 | 株式会社日本総合研究所 | 地域交通コミュニティ形成サーバ、地域交通コミュニティ形成システム及びその方法 |
WO2019004467A1 (ja) * | 2017-06-29 | 2019-01-03 | 本田技研工業株式会社 | 車両制御装置、車両制御方法及びプログラム |
JP2019212019A (ja) * | 2018-06-05 | 2019-12-12 | 日産自動車株式会社 | 移送モビリティサービスの提案方法及び移送モビリティサービスの提案装置 |
WO2020002958A1 (ja) * | 2018-06-26 | 2020-01-02 | 日産自動車株式会社 | 降車地点決定方法及び降車地点決定装置 |
JP2020004177A (ja) * | 2018-06-29 | 2020-01-09 | トヨタ自動車株式会社 | 情報処理装置及び情報処理方法、プログラム |
JP2020052925A (ja) * | 2018-09-28 | 2020-04-02 | マツダ株式会社 | 自動車運行管理システム |
JP2020123393A (ja) * | 2020-04-30 | 2020-08-13 | Line株式会社 | 情報処理方法 |
JPWO2021186630A1 (ja) * | 2020-03-18 | 2021-09-23 |
-
2003
- 2003-01-27 JP JP2003017517A patent/JP2004227490A/ja active Pending
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006072771A (ja) * | 2004-09-02 | 2006-03-16 | Brother Ind Ltd | 情報検索システム、情報入出力装置およびプログラム |
US7533083B2 (en) | 2004-09-02 | 2009-05-12 | Brother Kogyo Kabushiki Kaisha | Device, system and computer program product for retrieving information |
JP2007107938A (ja) * | 2005-10-12 | 2007-04-26 | Hitachi Ltd | ナビゲーション装置およびシステム |
JP2015092327A (ja) * | 2013-09-30 | 2015-05-14 | 株式会社日本総合研究所 | 外出スケジュール自動作成装置及びその方法 |
JP2016157185A (ja) * | 2015-02-23 | 2016-09-01 | Line株式会社 | 乗り合い支援装置及び乗り合いを支援するプログラム |
JP2016192049A (ja) * | 2015-03-31 | 2016-11-10 | 株式会社日本総合研究所 | 地域交通コミュニティ形成サーバ、地域交通コミュニティ形成システム及びその方法 |
WO2019004467A1 (ja) * | 2017-06-29 | 2019-01-03 | 本田技研工業株式会社 | 車両制御装置、車両制御方法及びプログラム |
JP2019212019A (ja) * | 2018-06-05 | 2019-12-12 | 日産自動車株式会社 | 移送モビリティサービスの提案方法及び移送モビリティサービスの提案装置 |
JP7223513B2 (ja) | 2018-06-05 | 2023-02-16 | 日産自動車株式会社 | 移送モビリティサービスの提案方法及び移送モビリティサービスの提案装置 |
WO2020002958A1 (ja) * | 2018-06-26 | 2020-01-02 | 日産自動車株式会社 | 降車地点決定方法及び降車地点決定装置 |
CN112313723B (zh) * | 2018-06-26 | 2023-02-28 | 日产自动车株式会社 | 下车地点决定方法和下车地点决定装置 |
CN112313723A (zh) * | 2018-06-26 | 2021-02-02 | 日产自动车株式会社 | 下车地点决定方法和下车地点决定装置 |
JPWO2020002958A1 (ja) * | 2018-06-26 | 2021-08-05 | 日産自動車株式会社 | 降車地点決定方法及び降車地点決定装置 |
JP2020004177A (ja) * | 2018-06-29 | 2020-01-09 | トヨタ自動車株式会社 | 情報処理装置及び情報処理方法、プログラム |
JP7067320B2 (ja) | 2018-06-29 | 2022-05-16 | トヨタ自動車株式会社 | 情報処理装置及び情報処理方法、プログラム |
JP2020052925A (ja) * | 2018-09-28 | 2020-04-02 | マツダ株式会社 | 自動車運行管理システム |
JP7093516B2 (ja) | 2018-09-28 | 2022-06-30 | マツダ株式会社 | 自動車運行管理システム |
JPWO2021186630A1 (ja) * | 2020-03-18 | 2021-09-23 | ||
JP7353462B2 (ja) | 2020-03-18 | 2023-09-29 | 三菱電機株式会社 | 通信制御装置および通信制御方法 |
JP7005682B2 (ja) | 2020-04-30 | 2022-01-21 | Line株式会社 | サーバ、プログラム、情報処理方法 |
JP2020123393A (ja) * | 2020-04-30 | 2020-08-13 | Line株式会社 | 情報処理方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4458453B2 (ja) | 相乗り仲介管理装置及びそのプログラム | |
US6732080B1 (en) | System and method of providing personal calendar services | |
US9159238B2 (en) | Location-aware selection of public transportation | |
JP3679788B2 (ja) | 移動状況情報提供方法及びサーバ | |
CN105761175A (zh) | 旅游路线订制方法和服务器 | |
EP1271368A1 (en) | Communication apparatus and communication system and method for calculating advertisement rates | |
JP2003203084A (ja) | 情報端末装置、サーバ、情報配信装置及び情報配信方法 | |
US20040181439A1 (en) | Reservation acceptance system and computer program product | |
JP2002539565A (ja) | 航空旅程予約のためのコンピュータ実行装置及び方法 | |
JP2003131604A (ja) | 広告表示方法、及び広告データ配信サーバ | |
JP2004094895A (ja) | 情報提供方法、情報提供装置および広告配信方法 | |
JP6280277B1 (ja) | 有償運送車両配車システムおよびプログラム | |
US20200132481A1 (en) | Information providing device, information providing system, information providing method, and recording medium | |
JP2004227490A (ja) | コミュニティ管理システムおよびその方法 | |
JP2019169110A (ja) | 情報配信装置 | |
JP2002024659A (ja) | 配車予約システム | |
JP2002296070A (ja) | 携帯通信装置、経路案内情報配信方法、経路案内情報配信システム及びプログラム | |
JP6973278B2 (ja) | サーバシステム、制御方法、及びプログラム | |
JP7031546B2 (ja) | 情報処理装置および情報処理方法 | |
JP6342595B1 (ja) | 有償運送車両配車システムおよびプログラム | |
JP2020071109A (ja) | データ生成装置、データ生成システム、データ生成方法、データ生成プログラム | |
JP2002063690A (ja) | 配車サービス方法 | |
JP2002163335A (ja) | タクシー業務運営システム | |
CA2335446A1 (en) | Door to doorstep directions | |
JP4969740B2 (ja) | 整備予約方法、整備予約プログラム及び整備予約システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20050331 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051219 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20060417 |