JP2013080307A - 滞在時間指定による行程検索方式 - Google Patents

Abstract

【課題】鉄道の座席予約システムを用いて、利用者の旅程を管理することができる。経由地の滞在時間（バッファ）の考慮がされているが、滞在時間（バッファ）を取得する位置等については、考慮がされておらず、利用者の滞在時間（バッファ）を取得する位置に関する意思決定を行うことができない。
【解決手段】そこで、他者の行程登録データを利用することにより、旅客が希望する滞在駅、滞在時間に応じた行程の検索を行い、各駅での所要時間をさまざまな理由（乗換・仕事・レジャー）により途中駅下車を考慮にいれた利用者の意思決定で設定することができる。
【選択図】図１

Description

本発明は座席予約システムに関する技術である。特に、旅先の滞在時間を旅程情報に含んで管理する技術に関する。

鉄道の座席予約システムを用いて、利用者の旅程を管理することができる。利用者に対しての旅程に関係する技術として、特許文献１では、経路案内装置において乗換駅での乗換時間を考慮した案内を提示する技術が開示されている。特許文献２では、各目的地とそこでの所要時間を設定すると移動に使える時間を算出し、時間内に収まるルートを提示する技術が開示されている。特許文献３では利用者の過去の訪問回数、頻度、評価により旅行計画を立案する技術が開示されている。

特開平8-263786号公報 特開平8-75493号公報 特開2000-11047号公報

しかし、いずれの特許文献でも列車単位の検索をしているため、列車を降りた後の行動も含めた旅程に対する「行程」については考慮されていない。具体的には、特許文献１では、経由地の滞在時間（バッファ）の考慮がされているが、滞在時間（バッファ）を取得する位置等については、考慮がされておらず、利用者の滞在時間（バッファ）を取得する位置に関する意思決定を行うことができない。また、特許文献２では、移動時間と時間内で移動できる経路を探すことを目的としており、目的地ごとに異なる不確かな所有時間の推定を行うという場合には対処できない。特許文献３では、発着時刻については、考慮がされておらず、各目的地の所要時間を推定し、計画を立案するという場合には対処できない。

そこで本願発明では、他者の行程登録データを利用することにより、従来の列車単位の検索ではなく、一人の旅程に対する「行程」という概念を取り入れることにより、旅客が希望する滞在駅、滞在時間に応じた行程の検索を行い、各駅での所要時間をさまざまな理由（乗換・仕事・レジャー）により途中駅下車を考慮にいれた利用者の意思決定で設定することができる。

本発明によれば、各目的地の所要時間を推定し、計画を立案することが可能になる。更に、出発時間、到着時間、滞在駅、滞在時間を設定することにより、蓄積された販売データから該当する行程を人気順、料金順に検索することができるようになる。

本発明による滞在指定検索システムの全体構成図 システム全体のフローチャート 指定情報入力画面フローチャート 指定情報入力画面イメージ 指定情報入力画面 項目説明 行程判定処理フロー 販売データフォーマット 行程見直し処理フロー 行程見直しデータフォーマット 行程見直しデータの例 （指定情報ａ） 行程見直しデータの例 （販売データＡ） 行程見直しデータの例 （販売データＢ） 行程見直しデータの例 （販売データＣ） 集計処理フロー 集計データフォーマット 検索結果出力画面フローチャート 検索結果出力画面イメージ 検索結果出力画面 項目説明

以下、図面を用いて本発明に関する実施の形態を説明する。

図１では、本実施の形態におけるシステム構成図を示す。本システムは検索端末１００と検索サーバ２００で構成される。これらの機器、施設のコンピュータは、メモリ、ハードディスクを含む記憶装置、ＣＰＵなどの処理装置を有し、記憶装置に格納されたプログラムに従って、処理装置が情報処理を実行するものである。

検索サーバ２００にはあらかじめ販売データ２５０（販売データのファイルフォーマットを図１０に示す。）、行程見直しデータ、集計データが設定され、記憶装置に格納されている。また、前述のＣＰＵなどの処理装置を用いて、行程判定処理、行程見直し処理、集計処理を実行する。また、これらの機器、施設はお互い通信回線で接続している。

図２のフローチャートを用いて、以下、本実施の形態の処理内容について説明する。

まず、検索端末１００の指定情報入力画面から滞在検索に必要な情報を入力してサーバに問い合わせる（Ｓ２０１）。

検索端末から検索サーバ問合せを受けた検索サーバ２００は、保持している販売データ２５０の先頭エントリから最終エントリまで、行程判定処理（Ｓ２０３）、行程見直し処理（Ｓ２０４）、集計処理（Ｓ２０５）を繰り返し処理する（Ｓ２０２〜Ｓ２０６）。

繰り返し処理が終了すると、集計した結果を端末に返信する（Ｓ２０７）。

最後に、検索結果出力画面に検索結果を表示する（Ｓ２０８）。

以降、図３、図６、図８、図１４、図１６を用いて、図２で説明した各処理（指定情報入力処理（Ｓ２０１）、行程判定処理（Ｓ２０３）、行程見直し処理（Ｓ２０４）、集計処理（Ｓ２０５）、検索結果表示処理（Ｓ２０８））の詳細を説明する。

図３を用いてＳ２０１の指定情報入力画面の処理フローについて説明する。Ｓ３０１にて乗車駅を入力、Ｓ３０２にて降車駅を入力、Ｓ３０３にて発着指定を入力、Ｓ３０４にて日時を入力、Ｓ３０５にて滞在駅と滞在時間を入力して、Ｓ３０６にて検索サーバに問い合わせる。なお、Ｓ３０５については複数の入力を可能とするが、本説明においては２個の入力を可能とする。指定情報入力画面の画面イメージについては図４に示す。ここに示すとおり、Ｓ３０１からＳ３０５までの入力はこの順番に限られるものではなく、Ｓ３０６の検索サーバ問合せ処理を実行する前までにこれら情報が揃っていれば良い。また、指定情報入力画面の項目説明を図５に示す。

図５は、指定情報入力画面の項目説明を示す図である。乗車駅は乗車駅入力（Ｓ３０１）、後者駅は降車駅入力（Ｓ３０２）、発着指定は発着指定入力（Ｓ３０３）、日時は日時入力（Ｓ３０４）、滞在情報は滞在駅と滞在時間入力（Ｓ３０５）である。

発着指定は乗車駅と降車駅に日時の意味を含めたものである。日時指定を行いたい場合は発着指定に乗車駅か降車駅を指定する必要がある。

図６を用いて行程判定処理２０３の処理フローを説明する。Ｓ６０１にて販売データ（ｉ）のヘッダ情報のうち乗降駅と入力された指定情報の乗降駅とが一致しているかを判定する。一致している場合は、Ｓ６０２にて指定発着情報が乗車か降車かを判定する。その結果、乗車の場合はＳ６０３にて乗車時間の検定を行う。ここでは、指定乗車日時が販売データ（ｉ）のヘッダ情報の乗車日時±１時間以下であるかを調べる。以下である場合は処理を終え、以上である場合はＳ６０５に進む。Ｓ６０２の判定が降車であった場合はＳ６０４にて降車時間の判定を行う。ここでは、指定降車日時が販売データ（ｉ）のヘッダ情報の降車日時±１時間であるかを調べる。

なお、判定の結果がＮＯの場合は、当該販売データ（ｉ）は対象外として、Ｓ６０５にて次の販売データ読込み処理を行う。つまり、図２のＳ２０４以降の処理は行なわずにＳ２０２に移行する。Ｓ６０４の判定結果がＹＥＳの場合は、当図６の処理を終了し、Ｓ２０４の行程見直し処理を行う。なお、販売データフォーマットについては図７に示す。

図7は、検索サーバが保持している販売データを示す図である。ヘッダー情報をキーとして販売データにアクセスすることができる。

図８を用いて、行程見直し処理（Ｓ２０４）の詳細処理フローを説明する。Ｓ８０１にて行程見直しデータ２６０（行程見直しデータのファイルフォーマットを図９に示す。）を初期化し、Ｓ８０２にて他駅滞在フラグを初期化する。次に、当該販売データ（ｉ）の行程情報（ｊ）に対して先頭データから最終データの１エントリ手前までＳ８０３からＳ８０９の処理を繰り返し行う。

まず、Ｓ８０４にて行程情報（ｊ）の滞在駅が指定滞在駅のいずれかと一致するか判定し、不一致の場合はＳ８１０にて他駅滞在フラグをオンにする。一致の場合は、Ｓ８０５にて他駅滞在フラグがオンか判定して、オフの場合はＳ８１１にて行程見直しテーブルに行程情報（ｊ）を追加する。オンの場合は、Ｓ８０６にて行程見直し最終エントリ滞在駅と当該滞在駅が一致するか判定して、不一致の場合は反復処理を抜ける。一致の場合は、Ｓ８０７にて（当該滞在終了時間＋当該滞在時間）−最終エントリ降車時刻を行程見直し最終エントリの滞在時間にセットし、Ｓ８０８にて他駅滞在フラグをオフする。Ｓ８０３からＳ８０９の繰り返し処理が完了したら、Ｓ８１３にて行程情報最終エントリを行程見直し最終エントリに追加して、Ｓ８１４にて当該行程見直し データヘッダ情報料金に行程見直し情報の有効エントリ分の料金を加算してセットする。

図９に行程見直しデータフォーマットを示す。図９は、検索サーバが保持している行程見直しデータを示した図である。このデータを用いて他者の行程登録データを参照することができる。

図１０から図１３に行程見直しデータの編集例を示す。図１０にある端末から入力された指定情報ａに対して、図１１の販売データＡは、Ｓ６０１、Ｓ６０３により、検索対象行程であると判断され、Ｓ２０４行程情報見直し処理を実施する。販売データＡの行程情報１はＳ８０４により検索対象行程として、Ｓ８０５にて他駅滞在フラグがオフのため、Ｓ８１１にて行程見直しデータに登録する。販売データ行程情報２は最終エントリであるため、Ｓ８１３により行程見直しデータに登録して、Ｓ８１４により当該行程見直しデータヘッダ情報料金を再設定する。

販売データＢは、Ｓ６０１、Ｓ６０３により、検索対象行程であると判断して、Ｓ２０４の行程情報見直し処理を実施する。販売データＢ行程情報１はＳ８０４により検索対象行程として、Ｓ８０５にて他駅滞在フラグがオフのため、Ｓ８１１にて行程見直しデータに登録する。販売データＢ行程情報２はＳ８０４により対象外行程のため、Ｓ８１０にて他駅滞在フラグをオンにする。販売データＢ行程情報３は最終エントリであるため、Ｓ８１２にて他駅滞在フラグがオンのため、行程見直しデータには登録せず、対象外データとして扱う。

販売データＣは、Ｓ６０１、Ｓ６０３により、検索対象行程であると判断して、Ｓ２０４の行程情報見直し処理を実施する。販売データＣ行程情報１はＳ８０４により検索対象行程として、Ｓ８０５にて他駅滞在フラグがオフのため、Ｓ８１１にて行程見直しデータに登録する。販売データＣ行程情報２はＳ８０４により対象外行程のため、Ｓ８１０にて他駅滞在フラグをオンにする。販売データＣ行程情報３はＳ８０４により検索対象行程であると判断して、Ｓ８０５にて他駅滞在フラグオンと判定し、Ｓ８０６にて行程見直し最終エントリ滞在駅＝当該滞在駅のため、Ｓ８０７により行程見直しデータ行程情報１の滞時間を再設定する。販売データＣ行程情報４は最終エントリであるため、Ｓ８１３により行程見直しデータに登録して、Ｓ８１４により料金を再設定する。

図１４を用いて、集計処理（S240）の処理フローを説明する。Ｓ１４１にて他駅滞在フラグがオンの場合は、当該販売データ（ｉ）は対象外とする。また、指定滞在駅（ｋ）の先頭エントリから最終エントリまで、Ｓ１４２からＳ１４４の間にあるＳ１４３にて、「指定滞在時間（ｋ）≦指定滞在駅(k)に対する行程見直し情報の滞在時間合計≦指定滞在時間(k)＋2時間」を繰り返して判定して、いずれか一つでも該当しないデータが存在する場合は、当該販売データ（ｉ）を対象外とする。当該販売データ（ｉ）が対象の場合は、Ｓ１４５にて集計データ２７０（集計データのファイルフォーマットを図１５に示す。）に同一行程情報が存在するか判定して、存在する場合はＳ１４７にて同一行程情報のヘッダ情報集計カウンタに１加算し、存在しない場合はＳ１４６にて集計データに当該販売データ（ｉ）を追加する。

図１６を用いて、検索結果出力画面の処理フローを説明する。Ｓ１６１にて検索結果を検索サーバ２００から受信してＳ１６２にて回答結果を出力する。

図１７に、検索結果出力画面の画面イメージについて示す。また、検索結果出力画面の項目説明を図１８に示す。

図１７と図１８は、指定情報入力画面から検索サーバ問合せを行った結果である。この図を用いて利用者は他者の行程登録データを確認でき、自分自身の意思決定を行うことができる。

上記の構成により、発時間、到着時間、滞在駅、滞在時間を指定することにより、蓄積された販売データから該当する行程を人気順、料金順に検索することができるようになる。

なお、本実施例では、乗降駅は同じ、つまり、出発駅から出発し滞在駅で下車しその後また出発駅と同じ駅に戻ることを想定して説明したが、これに限らず、乗降駅は異なる駅であっても構わない。例えば、東京から大阪へ移動する際に途中の京都で観光するようなケースにおいても適用できる。

100：検索端末、110：指定情報入力画面、120：検索結果出力画面、200：検索サーバ、210：行程判定処理、220：行程見直し処理、230：集計処理、240：販売データ、250：行程見直しデータ、260：集計データ。

Claims (8)

1. 入力情報に関連する旅程を提案する旅程提案方法であって、
   乗車駅及び降車駅に関する情報と、乗車日時及び降車日時に関する情報と、前記旅程に含まれる滞在駅及び当該滞在駅における滞在時間と、を備える指定情報を受信する受信ステップと、
   前記受信した指定情報に基づき、過去に販売された列車の実績情報のなかから、当該指定情報に関連する旅程を抽出する抽出ステップと、
   前記抽出された旅程を表示部に表示する表示ステップと、
   を備えることを特徴とする旅程提案方法。
2. 請求項１に記載の旅程提案方法において、
   前記実績情報は、旅程全体を按分する複数の行程からなり、当該行程毎に前記乗車駅及び降車駅に関する情報と、前記乗車日時及び降車日時に関する情報と、が規定されていることを特徴とする旅程提案方法。
3. 請求項２に記載の旅程提案方法において、
   前記抽出ステップは、前記行程毎の前記乗車駅及び降車駅に関する情報と前記乗車日時及び降車日時に関する情報と、前記指定情報と、に基き当該指定情報に関連する旅程を抽出することを特徴とする旅程提案方法。
4. 請求項３に記載の旅程提案方法において、
   前記実績情報は複数、記憶部に格納されており、
   前記抽出ステップは、前記複数の実績情報それぞれに対して、前記行程毎の前記乗車駅及び降車駅に関する情報と前記乗車日時及び降車日時に関する情報と、前記指定情報と、に基き当該指定情報に関連する旅程を抽出することを特徴とする旅程提案方法。
5. 入力情報に関連する旅程を提案する旅程提案システムであって、
   乗車駅及び降車駅に関する情報と、乗車日時及び降車日時に関する情報と、前記旅程に含まれる滞在駅及び当該滞在駅における滞在時間と、を備える指定情報を受信し、提案する旅程情報を送信する、通信部と、
   前記受信した指定情報に基づき、過去に販売された列車の実績情報のなかから、当該指定情報に関連する旅程を抽出する行程判定処理部と、
   を備えることを特徴とする旅程提案システム。
6. 請求項５に記載の旅程提案システムにおいて、
   前記実績情報は、旅程全体を按分する複数の行程からなり、当該行程毎に前記乗車駅及び降車駅に関する情報と、前記乗車日時及び降車日時に関する情報と、が規定されていることを特徴とする旅程提案システム。
7. 請求項６に記載の旅程提案システムにおいて、
   行程見直し処理部を更に備え、
   前記行程見直し処理部は、前記行程毎の前記乗車駅及び降車駅に関する情報と前記乗車日時及び降車日時に関する情報と、前記指定情報と、に基き当該指定情報に関連する旅程を抽出することを特徴とする旅程提案システム。
8. 請求項７に記載の旅程提案システムにおいて、
   前記実績情報は複数、記憶部に格納されており、
   前記行程見直し処理部は、前記複数の実績情報それぞれに対して、前記行程毎の前記乗車駅及び降車駅に関する情報と前記乗車日時及び降車日時に関する情報と、前記指定情報と、に基き当該指定情報に関連する旅程を抽出することを特徴とする旅程提案システム。

Images