JPWO2013014970A1 - 端末制御装置及び端末制御プログラム - Google Patents

Abstract

乗り物のスケジュール変更が発生した場合に、スケジュール変更に伴って必要となる手続を遅滞なく行うことができるようにすることを目的とする。スケジュールが変更されていない場合には、複数の手続を複数の手続端末１のどの手続端末１でも乗客が行えるように手続端末１を制御し、スケジュールが変更された場合には、複数の手続端末１のうちの少なくとも一部の手続端末１では複数の手続のうちの乗り物に関する特定の手続だけが行えるように手続端末１を制御する。

Description

この発明は、乗り物の乗客が乗り物に関する手続をするための手続端末を制御する技術に関する。

鉄道や航空機などの交通機関を利用する場合、交通機関を利用する乗客が必要に応じて立ち寄り、何らかの手続を行う端末（手続端末）が存在する。手続端末には、例えば、チケットの発行、チケットの払い戻し、乗る便の変更等の利用する乗り物に関係する複数の手続が行えるものや、乗り物に関係する手続だけでなく、乗り物の出発を待つ間に利用する施設の検索等の乗り物とは関係しない手続も行えるものもある。

特開２００１−１１８１８１号公報 特開２００２−１０９６７９号公報

乗り物の遅延や運休等の乗り物のスケジュール変更が発生した場合、チケットの払い戻しや乗る便の変更等の一部の手続を行う乗客が、通常時に比べ多くなる。チケットの払い戻しや乗る便の変更等の一部の手続を行う乗客は、これらの手続を早急に行うことを望むのが一般的である。この場合に、例えば施設の検索等の他の手続を行う乗客により手続端末の多くが使用されてしまうと、チケットの払い戻しや乗る便の変更等の一部の手続を早急に行えなくなってしまう。
この発明は、乗り物のスケジュール変更が発生した場合に、スケジュール変更に伴って必要となる手続を遅滞なく行うことができるようにすることを目的とする。

この発明に係る端末制御装置は、
乗り物の乗客が前記乗り物に関する手続を含む複数の手続を行うための手続端末であって、並べて設けられた複数の手続端末を制御する端末制御装置であり、
前記乗り物のスケジュールが変更されたか否かを判定する変更判定部と、
前記スケジュールが変更されていないと前記変更判定部が判定した通常時には、前記複数の手続を前記複数の手続端末のどの手続端末でも前記乗客が行えるように前記複数の手続端末を制御し、前記スケジュールが変更されたと前記変更判定部が判定した変更時には、前記複数の手続端末のうちの少なくとも一部の手続端末である特定端末では前記複数の手続のうちの前記乗り物に関する特定の手続だけが行えるように前記複数の手続端末を制御する端末制御部と
を備えることを特徴とする。

前記端末制御部は、前記通常時には、前記複数の手続のいずれかの手続を行うための手続情報を前記手続端末が表示する際、合わせて関連情報を前記手続端末に表示させ、前記変更時には、前記手続情報を前記手続端末が表示する際、広告を前記手続端末に表示させない
ことを特徴とする。

前記端末制御装置は、さらに、
前記変更時に、スケジュールが変更された便数をカウントして、カウントした便数に応じて、前記複数の手続端末のうちの何台の手続端末を前記特定端末にするかを決定する台数決定部
を備え、
前記端末制御部は、前記台数決定部が決定した台数の手続端末を前記特定端末にする
ことを特徴とする。

前記端末制御装置は、さらに、
前記変更時に、スケジュールが変更された便の予約人数に応じて、前記複数の手続端末のうちの何台の手続端末を前記特定端末にするかを決定する台数決定部
を備え、
前記端末制御部は、前記台数決定部が決定した台数の手続端末を前記特定端末にする
ことを特徴とする。

前記端末制御装置は、さらに、
前記変更時に、スケジュールが変更された便の乗り場の位置を特定する位置特定部
を備え、
前記端末制御部は、前記位置特定部が特定した乗り場の位置に応じて、前記複数の手続端末のうちのどの手続端末を前記特定端末にするかを決定する
ことを特徴とする。

前記端末制御装置は、さらに、
前記複数の手続端末の各手続端末に対応して設けられた表示装置を制御する表示装置制御部であって、前記変更時に、対応する手続端末で行える手続を表示装置に表示させる表示装置制御部
を備えることを特徴とする。

前記端末制御部は、前記変更時には、前記特定端末のうちの一部の手続端末では、前記複数の手続のうちの前記乗り物に関する第１の手続だけが行えるようにするとともに、残りの特定端末では、前記複数の手続のうちの前記乗り物に関する第２の手続であって、前記第１の手続とは異なる第２の手続だけが行えるようにする
ことを特徴とする。

前記端末制御装置は、さらに、
前記乗り物のスケジュールを示すスケジュール情報を記憶装置に記憶するスケジュール記憶部
を備え、
前記変更判定部は、前記乗り物の新しいスケジュール情報を取得して、取得した新しいスケジュール情報と、前記スケジュール記憶部が記憶したスケジュール情報とを比較することにより、前記乗り物のスケジュールが変更されたか否かを判定する
ことを特徴とする。

前記変更判定部は、災害が発生したか否かを判定し、
前記端末制御部は、前記変更判定部が災害が発生したと判定した場合には、前記特定端末では前記特定の手続だけが行えるように前記各手続端末を制御する
ことを特徴とする。

前記変更判定部は、災害が発生したか否かを判定し、
前記端末制御部は、前記変更判定部が災害が発生したと判定した場合には、前記手続端末の通常の手続機能を停止し、避難経路を表示させる
ことを特徴とする。

前記端末制御装置は、さらに、
乗客を特定可能な個人ＩＤであって、前記手続端末から送信された個人ＩＤに基づき、前記乗り物についての予約情報を蓄積しているサーバに対して、前記乗客の前記乗り物についての予約情報を照会する情報照会部
を備え、
前記端末制御部は、個人ＩＤを送信した手続端末を、前記情報照会部が照会した前記予約情報に関する手続だけが行えるように制御する
ことを特徴とする。

前記端末制御部は、前記個人ＩＤと、予約情報によって特定される前記乗客が予約した乗り物の出発時間までの残り時間と、個人ＩＤを送信した手続端末の位置とに基づき、提供するサービスを制御する
ことを特徴とする。

前記端末制御部は、前記通常時において、前記乗り物の予約人数から計算される前記手続端末の混雑度が所定の混雑度よりも高い場合、前記特定端末では前記特定の手続だけが行えるように前記各手続端末を制御する
ことを特徴とする。

この発明に係る端末制御プログラムは、
乗り物の乗客が前記乗り物に関する手続を含む複数の手続を行うための手続端末であって、並べて設けられた複数の手続端末を制御する端末制御プログラムであり、
前記乗り物のスケジュールが変更されたか否かを判定する変更判定処理と、
前記スケジュールが変更されていないと前記変更判定処理で判定した通常時には、前記複数の手続を前記複数の手続端末のどの手続端末でも前記乗客が行えるように前記複数の手続端末を制御し、前記スケジュールが変更されたと前記変更判定処理で判定した変更時には、前記複数の手続端末のうちの少なくとも一部の手続端末である特定端末では前記複数の手続のうちの前記乗り物に関する特定の手続だけが行えるように前記複数の手続端末を制御する端末制御処理と
をコンピュータに実行させることを特徴とする。

この発明に係る端末制御装置は、乗り物のスケジュール変更があった場合に、複数の手続端末のうちの一部を、乗り物に関する特定の手続だけが行えるように制限する。これにより、スケジュール変更に伴って必要となる手続を乗客が遅滞なく行うことが可能となる。

手続端末１の説明図。 航空機にスケジュール変更が発生している変更時における手続端末１の説明図。 通常時において表示部３に表示される情報の説明図。 変更時において表示部３に表示される情報の説明図。 実施の形態１に係る端末制御装置１０の機能構成を示すブロック図。 実施の形態１に係る端末制御装置１０の処理の流れを示すフローチャート。 実施の形態２に係る端末制御装置１０の機能構成を示すブロック図。 実施の形態２に係る端末制御装置１０の処理の流れを示すフローチャート。 実施の形態３に係る端末制御装置１０の機能構成を示すブロック図。 実施の形態３に係る端末制御装置１０の処理の流れを示すフローチャート。 実施の形態４に係る通常時において表示部３に表示される情報の説明図。 実施の形態４に係る変更時において表示部３に表示される情報の説明図。 実施の形態５に係る端末制御装置１０の機能構成を示すブロック図。 実施の形態５に係る端末制御装置１０の処理の流れを示すフローチャート。 実施の形態６に係る端末制御装置１０の機能構成を示すブロック図。 実施の形態６において表示部３に表示される情報の説明図。 実施の形態６に係る端末制御装置１０の処理の流れを示すフローチャート。 端末制御装置１０や手続端末１のハードウェア構成の一例を示す図。

実施の形態１．
ここでは、航空機の乗客等が航空機に関する手続等を行う手続端末１であって、空港内に設置された手続端末１を例として説明する。なお、手続端末１は、これに限らず、電車等の他の乗り物に関する手続を行うための端末であってもよいし、電車の駅構内やバスターミナル等の他の場所に設置された端末であってもよい。

図１は、手続端末１の説明図である。
空港内には、複数の手続端末１が並べて設置され、各手続端末１の上には、その手続端末１に対応付けられた表示装置２が設置されている。図１では、５台の手続端末１が並べて設置され、その上に各手続端末１に対応した５台の表示装置２が設置されている。各手続端末１は、情報を表示するＬＣＤ等の表示部３と、利用者が情報を入力するキーボードやカードリーダ等の入力部４とを備える。なお、表示装置２は、必ずしも手続端末１と一対でなくてもよく、設置場所に応じて、一部の手続端末１だけに設置されていてもよいし、手続端末１のみで構成してもよい。
航空機に遅延、欠航等のスケジュール変更が発生していない通常時には、チケットの発行、チケットの払い戻し、搭乗便の変更等の航空機に関係する複数の手続や、空港内の施設検索等の航空機に関係しない複数の手続を、どの手続端末１でも行える。また、通常時には、表示装置２には、対応する手続端末１とは関係なく、各便の搭乗口や出発時刻等を示すフライト情報や、各地の気象情報等を表示している。

図２は、航空機にスケジュール変更が発生している変更時における手続端末１の説明図である。
航空機にスケジュール変更が発生した場合、複数の手続端末１のうちの少なくとも一部の手続端末１（特定端末）は、航空機に関係する特定の手続だけが行えるように機能が制限される。また、各手続端末１に対応する表示装置２には、対応する手続端末１で行える手続を表す情報が表示される。
図２では、５台の手続端末１のうちの３台の手続端末１が特定の手続だけが行えるように機能制限されている。特に、１台の手続端末１はチケットの払い戻しだけが行え、２台の手続端末１は搭乗便の変更だけが行えるように機能制限されている。残りの２台は全ての手続が行える状態のままである。

航空機にスケジュール変更が発生している場合には、チケットの払い戻しや搭乗便の変更を行う乗客が多くなる。
全ての手続端末１で全ての手続が行える状態では、施設の検索を行う利用者等によって手続端末１が使用されてしまい、チケットの払い戻しや搭乗便の変更を早急に行うことができなくなってしまう虞がある。
しかし、一部の手続端末１をチケットの払い戻しや搭乗便の変更だけを行えるように機能制限することで、チケットの払い戻しや搭乗便の変更を遅滞なく行うことが可能となる。

図３は、通常時において表示部３に表示される情報の説明図である。
通常時には、表示部３は、各手続を行うための手続情報を表示する手続情報表示部５と、広告を表示する広告表示部６とに分割される。つまり、表示部３には、手続情報と広告とが表示される。
特に、広告表示部６には、手続情報表示部５に表示される情報と関連する広告が表示される。関連する広告とは、例えば、施設検索でレストランの検索が行われる場合には、レストランの広告のことである。関連する広告が存在しない場合には所定の広告が表示される。
また広告表示部６が表示する情報は、広告だけでなく特定の場所までの地図や案内等であってもよい。広告、地図、案内等を含めて手続情報と関連する関連情報と言う。

図４は、変更時において表示部３に表示される情報の説明図である。
変更時には、広告表示部６が設けられず、手続情報表示部５だけが設けられる。つまり、変更時には広告は表示されず、手続情報だけが表示される。また、機能が制限される手続端末１では、行えない手続を示すボタンは押せないようになっている（図４ではボタンが網掛としている）。
変更時に広告を表示しないのは、広告を見ることにより手続端末１の使用時間が長くなり、手続端末１が混雑することを防止するためである。また、急いでいる場合に広告を見ることで不快に感じる乗客がいる場合があるためである。
なお、広告表示部６を設けないのは、機能が制限される手続端末１だけとし、全ての手続が行える手続端末１では通常時と同様に広告表示部６を設けてもよい。

図５は、実施の形態１に係る端末制御装置１０の機能構成を示すブロック図である。
端末制御装置１０は、手続端末１と表示装置２とを制御する装置である。端末制御装置１０は、情報記憶部１１、変更判定部１２、端末制御部１３、表示装置制御部１４を備える。
情報記憶部１１は、乗り物の運行予定を示すスケジュール情報を予め記憶するための記憶装置である。ここでは、情報記憶部１１には、スケジュール情報として、航空機の運航予定を示すフライトスケジュールが記憶される。変更判定部１２は、スケジュール変更が発生したか否かを処理装置により判定する。端末制御部１３は、各手続端末１を制御する。表示装置制御部１４は、各表示装置２を制御する。

図６は、実施の形態１に係る端末制御装置１０の処理の流れを示すフローチャートである。
図６に示す処理は、空港の営業時間中、所定の時間毎に実行される。なお、図６に示す処理の開始前に、情報記憶部１１にはその日のフライトスケジュールが記憶される。

（Ｓ１１：変更判定処理）
変更判定部１２は、最新のフライトスケジュールを取得する。例えば、フライトスケジュールを管理する外部のサーバから、ネットワークを介して最新のフライトスケジュールを取得する。あるいは、管理者によって入力されたフライトスケジュールを取得する。変更判定部１２は、情報記憶部１１に記憶されたフライトスケジュールと、最新のフライトスケジュールとを比較して、スケジュール変更が発生したか否かを処理装置により判定する。
スケジュール変更が発生したと判定した場合（Ｓ１１でＹＥＳ）、処理をＳ１２へ進める。一方、スケジュール変更が発生していないと判定した場合（Ｓ１１でＮＯ）、処理を終了する。スケジュール変更が発生していない場合には、上述したように、全ての手続端末１で全ての手続を行うことができる。

（Ｓ１２：端末制御処理）
端末制御部１３は、スケジュール変更が発生したと変更判定部１２が判定した場合、予め定められた一部の手続端末１は、予め定められた特定の手続だけが行えるように、各手続端末１を制御する。また、端末制御部１３は、表示部３に広告が表示されないように、各手続端末１を制御する。
例えば、端末制御部１３は、ネットワークを介して各手続端末１へその手続端末１で行える手続を示す機能制限情報を送信する。手続端末１は、機能制限情報を受信すると、受信した機能制限情報が示す手続だけが行えるように機能を制限するとともに、広告の表示を止める。

（Ｓ１３：表示装置制御処理）
表示装置制御部１４は、対応する手続端末１で行える手続を示す情報を表示するように、各表示装置２を制御する。
例えば、表示装置制御部１４は、ネットワークを介して各表示装置２へその表示装置２に表示させる表示情報を送信する。表示装置２は、表示情報を受信すると、受信した表示情報を表示する。

なお、スケジュール変更が発生した便が出発した場合、あるいは、スケジュール変更が発生した便が出発して所定の時間が経過した場合、あるいは、スケジュール変更が発生してから所定の時間が経過した場合には、端末制御部１３は手続端末１の機能制限を解除し、広告も表示されるようにする。また、表示装置制御部１４は表示装置２に表示する情報も通常時に表示される情報に切り替える。
各便が出発したことを示す情報は、外部のシステムから取得すればよい。

以上のように、実施の形態１に係る端末制御装置１０は、スケジュール変更が発生した場合に、少なくとも一部の手続端末１は航空機に関する特定の手続だけを行えるように機能を制限する。これにより、スケジュール変更が発生した場合に、チケットの払い戻しや搭乗便の変更などを遅滞なく行うことが可能となり、利用者の利便性を高くすることができる。

なお、上記説明では、端末制御部１３は、通常時どの手続端末１でも全ての手続を行えるとした。しかし、通常時に各手続端末１で実施できる手続は、手続端末１毎に定められており、実施できる手続は手続端末１毎に異なっていてもよい。

また、情報記憶部１１に記憶されているスケジュール情報に関する条件が設定された条件テーブル（図示せず）を設け、スケジュール情報が条件テーブルに設定された条件を満たす場合は、通常時でも手続端末１の機能制限を行うようにしてもよい。
例えば、手続端末１の混雑度が条件テーブルに設定された混雑度以上となることが想定される場合、予め定めた手続端末１では、予め定めた特定の手続だけが行えるように、各手続端末１を制御してもよい。各時刻における手続端末１の混雑度は、その日の所定の時間毎の便数及び各便の予約人数から予測計算することが可能である。つまり、便数や予約人数等の条件が条件テーブルに設定された条件を満たす場合、予め定めた手続端末１では、予め定めた特定の手続だけが行えるように、各手続端末１を制御すればよい。例えば、当日の便数の総数が一定量以上のときは、予め定めた手続端末１の機能をチェックイン機能に限定するように制御すればよい。
このように制御することで、便数または予約人数で把握できる繁忙期には、空港全体の混雑が予想されるため、手続端末１の一部をチェックイン端末として代行することで、混雑時のチェックイン端末での滞留を緩和する効果が得られる。

実施の形態２．
実施の形態２では、１箇所に並べて設置された手続端末１のうち、何台の手続端末１の機能を制限するかを決定する方法について説明する。

チケットの払い戻しや搭乗便の変更等の一部の手続を行う乗客は、スケジュール変更が発生した便数が多くなるほど、多くなると考えられる。したがって、スケジュール変更が発生した便数が多くなるほど、チケットの払い戻しや搭乗便の変更等の一部の手続だけを行える手続端末１の台数を増やす必要がある。

図７は、実施の形態２に係る端末制御装置１０の機能構成を示すブロック図である。
実施の形態２に係る端末制御装置１０は、図５に示す実施の形態１に係る端末制御装置１０の機能に加え、台数決定部１５を備える。他は、実施の形態１に係る端末制御装置１０と同じである。

図８は、実施の形態２に係る端末制御装置１０の処理の流れを示すフローチャートである。実施の形態２に係る端末制御装置１０の処理について、図６に示す実施の形態１に係る端末制御装置１０の処理と異なる部分を中心に説明する。

Ｓ２１は、図６のＳ１１と同様である。

（Ｓ２２：台数決定処理）
スケジュール変更が発生したと判定された場合（Ｓ２１でＹＥＳ）、台数決定部１５は、スケジュール変更が発生した便数をカウントし、カウントされた便数に応じて、機能を制限する手続端末１の台数を決定する。
例えば、台数決定部１５は、スケジュール変更が発生した便数に応じて、設置された手続端末１のうち何割の手続端末１の機能を制限するかを予め記憶装置に記憶しておく。また、台数決定部１５は、設置された手続端末１の台数を予め記憶装置に記憶しておく。そして、台数決定部１５は、スケジュール変更が発生した便数と、設置された手続端末１の台数とから、機能を制限する手続端末１の台数を算出し、決定する。

（Ｓ２３：端末制御処理）
Ｓ２３は、図６のＳ１２と同様である。但し、端末制御部１３は、Ｓ２２で決定された台数の手続端末１について、予め定められた特定の手続だけが行えるように制御する。

Ｓ２４は、図６のＳ１３と同様である。

なお、Ｓ２２では、台数決定部１５は、行える手続毎に手続端末１の台数を決定してもよい。つまり、台数決定部１５は、チケットの払い戻しだけが行える手続端末１を何台とし、搭乗便の変更だけが行える手続端末１を何台とするかを決定してもよい。
例えば、台数決定部１５は、スケジュール変更が発生した便数に応じて、設置された手続端末１のうち何割の手続端末１をチケットの払い戻しだけが行える手続端末１とし、何割の手続端末１を搭乗便の変更だけが行える手続端末１とするかを予め記憶装置に記憶しておく。また、台数決定部１５は、設置された手続端末１の台数を予め記憶装置に記憶しておく。そして、台数決定部１５は、スケジュール変更が発生した便数と、設置された手続端末１の台数とから、各手続だけが行える手続端末１の台数を算出する。

また、台数決定部１５は、スケジュール変更が発生した便の予約人数を考慮して、機能を制限する手続端末１の台数を決定してもよい。台数決定部１５は、スケジュール変更が発生した便と、その便の予約人数を特定する。そして、スケジュール変更が発生した全ての便についての合計予約人数に応じて、機能を制限する手続端末１の台数を決定する。
例えば、台数決定部１５は、スケジュール変更が発生した全ての便についての合計予約人数に応じて、設置された手続端末１のうち何割の手続端末１の機能を制限するかを予め記憶装置に記憶しておく。また、台数決定部１５は、設置された手続端末１の台数を予め記憶装置に記憶しておく。そして、台数決定部１５は、スケジュール変更が発生した全ての便についての合計予約人数と、設置された手続端末１の台数とから、機能を制限する手続端末１の台数を算出し、決定する。
機能を制限する手続端末１の台数ではなく、各手続だけが行える手続端末１の台数を決定する場合にも、スケジュール変更が発生した便の予約人数を考慮してもよい。
なお、予約人数は、例えば、チケット予約システム等の他のシステムによって管理しているものを取得すればよい。

また、台数決定部１５は、複数の箇所に手続端末１が並べて設置されている場合、設置箇所毎に機能を制限する手続端末１の台数を決定する。
例えば、空港の入口付近に５台の手続端末１が設置されており、カウンター付近に１０台の手続端末１が設置されている場合、入口付近に設置された５台のうち何台の手続端末１の機能を制限するかを決定し、カウンター付近に設置された１０台のうち何台の手続端末１の機能を制限するかを決定する。
この場合、例えば、手続端末１の設置場所毎に、何割の手続端末１の機能を制限するかを予め記憶装置に記憶しておく。また、台数決定部１５は、設置場所毎に、設置された手続端末１の台数を予め記憶装置に記憶しておく。そして、台数決定部１５は、設置場所毎に、スケジュール変更が発生した便数と、その設置場所に設置された手続端末１の台数とから、機能を制限する手続端末１の台数を算出し、決定する。

また、スケジュール変更が発生した便が出発した場合、あるいは、スケジュール変更が発生した便が出発して所定の時間が経過した場合、あるいは、スケジュール変更が発生してから所定の時間が経過した場合には、台数決定部１５は、その便についてはスケジュール変更が発生した便から外して、機能を制限する手続端末１の台数を再決定する。

また、台数決定部１５は、空港の混雑度も考慮して、機能を制限する手続端末１の台数を決定してもよい。台数決定部１５は、スケジュール変更が発生した便数（あるいは、その便の搭乗人数）が同じであっても、空港が混雑しているほど、多くの手続端末１の機能を制限するようにしてもよい。
なお、混雑度は、例えば、空港に設置されたカメラやセンサ等から既存技術を用いて判断することが可能である。また、混雑度は、例えば、その日に出発する便の予約人数、あるいは、その日のその時間帯に出発する便の予約人数から推測してもよい。

以上のように、実施の形態２に係る端末制御装置１０は、スケジュール変更が発生した場合に、機能を制限する手続端末１の台数を適切に決定することができる。

実施の形態３．
実施の形態３では、１箇所に並べて設置された手続端末１のうち、どの位置に設置された手続端末１の機能を制限するかを決定する方法について説明する。

乗客は、自分が乗る便の搭乗口に近い方のゲートを通るのが一般的である。そして、乗客は、空港に到着すると、自分が通るゲートの方へ移動するのが一般的である。したがって、スケジュール変更が発生した便の搭乗口の位置に近い手続端末１を、チケットの払い戻しや搭乗便の変更等の一部の手続だけを行える手続端末１にするのがよい。

図９は、実施の形態３に係る端末制御装置１０の機能構成を示すブロック図である。
実施の形態３に係る端末制御装置１０は、図７に示す実施の形態２に係る端末制御装置１０の機能に加え、位置特定部１６を備える。他は、実施の形態２に係る端末制御装置１０と同じである。

図１０は、実施の形態３に係る端末制御装置１０の処理の流れを示すフローチャートである。実施の形態３に係る端末制御装置１０の処理について、図８に示す実施の形態２に係る端末制御装置１０の処理と異なる部分を中心に説明する。

Ｓ３１からＳ３２は、図８のＳ２１からＳ２２と同様である。

（Ｓ３３：位置特定処理）
位置特定部１６は、スケジュール変更が発生した便の搭乗口を特定し、並べて設けられた手続端末１のうち特定した搭乗口に近いゲート側に設置された手続端末１を、機能を制限する手続端末１として特定する。特に、位置特定部１６は、ゲート側に設置された手続端末１であって、Ｓ３２で決定された台数の手続端末１を機能を制限する手続端末１として特定する。
例えば、位置特定部１６は、各手続端末１の設置位置を示す位置情報を予め記憶装置に記憶しておく。そして、記憶した位置情報と、特定した搭乗口に近いゲートの位置とから、機能を制限する手続端末１を特定する。
なお、各便の搭乗口は、フライトスケジュールに含まれており、情報記憶部１１に記憶されている。

（Ｓ３４：端末制御処理）
Ｓ３４は、図８のＳ２３と同様である。但し、端末制御部１３は、Ｓ３３で特定された手続端末１について、予め定められた特定の手続だけが行えるように制御する。

Ｓ３５は、図６のＳ１３と同様である。

なお、Ｓ３２では、位置特定部１６は、Ｓ３２で決定した台数のうち所定の割合（例えば、８割）を、特定した搭乗口に近いゲート側に設置された手続端末１とし、残りの台数を前記ゲートと逆側に設置された手続端末１としてもよい。

また、位置特定部１６は、複数の便のスケジュール変更が発生した場合には、スケジュール変更が発生した各便の搭乗口に近いゲート側に設置された手続端末１のうち少なくとも所定台の手続端末１を、機能を制限する手続端末１として特定する。

以上のように、実施の形態３に係る端末制御装置１０は、スケジュール変更が発生した場合に、機能を制限する手続端末１の位置を適切に決定することができる。

なお、上記説明では、航空機の乗客等が航空機に関する手続等を行う手続端末１であって、空港内に設置された手続端末１を例として説明した。しかし、上述した通り、手続端末１は、これに限らず、電車等の他の乗り物に関する手続を行うための端末であってもよいし、電車の駅構内等の他の場所に設置された端末であってもよい。
例えば、手続端末１は、電車の駅に設置された券売機であってもよい。この場合、例えば、券売機は、チケットを販売するだけでなく、遅延証明書の発行等の手続を行ってもよい。そして、電車が遅延した場合には、一部の券売機を遅延証明書の発行だけを行うように機能制限してもよい。

また、上記説明では、一部の手続端末１の機能を制限するとした。この機能制限には、手続端末１の電源オフを含んでもよい。
例えば、一部の搭乗ゲートからの出発便がなくなった場合、その搭乗ゲートにつながる通路に並べて設置された手続端末１のうち、一部の手続端末１を電源オフするように制御してもよい。なお、一部の搭乗ゲートからの出発便がなくなったか否かは、フライト情報から判定することができる。
乗客数に応じて、動作させる手続端末１の台数を変更することで、稼動率の低い手続端末１を動作させておくことがなくなり、節電効果が得られる。

実施の形態４．
実施の形態４では、手続端末１で提供する情報提供サービスについて説明する。
情報提供サービスとは、携帯電話機、携帯ゲーム機等の携帯端末へ、クーポンやアプリケーションソフト、ゲームソフト、待ち受け画面等を提供するサービスである。例えば、手続端末１に携帯端末と通信する機能を設けておき、端末制御装置１０は通信機能を用いてクーポン等を携帯端末に提供する。

図１１は、通常時において表示部３に表示される情報の説明図である。
図１１では、手続情報表示部５には、情報提供サービスが「プレゼント」機能として表示される。通常時には、端末制御部１３は用意されている「プレゼント」機能が全て提供される。つまり、用意されているクーポンやアプリケーションソフト、ゲームソフト等がどれでも取得可能な状態である。

図１２は、変更時において表示部３に表示される情報の説明図である。
実施の形態４では「払い戻し」機能に加えて、「プレゼント」機能も選択可能となっている。しかし、この場合の「プレゼント」機能は、通常時と比較して、限定されたサービスとなる。つまり、用意されているクーポンやアプリケーションソフト、ゲームソフト等のうち、一部のみが取得可能な状態である。

実施の形態１で用いた図６のフローチャートで処理の流れを説明する。
Ｓ１１でスケジュール変更が発生しないと変更判定部１２が判定した場合（Ｓ１１でＮＯ）、端末制御部１３は用意されている「プレゼント」機能を全て提供するように制御する。一方、Ｓ１１で変更判定部１２がスケジュール変更が発生したと判定した場合（Ｓ１１でＹＥＳ）、Ｓ１２で端末制御部１３は「プレゼント」機能の一部だけを提供するように制御する。例えば、スケジュール変更が発生しない通常時は、待ち受け画面、ゲームソフト、店舗利用クーポン等が取得でき、スケジュール変更が発生した変更時には待ち受け画面だけが取得できるように機能を限定することが考えられる。

以上のように、実施の形態４に係る端末制御装置１０は、「プレゼント」機能で提供する情報をスケジュール変更と連動させて変更させることにより、必要な手続きを迅速に行わせながら、一定の乗客サービスを提供することが可能となる。

なお、繁忙期や混雑時間帯等、手続端末１利用の混雑が予想される時期や時間帯には、「プレゼント」機能を提供する手続端末１の台数を制限する、または提供する時間帯を制限する、または「プレゼント」機能で提供する情報を限定するように端末制御部１３が制御してもよい。これにより、一人の乗客が手続端末１を占有する時間を抑えることができる。

実施の形態５．
実施の形態５では、地震、火事、台風等の災害発生時の端末制御について説明する。
なお、航空機の出発地では通常の手続が可能で、到着地付近での地震、台風等の悪天により、航空機のスケジュール変更が発生した場合は、実施の形態１−４で説明した方法で、手続端末１を制御する。一方、航空機の出発空港内の火事や、空港を含む地域で地震が発生した場合には、以下に説明する方法で、手続端末１を制御する。

図１３は、実施の形態５に係る端末制御装置１０の機能構成を示すブロック図である。
実施の形態５に係る端末制御装置１０は、図５に示す実施の形態１に係る端末制御装置１０の機能に加え、災害情報記憶部１７を備える。他は、実施の形態１に係る端末制御装置１０と同じである。

図１４は、実施の形態５に係る端末制御装置１０の処理の流れを示すフローチャートである。実施の形態５に係る端末制御装置１０の処理について、図６に示す実施の形態１に係る端末制御装置１０の処理と異なる部分を中心に説明する。
（Ｓ４１：変更判定処理）
変更判定部１２は、最新の災害の特定情報を取得する。例えば、火事を検知する煙センサーや温度センサー、地震を検知する地震センサーによってセンシングされた情報を災害の特定情報として取得する。あるいは、管理者によって入力された災害の情報を災害の特定情報として取得する。
なお、災害情報記憶部１７には、発生した災害の特定情報と、手続端末１の制御情報とにより構成される災害情報が記憶されている。災害情報には、表示装置２の制御情報を含んでいてもよい。災害の特定情報は、各種センサーからセンシングされた数値に対応する基準となる数値と、管理者からの入力に対応する災害の事象との組み合わせで構成される。手続端末１及び表示装置２の制御情報は、発生した災害に対応する制御内容である。
具体的な例としては、「火事発生」（管理者からの入力に対応）、「煙検知を示す具体的な数値」（センサーからの入力に対応、数値ではなく「煙検知あり」、または「煙検知なし」の情報であってもよい）、「検知場所」を含む特定情報と、「検知場所が含まれるフロアは手続端末１に避難経路を表示」し、「表示装置２には「避難経路」という文字を表示」するという制御情報とが情報記憶部１１に記憶される。
変更判定部１２は、情報記憶部１１に記憶された災害情報と、入力された災害発生情報とを比較して、手続端末１及び表示装置２を制御する必要がある災害が発生したか否かを処理装置により判定する。例えば、管理者から「火事発生」という災害発生情報の入力、あるいは、センサーから煙検知を示す具体的な数値の災害発生情報の入力を受け付けると、記憶されている災害情報の一部と一致するため、変更判定部１２は災害が発生したと判定する。
災害が発生したと判定した場合（Ｓ４１でＹＥＳ）、処理をＳ４２へ進める。一方、災害が発生していないと判定した場合（Ｓ４１でＮＯ）、処理を終了する。手続端末１及び表示装置２を制御する必要がある災害が発生していないと判定した場合には、手続端末１では全ての手続を行うことができ、広告表示もされる。

Ｓ４２及びＳ４３は、図６のＳ１２及びＳ１３と同様である。

なお、例えば空港で火事が発生した場合は、空港内にいる人を速やかに危険がない場所に誘導する必要がある。そのため、Ｓ４２では、手続端末１の全ての手続機能を停止してもよい。この場合、例えば、手続端末１には避難経路を表示し、表示装置２には「避難経路」という文字を表示する。また手続端末１に、災害の発生状況、経過状況や物資の配給情報等を表示してもよい。
なお、避難経路は、災害発生場所を回避する安全な経路を災害情報記憶部１７に予め記憶しておき、災害情報を検知した検知場所に基づき、端末制御部１３は避難経路を表示する。安全確保を確実に行うため、端末制御部１３は避難経路を表示する前に、決定した避難経路を管理者に提示し、管理者から表示可否の入力を受け付けてから表示するように構成しても良い。
また、情報記憶部１１内に、検知場所に対応して、制御する手続端末１及び表示装置２を定めてもよい。

端末制御装置１０は、図１４に示す処理を繰り返し実行するので、災害発生後経過に対応して、制御情報を変更させることが可能である。例えば、火事発生の場合、検知場所から入力されるセンサーの値が正常値に近づいてきたときは、実施の形態２や実施の形態３で説明した制御方法と同様な方法により、１箇所に並べて設置された手続端末１のうち、所定台数の手続端末１の機能制限を解除し、また所定台数の手続端末１の機能を所定の機能（例えば、払い戻しや便変更の手続き）に制御してもよい。さらに、災害の発生場所から入力されるセンサーの値が正常値に近づいてきたときは、検知場所付近は変わらず避難経路を表示するように制御し、災害の発生場所から離れた場所（例えば、災害の発生場所が南ターミナルのときは北ターミナル）は所定台数の手続端末１の機能制限を解除し、また所定台数の手続端末１を一部の機能（例えば、払い戻しや便変更の手続き）に制限してもよい。
センサーの値が正常値に近づいてきたときではなく、何台のセンサーから災害の発生を示す情報を取得したかに応じて、機能制限の解除を行ってもよい。例えば、Ｓ４１の変更判定処理で、一定数（例えば３台）以上のセンサーから「煙検知あり」の情報を取得した場合に災害が発生したと判定するように構成している場合、一定数未満のセンサーからだけ「煙検知あり」の情報を取得するようになったときは、災害が落ち着いてきたと判定することができる。

以上のように、実施の形態５に係る端末制御装置１０は、災害が発生した場合に、所定の手続端末１の機能と表示装置２の表示とを制御する。また、災害が発生した場合に、一部の手続端末１を誘導灯として利用する。このように機能することにより、災害発生時の迅速な乗客の誘導を助長することが期待できる。

なお、図１４に示した処理は、実施の形態１−４で示したいずれかの処理と連動して動作するように制御してもよい。

実施の形態６．
実施の形態６では、手続端末１を用いて、個人向けのサービス提供について説明する。実施の形態１−５は、どの乗客に向けても同じサービス、情報を提供するが、実施の形態６では、特定の個人向けに特有のサービスを提供する。

図１５は、実施の形態６に係る端末制御装置１０の機能構成を示すブロック図である。
実施の形態６に係る端末制御装置１０は、図５に示す実施の形態１に係る端末制御装置１０の機能に加え、情報照会部１８を備える。また、手続端末１には、情報入力部２１を備える。
情報入力部２１は、入力部４に含まれる図示しないタッチパネル等の入力装置から乗客が所有している個人カード等から個人を特定する情報を読み込む。情報照会部１８は、外部のサーバにアクセスして、個人を特定する情報と紐付いている個人情報、予約情報等を取得する。個人カードは、航空機の場合はマイレージカード、電車の場合は、ＳＵＩＣＡ（登録商標）、ＰＡＳＭＯ（登録商標）等の個人を特定する個人ＩＤを含む情報が記憶されているカードである。

図１６は、実施の形態６における表示部３に表示される表示情報の説明図である。図１６に示すとおり、実施の形態６に係る手続端末１では、「居場所通知」機能を機能が提供される。

図１７は、実施の形態６に係る端末制御装置１０の処理の流れを示すフローチャートである。なお、実施の形態６の処理を開始する前に、実施の形態１−５のいずれかの処理が実行されているものとし、実施の形態６の処理は乗客から個人情報の入力を受け付けたときに、開始される。

（Ｓ５１：情報入力処理）
乗客は、個人カードからの入力が可能な手続端末１を用いて、個人カードをタッチパネルに接触させる。これにより情報入力部２１は、個人カードの個人情報が入力されたことを検知する。

（Ｓ５２：情報送信処理）
情報入力部２１は、入力された個人ＩＤを端末制御装置１０に送信する。
（Ｓ５３：情報受信処理）
端末制御部１３は、Ｓ５２で送信された個人ＩＤを受信し、情報照会部１８は、外部のサーバに対して個人ＩＤで特定される個人情報、予約情報（乗り物情報）を要求し、外部のサーバから個人情報と、予約情報とを受信する。

（Ｓ５４：端末制御処理）
端末制御部１３は、Ｓ５３で取得した予約情報が示す予約内容を変更するためのメニュー情報を手続情報表示部５に表示させ、予約情報に関連付けられている広告情報を広告表示部６に表示させる個人向けサービス画面を構成する。また広告表示部６により表示される情報は、予約情報に関連付けられた特定の場所までの地図、案内等の関連する情報でもよい。具体的には予約情報により特定される出発時刻、出発時刻までの待ち時間、搭乗ゲート位置等に関連付けられる広告、地図、案内等を表示する。また予約情報と手続端末１の位置とを考慮して、関連する情報を構成してもよい。

（Ｓ５５：表示装置制御処理）
表示装置制御部１４は、対応する手続端末１で行える手続を示す情報を表示するように、各表示装置２を制御する。ここでは、個人向けのサービスを提供する手続端末１に対応する表示装置２には、例えば「個人向けサービス提供中」等のメッセージを表示する。
例えば、表示装置制御部１４は、ネットワークを介して各表示装置２へその表示装置２に表示させる表示情報を送信する。表示装置２は、表示情報を受信すると、受信した表示情報を表示する。

以上のように、端末制御装置１０は、個人の予約情報に関する手続を行えるように制御する。そのため、改めて乗客側で便を指定する必要はなく、乗客側の入力操作を省略できる効果が期待できる。また広告表示部６に表示される広告は、個人の便情報に関連した情報を提供するため、乗客が知りたい情報を即座に提供できる効果が期待できる。

「居場所通知」機能は、個人情報に含まれる家族情報や予約情報に含まれる同行者情報にメールアドレスが含まれる場合、そのメールアドレスに対して、該当の手続端末１を操作したことを通知する機能である。
Ｓ５４の処理で、端末制御部１３は個人ＩＤに対応する個人情報と予約情報とを一時的に保持する。情報入力部２１は、「居場所通知」機能がタッチパネル等により乗客に選択されたことを検知すると、その選択を端末ＩＤ、個人ＩＤとともに、端末制御部１３に通知する。端末制御部１３は、「居場所通知」機能が選択されたことを受けて、一時的に保持している家族情報または、同行者情報のメールアドレス宛に、「居場所通知」機能が選択された時間に、個人ＩＤで特定される個人名が端末ＩＤで特定される場所で手続端末１を操作したことを通知する居場所通知メールを発信する。
具体的には、２０１１年８月１日１０時１０分（「居場所通知」機能が選択された時間）に、「山田 太郎」さん（個人ＩＤで特定される）が羽田空港の南ターミナル搭乗ゲート付近（端末ＩＤで特定される手続端末１の位置）にいる旨がメール内容として発信される。これにより、家族や同行者は、「山田 太郎」さんがいつどこにいるかの存在情報を把握することが可能になり、自宅にいる家族の場合は「山田 太郎」さんが空港に到着したことを把握できる。また同行者の場合は、「山田 太郎」さんが空港のどこにいるかまで把握することができるため、待ち合わせが可能となる。
さらに、実施の形態６で説明したような災害発生時に、この「居場所通知」機能を用いると、乗客の安否確認を行うことができる。予約情報を有していない個人（空港に遊びに来た人、見送り／出迎えに来た人等）でも個人カードを有していれば、この「居場所通知」機能により、家族情報に含まれるメールアドレス宛に居場所通知メールを発信することが可能となり、安否確認に役立てることができる。

実施の形態７．
実施の形態７では、実施の形態６で説明した個人向けのサービス提供について、さらに説明する。実施の形態７では、個人向けの「プレゼント」機能について説明する。

実施の形態６と同様に、個人カードからの入力が可能となっている手続端末１を用いて、乗客所有の個人カードから予約情報を取得すると、予約情報に応じた「プレゼント」を乗客に提供する。実施の形態７における表示部３に表示される表示情報は、図１６のとおりである。
例えば、端末制御部１３は現在時刻から出発時刻までの待ち時間を算出し、その待ち時間により、「プレゼント」内容を変更する。待ち時間が１時間以上ある場合は、待ち受け画面、ゲームソフト、店舗利用クーポン等が取得できるようにし、待ち時間が３０分以上１時間未満のときは、待ち受け画面、店舗利用クーポンが取得できるようにし、待ち時間が３０分未満のときは、待ち受け画面だけが取得できるように限定することが考えられる。
このように、「プレゼント」機能を乗客の予約情報と連動させて変更させることができ、乗客の利便性を向上させることが期待できる。

乗客が予約した便が欠航となった場合等の特定の場合には、「払い戻し」機能と「プレゼント」機能だけに限定してもよい。払い戻しは、速やかに処理することが望ましいので、スケジュール変更が発生した変更時には、実施の形態４で説明したように通常時と比較して「プレゼント」内容を限定する。例えば、通常は待ち受け画面、ゲームソフト、店舗利用クーポンが取得できるようにし、変更時には店舗利用クーポンの取得のみに機能を限定する。これにより、一定の乗客サービスは提供しつつ、必要な処理を速やかに実行することが期待できる。

さらに、乗客向けの「プレゼント」機能を特定の手続端末１のみで提供するように制御すると、乗客は空港内の待ち時間を利用して、「プレゼント」機能を探すタッチラリーのようなイベントを空港内で実現することができる。これにより、乗客は搭乗時間よりも早く来ないと、プレゼントをもらえないので、早めにターミナルに到着することが予想され、混雑緩和、定時性確保（便の出発が遅れない）の効果が期待できる。
また、フライト出発時刻が近づくと、搭乗ゲート付近の手続端末１でしか「プレゼント」を取得できないように構成してもよい。このように構成すると、乗客は早めに搭乗ゲートに向かうことが期待できるので、早めにセキュリティゲートを通過し、混雑緩和、定時性確保の効果が期待できる。
さらに、プレゼントを得るために、乗客が何度もタッチすると、乗客がどこにいるか把握しやすく、乗り遅れた乗客の居場所がわかりやすいという効果や、乗客の動線や動向を把握しやすいという効果が期待できる。さらに、同時に表示する広告が見られる機会が増えることが期待できる。
また、プレゼントを希少価値の高いものにすると、それを目当てに空港や駅に来る人を見込むことができ、空港や駅の収益増加が期待できる。プレゼントが待ち受け画面である場合などは、乗客が「プレゼント」機能を選択する度に、異なる待ち受け画面が選択できるように構成されることが望ましい。端末制御装置１０で個人ＩＤごとの待ち受け画面取得履歴を記憶しておき、待ち受け画面取得が選択されたときに、履歴情報にはない待ち受け画面を表示するように構成すれば、更なる乗客サービス向上ができる。

なお、以上の説明において、「便」とは、乗り物の１つ１つの運行のことである。また以上の説明において、「運行」と「運航」とは区別せずに表現している。

次に、実施の形態における端末制御装置１０のハードウェア構成について説明する。
図１８は、端末制御装置１０や手続端末１のハードウェア構成の一例を示す図である。
図１８に示すように、端末制御装置１０や手続端末１は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ・Ｐｒｏｃｅｓｓｉｎｇ・Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。ＣＰＵ９１１は、バス９１２を介してＲＯＭ９１３、ＲＡＭ９１４、ＬＣＤ９０１（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）、キーボード９０２（Ｋ／Ｂ）、通信ボード９１５、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。磁気ディスク装置９２０（固定ディスク装置）の代わりに、光ディスク装置、メモリカード読み書き装置などの記憶装置でもよい。磁気ディスク装置９２０は、所定の固定ディスクインタフェースを介して接続される。

磁気ディスク装置９２０又はＲＯＭ９１３などには、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。プログラム群９２３のプログラムは、ＣＰＵ９１１、オペレーティングシステム９２１、ウィンドウシステム９２２により実行される。

プログラム群９２３には、上記の説明において「変更判定部１２」、「端末制御部１３」、「表示装置制御部１４」、「台数決定部１５」、「位置特定部１６」、「災害情報記憶部１７」、「情報照会部１８」、「情報入力部２１」等として説明した機能を実行するソフトウェアやプログラムやその他のプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
ファイル群９２４には、上記の説明において「情報記憶部１１」に格納される情報やデータや信号値や変数値やパラメータが、「データベース」の各項目として記憶される。「データベース」は、ディスクやメモリなどの記録媒体に記憶される。ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出され、抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示などのＣＰＵ９１１の動作に用いられる。抽出・検索・参照・比較・演算・計算・処理・出力・印刷・表示のＣＰＵ９１１の動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリやキャッシュメモリやバッファメモリに一時的に記憶される。

また、上記の説明におけるフローチャートの矢印の部分は主としてデータや信号の入出力を示し、データや信号値は、ＲＡＭ９１４のメモリ、その他光ディスク等の記録媒体やＩＣチップに記録される。また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体や電波によりオンライン伝送される。
また、上記の説明において「〜部」として説明するものは、「〜回路」、「〜装置」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。また、「〜装置」として説明するものは、「〜回路」、「〜機器」、「〜手段」、「〜機能」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。すなわち、「〜部」として説明するものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組合せ、さらには、ファームウェアとの組合せで実施されても構わない。ファームウェアとソフトウェアは、プログラムとして、ＲＯＭ９１３等の記録媒体に記憶される。プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。すなわち、プログラムは、上記で述べた「〜部」としてコンピュータ等を機能させるものである。あるいは、上記で述べた「〜部」の手順や方法をコンピュータ等に実行させるものである。

１ 手続端末、２ 表示装置、３ 表示部、４ 入力部、５ 手続情報表示部、６ 広告表示部、１０ 端末制御装置、１１ 情報記憶部、１２ 変更判定部、１３ 端末制御部、１４ 表示装置制御部、１５ 台数決定部、１６ 位置特定部、１７ 災害情報記憶部、１８ 情報照会部、２１ 情報入力部。

Claims (14)

1. 乗り物の乗客が前記乗り物に関する手続を含む複数の手続を行うための手続端末であって、並べて設けられた複数の手続端末を制御する端末制御装置であり、
   前記乗り物のスケジュールが変更されたか否かを判定する変更判定部と、
   前記スケジュールが変更されていないと前記変更判定部が判定した通常時には、前記複数の手続を前記複数の手続端末のどの手続端末でも前記乗客が行えるように前記複数の手続端末を制御し、前記スケジュールが変更されたと前記変更判定部が判定した変更時には、前記複数の手続端末のうちの少なくとも一部の手続端末である特定端末では前記複数の手続のうちの前記乗り物に関する特定の手続だけが行えるように前記複数の手続端末を制御する端末制御部と
   を備えることを特徴とする端末制御装置。
2. 前記端末制御部は、前記通常時には、前記複数の手続のいずれかの手続を行うための手続情報を前記手続端末が表示する際、合わせて関連情報を前記手続端末に表示させ、前記変更時には、前記手続情報を前記手続端末が表示する際、広告を前記手続端末に表示させない
   ことを特徴とする請求項１に記載の端末制御装置。
3. 前記端末制御装置は、さらに、
   前記変更時に、スケジュールが変更された便数をカウントして、カウントした便数に応じて、前記複数の手続端末のうちの何台の手続端末を前記特定端末にするかを決定する台数決定部
   を備え、
   前記端末制御部は、前記台数決定部が決定した台数の手続端末を前記特定端末にする
   ことを特徴とする請求項１又は２に記載の端末制御装置。
4. 前記端末制御装置は、さらに、
   前記変更時に、スケジュールが変更された便の予約人数に応じて、前記複数の手続端末のうちの何台の手続端末を前記特定端末にするかを決定する台数決定部
   を備え、
   前記端末制御部は、前記台数決定部が決定した台数の手続端末を前記特定端末にする
   ことを特徴とする請求項１又は２に記載の端末制御装置。
5. 前記端末制御装置は、さらに、
   前記変更時に、スケジュールが変更された便の乗り場の位置を特定する位置特定部
   を備え、
   前記端末制御部は、前記位置特定部が特定した乗り場の位置に応じて、前記複数の手続端末のうちのどの手続端末を前記特定端末にするかを決定する
   ことを特徴とする請求項１から４までのいずれかに記載の端末制御装置。
6. 前記端末制御装置は、さらに、
   前記複数の手続端末の各手続端末に対応して設けられた表示装置を制御する表示装置制御部であって、前記変更時に、対応する手続端末で行える手続を表示装置に表示させる表示装置制御部
   を備えることを特徴とする請求項１から５までのいずれかに記載の端末制御装置。
7. 前記端末制御部は、前記変更時には、前記特定端末のうちの一部の手続端末では、前記複数の手続のうちの前記乗り物に関する第１の手続だけが行えるようにするとともに、残りの特定端末では、前記複数の手続のうちの前記乗り物に関する第２の手続であって、前記第１の手続とは異なる第２の手続だけが行えるようにする
   ことを特徴とする請求項１から６までのいずれかに記載の端末制御装置。
8. 前記端末制御装置は、さらに、
   前記乗り物のスケジュールを示すスケジュール情報を記憶装置に記憶するスケジュール記憶部
   を備え、
   前記変更判定部は、前記乗り物の新しいスケジュール情報を取得して、取得した新しいスケジュール情報と、前記スケジュール記憶部が記憶したスケジュール情報とを比較することにより、前記乗り物のスケジュールが変更されたか否かを判定する
   ことを特徴とする請求項１から７までのいずれかに記載の端末制御装置。
9. 前記変更判定部は、災害が発生したか否かを判定し、
   前記端末制御部は、前記変更判定部が災害が発生したと判定した場合には、前記特定端末では前記特定の手続だけが行えるように前記複数の手続端末を制御する
   ことを特徴とする請求項１から８までのいずれかに記載の端末制御装置。
10. 前記変更判定部は、災害が発生したか否かを判定し、
    前記端末制御部は、前記変更判定部が災害が発生したと判定した場合には、前記手続端末の通常の手続機能を停止し、避難経路を表示させる
    ことを特徴とする請求項１から８までのいずれかに記載の端末制御装置。
11. 前記端末制御装置は、さらに、
    乗客を特定可能な個人ＩＤであって、前記手続端末から送信された個人ＩＤに基づき、前記乗り物についての予約情報を蓄積しているサーバに対して、前記乗客の前記乗り物についての予約情報を照会する情報照会部
    を備え、
    前記端末制御部は、個人ＩＤを送信した手続端末を、前記情報照会部が照会した前記予約情報に関する手続だけが行えるように制御する
    ことを特徴とする請求項１から１０までのいずれかに記載の端末制御装置。
12. 前記端末制御部は、前記個人ＩＤと、予約情報によって特定される前記乗客が予約した乗り物の出発時間までの残り時間と、個人ＩＤを送信した手続端末の位置とに基づき、提供するサービスを制御する
    ことを特徴とする請求項１１に記載の端末制御装置。
13. 前記端末制御部は、前記通常時において、前記乗り物の予約人数から計算される前記手続端末の混雑度が所定の混雑度よりも高い場合、前記特定端末では前記特定の手続だけが行えるように前記複数の手続端末を制御する
    ことを特徴とする請求項１から１２までのいずれかに記載の端末制御装置。
14. 乗り物の乗客が前記乗り物に関する手続を含む複数の手続を行うための手続端末であって、並べて設けられた複数の手続端末を制御する端末制御プログラムであり、
    前記乗り物のスケジュールが変更されたか否かを判定する変更判定処理と、
    前記スケジュールが変更されていないと前記変更判定処理で判定した通常時には、前記複数の手続を前記複数の手続端末のどの手続端末でも前記乗客が行えるように前記複数の手続端末を制御し、前記スケジュールが変更されたと前記変更判定処理で判定した変更時には、前記複数の手続端末のうちの少なくとも一部の手続端末である特定端末では前記複数の手続のうちの前記乗り物に関する特定の手続だけが行えるように前記複数の手続端末を制御する端末制御処理と
    をコンピュータに実行させることを特徴とする端末制御プログラム。

Images