JP4548167B2 - 混雑状況案内装置 - Google Patents

Description

本発明は、テーマパークのアトラクションの待ち時間など、施設の混雑状況を案内する混雑状況案内装置に関し、特に、施設の未来の混雑状況を予測する混雑状況案内装置に関する。

近年、テーマパークのアトラクションなど、施設の待ち時間を利用者に案内するサービスが実現されてきた。特許文献１には、テーマパークのアトラクションや飲食店などの施設の待ち状況を状況案内サーバに格納しておく事、携帯電話機などの端末から要求を受け、施設の待ち状況を利用者に提供する事が記載されている。更に、特許文献１には、状況案内サーバに、待ち状況の更新履歴を格納しておき、更新履歴に基づいて、時間帯や曜日毎の施設の利用状況を分析し、その分析状況を利用者に提供する事が記載されている。

つまり、特許文献１の利用者は、端末を利用して、状況案内サーバから施設の現在の混雑状況や未来の混雑状況を取得する事が出来る。そして、利用者は、このようにして取得した混雑状況を参考にする事で、時間を無駄に過ごさないような行動を選択する事が出来る。例えば、利用者は、施設の利用に先立って、その施設の現在の混雑状況や未来の混雑状況を状況案内サーバから取得し、取得した混雑状況に応じて、その施設を利用するかどうか、施設を何時頃利用するか、などを決定する事が出来る。
特開２００３−２２３４２号公報

このように、利用者に提供される施設の現在や未来における混雑状況は、多くの利用者にとって、施設を利用するかどうか、施設を何時頃利用するか、などといった行動を決定する一助となっている。

そして、多くの利用者は、このような現在の混雑状況や未来の混雑状況の予想を参考にして、混雑していると予想される時間帯には施設の利用をやめておき、混雑していないと予想される時間帯に施設の利用をするように判断する。

しかしながら、特許文献１に開示されている技術では、過去の混雑状況のみに基づいて未来の混雑状況を分析し、分析した結果を、複数の利用者に同じように提供するため、多くの利用者が、その結果を参考とすればするほど、その予想精度が失われてしまう可能性がある。

例えば、ある時間帯では、過去の混雑状況に照らして、とても混雑していると予想される場合、その予想を見た利用者の多くは、その時間帯にその施設を利用しないように判断する。しかしながら、このような予想を参考にして、多くの利用者が同じような判断をした場合、未来の混雑状況の予想に反して、現実にはこの時間帯の利用者は減少する事になり、混雑しなかったという事になる。また、逆に、ある時間帯では、過去の混雑状況に照らして、混雑していないと予想される場合、その予想を見た多くの利用者は、その時間帯にその施設を利用しようと判断する。しかしながら、多くの利用者がこのような予想を参考にして、このような判断をした場合、未来の混雑状況の予想に反して、現実には、この時間帯の利用者は増加する事になり、混雑してしまったという事になる。

このように、未来の混雑状況を多くの利用者に提供すると、それを参考にした利用者の多くは、同じような行動をとってしまう可能性がある。従って、予想された混雑状況と実際の混雑状況とが相反するものとなる可能性があり、混雑状況の予想の精度が低下してしまう。

本発明は、このような課題に鑑みなされたものであって、過去の混雑状況だけでなく、施設を利用しようと考えている利用者の数、即ち施設の混雑状況に関心を示す利用者の数、の変動に応じて、未来の混雑状況をリアルタイムに予想していく事で、混雑状況の予想精度をより高める事の出来る混雑状況案内装置を提供することを目的とする。

上記課題を解決する為に、本発明では、施設を利用しようと考えている利用者の数の変動に応じて、未来の混雑状況をリアルタイムに予想出来れば、混雑状況の予想精度をより高める事が出来る事に着目した。

即ち、本発明の混雑状況案内装置は、条件毎に、過去の履歴に基づいて設定された混雑状況、及び問い合わせ回数を記憶する履歴記憶部と、前記条件の指定を含む未来の混雑状況の予想要求を受け付け、当該予想要求を受け付けた回数を計数する要求受付部と、前記要求受付部で受け付けた前記条件に対応する混雑状況及び問い合わせ回数を前記履歴記憶部から取得する履歴検索部と、前記要求受付部で計数した予想要求の前記回数、前記履歴検索部で取得した前記混雑状況及び問い合わせ回数に基づいて、前記未来の混雑状況を算出する混雑状況算出部と、を備える事を特徴とする。

本発明は、上述のように、利用者に未来の待ち時間を提供する毎に問合せ数は増大していく事になる。従って、予想する未来の待ち時間もそれに比例して増大していく事になる。即ち、問合せ数の少ない時期に未来の待ち時間を提供された利用者は、小さい数値の未来の待ち時間が提供される。従って、この利用者は、問い合わせした条件で施設の利用をする可能性が高い。一方、問合せ数の多い時期に未来の待ち時間を提供された利用者は、大きい数値の未来の待ち時間が提供される。従って、この利用者は、問い合わせをした条件で施設の利用をする可能性が低い。

このように、本発明の混雑状況案内装置では、問合せ数の少ない時期に問い合わせした利用者には、未来の待ち時間を少なく見せ、その利用者の利用を積極的にさせ、問合せ数の多い時期に問い合わせをした利用者には、未来の待ち時間を大きく見せ、その利用者の利用を消極的にさせる効果を奏する。つまり、未来の待ち時間を参考とする利用者を誘導するように未来の待ち時間をフレックスに変動させるため、混雑状況の予想をより信頼出来るものとする事が出来る。

本発明の混雑状況案内装置では、問合せ数の少ない時期に問い合わせした利用者には、未来の待ち時間を少なく見せ、その利用者の利用を積極的にさせ、問合せ数の多い時期に問い合わせをした利用者には、未来の待ち時間を大きく見せ、その利用者の利用を消極的にさせる効果を奏する。つまり、未来の待ち時間を参考とする利用者を誘導するように未来の待ち時間をフレックスに変動させるため、混雑状況の予想をより信頼出来るものとする事が出来る。

以下、本発明の実施例を図面に基づいて説明する。

本発明の実施例に係る混雑状況案内装置の処理態様を、図１乃至図９を用いて説明する。

図１は、本発明の実施例による、インターネット網、電話回線網及びＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等で実現されるネットワーク４を介して相互接続された混雑状況案内装置２及び携帯端末３からなる混雑状況案内システム１の構成を示している。

混雑状況案内装置２は、図２に示すように、ＣＰＵ、ＲＡＭ、ＲＯＭ、磁気記憶装置、及び各種インタフェースなどによって構成されている。磁気記憶装置には、図３に示すような問合せデータベース２−１、履歴データベース２−２、待ち時間通知要求受信部２−３、問合せ数更新部２−４、履歴検索部２−５、待ち時間算出部２−６、及び待ち時間通知部２−７がインストールされている。これらのプログラム及びデータベースは、必要に応じてＲＡＭにロードされ、ＣＰＵによって実行される。混雑状況案内装置２として、サーバコンピュータ、ワークステーション、パーソナルコンピュータなどの情報処理装置が用いられる。

本実施例の混雑状況案内装置２は、図３に示すように、問合せデータベース２−１、履歴データベース２−２、待ち時間通知要求受信部２−３、問合せ数更新部２−４、履歴検索部２−５、待ち時間算出部２−６、及び待ち時間通知部２−７で構成されている。

問合せデータベース２−１は、施設、日付、時間帯毎に、待ち時間を問い合わせられた回数（以下、問合せ回数として説明する。）を記憶するものである。

履歴データベース２−２は、施設、日付、時間帯毎に、過去の待ち時間の実績値（以下、過去の待ち時間として説明する。）、及び過去の待ち時間を問い合わせられた回数の実績値（以下、過去の問合せ回数として説明する）を記憶するものである。

待ち時間通知要求受信部２−３は、後述する携帯端末３から、利用施設、利用日付、利用時間帯を含む待ち時間通知要求を受信し、後述する問合せ数更新部２−４を起動するものである。

問合せ数更新部２−４は、待ち時間通知要求受信部２−３で受信した待ち時間通知要求に含まれる利用施設、利用日付、利用時間帯に対応する問合せ回数を問合せデータベース２−１から取得し、取得した問合せ回数を１カウントして更新するものである。

履歴検索部２−５は、待ち時間通知要求受信部２−３で受信した待ち時間通知要求に含まれる利用施設、利用日付、利用時間帯に対応する過去の待ち時間及び過去の問合せ回数を履歴データベース２−２から取得するものである。

待ち時間算出部２−６は、問合せ数更新部２−４で１カウントした問合せ回数、及び、履歴検索部２−５で取得した過去の待ち時間と過去の問合せ回数に基づいて、利用者の所望する利用施設、利用日付、利用時間帯の未来の待ち時間を算出する。

待ち時間通知部２−７は、待ち時間算出部２−６で算出した未来の待ち時間を、後述する携帯端末３に送信するものである。

携帯端末３は、混雑状況案内装置２と同様に、図２に示すように、ＣＰＵ、ＲＡＭ、ＲＯＭ、磁気記憶装置、各種インタフェース、ディスプレイ装置、及びマウス、キーボードなどによって構成されている。本実施例では、図２の通信インタフェースが図４に示す接続部３−３に相当し、図２のディスプレイ装置が図４に示す表示部３−１に相当し、図２のマウス、キーボードが図４に示す入力部３−２に相当する。また、磁気記憶装置には、図４に示す処理部３−４などの機能を実現するためのプログラムがインストールされている。これらのプログラムは、必要に応じてＲＡＭにロードされ、ＣＰＵによって実行される。携帯端末３として、ノート型のパーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、携帯電話機など、持ち運びに便利なものが用いられる。また、接続部３−３は、有線、無線を問わずネットワーク４と接続される。

携帯端末３は、図４に示すように、表示部３−１、入力部３−２、接続部３−３及び処理部３−４で構成されている。

表示部３−１は、公知のディスプレイ装置などの事であり、データの表示をする表示装置である。

入力部３−２は、公知のマウスやキーボードなどの事であり、データの入力に用いられる入力装置である。

接続部３−３は、公知のＬＡＮインタフェースカードなどの事であり、ネットワーク４とのデータの送受信に用いられる通信インタフェースである。

処理部３−４は、接続部３−３でネットワーク４を介して混雑状況案内装置２から受信したデータを表示するように表示部３−１に指示したり、入力部３−２で入力されたデータを、ネットワーク４を介して混雑状況案内装置２に送信するように接続部３−３に指示したりするものである。

次に、ある施設の未来の待ち時間を、利用者に提供する際の処理について説明をする。

本実施例では、ある利用者が、携帯端末３を利用して、利用者の所望する日付、時間帯におけるテーマパーク「フジツウランド」のアトラクション「アトラクションＡ」の待ち時間を取得する手順について説明をする。

図５は、本実施例における混雑状況案内システム１の処理をフローチャートで示したものである。

まず、利用者は、携帯端末３を混雑状況案内装置２に接続する。すると、混雑状況案内装置２の待ち時間通知要求受信部２−３が起動される。待ち時間通知要求受信部２−３は、起動されると、図６（ａ）乃至（ｃ）に例示する条件入力画面を表示出来るような情報を携帯端末３に送信する（Ｓ５−１）。

携帯端末３では、接続部３−３で、条件入力画面を表示出来るような情報を混雑状況案内装置２から受信すると、処理部３−４が起動される。処理部３−４は、混雑状況案内装置２から条件入力画面を表示できるような情報を受信すると、まず、図６（ａ）に例示するような利用日付選択画面を表示部３−１に表示するように指示をする。

利用者は、携帯端末３の入力部３−２を利用して、図６（ａ）に例示する利用日付選択画面に含まれるカレンダから所望する利用日付を選択する。本実施例では、２月１８日が選択されたものとして以下説明をする。

利用日付が選択されると、処理部３−４は、表示部３−１に図６（ｂ）に例示するような利用施設選択画面を表示するように指示をする。

利用者は、携帯端末３の入力部３−２を利用して、図６（ｂ）に例示する利用施設選択画面から所望するアトラクションを選択する。本実施例では、アトラクションＡが選択されたものとして以下説明をする。

利用施設が選択されると、処理部３−４は、表示部３−１に図６（ｃ）に例示するような利用時間帯選択画面を表示するように指示をする。

利用者は、携帯端末３の入力部３−２を利用して、図６（ｃ）に例示する利用時間帯選択画面から所望する時間帯を選択する。本実施例では、１１：００から１２：００が選択されたものとして以下説明をする。

本実施例では、携帯端末３は、フジツウランド専用の混雑状況案内装置２に接続するように説明している。しかしながら、混雑状況案内装置２は、複数のテーマパークの混雑状況を管理するように構成しても良い。このように構成した場合、表示部３−１に、図６（b）に例示する利用施設選択画面を表示させる前に、複数のテーマパークの一覧画面を表示させ、そのテーマパークの中から所望するものを選択させる画面を表示させるようにしても良い。また、この場合、混雑状況案内装置２の問合せデータベース２−１及び履歴データベース２−２は、上述の構成例に加え、テーマパーク毎に情報を格納する事になる。

本実施例では、上述のように、利用施設、利用日付、及び利用時間帯の入力がなされると、処理部３−４は、入力された利用施設、利用日付及び利用時間帯を含む待ち時間通知要求を混雑状況案内装置２に送信するように、接続部３−３に指示をする（Ｓ５−２）。

待ち時間通知要求受信部２−３は、携帯端末３から利用施設、利用日付、及び利用時間帯を含む待ち時間通知要求を受信すると、問合せ数更新部２−４を起動する。問合せ数更新部２−４は、起動されると、待ち時間通知要求受信部２−３で受信した待ち時間通知要求に含まれる利用施設、利用日付、及び利用時間帯に対応する問合せ数を問合せデータベース２−１から取得する（Ｓ５−３）。

ここで、図７に問合せデータベース２−１の構成例を示す。

図７に例示する問合せデータベース２−１は、利用施設フィールド、利用日付フィールド、利用時間帯フィールド、及び問合せ数フィールドで構成されている。

利用施設フィールドは、アトラクションなどの施設名を記憶するフィールドである。

利用日付フィールドは、利用施設フィールドに記憶された施設の利用日付を記憶するフィールドである。

利用時間帯フィールドは、利用施設フィールドに記憶された施設の利用時間帯を記憶するフィールドである。

問合せ数フィールドは、施設の利用日付、利用時間帯に対して、待ち時間通知要求がされた数、つまり問合せ数を記憶するフィールドである。

例えば、図７では、利用施設「アトラクションＡ」の「２月１８日」の「０９：００−１０：００」の待ち時間について、「３０００」件の問い合わせがあった事を示している。

同様に、利用施設「アトラクションＢ」の「２月１８日」の「０９：００−１０：００」の待ち時間について、「１０」件の問い合わせがあった事を示している。

本実施例では、図６に例示するように、利用施設「アトラクションＡ」、利用日付「２月１８日」、利用時間帯「１１：００−１２：００」で利用者は待ち時間通知要求をした。従って、問合せ数更新部２−４は、図７に例示する問合せデータベース２−１を参照し、問合せ数「８０００」を取得する事になる。

問合せ数更新部２−４は、問合せデータベース２−１から問合せ数を取得すると、取得した問合せ数を１カウントして、問合せデータベース２−１を更新する（Ｓ５−４）。

本実施例では、問合せ数は、「８０００」であったため、１カウントすると、「８００１」となり、利用施設「アトラクションＡ」、利用日付「２月１８日」、利用時間帯「１１：００−１２：００」の問合せ数を「８００１」に変更して、問合せデータベース２−１を更新する事になる。

問合せ数更新部２−４で問合せ数を１カウントして問合せデータベース２−１を更新すると、履歴検索部２−５が起動される。

履歴検索部２−５は、起動されると、履歴データベース２−２を参照して、待ち時間通知要求受信部２−３で受信した待ち時間通知要求に含まれる利用施設、利用日付、利用時間帯に対応する過去の待ち時間、及び過去の問合せ数を取得する（Ｓ５−５）。

ここで、図８に履歴データベース２−２の構成例を示す。

図８に例示する履歴データベース２−２は、利用施設フィールド、利用時間帯フィールド、平均待ち時間フィールド及び平均問合せ数フィールドで構成されている。

利用施設フィールドは、アトラクションなどの施設名を記憶するフィールドである。

利用時間帯フィールドは、利用施設フィールドに記憶された施設の利用時間帯を記憶するフィールドである。

平均待ち時間フィールドは、利用施設フィールドに記憶された施設、及び利用時間帯フィールドに記憶された利用時間帯に、過去、どれだけ待ち時間があったのか、過去の待ち時間の平均値を記憶するフィールドである。

平均問合せ数フィールドは、利用施設フィールドに記憶された施設、及び利用時間帯フィールドに記憶された利用時間帯に、過去、どれだけ問い合わせがあったのか、過去の問合せ数の平均値を記憶するフィールドである。

本実施例では、平均待ち時間フィールド、及び平均問合せフィールドに記憶される情報は、一律に定められているように説明しているが、例えば、曜日毎、日毎、月毎、年毎の平均値によって定められるようにしても構わない。また、天候、休日、週末、連休、季節といった日の属性に応じて定めても構わない。要するに、過去の待ち時間の実績値（履歴）に基づいて予測した未来の待ち時間を予め記憶しておくものであればどのように構成しても構わない。

例えば、図８では、利用施設「アトラクションＡ」の時間帯「０９：００−１０：００」における平均待ち時間及び平均問合せ数は、過去の実績によると、夫々、「４０」分、「１０００」件である事が分かる。これは、「アトラクションＡ」の「０９：００−１０：００」は、過去の履歴から大体「４０」分の待ち時間があり、その利用時間帯における待ち時間予測の問い合わせは、大体「１０００」件である事を意味する。同様に、施設名「アトラクションＢ」の時間帯「１５：００−１６：００」における平均待ち時間及び平均問合せ数は、過去の実績によると、夫々、「５」分、「１０」件である事が分かる。このように、履歴データベース２−２には、アトラクションの待ち時間や問合せ数の過去の実績値が記憶されている。ここで、上述のように、この過去の待ち時間及び過去の問合せ数を天候や季節などのような日付の属性毎に設定しても良い。

本実施例では、図６に例示するように、利用施設「アトラクションＡ」、利用日付「２月１８日」、利用時間帯「１１：００−１２：００」で利用者により待ち時間通知要求がされた。従って、履歴検索部２−５は、図８に例示するような履歴データベース２−２を参照して、過去の待ち時間として、「１００」分を、過去の問合せ数として「３０００」件を取得する事になる。そして、履歴検索部２−５は、過去の待ち時間及び過去の問合せ数を取得すると、待ち時間算出部２−６を起動する。

待ち時間算出部２−６は、起動されると、問合せ数更新部２−４で１カウントした問合せ数と過去の問合せ数に基づいて、問合せポイントを算出する（Ｓ５−６）。

ここで、問合せポイントとは、利用者により選択された利用施設、利用日付及び利用時間帯について、現在までに問い合わせられた問合せ数と過去に問い合わされた問合せ数との比率を示すものである。つまり、利用者により選択された利用施設、利用日付及び利用時間帯について、過去の履歴に比してどれくらい興味をもたれているか示すものである。具体的には、１カウントした問合せ数を過去の問合せ数で除算した解の事である。

本実施例では、１カウントした問合せ数は、「８００１」であり、過去の問合せ数は、「３０００」であった。従って、それらを除算した解は、「２．６６７」となる。つまり、問合せポイントは「２．６６７」である。このように、「２月１８日」の「１１：００−１２：００」における「アトラクションＡ」に対する問い合わせは、過去の履歴の「２．６６７」倍であり、過去に比して、それだけ多数の利用者に興味をもたれている事が分かる。

待ち時間算出部２−６は、問合せポイントを算出すると、算出した問合せポイントに基づいて未来の待ち時間を算出する（Ｓ５−７）。

未来の待ち時間とは、待ち時間通知要求受信部２−３で取得した待ち時間通知要求に含まれる利用施設、利用日付及び利用時間帯における待ち時間を予想したものである。

本実施例では、履歴検索部２−５で取得した過去の待ち時間と算出した問合せポイントとの積を未来の待ち時間として算出する。つまり、本実施例では、「１００」分と「２．６６７」の積の解、即ち、未来の待ち時間は、「２６６．７」分となる。つまり、過去の待ち時間の実績値の「２．６６７」倍の待ち時間であると予想する。

待ち時間算出部２−６において、未来の待ち時間を算出すると、待ち時間通知部２−７が起動され、算出した未来の待ち時間を携帯端末３に送信する（Ｓ５−８）。

携帯端末３の接続部３−３で未来の待ち時間を受信すると、処理部３−４は、図９に例示するような待ち時間表示画面を表示するように、表示部３−１に指示をする（Ｓ５−９）。

このように、本実施例では、利用施設、利用日付及び利用時間帯に対する現在や過去の問い合わせ数に応じて、未来の待ち時間を算出している。例えば本実施例では、上述のように、利用施設「アトラクションＡ」、利用日付「２月１８日」、利用時間帯「１１：００−１２：００」について、問合せ数が「３０００」の時点で待ち時間通知要求を受信した場合、未来の待ち時間を「２６６．７」分と予想した。一方、例えば、問合せ数が「２９９」の時点で上述の待ち時間通知要求を受信した場合では、未来の待ち時間を「１０」分と予想する事になる。つまり、本実施例の混雑状況案内装置２は、待ち時間通知要求を受信した時点における問合せ数に応じて、異なる予想をする。

このように、本実施例の混雑状況案内装置２では、利用者に未来の待ち時間を提供する毎に問合せ数は増大していく事になる。従って、予想する未来の待ち時間もそれに比例して増大していく事になる。即ち、問合せ数の少ない時期に未来の待ち時間を提供された利用者は、小さい数値の未来の待ち時間が提供される。従って、この利用者は、問い合わせした条件で施設の利用をする可能性が高い。一方、問合せ数の多い時期に未来の待ち時間を提供された利用者は、大きい数値の未来の待ち時間が提供される。従って、この利用者は、問い合わせをした条件で施設の利用をする可能性が低い。

このように、本実施例では、問合せ数の少ない時期に問い合わせした利用者には、未来の待ち時間を少なく見せ、その利用者の利用を積極的にさせ、問合せ数の多い時期に問い合わせをした利用者には、未来の待ち時間を大きく見せ、その利用者の利用を消極的にさせる効果を奏する。つまり、未来の待ち時間を参考とする利用者を誘導するように未来の待ち時間をフレックスに変動させるため、混雑状況の予想をより信頼出来るものにする。

また、問合せ数の少ない時期に未来の待ち時間を算出した場合、算出した未来の待ち時間の方が過去の待ち時間より小さければ、過去の待ち時間の方を利用者に提示するように構成しても良い。例えば、上述のように、未来の待ち時間を「１０」分と予想した場合、過去の待ち時間「１００」分の方が大きくなる。そこで、過去の待ち時間「１００」分を利用者に未来の待ち時間として提供する。これは、利用者による問い合わせ時点では予想される待ち時間は少ないが、時間の経過と共に、待ち時間が増大する事を考慮したものであり、このような構成とする事で、初期に問い合わせをした利用者にも適切な未来の待ち時間を提供する事が出来る。

また、利用者により選択された利用時間帯についての未来の待ち時間だけを利用者に提供するのでなく、その利用時間帯近辺の時間帯についても利用者に提供するようにしても良い。例えば、本実施例では、利用者により利用時間帯として、「１１：００−１２：００」が選択されていた。この場合、その近辺の時間帯、即ち「１０：００−１１：００」及び「１２：００−１３：００」の未来の待ち時間についても算出し、利用者に提供するように構成しても良い。また、このようにした場合、「１０：００−１１：００」及び「１２：００−１３：００」の時間帯については、間接的に問い合わせされたと判断する事が出来る。そこで、図７に例示した問合せデータベース２−１に間接問合せ数フィールドを追加し、間接的に問い合わせられた回数を格納するようにしても良い。そして、この間接問合せ数を考慮した上で、問合せポイントを算出するようにしても良い。例えば、予め間接問合せ数の重みを定めておき、その重みと間接問合せ数の積と問合せ数との和を問合せ数とみなすようにする。本実施例では、「１１：００−１２：００」の時間帯における間接問合せ数は、「１０：００−１１：００」及び「１２：００−１３：００」の問合せ数の和と等しい。なぜなら、「１０：００−１１：００」に問い合わせがなされた場合には、「１１：００−１２：００」を間接的に問い合わせ、「１２：００−１３：００」に問い合わせがなされた場合には、「１１：００−１２：００」を間接的に問い合わせるからである。ここで、「１１：００−１２：００」における間接問合せ数は、「１１０００」である。重みが「０．１」と予め定められていたとすれば、問合せ数は、「１１０００」＊「０．１」＋「８０００」の解となり、「９１００」となる。また、履歴データベース２−２に格納される平均問合せ数もこの数値を記憶するようにしておけば、上述のように、問合せポイントから未来の待ち時間を算出する事が出来る。例えば、図８の平均問合せ数が過去の間接問合せ数を考慮したものであったとすると、「９１００」と「３０００」の商は、「３．０３３」となり、未来の待ち時間を「３０３．３」分と予想する事になる。

次に、問合せデータベース２−１と履歴データベース２−２の更新タイミングについて簡単に説明をする。

混雑状況案内装置２では、図示しないが、本日日付が変更される度に、問合せデータベース２−１の利用日付フィールドから本日日付以前のレコードを検索し、検索したレコードの利用施設、利用時間帯毎の問合せ数を履歴データベース２−２の平均問合せ数に反映させて、当該検索した問合せデータベース２−１のレコードを削除する。

一方、履歴データベース２−２の平均待ち時間は、例えば施設の従業員により適宜入力された実績値に基づいて更新されるようになっている。

履歴データベースの平均待ち時間の更新方法については、公知である為、説明は省略する。

このように、本実施例における混雑状況案内装置２では、施設への問い合わせ数と過去の問い合わせ数の履歴に基づいて問合せポイントを算出し、問合せポイントと過去の待ち時間の履歴に基づいて未来の待ち時間を算出する。つまり、本実施例における混雑状況案内装置２では、問い合わせされた時点で、問い合わせられた日付、時間帯における施設の利用が、過去に比してどれだけ多くの利用者に興味をもたれているのかを考慮して待ち時間を算出している。従って、より正確な待ち時間を利用者に提示する事が出来る。

従来の混雑状況案内装置では、過去の実績だけに基づいて設定した待ち時間を、多くの利用者に対して同一の情報として提供していた。例えば、過去の履歴に基づいて、「１００」分という待ち時間を設定されていれば、何時でも誰にでも「１００」分を未来の待ち時間として提供するようにしていた。従って、多くの利用者が提供された待ち時間に応じて同じような行動をすると、待ち時間の予想に反する結果となる可能性があった。

一方、本実施例における混雑状況案内装置２では、利用者からの問い合わせ数が増加すればするほど、予想する待ち時間は増大する。従って、提供される待ち時間の予想は、利用者の問い合わせる時期によって違うため、利用者は、提供された待ち時間に応じて行動をする事が出来る。

本発明の混雑状況案内システムの概要を示す図である。 本発明の混雑状況案内装置のハードウェア構成の例を示す図である。 本発明の混雑状況案内装置の構成例を示す図である。 本発明の携帯端末の構成例を示す図である。 本発明の施設の待ち状況を案内する処理のフローチャートである。 条件入力画面の表示例である。 問合せデータベースのレコード構成例を示す図である。 履歴データベースのレコード構成例を示す図である。 待ち時間表示画面の表示例を示す図である。

符号の説明

１ 混雑状況案内システム
２ 混雑状況案内装置
３ 携帯端末
４ ネットワーク

Claims (5)

1. 条件毎に、過去の履歴に基づいて設定された混雑状況、及び問い合わせ回数を記憶する履歴記憶部と、
   前記条件の指定を含む未来の混雑状況の予想要求を受け付け、当該予想要求を受け付けた回数を計数する要求受付部と、
   前記要求受付部で受け付けた前記条件に対応する混雑状況及び問い合わせ回数を前記履歴記憶部から取得する履歴検索部と、
   前記要求受付部で計数した予想要求の前記回数、前記履歴検索部で取得した前記混雑状況及び問い合わせ回数に基づいて、前記未来の混雑状況を算出する混雑状況算出部と、
   を備える事を特徴とする混雑状況案内装置。
2. 前記混雑状況算出部は、前記要求受付部で計数した前記予想要求の回数と前記履歴検索部で取得した問い合わせ回数との比率を算出し、当該比率と前記履歴検索部で取得した混雑状況に基づいて、未来の混雑状況を算出する事を特徴とする請求項１記載の混雑状況案内装置。
3. 前記混雑状況算出部は、前記算出した未来の混雑状況が、前記履歴検索部で取得した混雑状況より混雑していないと判断できる場合、当該履歴検索部で取得した混雑状況を未来の混雑状況とする事を特徴とする請求項１記載の混雑状況案内装置。
4. 条件の指定を含む未来の混雑状況の予想要求を受け付け、当該予想要求を受け付けた回数を計数するステップと、
   条件毎に、過去の履歴に基づいて設定された混雑状況、及び問い合わせ回数を記憶する履歴記憶部を検索して、前記受け付けた前記条件に対応する混雑状況及び問い合わせ回数を取得するステップと、
   前記計数した予想要求の前記回数、前記履歴検索部で取得した前記混雑状況及び問い合わせ回数に基づいて、前記未来の混雑状況を算出するステップと、
   を実行する事を特徴とする混雑状況案内方法。
5. 条件の指定を含む未来の混雑状況の予想要求を受け付け、当該予想要求を受け付けた回数を計数する処理と、
   条件毎に、過去の履歴に基づいて設定された混雑状況、及び問い合わせ回数を記憶する履歴記憶部を検索して、前記受け付けた前記条件に対応する混雑状況及び問い合わせ回数を取得する処理と、
   前記計数した予想要求の前記回数、前記履歴検索部で取得した前記混雑状況及び問い合わせ回数に基づいて、前記未来の混雑状況を算出する処理と、
   をコンピュータに実行させるためのコンピュータプログラム。