JP2015075857A - 発券支援システム及び発券支援方法 - Google Patents

Abstract

【課題】 旅客の要望に合わせた乗降駅の代案を受け付けることで、旅客一人一人のニーズに沿った代案列車を提示する。
【解決手段】 操作端末３０にて入力した要求情報を受け付けて、列車在庫管理装置１０へ端末要求を送信し、端末要求の照会内容に基づき、列車在庫管理装置１０で保持している列車在庫管理ファイル１０２１に対して在庫サーチを行う。列車在庫管理装置１０では、代案駅検索に必要な営業キロ数を取得するため、列車在庫管理ファイル１０２１に対して代案営業キロサーチを行う。代案営業キロ数を取得した後、候補となる代案駅を求めるため、列車在庫管理装置１０で保持している駅情報管理ファイル１０２２に対して代案駅サーチを行う。代案駅を求めた後、取得した駅名に対して代案在庫サーチを行う。列車在庫管理装置１０は、以上で取得した在庫情報を操作端末３０に送信し、画面表示等により出力する。
【選択図】図１０

Description

本発明は、発券支援システム及び発券支援方法に関する。

鉄道利用者が駅の窓口などで必要な乗車券、指定席券などを購入する場合、発売窓口の係員に、乗車駅、行き先、乗車日などの発券に必要な情報を告げ、それを受けて係員が発券システムの操作端末を操作して、データセンターに問い合わせ、所望の乗車券類を発券する。センター問い合わせの結果、利用者の希望に沿った列車を取れない場合には、係員が利用者に時間帯、乗降駅の変更などに関して聞き取りを行い、再度センターに問い合わせるといった流れとなる。近年では、利用者が自身で駅の自動発券機を操作して、窓口の係員に対して口頭で伝えていたような所望の列車に関する情報を自身で入力して発券を行うこともある。操作端末を係員が操作する場合、利用者が自動発券機を自身で操作する場合、いずれであっても、当初の希望列車が取れなかった場合に、その代替案に関する様々な情報が提供されるとすれば、利用者にとっても係員にとっても利便性が向上する。

この点、従来、自動券売機で乗車券等を購入する際利用者に代案を提示する技術として、特許文献１に開示されている技術がある。特許文献１においては、旅客が要求した列車が満席の場合、あらかじめシステム上に定義した条件に従い、条件を変更して代案列車の照会、提示を行うことが記載されている。

特開平４−３５３９９３号公報

しかしながら、特許文献１においては、代案列車を照会する際の条件がシステム上に定義されており、すべての旅客に対して固定的な条件で代案列車を提示している。旅客のニーズは通常一人一人異なるため、固定的な条件の代案列車提示では旅客のニーズを満たすには十分でないと考えられる。また、希望乗車駅の隣接駅を代案として提示する場合に隣接代案テーブルを用いているが、隣接代案テーブルの登録は自動化されていないため、新駅が追加された時、隣接駅をどのように定義するか検討した上で登録しなければならないという問題もある。

上記の、及び他の課題を解決するために、本発明の一態様は、列車の利用を希望する場合の希望利用日、希望乗車時刻、希望乗車駅、及び希望降車駅の情報を少なくとも含む利用希望情報を受け付ける入力部と、利用可能な日付ごとに、利用可能な列車ごとの各停車駅の出発時刻及び到着時刻、列車ＩＤ、及び当該列車の各停車駅における利用可能空席数の情報を少なくとも含む列車在庫情報を記憶している列車在庫情報記憶部と、前記入力部からの前記利用希望情報を受信して、前記列車在庫情報記憶部に記憶されている前記列車在庫情報と対照し、前記利用希望情報の条件を満たす列車在庫情報があると判定した場合、当該列車在庫情報の少なくとも一部を送信する照会処理部と、前記照会処理部からの前記列車在庫情報に関する情報を受信して、当該列車在庫情報に関する情報を出力する出力部とを備え、前記入力部は、前記希望乗車駅及び前記希望降車駅の少なくともいずれかについて、許容可能な利用駅の範囲を受け付けて前記利用希望情報に含めることができるように構成され、前記照会処理部は、前記利用希望情報に前記許容可能な利用駅の範囲が含まれていると判定し、前記希望乗車駅又は前記希望降車駅の条件を満たす列車在庫情報がないと判定した場合、前記許容可能な利用駅の範囲に含まれる前記停車駅により前記列車在庫情報に利用可能な列車があるか検索する発券支援システムである。また、本発明の他の態様は、上記の課題を解決するための発券支援方法である。

本発明によれば、旅客の要望に基づいた乗降駅の代案提示を円滑に行うことで、旅客一人一人にニーズに沿った代案列車を提示することが可能となる。

図１は、本発明の一実施形態による発券支援システム１の構成を例示する図である。 図２は、発券支援システム１の列車在庫管理装置１０の概略構成図である。 図３は、発券支援システム１の操作端末３０の概略構成図である。 図４は、列車在庫管理ファイル１０２１の構成例を示す図である。 図５は、列車在庫管理ファイル１０２１の検索結果例を示す図である。 図６は、駅情報管理ファイル１０２２の構成例を示す図である。 図７は、操作端末３０から列車在庫管理装置１０に送信される端末要求入力例を示す図である。 図８は、列車在庫管理装置１０から操作端末３０に送信される端末回答出力例を示す図である。 図９は、内部作業用エリア１０２３の構成例を示す図である。 図１０は、本実施形態の発券支援システム１における操作端末３０からの照会処理シーケンス例を示す図である。 図１１は、操作端末３０の処理フロー例を示すフローチャートである。 図１２は、列車在庫管理装置１０の列車在庫照会処理例を示すフローチャートである。 図１３は、図１２における在庫サーチ処理例を説明するためのフローチャートである。 図１４は、図１２における代案営業キロサーチ処理例を説明するためのフローチャートである。 図１５は、図１２における代案駅サーチ処理例を説明するためのフローチャートである。 図１６は、図１２における代案在庫サーチ処理例を説明するためのフローチャートである。 図１７は、本実施形態による列車在庫照会処理の処理例を示す図である。 図１８は、本実施形態による列車在庫照会処理の処理例を示す図である。 図１９は、本実施形態による列車在庫照会処理の処理例を示す図である。 図２０は、本実施形態による列車在庫照会処理の処理例を示す図である。 図２１は、本実施形態による列車在庫照会処理の処理例を示す図である。

以下、本発明について、添付図面を参照しながらその一実施形態に即して説明する。本実施形態では、旅客の希望乗降駅に対する代案駅としての許容範囲を把握し、その許容範囲を営業キロで定量的に表した上で代案駅を抽出する。この許容範囲を、運賃計算算定の根拠となる営業キロを用いて定量的に表すため、既存の列車在庫管理ファイルを使用する。代案駅の抽出には列車在庫管理ファイルのキーの項目（キー項目、取得項目）を変更して得られる駅情報管理ファイルを使用する。本実施形態では、代替可能な範囲に含まれる候補駅を求めた上で、希望乗降時刻等の条件を満たす全ての候補駅について列車在庫照会（空席照会）を行う。

まず、本実施形態による発券支援システム１全体の構成について説明する。図１は、本実施形態における発券支援システム１の構成例を示す図である。本実施形態の発券支援システム１は、列車在庫管理装置１０と複数の操作端末３０とを備えている。列車在庫管理装置１０と各操作端末３０とは、通信ネットワーク２０によって相互に通信可能に接続されている。列車在庫管理装置１０は、鉄道会社の座席予約処理を管理するデータセンター等に設置され、旅客に提供可能な列車座席に関する情報（以下「列車在庫」という。）を格納している。本発券支援システム１の主要な機能は列車在庫管理装置１０に実装されている。操作端末３０は、駅、旅行会社等に設置され、係員あるいは旅客が操作する端末入出力装置である。通信ネットワーク２０は、セキュリティの観点等から例えば適宜の通信プロトコルを採用する専用線を用いることができるが、特定の形式の通信回線に限定されることはない。

次に、列車在庫管理装置１０について説明する。図２は、列車在庫管理装置１０のシステム構成例を示す図である。本発券支援システム１の機能を実現すべく、列車在庫管理装置１０は、送受信処理部１０１１、列車在庫照会処理部１０１２（照会処理部）、及び駅情報照会処理部１０１３（照会処理部）を有する処理部１０１と、列車在庫管理ファイル１０２１（列車在庫情報）、駅情報管理ファイル１０２２、及び内部作業用エリア１０２３を有する記憶部１０２（列車在庫情報記憶部）と、メモリ１０３と、通信ネットワーク２０に接続するための通信インタフェース（通信Ｉ／Ｆ）部１０４とを備える。これらの要素間は、内部バスにより通信可能に接続されている。

処理部１０１はＣＰＵ（Central Processing Unit）等のプロセッサであり、プログラムとして構成されている送受信処理部１０１１、列車在庫照会処理部１０１２、及び駅情報照会処理部１０１３によるデータ処理を実行する。送受信処理部１０１１は、操作端末３０からの要求受信処理、操作端末３０への回答送信処理を行う機能を有する。列車在庫照会処理部１０１２は、操作端末３０からの要求情報に基づき列車在庫管理ファイル１０２１を検索して列車在庫情報を取得する機能を有する。駅情報照会処理部１０１３は、駅情報管理ファイル１０２２から代案駅を取得する機能を有する。

記憶部１０２は、ハードディスクドライブ（ＨＤＤ）、半導体ドライブ（ＳＳＤ）等の記憶デバイスにより記憶領域を提供しており、前記のように、列車在庫管理ファイル１０２１、駅情報管理ファイル１０２２、及び内部作業用エリア１０２３を格納している。メモリ１０３は、例えばＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等の記憶デバイスで構成され、処理部１０１の主記憶装置として機能する。送受信処理部１０１１、列車在庫照会処理部１０１２、及び駅情報照会処理部１０１３の各プログラムは、記憶部１０２に格納しておき、必要に応じて処理部１０１がメモリ１０３上に読み出して実行させる。通信Ｉ／Ｆ１０４は、通信ネットワーク２０の仕様に対応したインタフェース機能を提供するハードウェア（例えばＮＩＣ（Network Interface Card））を備えて構成される。なお、処理部１０１は、上記の本発券支援システム１の機能を有するプログラムの他に、運賃計算等の他の機能のための処理プログラムを実行することができるように構成することができる。また、列車在庫管理装置１０には、表示モニタ、、プリンタ、タッチパネル、キーボード等の入出力デバイスを、必要に応じて設けることができる。

次に、本発券支援システム１の操作端末３０について説明する。図３は、操作端末３０のシステム構成例を示す図である。本発券支援システム１の機能を実現すべく、操作端末３０は、入出力処理部３０１１（入力部、出力部）、送受信処理部３０１２を有する処理部３０１と、メモリ３０２と、入出力デバイス３０３（入力部、出力部）と、通信ネットワーク２０に接続するための通信インタフェース（通信Ｉ／Ｆ）部３０４とを備える。これらの要素間は、内部バスにより通信可能に接続されている。

処理部３０１はＣＰＵ（Central Processing Unit）等のプロセッサであり、プログラムとして構成されている入出力処理部３０１１、及び送受信処理部３０１２によるデータ処理を実行する。入出力処理部３０１１は、後述する入出力デバイス３０３からのデータ入力に基づいて列車在庫管理装置１０への端末要求を生成するとともに、列車在庫管理装置１０からの回答から入出力デバイス３０３に出力する情報を生成する。送受信処理部３０１２は、列車在庫管理装置１０との間での要求送信処理、回答受信処理を行う。メモリ３０２は、例えばＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）等の記憶デバイスで構成され、処理部３０１の主記憶装置として機能する。入出力処理部３０１１、送受信処理部３０１２の各プログラムは、処理部３０１がメモリ３０２上で実行させる。なお、操作端末３０には、ＨＤＤ等の補助記憶装置を設けてもよい。また、処理部３０１は上記のプログラム以外の、操作端末３０で必要とされる機能のためのプログラムを実行することができるように構成することができる。

入出力デバイス３０３は、操作端末３０におけるデータ入力を受け付けるためのキーボード、タッチパネル等の入力デバイスと、表示モニタ、プリンタ等の出力デバイスを含む。通信Ｉ／Ｆ３０４は、通信ネットワーク２０の仕様に対応したインタフェース機能を提供するハードウェア（例えばＮＩＣ（Network Interface Card））を備えて構成される。

次に、列車在庫管理装置１０に格納されているデータについて説明する。図４は、列車在庫管理ファイル１０２１のデータ構造例である。列車在庫管理ファイル１０２１は、例えば、鉄道会社等の運転線区別、運転日別に、個別の列車ごとの停車駅、各駅の営業キロ程、出発時刻、到着時刻、各駅における座席在庫数、運転方向（下り／上り）等の項目を格納しており、本発券支援システム１を含む座席予約システムの基礎データを提供するファイルである。図４にはその一例として、東海道新幹線の列車在庫についてテーブル形式に構成されたものを示しており、１２月３０日に運転される「ひかり３号」（列車ＩＤの例）の停車駅と、着発時刻、各停車駅において旅客に供給可能な座席在庫数が記録されている。座席在庫は、列車の利用可能な設備にしたがって、「普通在庫」と「グリーン在庫」とに区分されている。図４の例では、同列車の東京発において、普通席が１０００、グリーン席が１００供給可能であることが示されている。なお、図４の列車在庫管理ファイル１０２１は、本発券支援システム１の処理に必要な項目を例示しているもので、その構成は特にこれに限定されるものではない。

図５は、操作端末３０から受信する検索キーにより、図４の列車在庫管理ファイル１０２１を検索した結果得られる検索結果例である。操作端末３０からの要求情報を検索キー１０２１１として列車在庫管理ファイル１０２１を検索することにより、取得情報１０２１２を取得することができる。検索キー１０２１１は、例えば乗車日１０２１１１、乗車時刻１０２１１２、乗車駅１０２１１３、降車駅１０２１１４、列車名１０２１１５、及び列車設備１０２１１６の項目を含む。検索キー１０２１１は、旅客の要望を係員が聞き取って、あるいは旅客自身が操作して操作端末３０に入力する情報である。乗車日１０２１１１には検索対象の乗車日を設定する。乗車時刻１０２１１２には検索対象の乗車時刻を設定する。例えば１８時以降に出発する列車を検索対象としたい場合、乗車時刻１０２１１２には１８：００と設定する。乗車駅１０２１１３には検索対象の第一希望の乗車駅を設定する。例えば新横浜を第一希望とする場合はその駅名を設定する。降車駅１０２１１４には第一希望の降車駅を設定する。例えば京都駅を第一希望とする場合はその駅名を設定する。列車名１０２１１５には検索対象の列車名を設定する。列車名とは、例えばのぞみ・ひかり等の列車名称であるが、列車番号等の他の項目によって指定してもよい。列車設備１０２１１６には検索対象の列車設備を設定する。列車設備とは、例えば自由席・指定席・グリーン席・個室などを示す。

取得情報１０２１２は、検索キー１０２１１により列車在庫管理ファイル１０２１を検索して取得される情報である。列車番号１０２１２１は、例えばのぞみ３号の場合には符号３を示す。残り在庫１０２１２２は検索対象の列車における残り在庫（供給可能な座席）数を示す。降車時刻１０２１２３はその列車の降車駅１０２１１４への到着時刻を示す。図５の例のように、例えばのぞみ３号が降車駅である名古屋駅に到着する予定時刻として、２０：１０等と記録される。営業キロ１０２１２４は該当列車の乗車駅から降車駅までの換算営業キロを示す。上り／下り１０２１２５はその列車の進行方向を示す。運賃１０２１２６は検索キー１０２１１に該当する列車に乗車した場合の運賃の金額を示す。運賃１０２１２６は、例えば列車在庫管理装置１０に運賃計算処理を実行するプログラムを実装することにより実現可能であるが、本発券支援システム１の機能とは直接関連しないため、詳細は省略する。

図５は駅情報管理ファイル１０２２のデータ構造例である。駅情報管理ファイル１０２２は、旅客が希望する降車駅を固定した場合に、乗車候補となる駅名を取得するのに使用するファイルである。駅情報管理ファイル１０２２は、列車在庫管理ファイル１０２１を、検索キー１０２２１で検索することにより生成することができる。検索キー１０２２１は、乗車日１０２２１１、駅１０２２１２、列車名１０２２１３、列車設備１０２２１４、営業キロ１０２２１５、及び上り／下り１０２２１６の各項目を含む。乗車日１０２２１１には検索対象の乗車日を設定する。駅１０２２１２には検索対象の固定駅（旅客の第一希望降車駅）を設定する。列車名１０２２１３には検索対象の列車名を設定する。例えば、のぞみ・ひかりのみ希望する場合はそのように設定する。列車設備１０２２１４には検索対象の列車設備を、例えば自由席・指定席・グリーン席・個室等で示す。営業キロ１０２２１５には固定駅（駅１０２２１２）から乗車候補駅までの営業キロを設定する。上り／下り１０２２１６には乗車候補駅から固定駅（駅１０２２１２）への進行方向を設定する。取得情報１０２２２は、乗車候補となる駅名を含む。駅１０２２２１は検索キー１０２２１による検索条件に合致する駅名を示す。例えば新横浜から５０キロ圏内で上り方面にある駅は東京、品川などである。具体的な検索手順については、処理フロー例に基づいて後述する。

次に、列車在庫管理装置１０に対して操作端末３０から入力される要求データのフォーマットについて説明する。図７は操作端末３０から列車在庫管理装置１０に入力される端末要求フォーマット１００（以下「端末要求１００」）の構成例である。利用希望情報である端末要求１００は、係員の操作により、あるいは旅客自身の操作により操作端末３０に入力されたデータに基づいて、列車在庫管理装置１０に対して与えられる列車在庫照会に関する問い合わせデータを記録しており、代案許可フラグ１００１、乗車日１００２、乗車時刻１００３、降車時刻１００４、乗車駅１００５、降車駅１００６、列車名１００７、列車設備１００８、代案乗車駅名（始）１００９、代案乗車駅名（終）１０３０、代案降車駅名（始）１０３１、及び代案降車駅名（終）１０３２の各項目を有する。代案許可フラグ１００１は、希望列車の第一希望の乗車駅のみではなく、希望乗車駅に近い他の乗車候補駅に関する代案提示を許可する時に、操作端末３０からの代案許可入力に応じてＯＮとなる。例として、第一希望乗車駅が新横浜であった場合、新横浜乗車だけではなく、新横浜乗車列車が満席の場合、東京・品川等の新横浜に近い駅の代案も許可するといった場合に、フラグＯＮとなる。乗車日１００２は端末入力された照会列車の乗車日を示す。乗車時刻１００３は端末入力された照会列車の希望乗車時刻を示し、この時刻より後の列車を照会する。降車時刻１００４は端末入力された照会列車の降車時間帯を示し、この時刻より前の列車を照会する。乗車駅１００５は端末入力された照会列車の第一希望乗車駅を示す。降車駅１００６は端末入力された照会列車の第一希望降車駅を示す。列車名１００７は端末入力された照会列車名を示し、複数設定可能である。列車設備１００８は端末入力された照会列車の設備を示し、複数設定可能である。代案乗車駅名（始）１００９は端末入力された顧客許容範囲内の乗車駅名始点を示す。例えば、第一希望は新横浜乗車であるが、東京乗車までは許可する場合、東京を設定する。代案乗車駅名（終）１０３０は端末入力された顧客許容範囲内の乗車駅名終点を示す。例えば、第一希望は新横浜乗車であるが、小田原乗車までは許容する場合、小田原を設定する。代案降車駅名（始）１０３１は端末入力された顧客許容範囲内の降車駅名始点を示す。例えば、第一希望は京都降車であるが、名古屋降車までなら許可する場合、名古屋を設定する。代案降車駅名（終）１０３２は端末入力された顧客許容範囲内の降車駅名終点を示す。例えば、第一希望は京都降車であるが、新大阪降車までなら許可する場合、新大阪と設定する。なお、本実施形態の端末要求１００では列車名１００７を設定しているが、列車名１００７を指定することなく、乗車日１００２、乗車時刻１００３、降車時刻１００４、乗車駅１００５、及び降車駅１００６を指定することにより、なんらかの列車在庫があるか検索することもできる。

次に、図７の端末要求に対して列車在庫管理装置１０から操作端末に返される端末回答フォーマット２００（以下「端末回答２００」）について説明する。図８は、列車在庫管理装置１０から操作端末３０に返される端末回答２００の構成例であり、この回答内容をそのまま、あるいはその一部を操作端末３０の入出力デバイス３０３を介して出力することができる。端末回答２００は、例えば、エントリ番号２００１、代案フラグ２００２、乗車日２００３、乗車時刻２００４、降車時刻２００５、乗車駅２００６、降車駅２００７、列車名２００８、列車設備２００９、列車番号２０１０、運賃２０１１、及び残り在庫２０１２の各項目を備えている。エントリ番号２００１は、例えば、照会結果が複数あった場合に各結果に割り当てられる項番を示す。代案フラグ２００２は該当する照会結果が希望乗降駅に対する代案である場合にＯＮされ、対応する乗降駅が第一希望ではなく許容範囲内の代替駅名であることを示す。乗車日２００３は照会の結果、在庫があった列車の乗車日を示し、端末要求に含まれる乗車日１００２と同一である。乗車時刻２００４は照会の結果、在庫があった列車の乗車時刻（発車時刻）を示す。降車時刻２００５は照会の結果、在庫があった列車の降車時刻（到着時刻）を示す。乗車駅２００６は照会の結果、在庫があった列車の乗車駅を示す。降車駅２００７は照会の結果、在庫があった列車の降車駅を示す。列車名２００８は照会の結果、在庫があった列車の列車名を示す。列車設備２００９は照会の結果、在庫があった列車の列車設備を示す。列車番号２０１０は照会の結果、在庫があった列車の列車番号を示す。運賃２０１１は照会の結果、在庫があった列車の乗車区間に対して発生する運賃の金額を示す。残り在庫２０１２は照会の結果、在庫があった列車に関して列車在庫管理装置１０に記録されている残り在庫（残り座席数）を示す。なお、端末回答２００に含まれている列車番号２０１０、残り在庫２０１２、降車時刻２００５、及び運賃２０１１の各項目は、図５の検索結果例における取得情報１０２１２の同一項目に対応する。また、乗車駅２００６は、図６の駅情報管理ファイル１０２２の取得情報１０２２２に対応する。

次に、図７の端末要求１００に記録されている内容に基づいて、列車在庫管理装置１０での具体的なデータ処理に利用するために、列車在庫管理装置１０内に一時的に設定される内部作業用エリア１０２３について説明する。図９は、内部作業用エリア１０２３のデータ構造例である。列車在庫管理装置１０での作業用に一時退避する項目、判定用フラグ等は本エリアに格納される。内部作業用エリア１０２３には、営業キロ１０２３１１、上り／下り１０２３１２、代案乗車営業キロ上限１０２３１３、代案乗車営業キロ下限１０２３１４、代案降車営業キロ上限１０２３１５、代案降車営業キロ下限１０２３１６、候補代案下限営業キロ１０２３１７、候補代案上限営業キロ１０２３１８、候補代案乗車駅１０２３１９、候補代案降車駅１０２３２０、エントリ番号１０２３２１、ループエンドフラグ（以下「ループエンドＦ」）１０２３２２、代案フラグ１０２３２３、乗車駅１０２３２４、及び降車駅１０２３２５の各項目が格納される。営業キロ１０２３１１は、後述する在庫サーチ処理で取得した営業キロを一時退避するエリアである。上り／下り１０２３１２は、在庫サーチ処理で取得した上り／下りを一時退避するエリアである。代案乗車営業キロ上限１０２３１３は、後述する代案営業キロサーチ処理で取得した代案乗車駅（始点）と希望する乗車駅間の営業キロ数を一時退避するエリアである。代案乗車営業キロ下限１０２３１４は、代案営業キロサーチ処理で取得した代案乗車駅（終点）と希望する乗車駅間の営業キロ数を一時退避するエリアである。代案降車営業キロ上限１０２３１５は、代案営業キロサーチ処理で取得した代案降車駅（終点）と希望する降車駅間の営業キロ数を一時退避するエリアである。代案降車営業キロ下限１０２３１６は、代案営業キロサーチ処理で取得した代案降車駅（始点）と希望する降車駅間の営業キロ数を一時退避するエリアである。候補代案下限営業キロ１０２３１７は、後述する代案駅サーチ処理で使用する代案として許容範囲内の下限営業キロ数を一時退避するエリアである。候補代案上限営業キロ１０２３１８は、代案駅サーチ処理で使用する代案として許容範囲内の上限営業キロ数を一時退避するエリアである。候補代案乗車駅１０２３１９は、駅情報管理ファイル１０２２から取得した代案として許容範囲内の候補乗車駅のリストを格納するエリアである。候補代案降車駅１０２３２０は、駅情報管理ファイル１０２２から取得した代案として許容範囲内の候補降車駅のリストを格納するエリアである。エントリ番号１０２３２１は、在庫サーチ処理で照会結果のカウントアップ用に使用するエリアである。ループエンドＦ１０２３２２は、在庫サーチ処理で処理判定用に使用するフラグである。代案フラグ１０２３２３は、代案１０２３１９、１０２３２０が記録されている場合にＯＮされるフラグである。乗車駅１０２３２４は、在庫サーチ処理で使用する第一希望乗車駅である。降車駅１０２３２５は、在庫サーチ処理で使用する第一希望降車駅である。なお、列車在庫管理装置１０内での内部作業用パラメータについては、例示の内部作業用エリア１０２３の構成に限定されることなく、後述する処理内容に応じて適宜設定することができる。

続いて、本発券支援システム１の機能を実現するための処理シーケンスについて順次説明する。まず、本発券支援システム１全体の処理の流れを説明し、次いで、操作端末３０、列車在庫管理装置１０での処理の詳細について説明する。図１０は、本発券支援システム１において操作端末３０から列車在庫管理装置１０に対して、乗降駅に関する代案提示要求を含む空席照会（列車在庫照会）を実行する場合の処理シーケンスである。まず、旅客又は係員が操作端末３０にて入力した要求情報を受け付けて（Ｓ３１０）、画面上の照会実行ボタン押下げ等により、操作端末３０から列車在庫管理装置１０へ端末要求１００が送信される（Ｓ３２０）。列車在庫管理装置１０では、端末要求１００を受信した後（Ｓ１０１０）、端末要求１００の照会内容に基づき、列車在庫管理装置１０で保持している列車在庫管理ファイル１０２１に対して在庫サーチを行う（Ｓ１０２０）。在庫サーチ後、列車在庫管理装置１０では、代案駅検索に必要な営業キロ数を取得するため、列車在庫管理ファイル１０２１に対して代案営業キロサーチを行う（Ｓ１０３０）。代案営業キロ数を取得した後、候補となる代案駅を求めるため、列車在庫管理装置１０で保持している駅情報管理ファイル１０２２に対して代案駅サーチを行う（Ｓ１０４０）。代案駅を求めた後、取得した駅名に対して代案在庫サーチを行う（Ｓ１０５０）。列車在庫管理装置１０は、以上で取得した在庫情報を回答２００として操作端末３０に送信する（Ｓ１０６０）。操作端末３０では、受信した照会結果を入出力デバイス３０３に画面表示等により出力する（Ｓ３３０、Ｓ３４０）。

続いて、図１０の全体処理フローにおいて実行される個々の処理フローについて詳細に説明する。まず、操作端末３０の処理部３０１によって実行される処理フローについて説明する。図１１は、操作端末３０の入出力処理部３０１１、送受信処理部３０１２が実行する処理フロー例を説明するためのフローチャートである。操作端末３０は、旅客あるいは係員の操作開始入力等を受け付けて処理を開始する（Ｓ３０）。操作端末３０の入出力処理部３０１１は、入出力デバイス３０３を通じて入力される、空席照会したい列車情報を受け付ける（Ｓ３１）。列車情報は、図７に例示した端末要求例に記載されている項目を含む。送受信処理部３０１２は、入力された情報を端末要求１００に設定し、列車在庫管理装置１０に送信する（Ｓ３２）。その後、送受信処理部３０１２は、列車在庫管理装置１０が空席照会した結果である回答２００を受信する（Ｓ３３）。入出力処理部３０１１は、その受信した結果に基づき入出力デバイス３０３に画面表示するなどして出力して処理を終了する（Ｓ３４、Ｓ３５）。以上の操作端末３０での処理により、旅客、係員等は、希望の列車に関する座席があるか、希望乗降駅に対する代替候補も含めて照会結果を得ることができる。

次に、列車在庫管理装置１０において実行される処理について説明する。図１２は、列車在庫管理装置１０での全体処理を説明するためのフローチャートである。まず、送受信処理部１０１１は、操作端末３０からの要求情報を受信し、必要な項目を内部作業用エリア１０２３に設定する（Ｓ１１）。ここでは、内部作業用エリア１０２３では、乗車駅１００５を乗車駅１０２３２４に、降車駅１００６を降車駅１０２３２５に設定する。次いで、列車在庫照会処理部１０１２は、操作端末３０からの要求情報に基づき、列車在庫管理ファイル１０２１に対して希望する列車の在庫サーチ処理を行う（Ｓ１２）。在庫サーチした結果、希望する列車の在庫があった場合は（Ｓ１３、Ｙｅｓ）、結果を送受信処理部１０１１に引き渡して回答送信を行う（Ｓ１８）。希望する列車の在庫がないと判定した場合（Ｓ１３、Ｎｏ）、列車在庫照会処理部１０１２は、内部作業用エリア１０２３を参照して代案許可フラグがＯＮかどうかの判定をする（Ｓ１４）。代案許可フラグがＯＮでないと判定した場合（Ｓ１４、Ｎｏ）、列車在庫照会処理部１０１２は、送受信処理部１０１１に処理を引き渡して在庫なしとの結果を回答させる（Ｓ１８）。Ｓ１４において代案許可フラグがＯＮであると判定した場合（Ｓ１４、Ｙｅｓ）、列車在庫照会処理部１０１２は、操作端末３０からの要求情報を検索キーにして、列車在庫管理ファイル１０２１に対して代案営業キロサーチを行う（Ｓ１５）。次いで、駅情報照会処理部１０１３は、Ｓ１５で取得した営業キロ等を検索キーに設定し、駅情報管理ファイル１０２２に対して代案駅サーチを行う（Ｓ１６）。さらに、列車在庫照会処理部１０１２は、Ｓ１５で取得した代案駅と操作端末３０からの要求情報に基づき、代案在庫サーチを行う（Ｓ１７）。列車在庫照会処理部１０１２は、Ｓ１７での代案在庫有無の結果を送受信処理部１０１１に引き渡して回答２００を生成し操作端末３０に送信して処理を終了する（Ｓ１８、Ｓ１９）。以上の列車在庫管理装置１０での処理によれば、操作端末３０からの要求に応じて、第一希望乗降駅に対する代替候補駅を含めた照会結果を提供することができ、旅客に対するサービス向上、駅係員の利便性向上を図ることができる。

次に、図１２に例示した列車在庫管理装置１０の全体処理フローに含まれる個別の処理について、処理フロー例を参照して説明する。図１３は、列車在庫管理装置１０の在庫サーチ処理Ｓ１２を詳細に説明するためのフローチャートである。在庫サーチ処理Ｓ１２は、４つのループ処理を含む。第１のループでは、最初に内部作業用エリア１０２３のエントリ番号１０２３２１を０クリアし、エントリ番号１０２３２１がエントリ番号２００１の最大値と一致するか、ループ終了条件と合致したことを表すループエンドＦ１０２３２２＝ＯＮが成立するまで処理を繰り返す（Ｓ１２０１〜Ｓ１２１９）。第２のループでは、端末要求１００の列車名１００７が複数設定可能なため、１エントリ目からエントリがなくなるか、ループエンドＦ１０２３２２＝ＯＮになるまで各列車名での処理を繰り返す（Ｓ１２０２〜Ｓ１２１８）。第３のループでは、端末要求１００の列車設備１００８が複数設定可能なため、１エントリ目からエントリがなくなるか、ループエンドＦ１０２３２２＝ＯＮになるまで、各列車設備について処理を繰り返す（Ｓ１２０３〜Ｓ１２１７）。第４のループでは、端末要求１００の乗車時刻１００３を検索開始時刻として、ループエンドＦ１０２３２２＝ＯＮになるまで処理を繰り返す（Ｓ１２０４〜Ｓ１２１６）。以上のループ処理で実行される処理フローについて説明すると、まず、列車在庫照会処理部１０１２は、図５に例示した列車在庫管理ファイル１０２１の検索キー１０２１１を、端末要求１００、内部作業用エリア１０２３の各情報を元に設定する。具体的には、乗車日１００２を乗車日１０２１１１に、乗車時刻１００３を乗車時刻１０２１１２に、乗車駅１０２３２４を乗車駅１０２１１３に、降車駅１０２３２５を降車駅１０２１１４に、列車名１００７を列車名１０２１１５に、列車設備１００８を列車設備１０２１１６に設定する（Ｓ１２０５）。

次に、列車在庫照会処理部１０１２は、Ｓ１２０５で設定した項目を検索キーとして、列車在庫管理ファイル１０２１をファイルサーチし（Ｓ１２０６）、取得した情報のうち、営業キロ１０２１２４、上り／下り１０２１２５を、代案提示に必要な情報として、内部作業用エリア１０２３の営業キロ１０２３１１、上り／下り１０２３１２に退避しておく（Ｓ１２０７）。列車在庫照会処理部１０１２は、ファイルサーチした結果、在庫があるか判定し（Ｓ１２０８）、あると判定した場合はＳ１２１０の処理に移る（Ｓ１２０８、Ｙｅｓ）。在庫がないと判定した場合（Ｓ１２０８、Ｎｏ）、列車在庫照会処理部１０１２は乗車時刻を時刻の最小単位（例えば１分）でカウントアップし（Ｓ１２０９）、Ｓ１２０１から次のエントリのループを行う。在庫があったと判定した場合、列車在庫照会処理部１０１２は、取得した列車の降車時刻が端末要求１００に設定されている降車時刻以前か判定する（Ｓ１２１０）。要求降車時刻後であった場合（Ｓ１２１０、Ｎｏ）、乗車時刻をそれ以上カウントアップしても降車時刻は要求範囲外のため、ループ終了条件成立と判定し、ループエンドＦ１０２３２２をＯＮにする（Ｓ１２１１）。この場合、処理はそのまま終了する（Ｓ１２２０）。次いで、列車在庫照会処理部１０１２は、取得した在庫情報を端末回答２００の各情報に設定する（Ｓ１２１２）。具体的には、内部作業用エリア１０２３のエントリ番号１０２３２１をカウントアップし、エントリ番号２００１に設定する。また、代案フラグ１０２３２３がＯＮの場合、代案であると判別し、回答２００の代案フラグ２００２をＯＮにする。さらに、列車在庫照会処理部１０１２は、乗車日１０２１１１を乗車日２００３に、乗車時刻１０２１１２を乗車時刻２００４に、降車時刻１０２１２３を降車時刻２００５に、乗車駅１０２１１３を乗車駅２００６に、降車駅１０２１１４を降車駅２００７に、列車名１０２１１６を列車名２００８に、列車設備１０２１１６を列車設備２００９に列車番号１０２１２１を列車番号２０１０に、運賃１０２１２６を運賃２０１１に、残り在庫１０２１２２を残り在庫２０１２に設定する。これにより、一つのエントリに関する回答２００が生成される。

次いで、列車在庫照会処理部１０１２は、あらかじめ回答件数の最大値として設定されている端末回答最大エントリに達したか判別し（Ｓ１２１３）、最大エントリであると判定した場合（Ｓ１２１３、Ｙｅｓ）、ループエンドＦ１０２３２２をＯＮにし（Ｓ１２１５）、処理を終了する。最大エントリでないと判定した場合（Ｓ１２１３、Ｎｏ）、列車在庫照会処理部１０１２は乗車時刻をカウントアップし（Ｓ１２１４）、乗車時刻がループ終了条件になったら第４のループ処理を終了する（Ｓ１２１６）。同様に、列車在庫照会処理部１０１２は、列車設備がループ終了条件になったら第３のループ処理を終了し（Ｓ１２１７）、列車名がループ終了条件になったら第２のループ処理を終了し（Ｓ１２１８）、エントリ番号がループ終了条件になったら第１のループ処理を終了する（Ｓ１２１９）。

以上の在庫サーチ処理により、列車在庫管理装置１０において、操作端末３０から端末要求１００によって照会された条件に合致する列車の在庫があるか判定し、該当する列車在庫に関する端末回答２００を生成することができる。

次に、列車在庫管理装置１０における代案営業キロサーチ処理について説明する。図１４は、図１２に例示した全体処理フローにおける代案営業キロサーチ処理Ｓ１５を詳細に説明するためのフローチャートである。代案営業キロサーチ処理は、操作端末３０からの要求が乗降駅に関して代案の提示を許可している場合に、候補駅選定の数量的な基準となる営業キロを算定するために実行される。まず、列車在庫照会処理部１０１２は、端末要求１００に代案乗車駅名（始）１００９が設定されているか判定し（Ｓ１５０１）、設定されていた場合はＳ１５０２の処理に移る。代案乗車駅名（始）１００９が設定されていないと判定した場合（Ｓ１５０１）、列車在庫照会処理部１０１２は、代案乗車駅名（始）１００９に対する営業キロサーチは行わず、Ｓ１５０５の処理に移る。代案乗車駅名（始）１００９がある場合、列車在庫照会処理部１０１２は、列車在庫管理ファイル１０２１の検索キー１０２１１を端末要求１００の各情報を元に設定する（Ｓ１５０２）。ここでは、図７の例で示すと、代案乗車駅名（始）１００９の東京から乗車駅１００５の新横浜までの営業キロ数を算出しようとしている。列車在庫照会処理部１０１２は、乗車日１００２を乗車日１０２１１１に、乗車時刻１００３を乗車時刻１０２１１２に、代案乗車駅名（始）１００９（図７の例では東京）を乗車駅１０２１１３に、乗車駅１００５（図７の例では新横浜）を降車駅１０２１１４に、列車名１００７を列車名１０２１１５に、列車設備１００８を列車設備１０２１１６に設定する。列車在庫照会処理部１０１２は、Ｓ１５０２で設定した項目を検索キーとして、列車在庫管理ファイル１０２１をファイルサーチする（Ｓ１５０３）。その結果取得した情報のうち、営業キロ１０２１２４は代案提示に必要な情報のため、内部作業用エリア１０２３に代案乗車営業キロ上限１０２３１３として退避しておく（Ｓ１５０４）。

次に、列車在庫照会処理部１０１２は、端末要求１００に代案乗車駅名（終）１０３０が設定されているか判定し（Ｓ１５０５）、設定されていた場合はＳ１５０６の処理に移る。代案乗車駅名（終）１０３０が設定されていないと判定した場合（Ｓ１５０５、Ｎｏ）、列車在庫照会処理部１０１２は、代案乗車駅名（終）１０３０に対する営業キロサーチは行わず、Ｓ１５０６の処理に移る。代案乗車駅名（終）１０３０がある場合、列車在庫照会処理部１０１２は、列車在庫管理ファイル１０２１の検索キー１０２１１を端末要求１００の各情報を元に設定する（Ｓ１５０６）。ここでは、図７の例で示すと、乗車駅１００５の新横浜から代案乗車駅名（終）１０３０の小田原までの営業キロ数を算出しようとしている。列車在庫照会処理部１０１２は、乗車日１００２を乗車日１０２１１１に、乗車時刻１００３を乗車時刻１０２１１２に、乗車駅１００５（図７の例では新横浜）を乗車駅１０２１１３に、代案乗車駅名（終）１０３０（図７の例では小田原）を降車駅１０２１１４に、列車名１００７を列車名１０２１１５に、列車設備１００８を列車設備１０２１１６に設定する。列車在庫照会処理部１０１２は、Ｓ１５０６で設定した項目を検索キーとして、列車在庫管理ファイル１０２１をファイルサーチする（Ｓ１５０７）。その結果取得した情報のうち、営業キロ１０２１２４は代案提示に必要な情報のため、内部作業用エリア１０２３に代案乗車営業キロ下限１０２３１４として退避しておく（Ｓ１５０８）。

次に、列車在庫照会処理部１０１２は、端末要求１００に代案降車駅名（始）１０３１が設定されているか判定し（Ｓ１５０９）、設定されていた場合はＳ１５１０の処理を続ける。代案降車駅名（始）１０３１が設定されていないと判定した場合（Ｓ１５０９、Ｎｏ）、列車在庫照会処理部１０１は、代案降車駅名（始）１０３１に対する営業キロサーチは行わず、Ｓ１５１３の処理に移る。代案降車駅名（始）１０３１がある場合、列車在庫照会処理部１０１２は、列車在庫管理ファイル１０２１の検索キー１０２１１を端末要求１００の各情報を元に設定する（Ｓ１５１０）。ここでは、図７の例で示すと、代案降車駅名（始）１０３１の名古屋から降車駅１００６の京都までの営業キロを算出しようとしている。列車在庫照会処理部１０１２は、乗車日１００２を乗車日１０２１１１に、乗車時刻１００３を乗車時刻１０２１１２に、代案降車駅名（始）１０３１（図７の例では名古屋）を乗車駅１０２１１３に、降車駅１００６（図７の例では京都）を降車駅１０２１１４に、列車名１００７を列車名１０２１１５に、列車設備１００８を列車設備１０２１１６に設定する。列車在庫照会処理部１０１２は、Ｓ１５１０で設定した項目を検索キーとして、列車在庫管理ファイル１０２１をファイルサーチする（Ｓ１５１１）。その結果取得した情報のうち、営業キロ１０２１２４は代案提示に必要な情報のため、内部作業用エリア１０２３に代案降車営業キロ下限１０２３１６として退避しておく（Ｓ１５１２）。

次に、列車在庫照会処理部１０１２は、端末要求１００に代案降車駅名（終）１０３２が設定されているか判定し（Ｓ１５１３）、設定されていると判定した場合はＳ１５１４の処理に移る。代案降車駅名（終）１０３２が設定されていないと判定した場合（Ｓ１５１３、Ｎｏ）、列車在庫照会処理部１０１２は、代案降車駅名（終）１０３２に対する営業キロサーチは行わず、処理を終了する（Ｓ１５１７）。代案降車駅名（終）１０３２がある場合、列車在庫照会処理部１０１２は、列車在庫管理ファイル１０２１の検索キー１０２１１を端末要求１００の各情報を元に設定する（Ｓ１５１４）。ここでは、図７の例で示すと、降車駅１００６の京都から代案降車駅名（終）１０３２の新大阪までの営業キロを算出しようとしている。列車在庫照会処理部１０１２は、乗車日１００２を乗車日１０２１１１に、乗車時刻１００３を乗車時刻１０２１１２に、降車駅１００６を乗車駅１０２１１３に、代案降車駅名（終）１０３２を降車駅１０２１１４に、列車名１００７を列車名１０２１１５に、列車設備１００８を列車設備１０２１１６に設定する。列車在庫照会処理部１０１２は、Ｓ１５１４で設定した項目を検索キーとして、列車在庫管理ファイル１０２１をファイルサーチする（Ｓ１５１５）。その結果取得した情報のうち、営業キロ１０２１２４は代案提示に必要な情報のため、内部作業用エリア１０２３に代案降車営業キロ上限１０２３１５として退避しておく（Ｓ１５１６）。以上の代案営業キロサーチ処理により、乗車駅の許容範囲、降車駅の許容範囲が、それぞれ営業キロで定量的に設定されることになる。

次に、図１２の列車在庫管理装置１０の全体処理フローにおける代案駅サーチ処理Ｓ１６について説明する。図１５は、列車在庫管理装置１０の代案駅サーチＳ１６を詳細に説明するためのフローチャートである。代案駅サーチ処理は駅情報照会処理部１０１３によって実行され、代案営業キロサーチ処理で求められた乗降駅代案候補の営業キロ範囲により具体的に代案候補駅名を特定するための処理である。

Ｓ１６００で処理を開始すると、駅情報照会処理部１０１３は、内部作業用エリア１０２３において、（営業キロ１０２３１１）−（代案乗車営業キロ下限１０２３１４）を候補代案下限営業キロ１０２３１７に設定する（Ｓ１６０１）。これは図７の例で示すと、新横浜から京都の営業キロは１８０キロであり、新横浜から小田原までの営業キロを代案乗車営業キロ下限１０２３１４として３０キロと仮定すると、候補代案下限営業キロ１０２３１７は１８０−３０＝１５０キロとなる。同様に、駅情報照会処理部１０１３は、内部作業用エリア１０２３において、（営業キロ１０２３１１）＋（代案乗車営業キロ上限１０２３１３）を候補代案上限営業キロ１０２３１８に設定する（Ｓ１６０２）。これは図７の例で示すと、新横浜から京都の営業キロは１８０キロであり、東京から新横浜までの営業キロを代案乗車営業キロ上限１０２３１３として１０キロと仮定すると、候補代案上限営業キロ１０２３１８は１８０＋１０＝１９０キロとなる。次いで、駅情報照会処理部１０１３は、候補代案乗車駅を求めるループを候補代案下限営業キロ１０２３１７から候補代案上限営業キロ１０２３１８まで行う（Ｓ１６０３〜Ｓ１６０８）。駅情報照会処理部１０１３は、駅情報管理ファイル１０２２の検索キー１０２２１を端末要求１００と内部作業用エリア１０２３の各情報を元に設定する（Ｓ１６０４）。具体的には、乗車日１００２を乗車日１０２１１１に、降車駅１００６を駅１０２２１２に、列車名１００７を列車名１０２２１３に、列車設備１００８を列車設備１０２２１４に、候補代案下限営業キロ１０２３１７を営業キロ１０２２１５に、上り／下り１０２３１２の反対（上り／下り１０２３１２＝上りなら下り）を上り／下り１０２２１６に設定する。

駅情報照会処理部１０１３は、Ｓ１６０４で設定した項目を検索キーとして、駅情報管理ファイル１０２２をファイルサーチし（Ｓ１６０５）、取得した駅１０２２２１を候補代案乗車駅１０２３１９に設定する（Ｓ１６０６）。その後、駅情報照会処理部１０１３は、候補代案下限営業キロ１０２３１７を所定の単位（例えば１ｋｍ）でカウントアップし（Ｓ１６０７）、候補代案上限営業キロ１０２３１８に達したらループ処理を終了する（Ｓ１６０８）。Ｓ１６０３〜Ｓ１６０８の処理を図７の例で示すと、京都駅から上り東京方面に１５０キロ（候補代案下限営業キロ１０２３１７）の駅があった場合は候補代案乗車駅１０２３１９に設定する。１５０キロ（候補代案下限営業キロ１０２３１７）から営業キロの所定単位でカウントアップし、１９０キロ（候補代案上限営業キロ１０２３１８）に達するまでに一致した候補代案乗車駅１０２３１９をリストアップしていく処理になる。

次いで、駅情報照会処理部１０１３は、内部作業用エリア１０２３において、（営業キロ１０２３１１）−（代案降車営業キロ下限１０２３１６）を候補代案下限営業キロ１０２３１７に設定する（Ｓ１６０９）。これは図７の例で示すと、新横浜から京都の営業キロは１８０キロであり、名古屋から京都までの営業キロを代案降車営業キロ下限１０２３１６として３０キロと仮定すると、候補代案下限営業キロ１０２３１７は１８０−３０＝１５０キロとなる。同様に、駅情報照会処理部１０１３は、内部作業用エリア１０２３において、（営業キロ１０２３１１）＋（代案降車営業キロ上限１０２３１５）を候補代案上限営業キロ１０２３１８に設定する（Ｓ１６１０）。これは図７の例で示すと、新横浜から京都の営業キロは１８０キロであり、京都から新大阪までの営業キロを代案降車営業キロ上限１０２３１５として２０キロと仮定すると、候補代案上限営業キロ１０２３１８は１８０＋２０＝２００キロとなる。次いで、駅情報照会処理部１０１３は、候補代案乗車駅を求めるループを候補代案下限営業キロ１０２３１７から候補代案上限営業キロ１０２３１８まで行う（Ｓ１６１１〜Ｓ１６１６）。駅情報照会処理部１０１３は、駅情報管理ファイル１０２２の検索キー１０２２１を端末要求１００と内部作業用エリア１０２３の各情報を元に設定する（Ｓ１６１２）。具体的には、乗車日１００２を乗車日１０２１１１に、乗車駅１００５を駅１０２２１２に、列車名１００７を列車名１０２２１３に、列車設備１００８を列車設備１０２２１４に、候補代案下限営業キロ１０２３１７を営業キロ１０２２１５に、上り／下り１０２３１２を上り／下り１０２２１６に設定する。

駅情報照会処理部１０１３は、Ｓ１６１２で設定した項目を検索キーとして、駅情報管理ファイル１０２２をファイルサーチし（Ｓ１６１３）、取得した駅１０２２２１を候補代案降車駅１０２３２０に設定する（Ｓ１６１５）。その後、駅情報照会処理部１０１３は、候補代案下限営業キロ１０２３１７を所定の単位でカウントアップし（Ｓ１６１５）、候補代案上限営業キロ１０２３１８に達したらループ処理を終了する（Ｓ１６１６）。Ｓ１６１１〜Ｓ１６１６の処理を図７の例で示すと、新横浜から下り京都方面に１５０キロ（候補代案下限営業キロ１０２３１７）の駅があった場合は、それを候補代案降車駅１０２３２０に設定する。１５０キロ（候補代案下限営業キロ１０２３１７）から営業キロの所定単位でカウントアップし、２００キロ（候補代案上限営業キロ１０２３１８）に達するまでに一致した候補代案降車駅１０２３２０をリストアップしていく処理になる。

以上の代案駅サーチ処理により、端末要求１００で許容範囲とされた乗降駅が、営業キロの条件に基づいて抽出される。

次に、図１２の列車在庫管理装置１０の全体処理フローにおける代案在庫サーチ処理Ｓ１７について説明する。図１６は列車在庫管理装置１０の代案在庫サーチＳ１７を詳細に説明するためのフローチャートであり、列車在庫照会処理部１０１２によって実行される。まず、列車在庫照会処理部１０１２は、この処理を実行している時点で候補代案を求めるため処理であるため、内部作業用エリア１０２３で代案フラグ１０２３２３をＯＮする（Ｓ１７０１）。列車在庫照会処理部１０１２は、候補代案乗車駅１０２３１９のエントリ数分ループ処理を行う（Ｓ１７０２〜Ｓ１７０４）。このループ処理の中で、列車在庫照会処理部１０１２は、候補代案乗車駅１０２３１９を乗車駅１０２３２４に設定し（Ｓ１７０３）、図１３の在庫サーチを行う（Ｓ１２）。エントリ数分ループ処理を行った場合、候補代案乗車駅に対するループ処理は終了する（Ｓ１７０４）。この処理の内容は、代案乗車駅として抽出された乗車駅について、利用可能な列車在庫があるかを、在庫サーチ処理により調べるものである。

次いで、列車在庫照会処理部１０１２は、候補代案降車駅１０２３２０のエントリ数分ループ処理を行う（Ｓ１７０５〜Ｓ１７０７）。このループ処理の中で、列車在庫照会処理部１０１２は、候補代案降車駅１０２３２０を降車駅１０２３２５に設定し（Ｓ１７０６）、図１３の在庫サーチを行う（Ｓ１２）。エントリ数分ループ処理を行った場合、候補代案降車駅に対するループ処理は終了する（Ｓ１７０７）。この処理の内容は、代案降車駅として抽出された降車駅について、利用可能な列車在庫があるかを、在庫サーチ処理により調べるものである。

以上の代案在庫サーチ処理により、端末要求１００の設定による許容範囲にある代案乗降駅について、利用可能な列車在庫があるかを調べ、抽出された候補があれば操作端末３０を介して提示することができる。また、座席予約機能において共用されている列車在庫管理装置１０の列車在庫管理ファイル１０２１を参照することにより代案の乗降駅をサーチしているため、本発券支援システム１専用の駅データを保持する必要がなく、新線開通、新駅設置などに伴うデータ修正を独自に実施する必要がない。

次に、以上説明した本実施形態の発券支援システム１の動作をより理解しやすくするために、旅客要望の処理例について説明する。ここでは、旅客の要望として、「１２月３０日の１８時に新横浜から乗車して新大阪まで行きたい。列車はのぞみ、ひかり、こだまのいずれでもよく、新横浜乗車で適当な列車がなければ乗車駅は東京〜小田原間でよい」と想定した。なお、以下の説明は単なる例示であって、これにより本発明がなんら制約されるものではない。

図１７は、第一希望の乗車駅である新横浜について、希望の乗車時刻、列車名で照会した結果を例示している。図１７の例では、いずれの条件でも残り在庫が０であり、条件を満たす列車がないことを示している。

図１７の結果を受けて、図１８では、旅客が乗車駅として許容する範囲の東京から小田原について、第一希望の新横浜からその両端駅である東京、小田原までの営業キロを求めている。図１９では、許容される乗車駅の範囲が、営業キロを用いて、新大阪側に（１８０−３０）キロ、東京側に（１８０＋１０）キロと表わされることがわかる。その結果、許容される乗車駅は、東京、品川、新横浜、小田原の４駅となる。

図２０に、旅客の要望に、許容乗車駅（代案乗車駅）として抽出された駅を加えて、在庫サーチを実行した結果を例示している。図２０では、東京乗車のこだま１本と、小田原乗車のひかり、こだま各１本が旅客要望を満たす列車として抽出されている。図２１は図２０で抽出された代案を操作端末３０に表示出力したイメージであり、抽出された列車を到着時刻でソートして表示している。この表示順は、乗車駅の営業キロ等他の項目で決定してもよい。以上のように、本実施形態によれば、旅客要望に沿った列車を乗降駅の代案を含めて提示することができ、発券処理の円滑化に資する等の効果を得ることができる。なお、本実施形態では代案乗降駅の抽出を、旅客要望の許容範囲から営業キロに換算して処理しているが、旅客が指定した範囲に含まれる駅を、列車在庫管理ファイル１０２１を参照して直接抽出するようにしてもよい。

以上、本実施形態によれば、旅客の要望に合わせた乗降駅の代案を受け付けることで、旅客一人一人のニーズに沿った代案列車を提示することが可能となり、旅客の満足度向上につながる。また、新駅ができた場合でも、本発券支援システム独自で駅データの修正、登録作業を行う必要がなく、システム保守業務を簡素化することができる。

以上、本発明の実施の形態について、その実施の形態に基づき具体的に説明したが、これに限定されるものではなく、その要旨を逸脱しない範囲で変更可能である。

１ 発券支援システム
１０列車在庫管理装置
２０ 通信ネットワーク
３０ 操作端末
１０１ 処理部（列車在庫管理装置１０）
１０２ 記憶部（列車在庫管理装置１０）
１０１１ 送受信処理部
１０１２ 列車在庫照会処理部
１０１３ 駅情報照会処理部
１０２１ 列車在庫管理ファイル
１０２２ 駅情報管理ファイル
１０２３ 内部作業用エリア
３０１ 処理部（操作端末３０）
３０１１ 入出力処理部
３０１２ 送受信処理部（操作端末３０）
３０３ 入出力デバイス

Claims (5)

1. 列車の利用を希望する場合の希望利用日、希望乗車時刻、希望乗車駅、及び希望降車駅の情報を少なくとも含む利用希望情報を受け付ける入力部と、
   利用可能な日付ごとに、利用可能な列車ごとの各停車駅の出発時刻及び到着時刻、列車ＩＤ、及び当該列車の各停車駅における利用可能空席数の情報を少なくとも含む列車在庫情報を記憶している列車在庫情報記憶部と、
   前記入力部からの前記利用希望情報を受信して、前記列車在庫情報記憶部に記憶されている前記列車在庫情報と対照し、前記利用希望情報の条件を満たす列車在庫情報があると判定した場合、当該列車在庫情報の少なくとも一部を送信する照会処理部と、
   前記照会処理部からの前記列車在庫情報に関する情報を受信して、当該列車在庫情報に関する情報を出力する出力部とを備え、
   前記入力部は、前記希望乗車駅及び前記希望降車駅の少なくともいずれかについて、許容可能な利用駅の範囲を受け付けて前記利用希望情報に含めることができるように構成され、
   前記照会処理部は、前記利用希望情報に前記許容可能な利用駅の範囲が含まれていると判定し、前記希望乗車駅又は前記希望降車駅の条件を満たす列車在庫情報がないと判定した場合、前記許容可能な利用駅の範囲に含まれる前記停車駅により前記列車在庫情報に利用可能な列車があるか検索する、
   発券支援システム。
2. 請求項１に記載の発券支援システムであって、
   前記利用希望情報に含まれる前記許容可能な利用駅の範囲が、当該範囲の両端駅によって示されており、
   前記列車在庫情報は、各前記停車駅の位置を示す営業キロ情報を含んでおり、
   前記照会処理部は、前記列車在庫情報を参照して、前記希望乗車駅又は前記希望降車駅と、前記利用希望情報に含まれる前記範囲の両端駅の位置を示す営業キロ情報を取得し、前記営業キロ情報が前記範囲の両端駅の営業キロ情報の範囲に含まれる前記停車駅を取得し、当該停車駅により前記列車在庫情報に利用可能な列車があるか検索する、
   発券支援システム。
3. 請求項１に記載の発券支援システムであって、
   前記入力部は、入力された前記利用希望情報を表示する表示部を備え、当該表示部が、前記許容可能な利用駅の範囲を示す前記範囲の両端駅を表示する、
   発券支援システム。
4. 請求項１に記載の発券支援システムであって、
   前記利用希望情報は、前記入力部から入力可能な、利用を希望する列車名を含み、
   前記列車在庫情報は、利用可能な列車について前記列車名と、当該列車名の列車の停車駅とを対応させて記憶している、
   発券支援システム。
5. プロセッサとメモリとを備えるコンピュータシステムによって実行される発券支援方法であって、
   列車の利用を希望する場合の希望利用日、希望乗車時刻、希望乗車駅、及び希望降車駅の情報を少なくとも含む利用希望情報を受け付け、
   利用可能な日付ごとに、利用可能な列車ごとの各停車駅の出発時刻及び到着時刻、列車ＩＤ、及び当該列車の各停車駅における利用可能空席数の情報を少なくとも含む列車在庫情報を記憶し、
   前記利用希望情報を、記憶されている前記列車在庫情報と対照し、前記利用希望情報の条件を満たす列車在庫情報があると判定した場合、当該列車在庫情報の少なくとも一部を送信し、
   前記列車在庫情報に関する情報を受信して、当該列車在庫情報に関する情報を出力し、
   前記希望乗車駅及び前記希望降車駅の少なくともいずれかについて、許容可能な利用駅の範囲を受け付けて前記利用希望情報に含めることができるように構成され、
   前記利用希望情報に前記許容可能な利用駅の範囲が含まれていると判定し、前記希望乗車駅又は前記希望降車駅の条件を満たす列車在庫情報がないと判定した場合、前記許容可能な利用駅の範囲に含まれる前記停車駅により前記列車在庫情報に利用可能な列車があるか検索する、
   発券支援方法。

Images