(57)【要約】      （修正有）【課題】運行中に空席である予約席を有効に活用する。【解決手段】予約管理サーバ１は、指定席ごとに、その指定席と予約者とを対応づける予約管理データベースと、予約者が使用する先予約者端末２ａおよび指定席を管理する指定席管理装置８に対して、それぞれ位置情報を確認するための位置確認信号を送信する送信手段と、それぞれ受信した位置確認信号の応答結果に含まれる両位置情報が一致するときに、応答結果の先予約者端末２ａを使用する予約者が、応答結果の指定席を使用していると判定する判定手段と、指定席を使用していない先予約者端末２ａに対して、予約をキャンセルする旨の変更案内を送信する案内手段と、を有する。【選択図】図２
2015203905.tif 000002
【特許請求の範囲】
【請求項１】
指定席ごとに、その指定席と予約者とを対応づける予約管理データベースと、
前記予約者が使用する予約者端末に自身の位置情報を確認するための位置確認信号を送信し、前記指定席を管理する指定席管理装置に対して、指定席の位置情報を確認するための位置確認信号を送信する送信手段と、
それぞれ受信した前記位置確認信号の応答結果に含まれる両位置情報が一致するときに、応答結果の前記予約者端末を使用する予約者が、応答結果の指定席を使用していると判定する判定手段と、
指定席を使用していない前記予約者端末に対して、前記予約管理データベースに登録されている予約をキャンセルする旨の変更案内を送信する案内手段と、を有することを特徴とする
予約管理サーバ。
【請求項２】
前記送信手段は、前記予約者端末および前記指定席管理装置に対して、前記位置確認信号を連続して複数回送信し、
前記判定手段は、複数回送信した前記位置確認信号への応答結果の両位置情報がすべて一致するときに、予約者が指定席を使用していると判定することを特徴とする
請求項１に記載の予約管理サーバ。
【請求項３】
前記案内手段は、両位置情報が不一致であると判定された前記予約者端末の位置情報から、指定席の予約開始時刻に指定席に到達できる経路を時刻表データから特定できない場合には、予約をキャンセルする旨の変更案内を送信することを特徴とする
請求項１または請求項２に記載の予約管理サーバ。
【請求項４】
前記案内手段は、両位置情報が不一致であると判定された前記予約者端末の位置情報に示される位置が動いており、かつ、指定席の予約区間内のチェックポイントにおいて予約した指定席に合流できる経路を時刻表データから特定できる場合には、前記チェックポイントまでの期間の予約をキャンセルする旨の変更案内を送信することを特徴とする
請求項１ないし請求項３のいずれか１項に記載の予約管理サーバ。
【請求項５】
前記案内手段は、ある期間において両位置情報が一致であると判定されたが、その後に両位置情報が不一致であると判定された前記予約者端末に対して、指定席の予約区間内において予約した指定席に再度合流できる経路を時刻表データから特定できない場合には、今後の期間の予約をキャンセルする旨の変更案内を送信することを特徴とする
請求項１ないし請求項４のいずれか１項に記載の予約管理サーバ。
【請求項６】
予約管理サーバは、
指定席ごとに、その指定席と予約者とを対応づける予約管理データベースを備えており、
前記予約者が使用する予約者端末に自身の位置情報を確認するための位置確認信号を送信し、前記指定席を管理する指定席管理装置に対して、指定席の位置情報を確認するための位置確認信号を送信し、
それぞれ受信した前記位置確認信号の応答結果に含まれる両位置情報が一致するときに、応答結果の前記予約者端末を使用する予約者が、応答結果の指定席を使用していると判定し、
指定席を使用していない前記予約者端末に対して、前記予約管理データベースに登録されている予約をキャンセルする旨の変更案内を送信することを特徴とする
予約管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、予約管理サーバ、および、予約管理方法の技術に関する。
【背景技術】
【０００２】
列車の指定席を事前予約した利用者は、発車後にその指定席を利用することができる。このような指定席の予約業務を駅の窓口内で駅員が対面して行ったり、駅構内の予約販売機が行ったりする代わりに、予約者が保持する携帯端末を介して受け付けるオンライン予約システムが普及している。
例えば、ＪＲ東日本では、指定席の予約システムとして、非特許文献１に記載の「モバイルSuica（登録商標）」を乗客に提供している。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】ＪＲ東日本、"モバイルSuica  払い戻し"、［online］、［平成26年4月4日検索］、インターネット〈URL：http://www.jreast.co.jp/mobilesuica/use/e-ticket/repayment_received.html〉
【発明の概要】
【発明が解決しようとする課題】
【０００４】
非特許文献１に記載のように、モバイルSuicaで予約した未使用のモバイルSuica特急券は、指定列車の時刻表に表示された発車時刻前までは払いもどしできるが、いったん発車時刻を過ぎてしまうと、払いもどしには対応していない。
【０００５】
そのため、指定席を予約したが利用しない予約者は、発車時刻を過ぎてしまうと、積極的には、予約済みの指定席をキャンセルしようとはしない。
また、鉄道会社も、実際に運行中の車内の座席が空席であっても、先客によってキャンセルされないうちは、その座席を別の客へと再販することができない。よって、行楽シーズンなどで車内が混雑するときでも、未使用の空席を有効活用できない。
【０００６】
そこで、本発明は、運行中に空席である予約席を有効に活用することを、主な課題とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するために、本発明の予約管理サーバは、指定席ごとに、その指定席と予約者とを対応づける予約管理データベースと、前記予約者が使用する予約者端末に自身の位置情報を確認するための位置確認信号を送信し、前記指定席を管理する指定席管理装置に対して、指定席の位置情報を確認するための位置確認信号を送信する送信手段と、それぞれ受信した前記位置確認信号の応答結果に含まれる両位置情報が一致するときに、応答結果の前記予約者端末を使用する予約者が、応答結果の指定席を使用していると判定する判定手段と、指定席を使用していない前記予約者端末に対して、前記予約管理データベースに登録されている予約をキャンセルする旨の変更案内を送信する案内手段と、を有することを特徴とする。
【０００８】
これにより、実際の予約者の乗車有無をもとに、キャンセルする案内が適切に予約者に通知されるので、運行中に空席である予約席を有効に活用することができる。
【０００９】
本発明は、前記送信手段が、前記予約者端末および前記指定席管理装置に対して、前記位置確認信号を連続して複数回送信し、前記判定手段が、複数回送信した前記位置確認信号への応答結果の両位置情報がすべて一致するときに、予約者が指定席を使用していると判定することを特徴とする。
【００１０】
これにより、偶然に予約列車と予約者が乗車する別の列車とが近接している場合でも、高精度に実際の予約者の乗車有無を判定することができる。
【００１１】
本発明は、前記案内手段が、両位置情報が不一致であると判定された前記予約者端末の位置情報から、指定席の予約開始時刻に指定席に到達できる経路を時刻表データから特定できない場合には、予約をキャンセルする旨の変更案内を送信することを特徴とする。
【００１２】
これにより、予約者の乗り遅れが発生した場合でも、早期に予約をキャンセルすることができる。
【００１３】
本発明は、前記案内手段が、両位置情報が不一致であると判定された前記予約者端末の位置情報に示される位置が動いており、かつ、指定席の予約区間内のチェックポイントにおいて予約した指定席に合流できる経路を時刻表データから特定できる場合には、前記チェックポイントまでの期間の予約をキャンセルする旨の変更案内を送信することを特徴とする。
【００１４】
これにより、予約者が途中乗車する場合でも、予約の一部である不使用期間のみをキャンセルすることができる。
【００１５】
本発明は、前記案内手段が、ある期間において両位置情報が一致であると判定されたが、その後に両位置情報が不一致であると判定された前記予約者端末に対して、指定席の予約区間内において予約した指定席に再度合流できる経路を時刻表データから特定できない場合には、今後の期間の予約をキャンセルする旨の変更案内を送信することを特徴とする。
【００１６】
これにより、予約者が途中下車する場合でも、予約の一部である不使用期間のみをキャンセルすることができる。
【発明の効果】
【００１７】
本発明によれば、運行中に空席である予約席を有効に活用することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態に関する予約管理システムを示す構成図である。図１（ａ）は、予約管理システムの構成図である。図１（ｂ）は、予約管理データベースの構成図である。
【図２】本発明の一実施形態に関する予約変更処理の概要を示すフロー説明図である。
【図３】本発明の一実施形態に関する予約管理サーバの予約変更処理を示すフロー説明図である。
【図４】本発明の一実施形態に関する不正乗車確認処理を示すフロー説明図である。
【発明を実施するための形態】
【００１９】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
図１（ａ）は、予約管理システムを示す構成図である。
予約管理システムは、予約管理サーバ１と、各予約者端末（先予約者端末２ａ、後予約者端末２ｂ）と、指定席管理装置８と、車掌端末９とがネットワークで接続されて構成される。
これらの予約管理システムの各装置は、それぞれＣＰＵ（Central Processing Unit）とメモリとハードディスク（記憶手段）とネットワークインタフェースを有するコンピュータとして構成され、このコンピュータは、ＣＰＵが、メモリ上に読み込んだプログラムを実行することにより、各処理部を動作させる。
【００２０】
先予約者端末２ａおよび後予約者端末２ｂは、それぞれ乗客により利用される端末である。これらの端末には、移動通信事業者の提供する位置情報ＡＰＩ（Application Programming Interface）を活用し作成された、自身の位置を通知するための位置情報提供機能が備わっている。なお、位置情報提供機能を実現する形態は、専用アプリとして端末にインストールする形態でもよいし、端末のｗｅｂブラウザからｗｅｂサーバに接続する形態でもよい。
以下では、ある座席に着目して、その座席を先に予約する者が操作する先予約者端末２ａと、その座席を後に予約する者が操作する後予約者端末２ｂとに分類して説明するが、両端末の機能は共通する。
【００２１】
予約管理サーバ１は、予約管理データベース１１と接続されており、その予約管理データベース１１内のデータを元に、座席の予約状況を管理する。
図１（ｂ）は、予約管理データベース１１の構成図である。予約管理データベース１１には、予約対象の席を特定する「席ＩＤ」ごとに、その利用者ＩＤ、時刻、列車位置、利用者位置、乗車判定を対応づけて格納する。
例えば、予約管理データベース１１の第１行は、席ＩＤ「R001-V01-S04-T01」で示される座席が、利用者ＩＤ「A1」（予約者端末のＩＤでもよい）の利用者によって予約されていることを示している。なお、席ＩＤは、列車ＩＤ「R001」と、その列車内の何両目かを示す車両ＩＤ「V01」と、その車両内の何座席目かを示す座席ＩＤ「S04」と、その座席ＩＤを列車の運行中のどの時間帯に占有するかを示す期間ＩＤ「T01」との組み合わせである。
【００２２】
さらに、予約管理データベース１１は、席ＩＤの座席について、位置取得時刻ごとに、座席の位置取得結果である列車位置と、予約者の位置取得結果である利用者位置と、両位置を比較した乗車判定とを対応づけている。なお、位置情報は、例えば、(x,y)表記であり、xが経度でyが緯度に対応する。
例えば、予約管理データベース１１の第１行は、「10:00」に両位置を取得した結果、先予約者端末２ａの位置が(80,80)であり、席ＩＤ「R001-V01-S04-T01」に対応する座席の位置が(100,100)であり、両位置間の距離が離れていることにより、予約者が座席付近に乗車していない（×不在）という判定がなされたことを示す。
【００２３】
一方、予約管理データベース１１の第２行は、利用者位置(120,120)と列車位置(120,120)とが一致している（距離が０である）ので、予約者が座席付近に乗車している（○乗車）と判定されている。
なお、図１（ｂ）では、両位置の取得回数が１回であり、その１回の両位置をもとに乗車判定がなされているが、両位置を複数回（例えば２回）連続で取得して、それぞれの両位置間の距離がすべて近接（または０）であるときに、予約者が座席付近に乗車している（○乗車）と判定してもよい。
【００２４】
図１（ａ）に戻って、指定席管理装置８は、予約管理データベース１１の「列車位置」列に書き出すための席ＩＤごとの位置情報を予約管理サーバ１に通知する装置である。指定席管理装置８の構成例として、例えば、列車の座席ごとに座席近傍にＧＰＳ端末（図示省略）を配置し、各ＧＰＳ端末から取得される座席ごとの位置情報を列車内の指定席管理装置８がとりまとめて、予約管理サーバ１に一括で通知する形態が挙げられる。
【００２５】
車掌端末９は、列車に乗車する車掌によって操作される端末である。車掌は、車掌端末９を介して、目視で確認した席に利用者が着席しているか否かを予約管理サーバ１に通知するとともに、車掌端末９を介して、着席している利用者が正規の予約者か、不正乗車をしている者かを知ることができる（詳細は図４）。
以下では、先予約者端末２ａ、指定席管理装置８、および、車掌端末９が、それぞれ列車内に存在し、予約管理サーバ１、および、後予約者端末２ｂが列車外に存在する例を示す。
【００２６】
図２は、予約変更処理の概要を示すフロー説明図である。
Ｓ１０１として、先予約者端末２ａは、予約管理サーバ１に対して、列車の出発前の指定席の予約を依頼する。予約管理サーバ１は、Ｓ１０１の予約を受け、指定席管理装置８および車掌端末９に予約されたことを通知し（Ｓ１０２）、予約が成功（ＯＫ）したことを先予約者端末２ａに返答する（Ｓ１０３）。
ここで、予約管理サーバ１は、図１（ｂ）で説明したように、予約管理データベース１１内において、先予約者端末２ａのＩＤと、予約対象の席ＩＤとを対応づける。
【００２７】
Ｓ１１０として、予約管理サーバ１は、Ｓ１０３で予約された席が配備されている列車の発車時刻を待つ。なお、列車の駅ごとの発車時刻は、例えば、予約管理データベース１１に時刻表データ（図示省略）としてあらかじめ登録されている。
この時刻表データは、予約した列車だけでなく、少なくとも予約列車の各停車駅に到達する各交通機関のデータが含まれており、ナビゲーションシステムとして、「東京駅を午前９時に出発して、大宮駅に到着するまでの経路と大宮駅での到着時刻とを検索する」などの検索条件に合致する経路を検索可能なデータである。
または、時刻表のダイヤが遅延により予定通り出発していない場合があるので、その場合には車掌端末９を介して車掌による手入力で、列車の発車時刻を通知してもよい。
これにより、Ｓ１１１ａ以下の処理が、列車が駅間を走行中（または信号により一時停止中）に行われる。
【００２８】
予約管理サーバ１は、Ｓ１０３で予約ＯＫした先予約者端末２ａの位置を確認する信号を送信し（Ｓ１１１ａ）、その応答として位置通知を受ける（Ｓ１１２ａ）。
予約管理サーバ１は、Ｓ１０２で予約通知した指定席の位置を確認する信号を、その指定席を管理する指定席管理装置８に送信し（Ｓ１１１ｂ）、その応答として位置通知を受ける（Ｓ１１２ｂ）。なお、両位置の確認の順番は、どちらが先でもよい。
さらに、予約管理サーバ１は、先予約者端末２ａの位置取得（Ｓ１１３ａ、Ｓ１１４ａ）と、指定席の位置取得（Ｓ１１３ｂ、Ｓ１１４ｂ）とを再度行ってもよい。
【００２９】
Ｓ１１５として、予約管理サーバ１は、両位置（Ｓ１１２ａの通知位置と、Ｓ１１２ｂの通知位置）間の距離が、所定距離より小さいか否かを照合する。ここで、予約管理サーバ１は、２回目の両位置（Ｓ１１４ａの通知位置と、Ｓ１１４ｂの通知位置）も照合してもよい。
Ｓ１１５の結果として、両位置が近接（両位置間の距離が、所定距離より小さい）または一致するときに（または、近接や一致が２回連続するときに）、予約管理サーバ１は、照合した予約者が指定席に乗車（着席）していると判定する。
一方、両位置間の距離が所定距離より小さくない（遠い）ときや、先予約者端末２ａの電源オフなどにより、位置取得に失敗したときは、予約管理サーバ１は、照合した予約者が指定席に乗車（着席）していないと判定する。
なお、利用者がトイレで一時離席していることや、位置取得の誤差を考慮して、所定距離は、例えば、車両３両分の長さである。
【００３０】
ここで、Ｓ１１５の両位置の近接判定を２回連続で行うことにより、１回目では偶然に指定席の列車と、利用者が乗車する別の列車とが近接することで、利用者が指定席に着席していないにもかかわらず、「指定席に乗車している」という誤検出を抑制することができる。
なお、指定席の列車と別の列車とが近接する事象としては、例えば、両列車が同じ線路上の前後に渋滞している事象や、両列車が隣接する線路上を交差する事象や、両列車が隣接する線路上を併走しており片方の列車がもう片方の列車を追い越す事象などが挙げられる。
【００３１】
なお、Ｓ１１１ａ〜Ｓ１１５にかかる時間は、２駅間の移動時間内におさまるようにすることが、望ましい。Ｓ１１１ａ〜Ｓ１１５にかかる時間は、新幹線列車のうちの収容される車両数（座席数）が一番多い場合でも、その座席分だけの位置確認が完了するのにかかる時間である。２駅間の移動時間は、例えば、移動速度が速い新幹線が最短で移動できる２駅間（換言すると２駅間の距離が短い）の時間である。
【００３２】
さらに、予約管理サーバ１は、１回目の位置取得（Ｓ１１１ａ、Ｓ１１２ａ、Ｓ１１１ｂ、Ｓ１１２ｂ）に対するＳ１１５の位置照合を行った後に、２回目の位置取得（Ｓ１１３ａ、Ｓ１１４ａ、Ｓ１１３ｂ、Ｓ１１４ｂ）とそのＳ１１５の位置照合を行ってもよい。
そして、予約管理サーバ１は、２回目の位置取得対象から、１回目の位置照合（Ｓ１１５）で成功（乗車）しているものを除外することで、処理量を軽減してもよい。そのときには、予約管理サーバ１は、すでに位置照合で成功したことを示すフラグを予約管理データベース１１内に書き込み、フラグが書き込まれていない座席を、今後の位置取得や位置照合の対象とする。このフラグは、列車が駅に到着するたびにリセット（消去）される。
【００３３】
予約管理サーバ１は、Ｓ１１５の位置照合により、失敗（乗車していない）と判定された指定席ごとに、先予約者端末２ａの利用者に対して乗車を確認するための画面信号を送信し（Ｓ１１６ａ）、その応答として乗車の確認結果を示す通知を受ける（Ｓ１１７ａ）。利用者は、Ｓ１１６ａの画面信号で先予約者端末２ａに表示される画面を参照し、自身が乗車しているか否かを画面にタッチするなどして確認結果を入力する。
【００３４】
同様に、予約管理サーバ１は、Ｓ１１５の位置照合により、失敗（乗車していない）と判定された指定席ごとに、車掌端末９を介して車掌に対して乗車を確認するための画面信号を送信し（Ｓ１１６ｂ）、その応答として乗車の確認結果を示す通知を受ける（Ｓ１１７ｂ）。車掌は、Ｓ１１６ｂの画面信号で車掌端末９に表示される画面を参照し、目視で確認した結果として、指定席に利用者が着席しているか否かを画面にタッチするなどして確認結果を入力する。
なお、実行順序は、Ｓ１１６ａ→Ｓ１１７ａ→Ｓ１１６ｂ→Ｓ１１７ｂでもよいし、Ｓ１１６ｂ→Ｓ１１７ｂ→Ｓ１１６ａ→Ｓ１１７ａでもよい。
【００３５】
なお、モバイルSuicaでは、モバイルSuica特急券を購入後、モバイル端末での受取り（ダウンロード）して改札機を通る必要がある。よって、先予約者端末２ａは、改札機を通過している履歴がないときには、予約者が家などに先予約者端末２ａを置き忘れたものとして、予約者の画面操作を待たずに、乗車していない旨の通知（Ｓ１１７ｂ）を応答してもよい。
【００３６】
Ｓ１２０として、予約管理サーバ１は、Ｓ１１７ａの通知およびＳ１１７ｂの通知のうち、両方の通知が「乗車している」ではないときには（または、片方の通知が「乗車していない」ときには）、先予約者端末２ａの予約をキャンセルして、その後の後予約者端末２ｂに予約を再販できるように、先予約者端末２ａに対する予約変更手続を計画する。以下、３種類の計画として、（計画１）〜（計画３）を例示する。
【００３７】
Ｓ１２０の（計画１）は、「途中乗車」のケースである。図１（ｂ）では、利用者ＩＤ「A1」の利用者が途中乗車している。
先予約者端末２ａの予約者は、予約区間のうちの前区間までは乗車せず、後区間からは乗車する予定である。そして、現在は前区間であるとする。
予約管理サーバ１は、Ｓ１１６ａの乗車確認において、予約者の位置情報が動いており、かつ、予約区間内のチェックポイント（合流予定駅）において予約した列車に合流できることが想定される場合（時刻表データから合流経路が特定できる場合）には、「現在乗車しているか否か」に加えて「今後乗車する予定か否か」も予約者に問い合わせる。
先予約者端末２ａの予約者は、Ｓ１１７ａの乗車通知において、「現在乗車していないが、今後乗車する予定である」旨を通知する。
これにより、予約管理サーバ１は、予約区間のうちの前区間だけ後予約者端末２ｂに予約を再販できるとともに、前区間の料金を先予約者端末２ａに払い戻しできる。
【００３８】
（計画１）の例として、予約者は東北新幹線の予約を東京駅からしているが、東京駅から乗車せず、大宮駅から乗車する場合を説明する。予約管理サーバ１は、予約者の位置情報を確認したところ、武蔵野線の新幹線への連絡線に乗車しており、時刻表データを参照すると大宮駅で乗車することが想定できるとの確認結果を得る。
そこで、予約管理サーバ１は、先予約者端末２ａに対してあらかじめ登録された通知方法、たとえばメールにて確認をうながし、予約者が大宮駅から乗車することを宣言した場合には東京駅−上野駅間の指定席料金の一部を予約者に返却する。
先予約者端末２ａは、路線図上の次の停車駅を中心に予約者端末に表示させ、スクロールによって先の合流予定駅を選択できるようにする。先予約者端末２ａは、路線図上の次の停車駅を中心に表示させることにより、予約者の指定動作の利便性を向上させる。
【００３９】
（計画１）の別の例として、コンサートなどの物理的に席が移動しない予約席を扱うときには、予約管理サーバ１は、予約席の位置確認（Ｓ１１１ｂなど）を省略することができる。予約管理サーバ１は、予約者（先予約者端末２ａ）があらかじめ指定したコンサート開始後時間までに到着圏内である場合には、予約者に途中合流の確認を促す。その確認の結果、先予約者端末２ａの通信状況が電波圏外であるなど、予約者の移動が確認できない場合には、先予約者端末２ａの予約席を後予約者端末２ｂに再販してもよい。
【００４０】
Ｓ１２０の（計画２）は、「途中下車」のケースである。図１（ｂ）では、利用者ＩＤ「A3」の利用者が途中下車している。
先予約者端末２ａの予約者は、予約区間のうちの前区間までは乗車しており、後区間からは下車する予定である。そして、現在は後区間であるとする。
予約管理サーバ１は、予約者が列車を早くおりた場合には、予約した列車に再乗車できない（別の後続列車が追い抜きできない）ことを時刻表データなどで確認した後、予約者に確認を促す。
先予約者端末２ａから乗車しない旨の通知が応答されたときには、先予約者端末２ａの予約席をキャンセルし、後予約者端末２ｂに再販することができる。なお、予約者が先予約者端末２ａを介して自らキャンセルすることもできるが、予約者に確認を促すことにより、キャンセルのし忘れを抑制できる。
【００４１】
Ｓ１２０の（計画３）は、「予約の全面変更」のケースである。
予約管理サーバ１は、Ｓ１１０の発車時刻前であっても、現在時刻における列車と予約者の両位置情報を取得する（Ｓ１１１ａ〜Ｓ１１２ｂ）。そして、予約管理サーバ１は、時刻表データを参照して、今後の発車時刻までに予約者の乗車が困難である（予約者が遅刻する）か否かを判定する。予約者が遅刻すると判定されるときには、予約管理サーバ１は、先予約者端末２ａの予約を全区間キャンセルさせるとともに、別のプランを先予約者端末２ａに推薦する。
予約管理サーバ１は、例えば列車の場合、予約者の位置情報から推測して最適な乗車列車を推薦する。
予約管理サーバ１は、例えば映画やコンサートなどの講演の場合、予約者の位置情報から推測して視聴可能な講演を推薦する。
【００４２】
Ｓ１２１として、予約管理サーバ１は、Ｓ１２０で計画した変更案内を先予約者端末２ａに通知し、先予約者端末２ａに予約の変更手続をさせた結果を受信する（Ｓ１２２）。予約管理サーバ１は、Ｓ１２２の結果（先予約者のキャンセル）を予約管理データベース１１に反映する。この反映処理は、例えば、席ＩＤに対応していた先予約者の利用者ＩＤを、予約管理データベース１１から削除する処理である。
Ｓ１２３として、予約管理サーバ１は、Ｓ１２２で変更された結果を車掌端末９にも通知することで、車掌に先予約者のキャンセルを知らせる。
Ｓ１３１〜Ｓ１３３は、後予約者端末２ｂの予約処理である。Ｓ１０１〜Ｓ１０３と同様に、予約管理サーバ１は、後予約者端末２ｂからの予約依頼を受けて、Ｓ１２２で変更（キャンセル）された指定席の予約を再販する。
【００４３】
図３は、予約管理サーバの予約変更処理を示すフロー説明図である。以下では、図２の説明と対応づけて、図３を説明する。
Ｓ２０１として、予約管理サーバ１は、発車時刻まで待つ（Ｓ１１０）。
Ｓ２０２として、予約管理サーバ１は、列車と予約者それぞれの位置情報を取得する（Ｓ１１１ａ〜Ｓ１１２ｂ）。
【００４４】
Ｓ２０３として、予約管理サーバ１は、列車は、現在駅間を走行中か否かを判定する。Ｓ２０３でＹｅｓならＳ２０４に進み、ＮｏならＳ２０２に戻る。
Ｓ２０４として、予約管理サーバ１は、両位置（Ｓ１１２ａの位置、Ｓ１１２ｂの位置）が一致するか否かを判定する（Ｓ１１５）。Ｓ２０４でＹｅｓならＳ２０５に進み、ＮｏならＳ２１１に進む。
【００４５】
Ｓ２０５として、予約管理サーバ１は、列車と予約者それぞれの位置情報を取得する（Ｓ１１３ａ〜Ｓ１１４ｂ）。
Ｓ２０６として、予約管理サーバ１は、両位置（Ｓ１１４ａの位置、Ｓ１１４ｂの位置）が一致するか否かを判定する（Ｓ１１５）。Ｓ２０６でＹｅｓなら乗車しているとして処理を終了し、ＮｏならＳ２１１に進む。
【００４６】
Ｓ２１１として、予約管理サーバ１は、予約者に乗車の確認をする（Ｓ１１６ａ）。
Ｓ２１２として、予約管理サーバ１は、乗車の通知（Ｓ１１７ａ）として、乗車しているか否かを判定する。Ｓ２１２でＹｅｓなら処理を終了し、ＮｏならＳ２１３に進む。
【００４７】
Ｓ２１３として、予約管理サーバ１は、車掌に乗車の確認をする（Ｓ１１６ｂ）。
Ｓ２１４として、予約管理サーバ１は、乗車の通知（Ｓ１１７ｂ）として、乗車しているか否かを判定する。Ｓ２１４でＹｅｓなら処理を終了し、Ｎｏなら予約者（先予約者端末２ａ）に予約変更を案内する（Ｓ１２０〜Ｓ１２３）。
【００４８】
図４は、不正乗車確認処理を示すフロー説明図である。不正乗車とは、予約者以外の乗客が予約席を確保していることである。なお、ある座席の予約者であっても、その座席の予約区間外（乗車駅の手前）から席を確保している場合には、不正乗車とする。
車掌は、以下の図４の処理により車掌端末９を介して不正乗車を知ることで、その場で乗車券の有無、指定席の場所の確認を行い、支払を促すことができる。
【００４９】
Ｓ３０１として、予約管理サーバ１は、車掌端末９から席ＩＤを指定された予約管理データベース１１内の検索要求を受け付ける。
Ｓ３０２として、予約管理サーバ１は、Ｓ３０１の席ＩＤを検索キーとして、予約管理データベース１１から指定された席の予約を確認する。
Ｓ３０３として、予約管理サーバ１は、Ｓ３０２の確認結果が予約あり（席ＩＤに対応する利用者ＩＤが空欄ではない）か否かを判定するとともに、予約ありの場合（Ｓ３０３でＹｅｓ）、その予約席の乗車判定が「○乗車」である（予約者が乗車している）か否かを判定する（Ｓ３０４）。
【００５０】
Ｓ３０３およびＳ３０４でＹｅｓなら、予約管理サーバ１は、予約者が正規に乗車している旨の検索応答を車掌端末９に返信する。
Ｓ３０３またはＳ３０４でＮｏなら、予約管理サーバ１は、予約者の未乗車が確定した席に不正者が乗車している旨の検索応答を車掌端末９に返信する。
【００５１】
以上説明した本実施形態では、先予約者端末２ａによる位置情報ＡＰＩを利用した位置情報提供機能と、予約管理サーバ１による予約者のモバイル端末と列車の予約席とを予約管理データベース１１で対応付ける機能を用いた、指定席の空席確認システムを提案した。この予約管理サーバ１は、Ｓ１１１ａ，Ｓ１１３ａの位置確認信号を送信する送信手段と、Ｓ１１５の両位置の照合を行う判定手段と、Ｓ１２０の計画に基づきＳ１２１の変更案内を送信する案内手段とを少なくとも有する。
鉄道会社は、予約者の位置情報と列車（予約された指定席）の位置情報とを取得し、両位置情報が一致した場合、予約者は予約した列車に乗車していると判断する。
これにより、位置情報を用いることで、実際の予約者の乗車有無を高精度に把握できるため、乗車していないと判断した場合は、指定席販売者は即座に予約者へ変更や払い戻しの手続きが必要か確認することができる。また、鉄道会社は、未使用の予約席を別の利用者へと迅速に再販できる。
【００５２】
なお、非特許文献１に記載の現状のモバイルSuicaのシステムでは、本実施形態の図２のＳ１２１のような列車の運行中における旅行プランの変更案内は、提示されてこなかった。
モバイルSuicaのシステムでは、鉄道会社は、列車の運転中止や遅れが生じた場合は、列車の運行情報や改札機から得られる情報に基づき、払いもどしの案内を発行する。払いもどし対象者には、乗車日３日後以降、アプリ画面上及びメールにより払いもどしの案内が届く。
また、災害時などには、列車や飛行機等の指定席を予約していても、ダイヤの乱れなどで必ずしも予約した指定席に乗るとは限らないため、予約済みでも乗車しない指定席が発生してしまう。
【００５３】
よって、モバイルSuicaのシステムでは、先予約者による未乗車時の予約キャンセル処理は、発生しにくくなってしまう。一方、本実施形態では、実際の予約者の乗車有無を高精度に把握するために、適切に未乗車時の予約キャンセルを先予約者端末２ａに促すことができる。
【符号の説明】
【００５４】
１      予約管理サーバ
２ａ    先予約者端末
２ｂ    後予約者端末
８      指定席管理装置
９      車掌端末
１１    予約管理データベース
【図１】
2015203905.tif 000003
【図２】
2015203905.tif 000004
【図３】
2015203905.tif 000005
【図４】
2015203905.tif 000006