以下に、添付の図面を参照して、本発明の実施の形態を詳細に説明する。なお、各図において同等の機能を有する構成要素には同一の符号を付し、同一符号の構成要素の詳しい説明は繰り返さない。
<第1の実施形態>
第1の実施形態に係る情報処理システムについて説明する。図1は、第1の実施形態に係る情報処理システム1の概略的な構成を示す図である。なお、同図において、各機能を
行う機能部は、それぞれ各機能を行う手段ということができる。
図1に示すように、情報処理システム1は、端末装置2と、サーバ3とを備えている。端末装置2とサーバ3とは、インターネット等のネットワーク4を介して互いに通信可能に接続されている。ネットワーク4は、無線回線を含むものであれば、回線の種類や形態は問わない。なお、端末装置2およびサーバ3の少なくとも一部は、コンピュータにより実現される。
端末装置2は、走行中のタクシーの車両内部、たとえばダッシュボードに設置されてタクシーとともに移動するものであり、たとえば、スマートフォンやタブレット端末などのモバイル端末、またはカーナビゲーション装置である。
図1に示すように、端末装置2は、端末通信部21と、端末制御部22と、端末記憶部23と、端末入力部24と、端末表示部25とを有している。各部は、バスを介して互いに通信可能に接続されている。
端末通信部21は、端末装置2とネットワーク4との間の通信インターフェースである。端末通信部21は、ネットワーク4を介して端末装置2とサーバ3との間で情報を送受信する。
端末制御部22は、端末装置2の各種処理を行う制御手段である。図1に示すように、端末制御部22は、位置測位部22aを有している。位置測位部22aは、端末装置2内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。
位置測位部22aは、端末装置2の現在位置を測位する。位置測位部22aは、たとえば、GPSなどの電波航法手段による測位情報に基づいて現在位置を測位する。位置測位部22aは、加速度センサや地磁気センサなどの自律航法手段による測位情報を測位に用いてもよい。
本実施形態において、端末装置2は、走行中のタクシーの車両内部に設定されて当該タクシーとともに移動するものであるから、位置測位部22aにより測位された位置情報は、少なくともタクシーの走行中におけるタクシーの位置情報を示すものである。
端末制御部22は、位置測位部22aにより測位された位置情報を、端末通信部21を通じてサーバ3に送信する。端末装置2から送信された測位情報(すなわち、タクシーの位置情報)は、サーバ3に記憶される。サーバ3に複数の時点での位置情報が記憶されることで、タクシーの移動履歴情報が形成される。
端末記憶部23は、たとえば内蔵メモリや外部メモリ(SDメモリカード等)などのデータストレージである。端末記憶部23には、端末制御部22が取り扱う各種データが記憶される。端末記憶部23は、必ずしも端末装置2内に設けられていなくてもよく、ネットワーク4を介して端末装置2と通信可能に接続された別の装置(たとえば、サーバ3)内に設けられていてもよい。
端末入力部24は、ユーザ(すなわちタクシードライバ)が端末装置2に情報を入力するためのインターフェースであり、たとえばモバイル端末におけるタッチパネルやマイクロフォンなどである。
端末表示部25は、端末装置2からユーザ(すなわちタクシードライバ)に対して各種
情報を表示するインターフェースであり、たとえば液晶ディスプレイ等の映像表示手段である。具体的には、たとえば、端末表示部25は、ユーザからの操作を受け付けるためのGUI(Graphical User Interface)を表示してもよい。
次に、サーバ3について説明する。図1に示すように、サーバ3は、サーバ通信部31と、サーバ制御部32と、サーバ記憶部33とを有している。各部は、バスを介して互いに通信可能に接続されている。
このうちサーバ通信部31は、サーバ3とネットワーク4との間の通信インターフェースである。サーバ通信部31は、ネットワーク4を介して端末装置2とサーバ3との間で情報を送受信する。
サーバ記憶部33は、たとえばハードディスク等の固定型データストレージである。サーバ記憶部33には、サーバ制御部32が取り扱う各種データが記憶される。たとえば、サーバ記憶部33は、交通ネットワーク情報を含む経路ネットワーク情報データベース33aと、地図情報を含む地図情報データベース33bと、乗車実績情報データベース33cとを含んでいる。
交通ネットワーク情報は、鉄道やバス等の交通網や道路網を規定する情報である。交通網の情報としては、交通機関の路線情報、時刻表情報、料金情報等を含む。道路網の情報は、例えば交差点等の道路網表現上の結節点であるノードのデータと、ノード間の道路区間であるリンクのデータとの組み合わせによって表現される。なお、本明細書において「道路」とは、ノード間の道路区間であるリンクを意味するものとする。
地図情報は、全国および各地方の道路地図などの地図データと、地図データに対応付けられた地図オブジェクト情報を含む。地図オブジェクト情報とは、地図上に表示される施設の形状についての形状情報、地図上に表示される注記についての注記情報、地図上に表示される記号についての記号情報などである。また、地図情報は公共交通機関の路線図に関する路線図情報を含んでいてもよい。また、地図情報は、地図上に表示される終電の終着駅や終バスの終着バス停における終着時刻情報を含んでいてもよく、地図上に表示される店舗の閉店時間情報を含んでいてもよい。
乗車実績情報データベース33cには、タクシー事業者から取得された複数のタクシーの乗車実績情報がデータベース化されている。図2は、乗車実績情報データベース33cに含まれるデータの一例を示している。
図2に示す例では、乗車実績情報データベース33cには、乗車日時と、乗車位置(たとえば緯度経度)と、降車位置(たとえば緯度経度)と、最終目的地(POI;Point of interest)と、流し/待ち/迎車のいずれのタクシーであるのかを識別する識別情報と、対向車線がある道路での車両走行方向と、タクシーの車種(小型/中型/大型)とが互いに関連付けて記憶されている。タクシーの車種には、バリアフリー車両か否かの情報や乗車定員の情報が含まれていてもよい。また、本件明細書では、端末装置2にインストールされた配車アプリを介して予約されたタクシーが向かう場合は、迎車に該当するものとし、「迎車」の識別情報には、配車アプリを介した予約による迎車か、それ以外(たとえば電話予約)の迎車かを識別する情報が含まれていてもよい。
図示は省略するが、乗車実績情報データベース33cには、さらに、乗車金額、乗車距離、乗客の属性(性別、年齢、観光客か否か、外国人か否か、車椅子など介助が必要な否か、乗車人数など)、天候(雨量、温度、湿度など)、曜日(祝日)、季節、曜日の並び(休日の前日か否か)、特定日(たとえば給料日である25日)か否か、月末か否か、六
曜(大安、仏滅など)といった情報が互いに関連付けて記憶されていてもよい。
上記の経路ネットワーク情報データベース33a、地図情報データベース33bおよび乗車実績情報データベース33cは、それぞれ、所定のタイミングでアップデートされてもよい。
なお、サーバ記憶部33の一部または全部は、必ずしもサーバ3内に設けられていなくてもよく、ネットワーク4を介してサーバ3と通信可能に接続された別の装置内に設けられていてもよい。
サーバ制御部32は、サーバ3の各種処理を行う制御手段である。図1に示すように、サーバ制御部32は、乗車実績取得部32aと、需要推定部32bと、経路探索部32cと、表示制御部32dと、時間指定受付部32eと、走行区域指定受付部32fと、目的地指定受付部32gと、スコア算出部32hと、を有している。これらの各部は、サーバ3内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。
乗車実績取得部32aは、乗車実績情報データベース33cを参照して、所定の地域(たとえば法令で定められた営業区域)内におけるタクシーの乗車実績情報を取得する。
需要推定部32bは、地図情報データベース33bを参照して、乗車実績取得部32aにより取得された乗車実績情報毎に、乗車実績情報に含まれる乗車位置情報(たとえば緯度経度情報)を、地図上の道路にマッチングさせる。そして、需要推定部32bは、道路毎の乗車実績数を集計し、集計した道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する。たとえば、需要推定部32bは、乗車実績数が比較的高い道路についてはタクシー需要として比較的高い数値を推定し、乗車実績数が比較的低い道路についてはタクシー需要として比較的低い数値を推定する。
需要推定部32bは、道路毎の単位距離当たりの乗車実績数に基づいて、道路毎のタクシー需要を推定してもよい。たとえば、長さ100mのA道路の乗車実績数と長さ200mのB道路の乗車実績数とが同一である場合、A道路の単位距離当たりの乗車実績数はB道路の単位距離当たりの乗車実績数の2倍となるため、需要推定部32bは、A道路のタクシー需要がB道路のタクシー需要の2倍であると推定してもよい。
また、図2を参照し、乗車実績情報に、流し/待ち/迎車のいずれのタクシーであるのかを識別する識別情報が含まれる場合には、需要推定部32bは、識別情報が「流し」の乗車実績情報のみに基づいて、道路毎のタクシー需要を推定してもよい。「流し」の乗車実績情報のみを利用することで、タクシー需要の推定精度を高めることができる。
経路探索部32cは、需要推定部32bにより推定された道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。ここで、「道路単位当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路に含まれる道路の数で除算した値に相当する。また、「単位距離当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路の総距離で除算した値に相当する。
たとえば、図3を参照し、A道路からB道路までの経路のうち、実線で示されたルートは、経路全体でのタクシー需要の合計が210であり、当該経路に含まれる道路の数が5であるから、道路単位当たりのタクシー需要は210/5=42である。一方、破線で示されたルートは、経路全体でのタクシー需要の合計が430であり、当該経路に含まれる
道路の数が9であるから、道路単位当たりのタクシー需要は430/9≒47である。したがって、破線で示されたルートは、実線で示されたルートよりも、道路単位当たりのタクシー需要が高い経路となる。この場合、経路探索部32cは、破線で示されたルートを、実線で示されたルートよりも優先的に探索する。
ユーザ(すなわちタクシードライバ)が、端末装置2の端末入力部24を介して、経路探索条件として、営業区域、走行希望道路、走行希望時間(〇時から〇時まで営業したい。今から〇時間走りたいなど)、走行希望距離、探索モード(ターゲットを長距離客あるいは短距離客(ちょい乗り客)にするなど)、乗客の属性(女性客に乗ってほしいなど)を設定した場合には、設定された経路探索条件が、端末装置2からサーバ3へと送信され、経路探索部32cは、道路毎のタクシー需要を探索コストに反映させたうえで、ユーザにより設定された経路探索条件に基づいて、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。
経路探索部32cは、道路毎のタクシー需要を探索コストに反映させたうえで、経路ネットワーク情報データベース33aを参照し、各道路(リンク)について、歩道の有無、車線の数、交差点分岐の有無、走りやすさ(道路交通状況、渋滞度、道幅、事故リスク)をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。また、本件発明者の知見によれば、鉄道駅やバス停から離れた地域はタクシー需要が比較的高いと推定できることから、経路探索部32cは、道路毎のタクシー需要を探索コストに反映させたうえで、各道路について、鉄道駅および/またはバス停からの距離をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。そのほか、周辺の鉄道駅やバス停における運行ダイヤやその行き先(目的地)を考慮してもよい。すなわち、ある地域について周辺の鉄道駅やバス停における次の便の発車時刻が現在時刻から所定時間以上先である場合は、現時点における当該地域のタクシー需要が比較的高いものと推定してもよい。
また、経路探索部32cは、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路として、特定スポット(たとえば、駅やホテルなどの大規模施設のタクシープール)における「待機」を組み込んだ経路を探索してもよい。この場合、経路探索部32cは、たとえば各タクシーの端末装置2から送信される位置情報に基づいて、特定スポットでのリアルタイムの客持ちタクシー台数を算出し、当該スポットでの客待ちタクシー台数が所定の閾値以下であれば、当該スポットでの「待機」を組み込んだ経路を探索し、当該スポットでの客待ちタクシー台数が所定の閾値を超えていれば、当該スポットでの「待機」を組み込むことなく「流し」の経路を探索するようになっていてもよい。
表示制御部32dは、地図情報データベース33bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に出力させる。表示制御部32dは、需要推定部32bにより推定された道路毎のタクシー需要を地図上に重ねて端末表示部25に表示させてもよい。具体的には、たとえば、表示制御部32dは、道路毎のタクシー需要を、図3に示すように、地図上の道路の近傍に数値で表示させてもよいし、図5に示すように、地図上の道路を数値に応じて色分けすることにより表示させてもよい。
また、本件発明者の知見によれば、鉄道駅からもバス停からも離れた地域はタクシー需要が比較的高いと推定できることから、表示制御部32dは、鉄道駅から所定距離(たとえば徒歩15分)以内の範囲および/またはバス停から所定距離(たとえば徒歩5分)以内の範囲を、公共交通手段からのアクセス圏として設定し、当該アクセス圏を地図上に色分けして端末表示部25に表示させてもよい。この場合、公共交通手段からのアクセス圏
外である交通空白地域を可視化することができ、ユーザであるタクシードライバは、「流し」のルートを決める際の参考情報としてこれを利用することができる。
また、表示制御部32dは、図5に示すように、経路探索部32cにより抽出された複数の経路のうちの少なくとも1つを、地図上に重ねて端末表示部25に表示させてもよい。この場合、表示制御部32dは、各タクシーの端末装置2から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部25に表示させる経路を割り振ってもよい。あるいは、タクシーの事業者が、各タクシーの端末装置2から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部25に表示させる経路を割り振ってもよい。特定の経路に車両が集中することなく、複数の経路にまんべんなく車両が割り振られることにより、事業者単位での営業効率を最大化することができる。
時間指定受付部32eは、ユーザが端末装置2の端末入力部24を介して所定の時間(時間帯ないし時刻)を指定し、当該指定された時間の情報が端末装置2からサーバ3へと送信されると、当該時間の指定を受け付ける。ここで、ユーザは、たとえば端末表示部25に表示されたスライドバー51(図13参照)を操作することにより、所定の時間を指定(ないし変更)してもよい。時間指定受付部32eが時間の指定を受け付けると、需要推定部32bは、指定された時間の乗車実績情報のみに基づいて、道路毎のタクシー需要を推定する。ここで、「指定された時間の乗車実績情報」とは、「時間帯」が指定された場合は、当該指定された時間帯の乗車実績情報を意味し、「時刻」が指定された場合は、当該指定された時刻を含む所定長さ(たとえば2時間)の時間帯の乗車実績情報を意味する。
走行区域指定受付部32fは、ユーザが端末装置2の端末入力部24を介して所定の走行区域を指定し、指定された走行区域の情報が端末装置2からサーバ3へと送信されると、当該走行区域の指定を受け付ける。走行区域指定受付部32fが走行区域の指定を受け付けると、経路探索部32cは、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。
具体的には、たとえば、図7を参照し、経路探索部32cは、地図情報データベース33bを参照して、指定された走行区域に含まれる1または2以上のノードまたは道路(リンク)を仮想経由地V1、V2として設定するとともに、タクシーの現在位置を目的地Gとして設定したうえで、道路毎のタクシー需要を探索コストに反映させて、経路探索を行う。この場合、経路探索部32cは、仮想経由地V1、V2を走行区域内でランダムに設定してもよい。これにより、特定の巡回経路だけに車両が集中することを防ぐことができる。
目的地指定受付部32gは、ユーザが端末装置2の端末入力部24を介して所定の目的地を指定し、指定された目的地の情報が端末装置2からサーバ3へと送信されると、当該目的地の指定を受け付ける。目的地指定受付部32gが目的地の指定を受け付けると、経路探索部32cは、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。この場合、経路探索部32cは、指定された目的地まで走行中のタクシーが当該目的地またはその近くに到達したときに、タクシー需要が予め定められた第1閾値より高い高需要スポットが、当該タクシーの近くにあるか否かを判定し、高需要スポットが近くにある場合には、指定された目的地を当該高需要スポットに変更し、当該高需要スポットまでの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索してもよい。
スコア算出部32hは、経路探索部32cにより抽出された複数の経路について、経路
毎のタクシー需要に応じたスコアを算出する。スコア算出部32hは、経路のバリエーションが出るよう(複数の経路同士の走行ルートや方面が異なるよう)、複数の経路同士の走行ルートや方面が類似する場合には、当該複数の経路のスコアを類似の割合に応じて下げてもよい。スコア算出部32hにより経路毎のスコアが算出されると、表示制御部32dは、経路探索部32cにより抽出された複数の経路を、スコア算出部32hにより算出された各経路のスコアとともに、端末装置2の端末表示部25に表示させる(たとえば図11参照)。図示は省略するが、表示制御部32dは、走行ルートの選択をしやすくするため、経路探索部32cにより抽出された複数の経路を地図上に表示の上、経路の概要を示す名称とともにスコアを表示(たとえば、「湾岸回りコース:90点」など)してもよい。そのほか、走りなれたルートなど、ユーザにとって走行したいルートが具体的に決まっている場合には、ユーザが端末表示部25に表示されている地図上の道路をなぞる等といった操作により走行ルートを指定し、指定された走行ルートの情報が端末装置2からサーバ3へと送信されると、スコア算出部32hが、当該走行ルートの指定を受け付け、当該ルートについてのスコア値を算出するようにしてもよい。
一例として、スコア算出部32hは、経路探索部32cにより抽出された複数の経路の各々について、たとえば走行中のタクシーの位置情報をマッチングさせることにより、当該経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第2閾値を超えた場合には、当該経路のスコアを下げてもよい。別の一例として、スコア算出部32hは、各タクシーの端末装置2からサーバ3へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第2閾値を超えた場合には、当該経路のスコアを下げてもよい。更に別の一例として、スコア算出部32hは、経路の提示実績数に応じてスコアを下げてもよい。すなわち、スコア算出部32hは、経路の提示実績数が予め定められた第3閾値を超えた場合には(第3閾値を超える回数、当該経路が提示されたら)、当該経路のスコアを下げてもよい。これらにより、特定の経路だけに車両が集中することを防ぐことができる。
需要推定部32bは、乗車実績情報に含まれる天候(雨量、温度、湿度など)、曜日(祝日)、季節、曜日の並び(休日の前日か否か)、特定日(たとえば給料日である25日)か否か、月末か否か、六曜(大安、仏滅など)のうち少なくとも一つの情報(特徴量)と、乗車実績情報毎に地図上の道路とマッチングさせて道路毎に集計された乗車実績数に基づいて推定された道路毎のタクシー需要とを教師データとして機械学習を実行し、上記特徴量を入力として道路毎のタクシー需要を推定する学習モデルを生成してもよい。
そして、ユーザ(すなわちタクシードライバ)が、端末装置2の端末入力部24を介して、天候(雨量、温度、湿度など)、曜日(祝日)、季節、曜日の並び(休日の前日か否か)、特定日(たとえば給料日である25日)か否か、月末か否か、六曜(大安、仏滅など)のうち少なくとも一つの情報(特徴量)を入力した場合には、入力された情報(特徴量)が端末装置2からサーバ3へと送信され、需要推定部32bは、生成された学習モデルを利用し、ユーザにより入力された情報(特徴量)に基づいて、道路毎のタクシー需要を推定してもよい。この場合、タクシーの乗車実績情報をタクシー事業者から取得できない状況でも、需要推定部32bは、天候や曜日などの情報(特徴量)を入力として学習モデルを利用することで、道路毎のタクシー需要を推定することが可能となる。
(動作の第1の態様)
次に、図4および図5を参照して、第1の実施形態に係る情報処理システム1の動作の第1の態様について説明する。図4は、情報処理システム1の動作の第1の態様を示すフローチャートである。図5は、情報処理システム1の動作の第1の態様において表示される画面の一例を示す図である。
図4に示すように、まず、乗車実績取得部32aは、乗車実績情報データベース33cを参照して、所定の地域(たとえば法令で定められた営業区域)内におけるタクシーの乗車実績情報を取得する(ステップS10)。
次に、需要推定部32bは、地図情報データベース33bを参照して、乗車実績取得部32aにより取得された乗車実績情報に含まれる乗車位置情報(たとえば緯度経度情報)を、地図上の道路にマッチングさせる(ステップS11)。需要推定部32bは、乗車実績取得部32aにより取得された乗車実績情報のうち、識別情報が「流し」の乗車実績情報の乗車位置情報のみを、地図上の道路にマッチングさせてもよい。
次に、ユーザであるタクシードライバが、端末装置2の端末入力部24を介して所定の時間を指定すると、指定された時間の情報は端末装置2からサーバ3へと送信され、時間指定受付部32eは、当該時間の指定を受け付ける(ステップS12)。
そして、需要推定部32bは、ステップS11におけるマッチング結果を参照して、指定された時間の道路毎の乗車実績数のみを集計し、集計した道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定する(ステップS13)。需要推定部32bは、道路毎の単位距離当たりの乗車実績数に基づいて、道路毎のタクシー需要を推定してもよい。また、ステップS11において、識別情報が「流し」の乗車実績情報の乗車位置情報のみを、地図上の道路にマッチングさせる場合には、需要推定部32bは、識別情報が「流し」の乗車実績情報のみに基づいて、道路毎のタクシー需要を推定してもよい。
ステップS13において、需要推定部32bは、乗車実績情報に含まれる乗車金額、乗車距離、乗客の属性(性別、年齢、観光客か否か、外国人か否か、車椅子など介助が必要な否か、乗車人数など)、天候(雨量、温度、湿度など)、曜日(祝日)、季節、曜日の並び(休日の前日か否か)、特定日(たとえば給料日である25日)か否か、月末か否か、六曜(大安、仏滅など)のうち少なくとも一つの情報を考慮して、道路毎のタクシー需要を推定してもよい。一例として、ユーザ(すなわちタクシードライバ)が、端末装置2の端末入力部24を介して対象日の日付と時間を指定すると、指定された対象日の日付と時間の情報が端末装置2からサーバ3へと送信され、需要推定部32bは、対象日の指定時間に対応する天候の予報情報を外部サーバから取得し、取得した天候の予報情報を考慮して、道路毎のタクシー需要を推定してもよい。別例として、ユーザ(すなわちタクシードライバ)が、端末装置2の端末入力部24を介して時間帯とともに希望する乗客属性(性別、特定の国籍の外国人など)を指定すると、指定された時間帯および乗客属性の情報が端末装置2からサーバ3へと送信され、需要推定部32bは、指定された時間帯および乗客属性の情報を考慮して、道路毎のタクシー需要を推定してもよい。
次に、ユーザであるタクシードライバが、端末装置2の端末入力部24を介して所定の目的地を指定すると、指定された目的地の情報は端末装置2からサーバ3へと送信され、目的地指定受付部32gは、当該目的地の指定を受け付ける(ステップS14)。
そして、経路探索部32cは、需要推定部32bにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する(ステップS15)。なお、「道路毎のタクシー需要を探索コストに反映させ」るとは、従来の経路探索では、たとえば時間、金銭および走りやすさをコスト係数として道路毎のコストを計算していたのに対し、時間、金銭および走りやすさに加えて、タクシー需要もコスト係数に含めて道路毎のコストを計算することを意味する。
次に、表示制御部32dは、地図情報データベース33bを参照し、所定の地域(たと
えば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、経路探索部32cにより抽出された経路の少なくとも1つを、端末表示部25に出力される地図上に重ねて表示させる(ステップS16)。図5に示すように、表示制御部32dは、経路探索部32cにより抽出された経路Rを、地図上に矢印で表示させてもよい。また、表示制御部32dは、端末装置2から取得される測位情報(タクシーの現在の位置情報)Aを、地図上に重ねて表示させてもよい。
また、表示制御部32dは、需要推定部32bにより推定された道路毎のタクシー需要情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS17)。図5に示すように、表示制御部32dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これにより、ユーザ(すなわちタクシードライバ)は、タクシー需要が高い道路を一目で直感的に把握できるようになる。
ところで、発明が解決しようとする課題の欄でも言及したように、従来のタクシーの需要予測技術では、携帯端末の位置情報を利用してエリア毎のタクシー需要を予測するため、ユーザであるタクシードライバは、タクシー需要が高いエリアは分かるものの、そのエリア内で実際にどの道路を走行すれば高い営業効率が得られるのかまでは分からなかった。
これに対し、本実施の形態によれば、乗車実績取得部32aが、タクシーの乗車実績情報を取得し、需要推定部32bが、乗車実績情報に含まれる乗車位置情報を地図上の道路にマッチングさせ、道路毎の乗車実績数に基づいて、道路毎のタクシー需要を推定し、経路探索部32cが、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い経路を優先的に探索するため、タクシーの走行経路に関し、営業効率が高い経路を探索することが可能となる。これにより、ユーザであるタクシードライバは、実際にどの道路を走行すれば高い営業効率が得られるのかが分かるようになり、営業効率を高めることができる。
(動作の第2の態様)
第1の実施形態に係る情報処理システム1の動作の第2の態様について、図6および図7を参照して説明する。図6は、情報処理システム1の動作の第2の態様を示すフローチャートである。図7は、情報処理システム1の動作の第2の態様において表示される画面の一例を示す図である。第2の態様において、需要推定部32bが道路毎のタクシー需要を推定する工程まで(ステップS10~S13)は、上述した第1の態様と同様であり、説明を省略する。
図6に示すように、第2の態様では、需要推定部32bが道路毎のタクシー需要を推定した後(ステップS13の後)、ユーザであるタクシードライバが、端末装置2の端末入力部24を介して所望の走行区域(たとえば、得意とするエリア)を指定すると、指定された走行区域の情報は端末装置2からサーバ3へと送信され、走行区域指定受付部32fは、当該走行区域の指定を受け付ける(ステップS24)。
そして、経路探索部32cは、需要推定部32bにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する(ステップS25)。図7に示す例では、経路探索部32cは、経路探索条件として、地図情報データベース33bを参照して、指定された走行区域に含まれる複数(図示された例では2つ)のノードを仮想経由地V1、V2として設定するとともに、タクシーの現在位置を目的地Gとして設定したうえで、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い
経路を優先的に探索する。
次に、表示制御部32dは、地図情報データベース33bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、経路探索部32cにより抽出された経路の少なくとも1つを、端末表示部25に出力される地図上に重ねて表示させる(ステップS26)。図7に示すように、表示制御部32dは、経路探索部32cにより抽出された経路Rを、地図上に矢印で表示させてもよい。また、表示制御部32dは、端末装置2から取得される測位情報(タクシーの現在の位置情報)Aを、地図上に重ねて表示させてもよい。
また、表示制御部32dは、需要推定部32bにより推定された道路毎のタクシー需要情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS27)。図7に示すように、表示制御部32dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これにより、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。
以上のような第2の態様によれば、上述した第1の態様と同様の作用効果が得られることに加えて、ユーザであるタクシードライバは、ある目的地までの経路(一方向の経路)の代わりに、指定された走行区域内で周遊(巡回)する経路を探索することができ、空車での走行時間の短縮を図ることができる。
(動作の第3の態様)
第1の実施形態に係る情報処理システム1の動作の第3の態様について、図8および図9を参照して説明する。第3の態様は、指定された目的地まで走行中のタクシーが、当該目的地またはその近くに到達したときに情報処理システム1により行われる処理(オートリルート処理)に関する。図8は、情報処理システム1の動作の第3の態様を示すフローチャートである。図9は、情報処理システム1の動作の第3の態様において表示される画面の一例を示す図である。
まず、図9の上図を参照し、サーバ制御部32は、端末装置2から送信される測位情報に基づいて、指定された目的地Gまで走行中のタクシーの現在位置Aが、当該目的地Gまたはその近くに到達したか否かを判定する。そして、走行中のタクシーの現在位置Aが目的地Gまたはその近くに到達したと判定されると、サーバ制御部32は、予め定められた第1閾値より高いタクシー需要を有する高需要スポットPが、当該タクシーの現在位置Aの近くにあるか否かを判定する(ステップS31)。
そして、高需要スポットPがタクシーの現在位置Aの近くにあると判定された場合には(ステップS31:YES)、図9の下図を参照し、指定された目的地Gを当該高需要スポットPへと変更する(ステップS32)。
そして、経路探索部32cは、上述したステップS15と同様にして、需要推定部32bにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地G(すなわち高需要スポットP)までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する(ステップS33)。
次に、表示制御部32dは、地図情報データベース33bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、経路探索部32cにより抽出された経路の少なくとも1つを、端末表示部25に出力される地図上に重ねて表示させる(ステップS34)。図9の下図に示すように、表
示制御部32dは、経路探索部32cにより抽出された経路R2を、地図上に矢印で表示させてもよい。
また、表示制御部32dは、需要推定部32bにより推定された道路毎のタクシー需要情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS35)。図9に示すように、表示制御部32dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。
上述したステップS31~S35は、走行中のタクシーの現在位置Aが指定された目的地Gまたはその近くに到達するたびに繰り返されてもよい。
以上のような第3の態様によれば、目的地Gまたはその近くに到達するたびに新たな走行経路が提示されるため、ユーザであるタクシードライバは、端末入力部24を操作して目的地を指定するためにタクシーをいちいち停車させる必要がなくなり、営業効率をさらに高めることができる。
(動作の第4の態様)
第1の実施形態に係る情報処理システム1の動作の第4の態様について、図10および図11を参照して説明する。図10は、情報処理システム1の動作の第4の態様を示すフローチャートである。図11は、情報処理システム1の動作の第4の態様において表示される画面の一例を示す図である。第4の態様において、経路探索部32cが道路単位当たりのタクシー需要が高い経路を優先的に探索する工程まで(ステップS10~S15)は、上述した第1の態様と同様であり、説明を省略する。
図10に示すように、第4の態様では、経路探索部32cが道路単位当たりのタクシー需要が高い経路を優先的に探索した後(ステップS15の後)、スコア算出部32hが、経路探索部32cにより抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出する(ステップS33)。
次に、表示制御部32dは、図11の上図に示すように、経路探索部32cにより抽出された複数の経路を、スコア算出部32hにより算出された各経路のスコアとともに、端末装置2の端末表示部25に表示させる(ステップS34)。
次に、ユーザであるタクシードライバが、端末表示部25に表示された各経路のスコアを参照しながら、端末入力部24を介して1つの経路を選択すると、選択された経路の情報が端末装置2からサーバ3へと送信され、サーバ制御部32は、経路の選択を受け付ける(ステップS35)。
そして、表示制御部32dは、地図情報データベース33bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、ユーザにより選択された経路の情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS36)。
次いで、スコア算出部32hは、経路探索部32cにより抽出された複数の経路の各々について、当該経路を走行するタクシーの数を推定する。具体的には、たとえば、スコア算出部32hは、各タクシーの端末装置2からサーバ3へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定する。あるいは、スコア算出部32hは、各タクシーの端末装置2からサーバ3へと送信される各タクシーの位置情報に基づいて、各経路を走行するタクシーの数を推定してもよい。図11の中央図に示すように、スコア算出部32h、推定された各経路を走行するタクシーの数を、スコア
算出部32hにより算出された各経路のスコアとともに、端末装置2の端末表示部25に表示させてもよい。そして、スコア算出部32hは、各経路を走行するタクシーの数が、予め定められた第2閾値(たとえば、10台)を超えたか否かを判定する(ステップS37)。
各経路を走行するタクシーの数が第2閾値を超えた場合には(ステップS37:YES)、スコア算出部32hは、当該の経路のスコアを下げる(ステップS38)。図11に示す例では、ルート1を走行するタクシーの数(=12台)が第2閾値(=10台)を超えたことから、スコア算出部32hは、ルート1のスコアを「95」から「65」へと下げている。これにより、ルート1の魅力が下がり、ルート1に車両がこれ以上集中することを防ぐことができる。
以上のような第4の態様によれば、ユーザであるタクシードライバが、端末表示部25に表示された各経路のスコアを参照しながら、端末入力部24を介して1つの経路を選択する際に、スコア算出部32hが、走行するタクシーの数が第2閾値を超えている経路についてはそのスコアを下げることで、当該経路の魅力を下げるため、ユーザであるタクシードライバは、走行するタクシーの数が第2閾値を超えている経路の選択を避けるようになる。これにより、各経路を走行するタクシーの数を自動的に分散させることが可能となり、事業者単位での営業効率を最大化することができる。
(動作の第5の態様)
第1の実施形態に係る情報処理システム1の動作の第5の態様について、図12および図13を参照して説明する。図12は、情報処理システム1の動作の第5の態様を示すフローチャートである。図13は、情報処理システム1の動作の第5の態様において表示される画面の一例を示す図である。第5の態様において、需要推定部32bが道路毎のタクシー需要を推定する工程まで(ステップS10~S13)は、上述した第1の態様と同様であり、説明を省略する。
図12に示すように、第5の態様では、需要推定部32bが道路毎のタクシー需要を推定した後(ステップS13の後)、表示制御部32dは、地図情報データベース33bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、需要推定部32bにより推定された道路毎のタクシー需要情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS17)。図13に示すように、表示制御部32dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。これにより、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。
図13に示すように、表示制御部32dは、所定の地域の地図に隣接して、時間帯を選択(ないし変更)するためのスライドバー51を、端末表示部25に表示させてもよい。
次に、ユーザであるタクシードライバが、端末入力部24を介してスライドバー51を操作して新たな時間を指定すると、指定された時間の情報は端末装置2からサーバ3へと送信される。時間指定受付部32eは、新たに指定された時間の情報が端末装置2からサーバ3へと送信されたか否かに応じて、時間の変更があるか否かを判定する(ステップS18)。
そして、時間の変更があると判定された場合には(ステップS18:YES)、時間指定受付部32eは、新たに指定された時間の指定を受け付け(ステップS12)、新たに指定された時間についてステップS13~S17の処理を繰り返す。
以上のような第5の態様によれば、ユーザであるタクシードライバは、端末表示部25に表示される道路毎のタクシー需要情報を、時間別に容易に切り替えて比較したり、道路毎のタクシー需要の時間変化を把握したりすることが可能となり、営業効率の高い経路の分析にこれを役立てることができる。
<第2の実施形態>
次に、第2の実施形態に係る情報処理システムについて説明する。図14は、第2の実施形態に係る情報処理システム101の概略的な構成を示す図である。なお、同図において、各機能を行う機能部は、それぞれ各機能を行う手段ということができる。
図14に示すように、情報処理システム101は、端末装置2と、サーバ103とを備えている。端末装置2とサーバ103とは、インターネット等のネットワーク4を介して互いに通信可能に接続されている。端末装置2およびネットワーク4の構成は、上述した第1の実施形態と同様であり、説明を省略する。なお、端末装置2およびサーバ103の少なくとも一部は、コンピュータにより実現される。
図14に示すように、サーバ103は、サーバ通信部131と、サーバ制御部132と、サーバ記憶部133とを有している。各部は、バスを介して互いに通信可能に接続されている。
このうちサーバ通信部131は、サーバ103とネットワーク4との間の通信インターフェースである。サーバ通信部131は、ネットワーク4を介して端末装置2とサーバ103との間で情報を送受信する。
サーバ記憶部133は、たとえばハードディスク等の固定型データストレージである。サーバ記憶部133には、サーバ制御部132が取り扱う各種データが記憶される。たとえば、サーバ記憶部133は、交通ネットワーク情報を含む経路ネットワーク情報データベース133aと、地図情報を含む地図情報データベース133bと、経路検索ログデータベース133cとを含んでいる。
交通ネットワーク情報は、鉄道やバス等の交通網や道路網を規定する情報である。交通網の情報としては、交通機関の路線情報、時刻表情報、料金情報等を含む。道路網の情報は、例えば交差点等の道路網表現上の結節点であるノードのデータと、ノード間の道路区間であるリンクのデータとの組み合わせによって表現される。なお、本明細書において「道路」とは、ノード間の道路区間であるリンクを意味するものとする。
地図情報は、全国および各地方の道路地図などの地図データと、地図データに対応付けられた地図オブジェクト情報を含む。地図オブジェクト情報とは、地図上に表示される施設の形状についての形状情報、地図上に表示される注記についての注記情報、地図上に表示される記号についての記号情報などである。また、地図情報は公共交通機関の路線図に関する路線図情報を含んでいてもよい。また、地図情報は、地図上に表示される終電の終着駅や終バスの終着バス停における終着時刻情報を含んでいてもよく、地図上に表示される店舗の閉店時間情報を含んでいてもよい。
経路検索ログデータベース133cには、乗換検索や地図上のルート検索などの経路検索Webサービス(またはアプリ)を利用した複数のユーザの経路検索ログがデータベース化されている。図15は、経路検索ログデータベース133cに含まれるデータの一例を示している。
図15に示す例では、経路検索ログデータベース133cには、検索条件と検索結果と
が互いに関連付けて記憶されている。検索条件には、出発地と、目的地と、出発時刻または到着時刻と、タクシー利用の有無とが含まれる。また、探索結果には、出発地から目的地までの経路の内容と、タクシーの利用の有無とが含まれる。
経路検索ログデータベース133cは、乗換検索や地図上のルート検索から得られる経路検索ログに加えて、スポット検索から得られるスポット検索ログを含んでいてもよい。また、経路検索ログデータベース133cは、検索ログとして、タクシー配車サービスで入力された配車希望位置情報やタクシー経路検索サービス、タクシー料金検索サービスで入力された出発地の位置情報を含んでいてもよい。
上記の経路ネットワーク情報データベース133a、地図情報データベース133bおよび乗車実績情報データベース133cは、それぞれ、所定のタイミングでアップデートされてもよい。
なお、サーバ記憶部133の一部または全部は、必ずしもサーバ103内に設けられていなくてもよく、ネットワーク4を介してサーバ103と通信可能に接続された別の装置内に設けられていてもよい。
サーバ制御部132は、サーバ103の各種処理を行う制御手段である。図14に示すように、サーバ制御部132は、経路検索ログ取得部132aと、需要推定部132bと、経路探索部132cと、表示制御部132dと、時間指定受付部132eと、走行区域指定受付部132fと、目的地指定受付部132gと、スコア算出部132hと、を有している。これらの各部は、サーバ103内のプロセッサが所定のプログラムを実行することにより実現されてもよいし、ハードウェアで実装されてもよい。
経路検索ログ取得部132aは、経路検索ログ情報データベース133cを参照して、所定の地域(たとえば法令で定められた営業区域)内に出発地または目的地が含まれる経路検索ログを取得する。経路検索ログ取得部132aは、経路検索ログ情報データベース133cを参照し、所定の地域(たとえば法令で定められた営業区域)内に出発地または目的地が含まれる経路検索ログに加えて、当該地域内に検索対象のスポットが含まれるスポット検索ログを取得してもよい。
需要推定部132bは、地図情報データベース133bを参照して、経路検索ログ取得部132aにより取得された経路検索ログ毎に、経路検索ログに含まれる出発地または目的地の位置情報を、地図上のスポットにマッチングさせる。経路検索ログ取得部132aによりスポット検索ログが取得されている場合には、需要推定部132bは、スポット検索ログに含まれる検索対象のスポットの位置情報を、地図上のスポットにマッチングさせてもよい。そして、需要推定部132bは、スポット毎の検索回数(経路検索における出発地または目的地として指定された回数)を集計し、集計したスポット毎の検索回数と、スポットと道路との位置関係とに基づいて、道路毎のタクシー需要を推定する。たとえば、検索回数が多いスポット周辺は混雑が予測されるから、需要推定部132bは、検索回数が比較的多いスポット周辺の道路についてはタクシー需要として比較的高い数値を推定し、検索回数が比較的低いスポット周辺の道路についてはタクシー需要として比較的低い数値を推定する。また、需要推定部132bは、混雑が予測されるスポットからの距離に応じて各道路のタクシー需要を推定してもよいし、混雑が予測されるスポットの出入口からの距離に応じて各道路のタクシー需要を推定してもよい。
また、図15を参照し、経路検索ログの検索条件または検索結果に、タクシーの利用の有無を示す情報が含まれる場合には、需要推定部132bは、タクシーの利用ありの経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。タクシーの利用あり
の経路検索ログのみを利用することで、タクシー需要の推定精度を高めることができる。
需要推定部132bは、検索条件として出発日時または到着日時に検索時点より未来の日時が指定された経路検索ログ(いわゆる事前経路検索ログ)のみに基づいて、道路毎のタクシー需要を推定してもよい。本件発明者らの知見によれば、未来の日時を指定して経路検索を行うユーザは、当該指定された日時において検索結果どおりの経路で移動する可能性が比較的高いから、検索条件として出発日時または到着日時に検索時点より未来の日時が指定された経路検索ログ(事前経路検索ログ)のみを利用することで、タクシー需要の推定精度を高めることができる。
また、需要推定部132bは、終電検索(準終電検索を含む)または始発検索の経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。なお、本明細書において「準終電検索」とは、目的地までの終電後の経路であって、目的地の手前の途中駅までの終電の経路と当該途中駅から目的地までのタクシーの経路との組み合わせを検索することをいう。本件発明者らの知見によれば、終電検索(準終電検索を含む)または始発検索を行うユーザは、検索結果どおりの経路で移動する可能性が比較的高いから、終電検索(準終電検索を含む)または始発検索の経路検索ログのみを利用することで、タクシー需要の推定精度を高めることができる。
経路探索部132cは、需要推定部132bにより推定された道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。ここで、「道路単位当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路に含まれる道路の数で除算した値に相当する。また、「単位距離当たりのタクシー需要」とは、経路全体でのタクシー需要の合計を当該経路の総距離で除算した値に相当する。
たとえば、図3を参照し、A道路からB道路までの経路のうち、実線で示されたルートは、経路全体でのタクシー需要の合計が210であり、当該経路に含まれる道路の数が5であるから、道路単位当たりのタクシー需要は210/5=42である。一方、破線で示されたルートは、経路全体でのタクシー需要の合計が430であり、当該経路に含まれる道路の数が9であるから、道路単位当たりのタクシー需要は430/9≒47である。したがって、破線で示されたルートは、実線で示されたルートよりも、道路単位当たりのタクシー需要が高い経路となる。この場合、経路探索部132cは、破線で示されたルートを、実線で示されたルートよりも優先的に探索する。
ユーザ(すなわちタクシードライバ)が、端末装置2の端末入力部24を介して、経路探索条件として、営業区域、走行希望道路、走行希望時間(〇時から〇時まで営業したい。今から〇時間走りたいなど)、走行希望距離、探索モード(ターゲットを長距離客あるいは短距離客(ちょい乗り客)にするなど)、乗客の属性(女性客に乗ってほしいなど)を設定した場合には、設定された経路探索条件が、端末装置2からサーバ103へと送信され、経路探索部132cは、道路毎のタクシー需要を探索コストに反映させたうえで、ユーザにより設定された経路探索条件に基づいて、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索する。
経路探索部132cは、道路毎のタクシー需要を探索コストに反映させたうえで、経路ネットワーク情報データベース133aを参照し、各道路(リンク)について、歩道の有無、車線の数、交差点分岐の有無、走りやすさ(道路交通状況、渋滞度、道幅、事故リスク)をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。また、本件発明者の知見によれば、鉄道駅やバス停から離れた地域はタクシー需要が比較的高いと推定できることから、経路探索部1
32cは、道路毎のタクシー需要を探索コストに反映させたうえで、各道路について、鉄道駅および/またはバス停からの距離をさらに考慮して、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路を優先的に探索してもよい。そのほか、周辺の鉄道駅やバス停における運行ダイヤやその行き先(目的地)を考慮してもよい。すなわち、ある地域について周辺の鉄道駅やバス停における次の便の発車時刻が現在時刻から所定時間以上先である場合は、現時点における当該地域のタクシー需要が比較的高いものと推定してもよい。
また、経路探索部132cは、道路単位当たりのタクシー需要または単位距離当たりのタクシー需要が高い経路として、特定スポット(たとえば、駅やホテルなどの大規模施設のタクシープール)における「待機」を組み込んだ経路を探索してもよい。この場合、経路探索部132cは、たとえば各タクシーの端末装置2から送信される位置情報に基づいて、特定スポットでのリアルタイムの客持ちタクシー台数を算出し、当該スポットでの客待ちタクシー台数が所定の閾値以下であれば、当該スポットでの「待機」を組み込んだ経路を探索し、当該スポットでの客待ちタクシー台数が所定の閾値を超えていれば、当該スポットでの「待機」を組み込むことなく「流し」の経路を探索するようになっていてもよい。
表示制御部132dは、地図情報データベース133bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に出力させる。表示制御部132dは、需要推定部132bにより推定された道路毎のタクシー需要を地図上に重ねて端末表示部25に表示させてもよい。具体的には、たとえば、表示制御部132dは、道路毎のタクシー需要を、図3に示すように、地図上の道路の近傍に数値で表示させてもよいし、図17に示すように、地図上の道路を数値に応じて色分けすることにより表示させてもよい。
また、本件発明者の知見によれば、鉄道駅からもバス停からも離れた地域はタクシー需要が比較的高いと推定できることから、表示制御部132dは、鉄道駅から所定距離(たとえば徒歩15分)以内の範囲および/またはバス停から所定距離(たとえば徒歩5分)以内の範囲を、公共交通手段からのアクセス圏として設定し、当該アクセス圏を地図上に色分けして端末表示部125に表示させてもよい。この場合、公共交通手段からのアクセス圏外である交通空白地域を可視化することができ、ユーザであるタクシードライバは、「流し」のルートを決める際の参考情報としてこれを利用することができる。
また、表示制御部132dは、図17に示すように、経路探索部132cにより抽出された複数の経路のうちの少なくとも1つを、地図上に重ねて端末表示部25に表示させてもよい。この場合、表示制御部132dは、各タクシーの端末装置2から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部25に表示させる経路を割り振ってもよい。あるいは、タクシーの事業者が、各タクシーの端末装置2から送信される位置情報を考慮して、特定の経路に車両が集中しないように、各タクシーの端末表示部25に表示させる経路を割り振ってもよい。特定の経路に車両が集中することなく、複数の経路にまんべんなく車両が割り振られることにより、事業者単位での営業効率を最大化することができる。
また、表示制御部132dは、図17に示すように、検索回数が比較的多く、高いタクシー需要が見込まれるスポットまたはエリア情報を、その検索回数および/または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部25に表示させてもよい。図17に示す例では、検索回数が比較的多いA駅について、その検索回数が、検索回数に応じた大きさのバブル(円)で表示されるとともに、平常時の検索回数との比較情報が文字で表示されている。また、検索回数が比較的多いB駅についても、その検索回数が、検
索回数に応じた大きさのバブル(円)で表示されるとともに、平常時の検索回数との比較情報が文字で表示されている。
図示は省略するが、表示制御部132dは、地図情報データベース33bを参照し、端末表示部25に表示させる地図の範囲内に終電の終着駅(または終バスの終着バス停)が含まれている場合には、当該終着駅(または終着バス停)の位置情報や終着時刻に関する情報を、地図上に重ねて端末表示部25に表示させてもよい。また、表示制御部132dは、端末表示部25に表示させる地図の範囲内に準終電検索の途中駅(すなわち終電後にタクシーに乗り換える駅)が含まれている場合には、当該途中駅の位置情報や終着時刻に関する情報を、地図上に重ねて端末表示部25に表示させてもよい。
また、表示制御部132dは、地図情報データベース33bを参照し、終電(または終バス)後に閉店する店舗の閉店時間情報を、地図上に重ねて端末表示部25に表示させてもよい。終電(または終バス)後に閉店する店舗の閉店時間情報を表示させる場合には、表示制御部132dは、所定のエリア毎に閉店時間が最も遅い店舗を特定し、エリア単位で店舗の閉店時間情報を端末表示部25に表示させてもよい。
時間指定受付部132eは、ユーザが端末装置2の端末入力部24を介して所定の時間を指定し、当該指定された時間の情報が端末装置2からサーバ103へと送信されると、当該時間の指定を受け付ける。ここで、ユーザは、たとえば端末表示部25に表示されたスライドバー51(図25参照)を操作することにより、所定の時間を指定(ないし変更)してもよい。時間指定受付部132eが時間の指定を受け付けると、需要推定部132bは、出発時刻または到着時刻が指定された時間に対応する経路検索ログのみに基づいて、道路毎のタクシー需要を推定する。ここで、「指定された時間に対応する経路検索ログ」とは、「時間帯」が指定された場合は、出発時刻または到着時刻が当該指定された時間帯に入る経路探索ログを意味し、「時刻」が指定された場合は、出発時刻または到着時刻が当該指定された時刻を含む所定長さ(たとえば2時間)の時間帯に入る経路検索ログを意味する。
走行区域指定受付部132fは、ユーザが端末装置2の端末入力部24を介して所定の走行区域を指定し、指定された走行区域の情報が端末装置2からサーバ103へと送信されると、当該走行区域の指定を受け付ける。走行区域指定受付部132fが走行区域の指定を受け付けると、経路探索部132cは、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。
具体的には、たとえば、図19を参照し、経路探索部132cは、地図情報データベース133bを参照して、指定された走行区域に含まれる1または2以上のノードまたは道路(リンク)を仮想経由地V1、V2として設定するとともに、タクシーの現在位置を目的地Gとして設定したうえで、道路毎のタクシー需要を探索コストに反映させて、経路探索を行う。この場合、経路探索部132cは、仮想経由地V1、V2を走行区域内でランダムに設定してもよい。これにより、特定の巡回経路だけに車両が集中することを防ぐことができる。
目的地指定受付部132gは、ユーザが端末装置2の端末入力部24を介して所定の目的地を指定し、指定された目的地の情報が端末装置2からサーバ3へと送信されると、当該目的地の指定を受け付ける。目的地指定受付部132gが目的地の指定を受け付けると、経路探索部132cは、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する。この場合、経路探索部132cは、指定された目的地まで走行中のタクシーが当該目的地またはその近くに到達したときに、タクシー需要が予め定められた第1閾値より高い高需要スポットが、当該タクシーの近くにあるか否
かを判定し、高需要スポットが近くにある場合には、指定された目的地を当該高需要スポットに変更し、当該高需要スポットまでの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索してもよい。
スコア算出部132hは、経路探索部132cにより抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出する。スコア算出部132hは、経路のバリエーションが出るよう(複数の経路同士の走行ルートや方面が異なるよう)、複数の経路同士の走行ルートや方面が類似する場合には、当該複数の経路のスコアを類似の割合に応じて下げてもよい。スコア算出部132hにより経路毎のスコアが算出されると、表示制御部132dは、経路探索部132cにより抽出された複数の経路を、スコア算出部132hにより算出された各経路のスコアとともに、端末装置2の端末表示部25に表示させる(たとえば図23参照)。図示は省略するが、表示制御部132dは、走行ルートの選択をしやすくするため、経路探索部132cにより抽出された複数の経路を地図上に表示の上、経路の概要を示す名称とともにスコアを表示(たとえば、「湾岸回りコース:90点」など)してもよい。
一例として、スコア算出部132hは、経路探索部132cにより抽出された複数の経路の各々について、たとえば走行中のタクシーの位置情報をマッチングさせることにより、当該経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第2閾値を超えた場合には、当該経路のスコアを下げてもよい。別の一例として、スコア算出部132hは、各タクシーの端末装置2からサーバ103へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定し、推定したタクシーの数が予め定められた第2閾値を超えた場合には、当該経路のスコアを下げてもよい。更に別の一例として、スコア算出部132hは、経路の提示実績数に応じてスコアを下げてもよい。すなわち、スコア算出部132hは、経路の提示実績数が予め定められた第3閾値を超えた場合には(第3閾値を超える回数、当該経路が提示されたら)、当該経路のスコアを下げてもよい。これらにより、特定の経路だけに車両が集中することを防ぐことができる。
(動作の第1の態様)
次に、図16および図17を参照して、第2の実施形態に係る情報処理システム101の動作の第1の態様について説明する。図16は、情報処理システム101の動作の第1の態様を示すフローチャートである。図17は、情報処理システム101の動作の第1の態様において表示される画面の一例を示す図である。
図16に示すように、まず、経路検索ログ取得部132aは、経路検索ログデータベース133cを参照して、所定の地域(たとえば法令で定められた営業区域)内に出発地または目的地が含まれる経路検索ログを取得する(ステップS110)。
次に、需要推定部132bは、地図情報データベース133bを参照して、経路検索ログ取得部132aにより取得された経路検索ログに含まれる出発地または目的地の位置情報を、地図上のスポットにマッチングさせる(ステップS111)。需要推定部32bは、乗車実績取得部32aにより取得された乗車実績情報のうち、検索条件または検索結果にタクシーの利用を含む経路検索ログに含まれる出発地または目的地の位置情報のみを、地図上の道路にマッチングさせてもよい。
次に、ユーザであるタクシードライバが、端末装置2の端末入力部24を介して所定の時間を指定すると、指定された時間の情報は端末装置2からサーバ103へと送信され、時間指定受付部132eは、当該時間の指定を受け付ける(ステップS112)。
そして、需要推定部132bは、ステップS111におけるマッチング結果を参照して、出発時刻または到着時刻が指定された時間に対応するスポット毎の検索回数のみを集計し、集計したスポット毎の検索回数と、スポットと道路との位置関係とに基づいて、道路毎のタクシー需要を推定する(ステップS113)。需要推定部132bは、道路毎の単位距離当たりの乗車実績数に基づいて、道路毎のタクシー需要を推定してもよい。また、ステップS111において、タクシーの利用ありの経路検索ログに含まれる出発地または目的地の位置情報のみを、地図上の道路にマッチングさせる場合には、需要推定部132bは、検索条件または検索結果にタクシーの利用を含む記経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。
ステップS111およびS113に関し、需要推定部132bは、検索条件として出発日時または到着日時に検索時点より未来の日時が指定された経路検索ログ(いわゆる事前経路検索ログ)のみに基づいて、道路毎のタクシー需要を推定してもよい。また、需要推定部132bは、終電検索(準終電検索を含む)または始発検索の経路検索ログのみに基づいて、道路毎のタクシー需要を推定してもよい。
次に、ユーザであるタクシードライバが、端末装置2の端末入力部24を介して所定の目的地を指定すると、指定された目的地の情報は端末装置2からサーバ103へと送信され、目的地指定受付部132gは、当該目的地の指定を受け付ける(ステップS114)。
そして、経路探索部132cは、需要推定部132bにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する(ステップS115)。なお、「道路毎のタクシー需要を探索コストに反映させ」るとは、従来の経路探索では、たとえば時間、金銭および走りやすさをコスト係数として道路毎のコストを計算していたのに対し、時間、金銭および走りやすさに加えて、タクシー需要もコスト係数に含めて道路毎のコストを計算することを意味する。
次に、表示制御部132dは、地図情報データベース133bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、経路探索部132cにより抽出された経路の少なくとも1つを、端末表示部25に出力される地図上に重ねて表示させる(ステップS116)。図17に示すように、表示制御部132dは、経路探索部132cにより抽出された経路Rを、地図上に矢印で表示させてもよい。また、表示制御部132dは、端末装置2から取得される測位情報(タクシーの現在の位置情報)Aを、地図上に重ねて表示させてもよい。
また、表示制御部132dは、需要推定部132bにより推定された道路毎のタクシー需要情報を、端末表示部125に出力される地図上に重ねて表示させる(ステップS117)。図17に示すように、表示制御部132dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これにより、ユーザ(すなわちタクシードライバ)は、タクシー需要が高い道路を一目で直感的に把握できるようになる。
図17に示すように、表示制御部132dは、検索回数が比較的多く、高いタクシー需要が見込まれるスポット(A駅およびB駅)の情報を、その検索回数および/または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部25に表示させてもよい。
ところで、発明が解決しようとする課題の欄でも言及したように、従来のタクシーの需
要予測技術では、携帯端末の位置情報を利用してエリア毎のタクシー需要を予測するため、ユーザであるタクシードライバは、タクシー需要が高いエリアは分かるものの、そのエリア内で実際にどの道路を走行すれば高い営業効率が得られるのかまでは分からなかった。
これに対し、本実施の形態によれば、経路検索ログ取得部132aが、経路検索アプリや経路検索Webサービスにより得られる経路検索ログを取得し、需要推定部132bが、経路検索ログに含まれる出発地または目的地の位置情報を地図上のスポットにマッチングさせ、スポット毎の検索回数と、スポットと道路との位置関係とに基づいて、道路毎のタクシー需要を推定し、経路探索部132cが、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い経路を優先的に探索するため、タクシーの走行経路に関し、営業効率が高い経路を探索することが可能となる。これにより、ユーザであるタクシードライバは、実際にどの道路を走行すれば高い営業効率が得られるのかが分かるようになり、営業効率を高めることができる。
(動作の第2の態様)
第2の実施形態に係る情報処理システム1の動作の第2の態様について、図18および図19を参照して説明する。図18は、第情報処理システム101の動作の第2の態様を示すフローチャートである。図19は、情報処理システム101の動作の第2の態様において表示される画面の一例を示す図である。第2の態様において、需要推定部132bが道路毎のタクシー需要を推定する工程まで(ステップS110~S113)は、上述した第1の態様と同様であり、説明を省略する。
図18に示すように、第2の態様では、需要推定部132bが道路毎のタクシー需要を推定した後(ステップS113の後)、ユーザであるタクシードライバが、端末装置2の端末入力部24を介して所望の走行区域(たとえば、得意とするエリア)を指定すると、指定された走行区域の情報は端末装置2からサーバ103へと送信され、走行区域指定受付部132fは、当該走行区域の指定を受け付ける(ステップS124)。
そして、経路探索部132cは、需要推定部132bにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された走行区域内で周遊する経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する(ステップS125)。図19に示す例では、経路探索部132cは、経路探索条件として、地図情報データベース33bを参照して、指定された走行区域に含まれる複数(図示された例では2つ)のノードを仮想経由地V1、V2として設定するとともに、タクシーの現在位置を目的地Gとして設定したうえで、道路毎のタクシー需要を探索コストに反映させ、道路単位当たりのタクシー需要が高い経路を優先的に探索する。
次に、表示制御部132dは、地図情報データベース133bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、経路探索部132cにより抽出された経路の少なくとも1つを、端末表示部25に出力される地図上に重ねて表示させる(ステップS126)。図19に示すように、表示制御部132dは、経路探索部132cにより抽出された経路Rを、地図上に矢印で表示させてもよい。また、表示制御部132dは、端末装置2から取得される測位情報(タクシーの現在の位置情報)Aを、地図上に重ねて表示させてもよい。
また、表示制御部132dは、需要推定部132bにより推定された道路毎のタクシー需要情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS27)。図19に示すように、表示制御部132dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよいし、太さを変えて表示させてもよい。これに
より、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。
図19に示すように、表示制御部132dは、検索回数が比較的多く、高いタクシー需要が見込まれるスポット(A駅およびB駅)の情報を、その検索回数および/または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部25に表示させてもよい。
以上のような第2の態様によれば、上述した第1の態様と同様の作用効果が得られることに加えて、ユーザであるタクシードライバは、ある目的地までの経路(一方向の経路)の代わりに、指定された走行区域内で周遊(巡回)する経路を探索することができ、空車での走行時間の短縮を図ることができる。
(動作の第3の態様)
第2の実施形態に係る情報処理システム101の動作の第3の態様について、図20および図21を参照して説明する。第3の態様は、指定された目的地まで走行中のタクシーが、当該目的地またはその近くに到達したときに情報処理システム101により行われる処理(オートリルート処理)に関する。図20は、情報処理システム101の動作の第3の態様を示すフローチャートである。図21は、情報処理システム101の動作の第3の態様において表示される画面の一例を示す図である。
まず、図20の上図を参照し、サーバ制御部132は、端末装置2から送信される測位情報に基づいて、指定された目的地Gまで走行中のタクシーの現在位置Aが、当該目的地Gまたはその近くに到達したか否かを判定する。そして、走行中のタクシーの現在位置Aが目的地Gまたはその近くに到達したと判定されると、サーバ制御部132は、予め定められた第1閾値より高いタクシー需要を有する高需要スポットPが、当該タクシーの現在位置Aの近くにあるか否かを判定する(ステップS131)。
そして、高需要スポットPがタクシーの現在位置Aの近くにあると判定された場合には(ステップS131:YES)、図20の下図を参照し、指定された目的地Gを当該高需要スポットPへと変更する(ステップS132)。
そして、経路探索部132cは、上述したステップS115と同様にして、需要推定部132bにより推定された道路毎のタクシー需要を探索コストに反映させ、指定された目的地G(すなわち高需要スポットP)までの経路であって、道路単位当たりのタクシー需要が高い経路を優先的に探索する(ステップS133)。
次に、表示制御部132dは、地図情報データベース133bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、経路探索部132cにより抽出された経路の少なくとも1つを、端末表示部25に出力される地図上に重ねて表示させる(ステップS134)。図21の下図に示すように、表示制御部132dは、経路探索部132cにより抽出された経路R2を、地図上に矢印で表示させてもよい。
また、表示制御部132dは、需要推定部132bにより推定された道路毎のタクシー需要情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS135)。図21に示すように、表示制御部132dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。
上述したステップS131~S135は、走行中のタクシーの現在位置Aが指定された
目的地Gまたはその近くに到達するたびに繰り返されてもよい。
以上のような第3の態様によれば、目的地Gまたはその近くに到達するたびに新たな走行経路が提示されるため、ユーザであるタクシードライバは、端末入力部24を操作して目的地を指定するためにタクシーをいちいち停車させる必要がなくなり、営業効率をさらに高めることができる。
(動作の第4の態様)
第2の実施形態に係る情報処理システム101の動作の第4の態様について、図22および図23を参照して説明する。図22は、情報処理システム101の動作の第4の態様を示すフローチャートである。図23は、情報処理システム101の動作の第4の態様において表示される画面の一例を示す図である。第4の態様において、経路探索部132cが道路単位当たりのタクシー需要が高い経路を優先的に探索する工程まで(ステップS110~S115)は、上述した第1の態様と同様であり、説明を省略する。
図22に示すように、第4の態様では、経路探索部132cが道路単位当たりのタクシー需要が高い経路を優先的に探索した後(ステップS115の後)、スコア算出部132hが、経路探索部132cにより抽出された複数の経路について、経路毎のタクシー需要に応じたスコアを算出する(ステップS133)。
次に、表示制御部132dは、図23の上図に示すように、経路探索部132cにより抽出された複数の経路を、スコア算出部132hにより算出された各経路のスコアとともに、端末装置2の端末表示部25に表示させる(ステップS134)。
次に、ユーザであるタクシードライバが、端末表示部25に表示された各経路のスコアを参照しながら、端末入力部24を介して1つの経路を選択すると、選択された経路の情報が端末装置2からサーバ103へと送信され、サーバ制御部132は、経路の選択を受け付ける(ステップS135)。
そして、表示制御部132dは、地図情報データベース133bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、ユーザにより選択された経路の情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS136)。
次いで、スコア算出部132hは、経路探索部132cにより抽出された複数の経路の各々について、当該経路を走行するタクシーの数を推定する。具体的には、たとえば、スコア算出部132hは、各タクシーの端末装置2からサーバ103へと送信される選択された経路の情報を集計することにより、各経路を走行するタクシーの数を推定する。あるいは、スコア算出部132hは、各タクシーの端末装置2からサーバ103へと送信される各タクシーの位置情報に基づいて、各経路を走行するタクシーの数を推定してもよい。図23の中央図に示すように、スコア算出部132h、推定された各経路を走行するタクシーの数を、スコア算出部132hにより算出された各経路のスコアとともに、端末装置2の端末表示部25に表示させてもよい。そして、スコア算出部132hは、各経路を走行するタクシーの数が、予め定められた第2閾値(たとえば、10台)を超えたか否かを判定する(ステップS137)。
各経路を走行するタクシーの数が第2閾値を超えた場合には(ステップS137:YES)、スコア算出部132hは、当該の経路のスコアを下げる(ステップS138)。図23に示す例では、ルート1を走行するタクシーの数(=12台)が第2閾値(=10台)を超えたことから、スコア算出部132hは、ルート1のスコアを「95」から「65
」へと下げている。これにより、ルート1の魅力が下がり、ルート1に車両がこれ以上集中することを防ぐことができる。
以上のような第4の態様によれば、ユーザであるタクシードライバが、端末表示部25に表示された各経路のスコアを参照しながら、端末入力部24を介して1つの経路を選択する際に、スコア算出部132hが、走行するタクシーの数が第2閾値を超えている経路についてはそのスコアを下げることで、当該経路の魅力を下げるため、ユーザであるタクシードライバは、走行するタクシーの数が第2閾値を超えている経路の選択を避けるようになる。これにより、各経路を走行するタクシーの数を自動的に分散させることが可能となり、事業者単位での営業効率を最大化することができる。
(動作の第5の態様)
第2の実施形態に係る情報処理システム101の動作の第5の態様について、図24および図25を参照して説明する。図24は、情報処理システム101の動作の第5の態様を示すフローチャートである。図25は、情報処理システム101の動作の第5の態様において表示される画面の一例を示す図である。第5の態様において、需要推定部132bが道路毎のタクシー需要を推定する工程まで(ステップS110~S113)は、上述した第1の態様と同様であり、説明を省略する。
図24に示すように、第5の態様では、需要推定部132bが道路毎のタクシー需要を推定した後(ステップS113の後)、表示制御部132dは、地図情報データベース133bを参照し、所定の地域(たとえば法令で定められた営業区域)の地図を、端末装置2の端末表示部25に表示させるとともに、需要推定部132bにより推定された道路毎のタクシー需要情報を、端末表示部25に出力される地図上に重ねて表示させる(ステップS117)。図25に示すように、表示制御部132dは、地図上の各道路を、タクシー需要情報の大きさに応じて色分けして表示させてもよい。これにより、ユーザであるタクシードライバは、タクシー需要が高い道路を一目で直感的に把握できるようになる。
また、表示制御部132dは、図25に示すように、検索回数が比較的多く、高いタクシー需要が見込まれるスポット(A駅およびB駅)の情報を、その検索回数および/または平常時の検索回数との比較情報とともに、地図上に重ねて端末表示部25に表示させてもよい。
図25に示すように、表示制御部132dは、所定の地域の地図に隣接して、時間帯を選択(ないし変更)するためのスライドバー51を、端末表示部25に表示させてもよい。
次に、ユーザであるタクシードライバが、端末入力部24を介してスライドバー51を操作して新たな時間を指定すると、指定された時間の情報は端末装置2からサーバ103へと送信される。時間指定受付部132eは、新たに指定された時間の情報が端末装置2からサーバ103へと送信されたか否かに応じて、時間の変更があるか否かを判定する(ステップS118)。
そして、時間の変更があると判定された場合には(ステップS118:YES)、時間指定受付部132eは、新たに指定された時間の指定を受け付け(ステップS112)、新たに指定された時間についてステップS113~S117の処理を繰り返す。
以上のような第5の態様によれば、ユーザであるタクシードライバは、端末表示部25に表示される道路毎のタクシー需要情報を、時間別に容易に切り替えて比較したり、道路毎のタクシー需要の時間変化を把握したりすることが可能となり、営業効率の高い経路の
分析にこれを役立てることができる。
なお、上述した実施形態で説明した情報処理システム1の少なくとも一部は、ハードウェアで構成してもよいし、ソフトウェアで構成してもよい。ハードウェアで構成する場合には、情報処理システム1の少なくとも一部の機能を実現するプログラムをフレキシブルディスクやCD-ROM等の記録媒体に収納し、コンピュータに読み込ませて実行させてもよい。記録媒体は、磁気ディスクや光ディスク等の着脱可能なものに限定されず、ハードディスク装置やメモリなどの固定型の記録媒体でもよい。
また、情報処理システム1の少なくとも一部の機能を実現するプログラムを、インターネット等の通信回線(無線通信も含む)を介して頒布してもよい。さらに、同プログラムを暗号化したり、変調をかけたり、圧縮した状態で、インターネット等の有線回線や無線回線を介して、あるいは記録媒体に収納して頒布してもよい。
さらに、一つまたは複数の情報処理装置によって情報処理システム1を機能させてもよい。複数の情報処理装置を用いる場合、情報処理装置のうちの1つをコンピュータとし、当該コンピュータが所定のプログラムを実行することにより情報処理システム1の少なくとも1つの手段として機能が実現されてもよい。
また、方法の発明においては、全ての工程(ステップ)をコンピュータによって自動制御で実現するようにしてもよい。また、各工程をコンピュータに実施させながら、工程間の進行制御を人の手によって実施するようにしてもよい。また、さらには、全工程のうちの少なくとも一部を人の手によって実施するようにしてもよい。
上記の記載に基づいて、当業者であれば、本発明の追加の効果や様々の変形を想到できるかもしれないが、本発明の態様は、上述した個々の実施形態に限定されるものではない。特許請求の範囲に規定された内容およびその均等物から導き出される本発明の概念的な思想と趣旨を逸脱しない範囲で種々の追加、変更および部分的削除が可能である。