JP2005301629A - タクシー検索システム、車載装置とそのプログラム、サーバ装置とそのプログラム、課金サーバ装置とそのプログラム、およびビジネス方法 - Google Patents

Abstract

【課題】サーバ装置の負荷を軽減しつつタクシー事業者およびユーザの双方にとっての便宜を向上し得るタクシー検索システムを提供すること。
【解決手段】タクシー乗客側とタクシー側とで同じブロック情報を用い、ユーザおよびタクシーの位置をブロックを単位として管理する。タクシー乗客側は乗車希望ブロックと目的地ブロックとをシステムに指定し、タクシー側は現在位置ブロックと状態とをシステムに登録する。これによりサーバ装置２と車載装置１との間で一度に大量のメッセージが授受されることを防止する。また、タクシーの所在するブロック情報に加えてタクシーの状態（空車、回送、賃送、迎車）をも管理することにより、空車のタクシーだけでなく、回送状態のタクシーをも検索対象とする。
【選択図】 図８

Description

本発明は、タクシーを要求地点に適切に配車するために用いられるタクシー検索システムと、このタクシー検索システムに用いられる車載装置とそのプログラム、サーバ装置とそのプログラム、課金サーバ装置とそのプログラム、およびビジネス方法に関わる。

タクシーなどの車両を要求地点に適切に配車するために配車システムが用いられる。この分野においては多くの技術が公開されており、例えば特許文献１または２に記載の技術が知られている。
特許文献１には、複数のタクシーが自己の位置情報をそれぞれサーバに定期的に通知することにより全てのタクシーの位置を管理し、これによりタクシーを経済的かつ効率的に配車できるようにする配車システムが開示される。しかしながら最も近くに位置するタクシーをユーザのもとへ配車するには、タクシーだけでなくユーザの位置情報をもサーバに通知する必要がある。よって移動端末からタクシーをコールするにはユーザ端末がＧＰＳ（Global Positioning System）機能を備えることが前提となるため、コストが嵩むなどの不具合が有る。

特許文献２に記載の技術では、ユーザからタクシーの検索要求が与えられたことをトリガとして、位置情報の通知を要求する信号がサーバから全てのタクシーに配信される。これに応じた各タクシーからの通知結果をもとにサーバが最適なタクシーを検索するようにした配車方法が、この文献には開示される。この文献においても、移動端末からのコールには端末が測位機能を備える必要が有る。また固定端末からのコール時にはその位置を詳細に、例えばＡ県Ｂ市Ｃ丁目Ｄ番地というように通知する必要が有る。よってユーザが出先の公衆電話からタクシーをコールする場合などには、ユーザへの負担が大きく不便であると言わざるを得ない。

また、特許文献１および２のいずれに開示される方法においても、サーバと全てのタクシーとの間で、情報通信がほぼ同時に実行される。タクシーは日本全国に数十万台もあるので一度に数十万件にも及ぶ位置情報がサーバに送信される可能性があり、サーバの負荷は非常に重くなる。

なお非特許文献１に、当該技術分野に係わるプロトコルであるＳＩＭＰＬＥプロトコルに関する詳細が開示される。ＳＩＭＰＬＥプロトコルを移動通信網上に転送する技術は、ＩＥＴＦ（Internet Engineering Task Force; http://www.ietf.org/）や３ＧＰＰ（The 3rd Generation Partnership Project; http://www.3gpp.org/）などの標準化団体において継続的に検討されている。

ほとんどの既存の技術においては、ユーザ端末とタクシーとの詳細な位置情報をそれぞれ収集し、両者間の距離を正確に算出するようにしている。しかしながら走行中のタクシーの位置は時々刻々と変化するので、ユーザの最も近くに所在するタクシーも次々に変化するのが普通である。また、到着時間の数十秒程度の遅れを気にするユーザはほぼ皆無に近いと言える。よって正確な距離の算出にとらわれず、既存の技術と異なる方式によれば、より便利な配車システムを提供できる可能性が有る。
特開２００２−３６７０８５号公報 特開２００３−２２４９６号公報 " SIP for Instant Messaging and Presence Leveraging "、[online]、インターネット、＜URL ： http://www.ietf.org/html.charters/simple-charter.html＞

以上述べたように既存の配車システムは、ユーザ端末とタクシーとの詳細な位置情報に基づき両者間の正確な距離を算出するようにしているため、移動端末にＧＰＳ機能を搭載する必要が有ったり、サーバ装置の負荷が大きいという不具合を持つ。またユーザにとって必ずしも便利とは言えない面がある。

このほかタクシー事業者にはそれぞれ営業区域が定められており、各タクシーはそれぞれ属する事業者の営業区域内において営業することになっている。ただしユーザの目的地が営業区域内であれば、タクシーは営業区域外を走行中でもそのユーザをピックアップして良いことになっている。しかしながらこのような状態にあるタクシーをも検索対象とするシステムは知られていない。タクシーは区域外から営業区域内に戻るときは「回送」表示にするので、ユーザにとっては、見かけたタクシーの営業区域が自分の行先であるかどうか判断できず、タクシーの運転者にとっても、見かけたユーザの目的地が営業区域内であるかどうか判断できないからである。このため空の状態で営業区域に戻るタクシーは数多く、折角のビジネスチャンスを失うことが多分に有る。

さらに現状では、タクシーの配車業務は個々の事業者ごとに閉じられた格好となっている。すなわち、ユーザから電話を受けた事業者のオペレータが独自の無線網を使用して、事業者内における最適なタクシーを見つけるようになっている。これに代えて、異なるタクシー事業者間に共通のタクシー検索システムを設けることができれば、このシステムの運営会社がタクシー事業者に代わって最適なタクシーを検索して仲介料を取るといったビジネスモデルを展開できる可能性が有る。

本発明は上記事情によりなされたもので、その目的は、サーバ装置の負荷を軽減しつつタクシー事業者およびユーザの双方にとっての便宜を向上し得るタクシー検索システム、車載装置とそのプログラム、サーバ装置とそのプログラム、課金サーバ装置とそのプログラム、およびビジネス方法を提供することにある。

上記目的を達成するために本発明の一態様によれば、それぞれ営業区域を定められた複数のタクシーにそれぞれ搭載される車載装置と、この車載装置と通信可能なサーバ装置とを具備し、このサーバ装置にアクセス可能なクライアント装置を用いて前記タクシーをコールするタクシー検索システムであって、前記タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義するようにする。

このようにしたので、タクシーの現在位置、ユーザの現在位置などをブロック単位で管理することが可能になる。これによりユーザ端末の詳細な位置を把握する必要が無くなり、ＧＰＳなどの機能をユーザ端末に搭載しなくとも良くなる。

また本発明の一態様によれば、前記車載装置は、自装置を搭載するタクシーの現在位置を測位してこのタクシーの所在する現在位置ブロックを特定するブロック特定手段と、自装置を搭載するタクシーの状態を少なくとも空車、賃送、回送、および、迎車のいずれかの状態に特定する状態特定手段と、前記ブロック特定手段により特定される現在位置ブロックが変化した場合に変化後の現在位置ブロックを前記サーバ装置に通知し、前記状態特定手段により特定される状態が変化した場合に変化後の状態を前記サーバ装置に通知する通知手段とを備え、前記サーバ装置は、前記複数の車載装置の各々から通知される情報に基づいて更新されるデータベースであって、現在位置ブロックと、少なくとも空車、賃送、回送、および、迎車のいずれかの状態と、車両識別子と、料金体系と、前記営業区域を形成するブロック群の識別子と、運転者の連絡先とを含むプレゼンス情報を前記タクシーごとに対応付けたプレゼンス情報データベースと、ユーザにより乗車希望地に対応して指定される乗車希望ブロックと前記ユーザにより目的地に対応して指定される目的地ブロックとを含む検索要求を受理する受理手段と、前記検索要求が受理された場合に、空車状態にあるタクシーと、回送状態にあるタクシーであって前記目的地ブロックを営業区域に含むタクシーとからなるタクシー群のうち、現在位置ブロックが前記乗車希望ブロックに一致するタクシーを前記プレゼンス情報データベースから検索する検索手段と、この検索手段により検索されたタクシーの車両識別子と、料金体系と、連絡先とを少なくとも含む返送メッセージを生成するメッセージ生成手段と、前記返送メッセージを前記クライアント装置に返送する返送手段とを備えることを特徴とするタクシー検索システムが提供される。

このような手段を講じることにより、それぞれのタクシーはＧＰＳなどの測位手段を用いて自己の現在位置情報（緯度、経度など）を取得し、自車両が現時点で位置するブロック（現在位置ブロック）を逐次特定する。また自車両が少なくとも空車、賃送、回送、および、迎車のいずれの状態にあるかを逐次特定する。そして、現在位置ブロック、または自車両の状態が変化した場合にのみ、その旨がサーバ装置に通知される。従って、複数のタクシーからのサーバ装置への通知処理は時間的に分散されるようになり、サーバ装置に負荷が一度に集中することを防止できるようになる。

また上記構成によれば、空車状態だけでなく、回送状態にあるタクシーをも含めた検索処理が実施される。これによりユーザにとっては選択の幅が広がるため、より便利になる。またタクシー事業者にとってもより多くのビジネスチャンスを確保できるようになるので、ユーザおよび事業者の双方にとってのメリットは大きい。

本発明によれば、サーバ装置の負荷を軽減しつつタクシー事業者およびユーザの双方にとっての便宜を向上し得るタクシー検索システム、車載装置とそのプログラム、サーバ装置とそのプログラム、課金サーバ装置とそのプログラム、およびビジネス方法を提供することができる。

図１は、本発明に係わるタクシー検索システムの実施の形態を示すシステム図である。図１のシステムは、複数のタクシーにそれぞれ搭載される車載装置１と、ＩＰ（Internet Protocol）網ＩＰＮ内に設けられるサーバ装置２と、ユーザ端末５〜７とを備える。このうちユーザ端末５および車載装置１は基地局ＣＳを介して移動電話網ＭＮに接続され、ユーザ端末６は固定電話網ＴＸＮとＩＰ網ＩＰＮとに接続され、ユーザ端末７はＩＰ網ＩＰＮに接続される。

ユーザ端末６は音声通話機能に加えてＩＰパケットを処理する機能を備え、Ｗｅｂページにアクセスする機能を有する固定端末である。ユーザ端末７はＩＰ網ＩＰＮとのデータ通信機能に加え、ＩＰ網ＩＰＮを経由する音声通話機能を備える。この種の機能はＶｏＩＰ（Voice over IP：ヴォイプ）と称される。ユーザ端末５は、携帯電話機や携帯情報端末（ＰＤＡ：Personal Digital Assistants）などにＩＰ網ＩＰＮへの接続制御機能を実装して実現され、ユーザ端末６，７と同様にＷｅｂブラウザとしての機能を併せ持つ。車載装置１はＧＰＳによる測位機能を備え、ＧＰＳ衛星８からの測位電波を受信処理することにより、自装置を搭載するタクシー１００の位置をリアルタイムに計測する。

ＩＰ網ＩＰＮと移動電話網ＭＮとはゲートウェイ装置３を介して接続され、固定電話網ＴＸＮと移動電話網ＭＮとはゲートウェイ装置４を介して接続される。ゲートウェイ装置３，４は例えばレイヤ２以下でのプロトコル変換を行う。これにより、車載装置１およびユーザ端末５〜７のいずれからもサーバ装置２へのアクセスが可能である。このほか図１のシステムは、ＩＰ網ＩＰＮに接続される課金サーバ９と、タクシー１００の運転手に所持される携帯電話機ＭＴとを備える。

図２は、本実施形態において新たに採り入れる概念である［ブロック］につき説明するための概念図である。すなわち本実施形態では、タクシーの営業区域を少なくとも１つ含む地理的領域（地域）を、複数のブロックに分割する。例えば対象とする地域が市町村の単位であれば、ブロックは、さらに細かい単位の小エリアに区分される。図２にはブロック１〜ブロック９なる９つのブロックが示される。このように分割されたブロック情報はユーザと全てのタクシーとで共通に用いられる。要するに本実施形態においては、ユーザ、タクシー、タクシー事業者で共通のブロック情報を利用するようにする。本実施形態では、タクシー配車に係わる位置情報を、ブロックを単位として管理するようにする。また各ブロックがそれぞれ唯一の営業区域に属するようにする。つまり１つのブロックが複数の営業区域に跨らないようにする。

図３は、図１の車載装置１の実施の形態を示す機能ブロック図である。この車載装置１は、サービス制御部４０、内部バスＩＢ、各種プログラムを記憶するＲＯＭ１２、ＲＡＭ１３、ＧＰＳ装置１９、通信処理部２５、および、車両情報入力インタフェース２４を備える。

サービス制御部４０は内部バスＩＢを介して各部と接続され、車載装置１全体の制御を司る。すなわちサービス制御部４０は、ＲＯＭ１２に記憶されるプログラムを実行するにより基地局ＣＳとの通信やタクシー配車に係わる種々の機能を実現する。ＲＯＭ１２は、サービス制御部４０を動作させるためのプログラムおよび各種設定データを格納するための読み込み専用のメモリである。ＲＡＭ１３は、サービス制御部４０による読み書き可能のメモリ装置であり、各種データを一時的に記憶させる作業領域として使用され、例えば通信処理部２５を介して受信したデータなどを一時的に記憶する。

ＧＰＳ装置１９はＧＰＳ衛星８から受信したＧＰＳ電波に基づいて車両の現在位置を逐次計測する。車両情報入力インタフェース２４は、タクシー１００の各種の状態を検知してシステムに入力する。タクシー１００の状態には、「空車」、「賃送」、「回送」、および、「迎車」などが有る。また車両情報入力インタフェース２４は、例えばタッチパネルなどを用いた運転手の操作をシステムに通知するための処理を行う。通信処理部２５はアンテナ２０ａを介して基地局ＣＳに無線接続され、通信データのパケット変換処理などを実施してサーバ装置２、およびユーザ端末５〜７との情報通信を仲介する。

ところでサービス制御部４０は、本実施形態に係わる処理機能としてブロック特定処理部４０ａと、状態特定処理部４０ｂと、通知処理部４０ｃと、契約情報処理部４０ｄとを備える。ブロック特定処理部４０ａは、ＧＰＳ装置１９により取得されたタクシー１００の位置情報（緯度および経度）に基づいて、タクシー１００の所在する現在位置ブロックを特定する。状態特定処理部４０ｂは、車両情報入力インタフェース２４から取得した情報に基づいて、タクシー１００の状態を「空車」、「賃送」、「回送」、および、「迎車」のいずれかの状態に特定する。

通知処理部４０ｃは、タクシー１００の移動に伴いタクシー１００の所在するブロックが変化した時点で、その旨をサーバ装置２に通知する。これによりサーバ装置２は、現時点でタクシー１００が所在するブロックを逐次把握することができる。また通知処理部４０ｃは、状態特定処理部４０ｂにより特定されるタクシー１００の状態が変化した時点で、その旨をサーバ装置２に通知する。これによりサーバ装置２は、現時点におけるタクシー１００の状態を逐次把握することができる。なお通知処理部４０ｃは、車載装置１の起動時点においても、タクシー１００の所在ブロック情報と状態とをサーバ装置２に通知する。契約情報処理部４０ｄは、ユーザとのタクシー搭乗契約に係わる種々の処理を実行する。例えば契約情報処理部４０ｄは、サーバ装置２から送られた契約キー情報を運転手に通知したり、車両情報入力インタフェース２４を介して入力された、運転手の搭乗の可否の意志をシステムに通知したりなどの処理を行う。なおブロック特定処理部４０ａと、状態特定処理部４０ｂと、通知処理部４０ｃと、契約情報処理部４０ｄとは、例えばＲＯＭ１２に記憶されるプログラムによりソフトウェア的に実現される処理機能である。

図４は、図１のサーバ装置２の実施の形態を示す機能ブロック図である。特にこのサーバ装置２は、Ｗｅｂサーバとしての機能を備える。図５においてサーバ装置２は、Ｗｅｂサーバ処理部９３と、記憶部９５と、制御部９６と、プレゼンス情報収集部９７とを備える。

Ｗｅｂサーバ処理部９３はＩＰ網ＩＰＮに接続され、車載装置１、ユーザ端末５〜７との間でＩＰデータを授受し、サーバ装置２にＷｅｂサーバとしての機能を持たせる。このほかＷｅｂサーバ処理部９３は、タクシーの検索を要求する検索要求がユーザ端末５〜７から到達した場合にこれを受理し、この検索要求に含まれる乗車希望ブロックと目的地ブロックとを制御部９６に通知する。なお乗車希望ブロックとはユーザの希望する乗車位置を含むブロックであり、目的地ブロックとはユーザの希望する降車位置を含むブロックである。プレゼンス情報収集部９７は、タクシー１００から通知されるプレゼンス情報を収集する。記憶部９５は、各種の制御プログラムや設定データなどに加え、本実施形態に係わる新規要素としてプレゼンス情報データベース９５ａと、課金ログデータベース９５ｂとを記憶する。

ところで制御部９６は、本実施形態に係わる制御機能として検索処理部９６ａと、ＣＧＩ処理部９６ｂと、契約特定処理部９５ｃと、データ加工処理部９６ｄとを備える。検索処理部９６ａは、ユーザ端末からの検索要求が受理された場合に、ユーザの希望する条件を満たすタクシーを検索する。具体的には検索処理部９６ａは、空車状態にあるタクシーと、回送状態にあるタクシーであって目的地ブロックを営業区域に含むタクシーとをプレゼンス情報データベース９５ａから取得する。そしてこれらのタクシー群から、現在位置ブロックが乗車希望ブロックに一致するタクシーを、プレゼンス情報データベース９５ａから取得する。

特に検索処理部９６ａは、現在位置ブロックが乗車希望ブロックに一致するタクシーがプレゼンス情報データベース９５ａに無い場合には、乗車希望ブロックに近いブロックから順次タクシーを検索する。その際、既定台数（例えば１０台）に達するまで、検索処理を継続するようにしても良い。

ＣＧＩ処理部９６ｂは、検索処理部９６ａにより検索されたタクシーの車両ナンバーと、料金体系と、運転手の連絡先と、運転手の氏名と、タクシー事業者名とをリストアップした返送メッセージを生成する。この返送メッセージは、例えばサーバ装置２に記憶されるＣＧＩ（Common Gateway Interface）プログラムにより、ＨＴＭＬ（HyperText Markup Language）データなどの形式で生成される。この返送メッセージは、Ｗｅｂサーバ処理部９３により検索要求元のユーザ端末に返送される。

契約特定処理部９５ｃは、ユーザに返送された返送メッセージに含まれるタクシーのうちこのユーザとの搭乗契約が成立したタクシーを特定する。なお契約特定処理部９５ｃは、タクシーの運転手に、迎車を受け入れるか否かを選択する機会を与えるための処理も行う。この処理手順については後述する。契約特定処理部９５ｃにより契約の成立したことを特定されたタクシーは、課金ログデータベース９５ｂにその履歴を蓄積される。すなわち課金ログデータベース９５ｂは、契約特定処理部９５ｃにより特定された履歴をタクシーごとに対応付けたデータベースである。データ加工処理部９６ｄは、プレゼンスデータ収集部９７により取得されたデータを用いてプレゼンス情報データベース９５ａのプレゼンス情報（現在位置ブロック，状態）を更新する。

図１の課金サーバ９は、課金ログデータベース９５ｂの内容をＩＰ網ＩＰＮを介して定期的に取得し、その内容から、一定期間における搭乗契約の成立回数に基づいてタクシーまたはタクシー事業者ごとに課金する。なお検索処理部９６ａと、ＣＧＩ処理部９６ｂと、契約特定処理部９６ｃと、データ加工処理部９６ｄとは、予め用意されるプログラムに基づいてソフトウェア的に実現される処理機能である。また図４に示すサーバ装置２は、ＩＰ網ＩＰＮを介して課金サーバ９と種々のデータを授受し合うインタフェース部を備えるがここでは図示しない。

図５は、図４のプレゼンス情報データベース９５ａの実施の形態を示す模式図である。プレゼンス情報データベース９５ａは、複数のタクシーのそれぞれごとにプレゼンス情報を対応付けたデータベースである。プレゼンス情報とは現在位置ブロックおよび状態を、タクシーごとに管理するための情報である。

図５のプレゼンス情報には、例えば現在位置ブロック、状態（空車、賃送、回送、または、迎車）、事業者名、事業者の営業区域に含まれるブロック識別子（営業ブロック）、事業者の料金体系、運転手氏名、運転手の連絡先、および、車両ナンバーが含まれる。このプレゼンス情報データベース９５ａは、車載装置１からそれぞれ通知される情報に基づいて更新される。このうち現在位置ブロックと、状態とは比較的頻繁に更新され得る。次に、上記構成における動作を説明する。

図６は、図１のシステムの車載装置１、サーバ装置２、および、ユーザ端末５の処理手順を示すシーケンス図である。図６において、車載装置１はタクシー１００のプレゼンス情報を常時モニタし、その変化を検出する（ステップＳ１）。例えば、図２の点１から点２に示すように現在位置ブロックが変化するとプレゼンス情報の変化が検出され、その旨がサーバ装置２に通知される（ステップＳ２）。

サーバ装置２はこれを受けてプレゼンス情報データベース９５ａの内容を更新し（ステップＳ３）、これによりタクシー１００の現在位置ブロックおよび現在状態がサーバ装置２に登録される。なおタクシー１００がサーバ装置２にプレゼンス情報を通知するには、ＳＩＭＰＬＥプロトコルを携帯電話網上に転送する技術を用いると良い。

タクシーを検索したいユーザは、ユーザ端末５を用いてサーバ装置２の検索用ページにＨＴＴＰ（HyperText Transport Protocol）でアクセスする。この検索用ページには例えば図２に示すブロックが模式的に表示され、ユーザは乗車希望位置を含むブロックと、目的地を含むブロックとを選択する。

ユーザ端末５を介して乗車希望ブロックと目的地ブロックとが選択されると（ステップＳ４）、サーバ装置２はユーザの要求に沿うタクシーを検索する（ステップＳ５）。その結果例えば１０台のタクシーが見つかると、それらのタクシーをリストアップしたタクシー選択画面がユーザ端末５に表示される（ステップＳ５）。

図７は、図６のステップＳ６の完了時にユーザ端末５に表示されるタクシー選択画面の一例を示す図である。タクシー選択画面には、リストアップされたタクシーの車両ナンバーと、事業者の料金体系と、運転者の連絡先（携帯電話機ＭＴの電話番号など）とが少なくとも表示される。さらに、運転者の氏名と事業者名称とを併せて表示すると、ユーザと運転者とが電話で連絡を取り合うのに都合が良い。

さて、タクシー選択画面に表示されるタクシーから一つのタクシーを決定すると（ステップＳ７）、ユーザはそのタクシーをタクシー選択画面上で選択指定する。そうすると、選択されたタクシーの識別子（車両ナンバーなど）がサーバ装置２に通知される（ステップＳ８）。これを受けてサーバ装置２は、契約キー情報としての受け付け番号を含む予約依頼メッセージを、選択されたタクシーの車載装置１に転送する（ステップＳ９）。

このメッセージを受け取ったタクシーの運転手は、予約を受け付けるか否かを判断する（ステップＳ１０）。予約を拒否するのであれば運転手は車載装置１を操作し、ＮＧメッセージをサーバ装置２を介してユーザ端末５に返送する（ステップＳ１１，Ｓ１２）。この場合、処理手順は再びステップＳ７に戻り、ユーザ端末５のタクシー選択画面が更新されて別のタクシーの選択が促される。

予約を承認するのであれば運転手は車載装置１を操作し、ＯＫメッセージをサーバ装置２に返送する（ステップＳ１３）。これを受けてサーバ装置２は、ＯＫメッセージとともに受け付け番号をユーザ端末５に通知する（ステップＳ１４）。これとともにサーバ装置２は内蔵のタイマをスタートさせ、ＯＫメッセージの送出から経過した時間の計測を開始する（ステップＳ１５）。

ここまでの手順が完了すると、ユーザは、選択したタクシーの運転手の携帯電話機ＭＴに電話をかける。そして、ユーザと運転手との間で受け付け番号を照合したのち、口頭で待ち合わせ場所を連絡する。ここで両者の意志が確定したことをもって、ユーザと運転手との間で搭乗契約が成立したものとみなすことができる。なお待ち合わせ場所については、ブロック番号よりもより詳細な住所を伝えるようにする。

搭乗契約が成立すると、タクシーの運転手は運転するタクシー１００の状態を「迎車」に切り替えたのち、待ち合わせ場所に向かう。そうするとその旨がサーバ装置２に通知され（ステップＳ１７）、プレゼンス情報データベース９５ａが更新される。次にサーバ装置２は、受け付け番号をユーザ端末５に発行してから一定時間内にタクシー１００の状態が「迎車」に変化したことをトリガとして、関係するタクシー１００を課金ログデータベース９５ｂに登録する（ステップＳ１８）。なお以上の処理手順は、ユーザ端末６または７を用いた場合にも同様にして実施される。

課金ログデータベース９５ｂは、搭乗契約の成立の履歴を各タクシーごとに管理するためのデータベースであり、タクシーの識別番号、業者名、契約成立の日時などが登録される。課金サーバ９（図１）は課金ログデータベース９５ｂの内容を定期的に、例えば１か月おきに収集し、タクシーごと、またはタクシー業者ごとに搭乗契約成立の度数を集計する。そして、１度数あたりの単価を乗算することにより、検索サービス実行にかかる請求料金を算出する。すなわち、タクシー業者とは独立した事業体としての検索代行システム運営会社を設け、この検索代行システム運営会社がタクシー検索にかかる費用をタクシー事業者に課金するというビジネスモデルを展開することが可能になる。

なお、受け付け番号が発行されていないタクシーから「迎車」への状態変更通知を受信しても、サーバ装置はこのタクシーを課金ログデータベース９５ｂに登録しないようにする。また、受け付け番号を通知された後にユーザの気が変わり、予約を解除したい場合にはユーザ端末画面上に表示される予約解除ボタンをクリック（ステップ１９のＹｅｓ）するようにする。そうするとサーバ装置２はその旨を認識し、一旦選択されたタクシーに予約解除メッセージを送付する。これによりサーバ装置２、タクシー１００ともに予約前の状態に戻る。さらに、タイマーの計時時間が過度に長くなった場合にも同様に、予約を解除できるようにすると良い。このように、受け付け番号に有効時間を設けることにより、タクシーの運転手がユーザからの連絡を長時間に渡って待ち続けることを防止できる。

図８は、図６の検索処理ステップＳ５における処理手順の一例を示すフローチャートである。検索処理が開始されると、まず初期化処理が実行され、ユーザの乗車希望ブロックに近い順に各ブロックに番号ｉを付す。乗車希望ブロックと同じブロックにおいては、ｉ＝０となる（ステップＳ５１）。そしてブロック内におけるタクシーがリストアップされ（ステップ５２）、その状態が、プレゼンス情報データベース９５ａの内容に基づいて確認される（ステップＳ５４）。賃送または迎車状態のタクシーは検索対象から除外される（ステップＳ５５）。

一方、空車のタクシーは検索結果に追加される（ステップＳ５７）。これに加えて本実施形態では、回送状態のタクシーも検索候補に採り挙げるようにする。すなわちステップＳ５４において回送と判定されたタクシーは、その営業区域がユーザの目的地ブロックを含むか否かを検証される（ステップＳ５６）。目的地ブロックと営業区域とが異なっていれば（Ｎｏ）検索対象から除外されるが、目的地ブロックが営業区域に含まれていれば（Ｙｅｓ）、そのタクシーは検索結果に追加される。

次に、ブロック内において検索されたタクシーの台数が既定の台数したか否かが判定され（ステップ５８）、例えば１０台に達していれば検索結果がユーザ端末に表示される（ステップ６０）。既定台数に達していなければ、ｉ＝ｉ＋１として（ステップＳ５９）、ユーザに近いブロックから同様の処理が順次繰り返される。なお、車庫に戻るなどの事情で営業活動を休止するタクシーにおいても、回送状態になることがある。このような場合には、本システムへの状態登録を行わないことで、検索対象から除外することができる。これは、車載装置１の通知処理部４０ｃの機能をオフにすることで可能である。

以上述べたように本実施形態では、タクシー乗客側とタクシー側とで同じ地理情報（ブロック）を用い、タクシー乗客側は乗車希望ブロックと目的地ブロックとをシステムに指定し、タクシー側は現在位置ブロックと状態とをシステムに登録するようにする。これによりユーザは、現在位置および目的地の詳細な位置（番地または座標データなど）サーバ装置２に通知しなくとも、任意のブロックを指定するだけで検索要求を発出することができる。つまり、既存の技術に比べて粗い情報を用いて、より簡単にタクシーを検索することが可能になる。

また、サーバ装置２にブロック指定用のＷｅｂ画面を用意することもできるので、Ｗｅｂクライアント機能と電話機能（またはＶｏＩＰ機能）とを備えていれば、無線端末、固定端末のいずれもユーザ端末として使用できる。また本実施形態においては、ユーザにとっては最終的にタクシーの電話番号が分かれば良い。これにより、比較的簡易な装置をユーザ端末５〜７として用いることができる。さらに、サーバ装置２が用意したブロック選択肢の中から任意のブロックを選択すればよいので、ユーザは現地の住所を詳細に把握する必要が無い。よって固定端末で外出先から利用する場合においても、ユーザの利便性は大幅に向上する。

また本実施形態ではタクシーの状態（空車、回送、賃送、迎車）をも管理するようにしているので、営業区域外を走行中のタクシーであっても、ユーザの目的地が営業区域内であれば検索対象候補となる。これにより、回送状態であるタクシーにおいてもユーザをピックアップできる可能性が生まれる。従ってタクシー事業者にとっては営業効率が向上する。また、ユーザにとっては検索候補のタクシーが多くなるので選択の幅が広がる。これにより事業者、ユーザの双方ともにメリットを得ることができる。

また本実施形態では、タクシー１００の状態、および、所在ブロックが変化した場合にのみ、その旨をサーバ装置２に通知するようにしている。従ってタクシー１００とサーバ装置２との間でのメッセージの授受が時間的に分散される。すなわち既存のシステムでは、全てのタクシー（長期停車中のタクシーも含む）の位置情報が一斉にサーバ装置２に通知されるため、その時点におけるサーバ装置２の負担は非常に大きい。これに対し本実施形態では、タクシー１００からサーバ装置２に転送されるデータ量が必要最小限に留められ、しかも一度に集中することを予防できるため、サーバ装置２の処理負担を格段に軽減することができる。これにより処理能力の比較的低いコンピュータを用いてもシステムを構築することができ、コスト的なメリットも大きい。

さらに本実施形態では、検索の結果ユーザとの搭乗契約が成立した履歴をタクシーごとに蓄積できる機能を設けているので、タクシー事業者から仲介料を請求するというビジネスモデルを実現することが可能になる。これらのことから、サーバ装置の負荷を軽減しつつタクシー事業者およびユーザの双方にとっての便宜を向上させることが可能となる。

なお、本発明は上記実施の形態に限定されるものではない。例えば本実施形態では１０台のタクシーが見つかるまで検索処理を継続するようにしたが、最低でも１台のタクシーが見つかった時点で検索を終了するようにすれば、検索時間をより短縮することが可能になる。またプレゼンス情報データベース９５ａに、タクシー１００の色や車体の特徴（セダン、ワゴンなど）などを登録し、これらをユーザ端末に表示するようにしても良い。このようにすれば待ち合わせの際に便利である。このほか、本発明の要旨を逸脱しない範囲で種々の変形実施が可能である。

本発明に係わるタクシー検索システムの実施の形態を示すシステム図。 本発明において新たに採り入れる概念である［ブロック］につき説明するための概念図。 図１の車載装置１の実施の形態を示す機能ブロック図。 図１のサーバ装置２の実施の形態を示す機能ブロック図。 図４のプレゼンス情報データベース９５ａの実施の形態を示す模式図。 図１のシステムの車載装置１、サーバ装置２、および、ユーザ端末５の処理手順を示すシーケンス図。 図６のステップＳ６の完了時にユーザ端末５に表示されるタクシー選択画面の一例を示す図。 図６の検索処理ステップＳ５における処理手順の一例を示すフローチャート。

符号の説明

ＭＴ…携帯電話機、ＩＰＮ…ＩＰ網、ＣＳ…基地局、ＭＮ…移動電話網、ＴＸＮ…固定電話網、ＩＢ…内部バス、１…車載装置、２…サーバ装置、３，４…ゲートウェイ装置、５〜７…ユーザ端末、８…ＧＰＳ衛星、９…課金サーバ、１２…ＲＯＭ、１３…ＲＡＭ、１９…ＧＰＳ装置、２０ａ…アンテナ、２４…車両情報入力インタフェース、２５…通信処理部、４０…サービス制御部、４０ａ…ブロック特定処理部、４０ｂ…状態特定処理部、４０ｃ…通知処理部、４０ｄ…契約情報処理部、９３…Ｗｅｂサーバ処理部、９５…記憶部、９５ａ…プレゼンス情報データベース、９５ｂ…課金ログデータベース、９５ｃ…契約特定処理部、９６…制御部、９６ａ…検索処理部、９６ｂ…ＣＧＩ処理部、９６ｃ…契約特定処理部、９６ｄ…データ加工処理部、９７…プレゼンス情報収集部、１００…タクシー

Claims (17)

1. それぞれ営業区域を定められた複数のタクシーにそれぞれ搭載される車載装置と、この車載装置と通信可能なサーバ装置とを具備し、このサーバ装置にアクセス可能なクライアント装置を用いて前記タクシーをコールするタクシー検索システムであって、
   前記タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義し、
   前記車載装置は、
   自装置を搭載するタクシーの現在位置を測位してこのタクシーの所在する現在位置ブロックを特定するブロック特定手段と、
   自装置を搭載するタクシーの状態を少なくとも空車、賃送、回送、および、迎車のいずれかの状態に特定する状態特定手段と、
   前記ブロック特定手段により特定される現在位置ブロックが変化した場合に変化後の現在位置ブロックを前記サーバ装置に通知し、前記状態特定手段により特定される状態が変化した場合に変化後の状態を前記サーバ装置に通知する通知手段とを備え、
   前記サーバ装置は、
   前記複数の車載装置の各々から通知される情報に基づいて更新されるデータベースであって、現在位置ブロックと、少なくとも空車、賃送、回送、および、迎車のいずれかの状態と、車両識別子と、料金体系と、前記営業区域を形成するブロック群の識別子と、運転者の連絡先とを含むプレゼンス情報を前記タクシーごとに対応付けたプレゼンス情報データベースと、
   ユーザにより乗車希望地に対応して指定される乗車希望ブロックと前記ユーザにより目的地に対応して指定される目的地ブロックとを含む検索要求を受理する受理手段と、
   前記検索要求が受理された場合に、空車状態にあるタクシーと、回送状態にあるタクシーであって前記目的地ブロックを営業区域に含むタクシーとからなるタクシー群のうち、現在位置ブロックが前記乗車希望ブロックに一致するタクシーを前記プレゼンス情報データベースから検索する検索手段と、
   この検索手段により検索されたタクシーの車両識別子と、料金体系と、連絡先とを少なくとも含む返送メッセージを生成するメッセージ生成手段と、
   前記返送メッセージを前記クライアント装置に返送する返送手段とを備えることを特徴とするタクシー検索システム。
2. さらに、前記ユーザに返送された返送メッセージに含まれるタクシーのうち前記ユーザとの搭乗契約が成立したタクシーを特定する契約特定手段と、
   前記契約特定手段により特定された履歴を前記タクシーごとに対応付けた契約履歴データベースとを具備することを特徴とする請求項１に記載のタクシー検索システム。
3. さらに、前記契約履歴データベースに蓄積される内容から一定期間における搭乗契約の成立回数に基づいて、前記複数のタクシー、または前記複数のタクシーごとの事業者に課金する課金手段を具備することを特徴とする請求項２に記載のタクシー検索システム。
4. 前記契約特定手段は、
   前記ユーザにより選択されたタクシーを前記サーバ装置に通知する手順と、
   前記ユーザに契約キー情報を通知する手順と、
   前記タクシーに前記契約キー情報を通知する手順と、
   前記ユーザと前記タクシーとの間での通信により互いに前記契約キー情報を照合する照合手順と、
   この照合手順の結果前記選択されたタクシーの状態が迎車になったことを確認する手順と
   を実行して前記搭乗契約が成立したタクシーを特定することを特徴とする請求項２に記載のタクシー検索システム。
5. 前記契約特定手段は、
   前記契約キー情報を通知されたタクシーの運転手が前記ユーザへの迎車を受け付けるか否かを確認する手順と、
   この運転手により前記ユーザへの迎車が拒否された場合に前記ユーザにその旨を通知し、異なるタクシーの選択を促す手順とを実行することを特徴とする請求項４に記載のタクシー検索システム。
6. 前記検索手段は、現在位置ブロックが前記乗車希望ブロックに一致するタクシーが前記プレゼンス情報データベースに無い場合に、前記乗車希望ブロックに近いブロックから順次タクシーを検索することを特徴とする請求項１に記載のタクシー検索システム。
7. 前記検索手段は、検索されたタクシーの台数が既定台数に達するまで検索を継続することを特徴とする請求項６に記載のタクシー検索システム。
8. タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義したタクシー検索システムに備えられるサーバ装置と通信可能な車載装置であって、
   自装置を搭載するタクシーの現在位置を測位してこのタクシーの所在する現在位置ブロックを特定するブロック特定手段と、
   自装置を搭載するタクシーの状態を少なくとも空車、賃送、回送、および、迎車のいずれかの状態に特定する状態特定手段と、
   前記ブロック特定手段により特定される現在位置ブロックが変化した場合に変化後の現在位置ブロックを前記サーバ装置に通知し、前記状態特定手段により特定される状態が変化した場合に変化後の状態を前記サーバ装置に通知する通知手段とを具備することを特徴とする車載装置。
9. タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義したタクシー検索システムに属する複数のタクシーにそれぞれ搭載される車載装置と通信可能なサーバ装置であって、
   前記複数の車載装置の各々から通知される情報に基づいて更新されるデータベースであって、現在位置ブロックと、少なくとも空車、賃送、回送、および、迎車のいずれかの状態と、車両識別子と、料金体系と、前記営業区域を形成するブロック群の識別子と、運転者の連絡先とを含むプレゼンス情報を前記タクシーごとに対応付けたプレゼンス情報データベースと、
   ユーザにより乗車希望地に対応して指定される乗車希望ブロックと前記ユーザにより目的地に対応して指定される目的地ブロックとを含む検索要求を受理する受理手段と、
   前記検索要求が受理された場合に、空車状態にあるタクシーと、回送状態にあるタクシーであって前記目的地ブロックを営業区域に含むタクシーとからなるタクシー群のうち、現在位置ブロックが前記乗車希望ブロックに一致するタクシーを前記プレゼンス情報データベースから検索する検索手段とを具備することを特徴とするサーバ装置。
10. タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義したタクシー検索システムに備えられるサーバ装置と通信可能で、かつコンピュータにより配車に係わる処理を実行する車載装置で使用されるプログラムであって、
    前記車載装置を搭載するタクシーの現在位置を測位してこのタクシーの所在する現在位置ブロックを特定するブロック特定処理と、
    前記車載装置を搭載するタクシーの状態を少なくとも空車、賃送、回送、および、迎車のいずれかの状態に特定する状態特定処理と、
    前記ブロック特定処理により特定される現在位置ブロックが変化した場合に変化後の現在位置ブロックを前記サーバ装置に通知し、前記状態特定手段により特定される状態が変化した場合に変化後の状態を前記サーバ装置に通知する通知処理と、
    を、前記コンピュータに実行させることを特徴とするプログラム。
11. タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義したタクシー検索システムに属する複数のタクシーにそれぞれ搭載される車載装置と通信可能で、かつコンピュータにより配車に係わる処理を実行するサーバ装置で使用されるプログラムであって、
    現在位置ブロックと、少なくとも空車、賃送、回送、および、迎車のいずれかの状態と、車両識別子と、料金体系と、前記営業区域を形成するブロック群の識別子と、運転者の連絡先とを含むプレゼンス情報を前記タクシーごとに対応付けたプレゼンス情報データベースを、前記複数の車載装置の各々から通知される情報に基づいて生成する処理と、
    ユーザにより乗車希望地に対応して指定される乗車希望ブロックと前記ユーザにより目的地に対応して指定される目的地ブロックとを含む検索要求を受理する処理と、
    前記検索要求が受理された場合に、空車状態にあるタクシーと、回送状態にあるタクシーであって前記目的地ブロックを営業区域に含むタクシーとからなるタクシー群のうち、現在位置ブロックが前記乗車希望ブロックに一致するタクシーを前記プレゼンス情報データベースから検索する検索処理と、
    を、前記コンピュータに実行させることを特徴とするプログラム。
12. タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義したタクシー検索システムであってユーザとの搭乗契約が成立したタクシーを特定する契約特定手段と、この契約特定手段により特定された履歴を前記タクシーごとに対応付けた契約履歴データベースとを具備するタクシー検索システムに備えられる課金サーバ装置であって、
    前記契約履歴データベースに蓄積される内容から一定期間における搭乗契約の成立回数に基づいて、前記複数のタクシー、または前記複数のタクシーごとの事業者に課金する課金手段を具備することを特徴とする課金サーバ装置。
13. タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義したタクシー検索システムであってユーザとの搭乗契約が成立したタクシーを特定する契約特定手段と、この契約特定手段により特定された履歴を前記タクシーごとに対応付けた契約履歴データベースとを具備するタクシー検索システムに備えられ、かつコンピュータにより課金に係わる処理を実行する課金サーバ装置で使用されるプログラムであって、
    前記契約履歴データベースに蓄積される内容から一定期間における搭乗契約の成立回数に基づいて、前記複数のタクシー、または前記複数のタクシーごとの事業者に課金する課金処理、
    を、前記コンピュータに実行させることを特徴とするプログラム。
14. タクシーの営業区域を含む地域を複数に分割して複数のブロックを定義したタクシー検索システムに用いられるビジネス方法であって、
    現在位置ブロックと、少なくとも空車、賃送、回送、および、迎車のいずれかの状態と、車両識別子と、料金体系と、前記営業区域を形成するブロック群の識別子と、運転者の連絡先とを含むプレゼンス情報を前記タクシーごとに対応付けてデータベース管理し、
    配車を要求するユーザの端末装置に前記複数のブロックを表示し、
    乗車希望地に対応する乗車希望ブロックと目的地に対応する目的地ブロックとが前記ユーザにより指定された場合に、空車状態にあるタクシー、または、回送状態にあるタクシーであって前記目的地ブロックを前記営業区域に含むタクシーを前記乗車希望ブロックに近いブロックから順次検索し、
    この検索の結果を前記ユーザの使用するユーザ端末に表示し、
    前記ユーザ端末に表示され且つ前記ユーザとの搭乗契約が成立した回数を前記タクシーごとに管理し、この契約成立回数に基づいて前記複数のタクシー、またはこの複数のタクシーごとの事業者に課金することを特徴とするビジネス方法。
15. 前記選択されたタクシーの状態が迎車状態に切り替えられた場合に、この状態の切り替えを契機として前記契約成立回数をカウントすることを特徴とする請求項１４に記載のビジネス方法。
16. 前記選択されたタクシーの状態が一定期間内に迎車状態に切り替わらない場合には、この選択されたタクシーの契約成立回数をカウントしないことを特徴とする請求項１５に記載のビジネス方法。
17. 迎車状態に切り替えられたタクシーであって、且つ前記ユーザ端末に表示された履歴をもたないタクシーの契約成立回数をカウントしないことを特徴とする請求項１５に記載のビジネス方法。

Images