ホーム > 特許ランキング > 両備ホールディングス株式会社
知財求人 - 知財ポータルサイト「IP Force」
特許7631602高速バスシステム、高速バス処理方法、及び、高速バス処理プログラム、並びに、交通予約システム、交通予約方法、及び、交通予約プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2025-02-07
(45)【発行日】2025-02-18
(54)【発明の名称】高速バスシステム、高速バス処理方法、及び、高速バス処理プログラム、並びに、交通予約システム、交通予約方法、及び、交通予約プログラム
(51)【国際特許分類】
G06Q 10/02 20120101AFI20250210BHJP
G06Q 50/40 20240101ALI20250210BHJP
【ＦＩ】
G06Q10/02
G06Q50/40
【請求項の数】
10
(21)【出願番号】P 2024125194
(22)【出願日】2024-07-31
【審査請求日】2024-09-09
【早期審査対象出願】
(73)【特許権者】
【識別番号】509304922
【氏名又は名称】両備ホールディングス株式会社
(74)【代理人】
【識別番号】110002354
【氏名又は名称】弁理士法人平和国際特許事務所
(72)【発明者】
【氏名】大上 真司
(72)【発明者】
【氏名】三垣 順平
【審査官】毛利 太郎
(56)【参考文献】
【文献】特表２０２０－５１４８９５（ＪＰ，Ａ）
【文献】特開２００５－２１６０３４（ＪＰ，Ａ）
【文献】特開２０２３－０８６７８８（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ １０／００ － ９９／００
(57)【特許請求の範囲】
【請求項1】
複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバと、を備えた高速バスシステムにおいて、前記サーバは、
前記予約システムが記憶している管理情報を記憶する管理情報記憶手段と、
路線の予約を受け付ける予約受付手段と、
前記予約受付手段により路線の予約を受け付けた場合、前記管理情報記憶手段に記憶されている管理情報に基づいて前記路線の予約を実行する予約手段と、を備え、
前記管理情報には、高速バスの座席の予約に必要な座席情報が含まれ、
座席の予約を受け付ける座席予約受付手段と、
前記座席予約受付手段により座席の予約を受け付けた場合、前記管理情報記憶手段に記憶されている座席情報に基づいて前記座席の予約を実行する座席予約手段と、を備え、
前記路線には、第１運営者及び第２運営者を含む複数の運営者が共同して高速バスを運行する共同運行路線が含まれ、
前記共同運行路線で運行される高速バスの座席を示す情報に、特定の運営者が管理する座席であることを示す特定情報を対応付けて記憶する特定情報記憶手段と、
前記特定情報が対応付けられている座席に対し、前記特定の運営者による予約を許容すると共に前記座席予約手段による予約を制限する座席予約制御手段と、を備えた
ことを特徴とする高速バスシステム。
【請求項2】
前記路線には、第三運営者を含む複数の運営者が共同して運行する共同運行路線が含まれ、
前記特定情報記憶手段は、
前記第三運営者が管理する座席であることを示す特定情報を、前記座席を示す情報に対応付けて記憶し、
前記座席予約制御手段は、
前記特定情報が対応付けられている座席に対し、前記座席予約手段による予約を実行させる
ことを特徴とする請求項１記載の高速バスシステム。
【請求項3】
前記特定情報記憶手段に、一の運営者が管理している座席に対し、他の運営者が管理している座席であることを示す特定情報を対応付けて記憶させることで、前記座席を他の運営者が管理する座席に変更する変更手段を備えた
ことを特徴とする請求項１又は２に記載の高速バスシステム。
【請求項4】
前記変更手段は、
前記一の運営者が管理している座席の数が所定数になった場合に実行する
ことを特徴とする請求項３に記載の高速バスシステム。
【請求項5】
前記路線は、第１路線と第２路線を含む複数の路線を乗継ぎする乗継路線を含む
ことを特徴とする請求項１に記載の高速バスシステム。
【請求項6】
複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバと、を用いた高速バス予約方法において、
前記予約システムが記憶している管理情報を記憶する第１ステップと、
路線の予約を受け付ける第２ステップと、
前記第２ステップにより路線の予約を受け付けた場合、前記第１ステップにおいて記憶した管理情報に基づいて前記路線の予約を実行する第３ステップと、を有し、
前記管理情報には、高速バスの座席の予約に必要な座席情報が含まれ、
座席の予約を受け付ける第４ステップと、
前記第４ステップにより座席の予約を受け付けた場合、前記管理情報に記憶されている座席情報に基づいて前記座席の予約を実行する第５ステップと、を有し、
前記路線には、第１運営者及び第２運営者を含む複数の運営者が共同して高速バスを運行する共同運行路線が含まれ、
前記共同運行路線で運行される高速バスの座席を示す情報に、特定の運営者が管理する座席であることを示す特定情報を対応付けて記憶する第６ステップと、
前記特定情報が対応付けられている座席に対し、前記特定の運営者による予約を許容すると共に前記第５ステップにおける予約を制限する第７ステップと、を有する
ことを特徴とする高速バス予約方法。
【請求項7】
複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと接続されたコンピュータを、
前記予約システムが記憶している管理情報を記憶する管理情報記憶手段、
路線の予約を受け付ける予約受付手段、
前記予約受付手段により路線の予約を受け付けた場合、前記管理情報記憶手段に記憶されている管理情報に基づいて前記路線の予約を実行する予約手段、として機能させ、
前記管理情報には、高速バスの座席の予約に必要な座席情報が含まれ、
座席の予約を受け付ける座席予約受付手段、
前記座席予約受付手段により座席の予約を受け付けた場合、前記管理情報記憶手段に記憶されている座席情報に基づいて前記座席の予約を実行する座席予約手段、として機能させ、
前記路線には、第１運営者及び第２運営者を含む複数の運営者が共同して高速バスを運行する共同運行路線が含まれ、
前記共同運行路線で運行される高速バスの座席を示す情報に、特定の運営者が管理する座席であることを示す特定情報を対応付けて記憶する特定情報記憶手段、
前記特定情報が対応付けられている座席に対し、前記特定の運営者による予約を許容すると共に前記座席予約手段による予約を制限する座席予約制御手段、として機能させる
ことを特徴とする高速バス予約プログラム。
【請求項8】
複数の運営者により運営される複数のルートの予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバと、を備えた交通予約システムにおいて、
前記サーバは、
前記予約システムが記憶している管理情報を記憶する管理情報記憶手段と、
ルートの予約を受け付ける予約受付手段と、
前記予約受付手段によりルートの予約を受け付けた場合、前記管理情報記憶手段に記憶されている管理情報に基づいて前記ルートの予約を実行する予約手段と、を備え、
前記管理情報には、交通手段の座席の予約に必要な座席情報が含まれ、
座席の予約を受け付ける座席予約受付手段と、
前記座席予約受付手段により座席の予約を受け付けた場合、前記管理情報記憶手段に記憶されている座席情報に基づいて前記座席の予約を実行する座席予約手段と、を備え、
前記ルートには、第１運営者及び第２運営者を含む複数の運営者が共同して交通手段を運行する共同運行路線が含まれ、
前記共同運行路線で運行される交通手段の座席を示す情報に、特定の運営者が管理する座席であることを示す特定情報を対応付けて記憶する特定情報記憶手段と、
前記特定情報が対応付けられている座席に対し、前記特定の運営者による予約を許容すると共に前記座席予約手段による予約を制限する座席予約制御手段と、を備えた
ことを特徴とする交通予約システム。
【請求項9】
複数の運営者により運営される複数のルートの予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバと、を用いた交通予約方法において、
前記予約システムが記憶している管理情報を記憶する第１ステップと、
ルートの予約を受け付ける第２ステップと、
前記第２ステップによりルートの予約を受け付けた場合、前記第１ステップにおいて記憶した管理情報に基づいて前記ルートの予約を実行する第３ステップと、を有し、
前記管理情報には、交通手段の座席の予約に必要な座席情報が含まれ、
座席の予約を受け付ける第４ステップと、
前記第４ステップにより座席の予約を受け付けた場合、前記管理情報に記憶されている座席情報に基づいて前記座席の予約を実行する第５ステップと、を有し、
前記ルートには、第１運営者及び第２運営者を含む複数の運営者が共同して交通手段を運行する共同運行路線が含まれ、
前記共同運行路線で運行される交通手段の座席を示す情報に、特定の運営者が管理する座席であることを示す特定情報を対応付けて記憶する第６ステップと、
前記特定情報が対応付けられている座席に対し、前記特定の運営者による予約を許容すると共に前記第５ステップにおける予約を制限する第７ステップと、を有する
ことを特徴とする交通予約方法。
【請求項10】
複数の運営者により運営される複数のルートの予約に必要な管理情報をそれぞれ記憶する各予約システムと接続されたコンピュータを、
前記予約システムが記憶している管理情報を記憶する管理情報記憶手段、
ルートの予約を受け付ける予約受付手段、
前記予約受付手段によりルートの予約を受け付けた場合、前記管理情報記憶手段に記憶されている管理情報に基づいて前記ルートの予約を実行する予約手段、として機能させ、
前記管理情報には、交通手段の座席の予約に必要な座席情報が含まれ、
座席の予約を受け付ける座席予約受付手段、
前記座席予約受付手段により座席の予約を受け付けた場合、前記管理情報記憶手段に記憶されている座席情報に基づいて前記座席の予約を実行する座席予約手段、として機能させ、
前記ルートには、第１運営者及び第２運営者を含む複数の運営者が共同して交通手段を運行する共同運行路線が含まれ、
前記共同運行路線で運行される交通手段の座席を示す情報に、特定の運営者が管理する座席であることを示す特定情報を対応付けて記憶する特定情報記憶手段、
前記特定情報が対応付けられている座席に対し、前記特定の運営者による予約を許容すると共に前記座席予約手段による予約を制限する座席予約制御手段、として機能させる
ことを特徴とする交通予約プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、高速バスサービスにおける乗継ルート等のルート検索、予約、決済等、及び、予約処理の円滑化、共同運行路線の座席予約等を効果的に実行可能な高速バスシステム、高速バス処理方法、及び、高速バス処理プログラムに関する。
【背景技術】
【0002】
バス、飛行機、フェリー、タクシー、レンタカー、レンタサイクル等の複数種類の交通手段を一括で検索し、検索結果を提供するマルチモーダル交通検索システムが提案されている（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１９－２１１９６０号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
この種のシステムを活用し、検索された複数の交通手段を実際に利用する場合、第１の交通手段を利用した後、第２の交通手段の利用に際し、交通手段の乗継ぎが必要になる。
乗継ぎは、複数種類の交通手段を利用する場合だけでなく、単一の交通手段を利用する場合にも生じる。
例えば、高速バスの路線は、高速道路に沿って全国に設けられているが、地域ごとに運営するバス会社（主体）が異なるなどの理由から、発着地によってはバスや路線を乗り継ぐ必要がある。
例えば、地域Ａ（例えば東日本）は、バス会社Ａが高速バスＡの路線Ａを運営しているとすると、利用者が、地域Ａ内（例えば東京～名古屋）を高速バスで移動したい場合には、高速バスＡを利用しなければならない。
また、地域Ｂ（例えば西日本）は、バス会社Ｂが高速バスＢの路線Ｂを運営しているとすると、利用者が、地域Ｂ内（例えば大阪～岡山）を高速バスで移動したい場合には、高速バスＢを利用しなければならない。
そうすると、高速バスＡを利用する場合、バス会社Ａが運営する予約サイトや窓口（窓口Ａという）にアクセスして予約及び決済を行う必要があり、高速バスＢを利用する場合は、バス会社Ｂが運営する予約サイトや窓口（窓口Ｂという）にアクセスして予約及び決済を行う必要がある。
このため、高速バスを利用して地域Ａと地域Ｂをまたぐ移動（例えば東京→岡山）を行う場合、高速バスＡで路線Ａを移動した後、高速バスＢに乗り継いで路線Ｂを移動する必要があると共に、予め、窓口Ａにアクセスして高速バスＡの路線Ａ（例えば東京→大阪）の予約及び決済を行い、且つ、窓口Ｂにアクセスして高速バスＢの路線Ｂ（例えば大阪→岡山）の予約及び決済を行う必要があった。
つまり、乗継ぎだけでなく、複数の窓口にアクセスしてそれぞれ手続きを行う必要があった。
乗継ぎの活用により高速バスの路線を実質拡充できるなどメリットも見込める。
しかしながら、乗継ぎに伴う予約や決済などの手続きが煩わしい問題が残存する。
つまり、従来の高速バスシステムは、乗継ぎを行うことで利用価値の向上が図れるにもかかわらず、手続きが煩わしいことが課題として残っていた。
乗継ぎは、複数種類の交通手段を利用する場合だけでなく、単一の交通手段を利用する場合にも生じる。
例えば、高速バスの路線は、高速道路に沿って全国に設けられているが、地域ごとに運営するバス会社（主体）が異なるなどの理由から、発着地によってはバスや路線を乗り継ぐ必要がある。
例えば、地域Ａ（例えば東日本）は、バス会社Ａが高速バスＡの路線Ａを運営しているとすると、利用者が、地域Ａ内（例えば東京～名古屋）を高速バスで移動したい場合には、高速バスＡを利用しなければならない。
また、地域Ｂ（例えば西日本）は、バス会社Ｂが高速バスＢの路線Ｂを運営しているとすると、利用者が、地域Ｂ内（例えば大阪～岡山）を高速バスで移動したい場合には、高速バスＢを利用しなければならない。
そうすると、高速バスＡを利用する場合、バス会社Ａが運営する予約サイトや窓口（窓口Ａという）にアクセスして予約及び決済を行う必要があり、高速バスＢを利用する場合は、バス会社Ｂが運営する予約サイトや窓口（窓口Ｂという）にアクセスして予約及び決済を行う必要がある。
このため、高速バスを利用して地域Ａと地域Ｂをまたぐ移動（例えば東京→岡山）を行う場合、高速バスＡで路線Ａを移動した後、高速バスＢに乗り継いで路線Ｂを移動する必要があると共に、予め、窓口Ａにアクセスして高速バスＡの路線Ａ（例えば東京→大阪）の予約及び決済を行い、且つ、窓口Ｂにアクセスして高速バスＢの路線Ｂ（例えば大阪→岡山）の予約及び決済を行う必要があった。
つまり、乗継ぎだけでなく、複数の窓口にアクセスしてそれぞれ手続きを行う必要があった。
乗継ぎの活用により高速バスの路線を実質拡充できるなどメリットも見込める。
しかしながら、乗継ぎに伴う予約や決済などの手続きが煩わしい問題が残存する。
つまり、従来の高速バスシステムは、乗継ぎを行うことで利用価値の向上が図れるにもかかわらず、手続きが煩わしいことが課題として残っていた。
【0005】
このような課題に対し、手続きの電子化を行うことで一定の効果は得られるが、既存の予約システムとの通信を介した連携処理において障害等が発生し易く、これにより生じる他の問題に対処する必要がある（図２４参照）。
加えて、高速バスサービスにおいては、１つの路線（１台のバス）を複数のバス会社が共同運行する場合があり、以下に示すような座席管理上の課題があった。
例えば、バス会社Ａとバス会社Ｂが共同運行する路線において、バス会社Ａは、バスの前方半分の座席（前部座席という）を管理し、バス会社Ｂは前記バスの後方半分の座席（後部座席という）を管理するというケースについて説明する。
バス会社Ａが運営する予約システムＡでは前部座席に関する座席予約や座席管理（予約済み、空席などの予約状態の管理を含む）ができ、バス会社Ｂが運営する予約システムＢでは後部座席に関する座席予約や座席管理ができる。
このため、予約システムＡを介して予約するユーザーは、前部座席がすべて予約済みの場合、後部座席に空席があっても、当該後部座席は予約システムＢの管理下にあるため予約することはできない、という不合理な問題が生じていた。
共同運行においては、路線全体の売上げを所定の割合で各バス事業者に分配するところ、このような運営は売上げ増加を妨げる問題にもなる。
これらの問題に対し、従来は、バス会社Ａの担当者とバス会社Ｂの担当者とが電話等を介して連絡をとりあい、予約システムＢ管理下にある後部座席の一部をバス会社Ａに受け渡すことで対応していたが、人為的に行うため、煩わしく、かつ、間違いが生じ易いという問題があった。
加えて、高速バスサービスにおいては、１つの路線（１台のバス）を複数のバス会社が共同運行する場合があり、以下に示すような座席管理上の課題があった。
例えば、バス会社Ａとバス会社Ｂが共同運行する路線において、バス会社Ａは、バスの前方半分の座席（前部座席という）を管理し、バス会社Ｂは前記バスの後方半分の座席（後部座席という）を管理するというケースについて説明する。
バス会社Ａが運営する予約システムＡでは前部座席に関する座席予約や座席管理（予約済み、空席などの予約状態の管理を含む）ができ、バス会社Ｂが運営する予約システムＢでは後部座席に関する座席予約や座席管理ができる。
このため、予約システムＡを介して予約するユーザーは、前部座席がすべて予約済みの場合、後部座席に空席があっても、当該後部座席は予約システムＢの管理下にあるため予約することはできない、という不合理な問題が生じていた。
共同運行においては、路線全体の売上げを所定の割合で各バス事業者に分配するところ、このような運営は売上げ増加を妨げる問題にもなる。
これらの問題に対し、従来は、バス会社Ａの担当者とバス会社Ｂの担当者とが電話等を介して連絡をとりあい、予約システムＢ管理下にある後部座席の一部をバス会社Ａに受け渡すことで対応していたが、人為的に行うため、煩わしく、かつ、間違いが生じ易いという問題があった。
【0006】
本発明は、以上のような従来の技術が有する課題を解決するために提案されたものであり、乗継ぎやその手続きが容易・有益な高速バスシステム、高速バス処理方法、及び、高速バス処理プログラムの提供を目的とする。
また、予約処理の円滑化、及び、共同運行路線の座席予約等の効率化を可能にした高速バスシステム、高速バス予約方法、及び、高速バス予約プログラムの提供を目的とする。
また、予約処理の円滑化、及び、共同運行路線の座席予約等の効率化を可能にした高速バスシステム、高速バス予約方法、及び、高速バス予約プログラムの提供を目的とする。
【課題を解決するための手段】
【0007】
上記課題に鑑み、本発明の一態様に係る高速バスシステムは、複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバと、を備えた高速バスシステムにおいて、前記サーバは、前記予約システムが記憶している管理情報を記憶する管理情報記憶手段と、路線の予約を受け付ける予約受付手段と、前記予約受付手段により路線の予約を受け付けた場合、前記管理情報記憶手段に記憶されている管理情報に基づいて前記路線の予約を実行する予約手段と、を備える構成とした。
【0008】
また、本発明の他の一態様に係る高速バス予約方法は、複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバと、を用いた高速バス予約方法において、前記予約システムが記憶している管理情報を記憶する第１ステップと、路線の予約を受け付ける第２ステップと、前記第２ステップにより路線の予約を受け付けた場合、前記第１ステップにおいて記憶した管理情報に基づいて前記路線の予約を実行する第３ステップと、を有するようにした。
【0009】
また、本発明の他の一態様に係る高速バス予約プログラムは、複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと接続されたコンピュータを、前記予約システムが記憶している管理情報を記憶する管理情報記憶手段、路線の予約を受け付ける予約受付手段、前記予約受付手段により路線の予約を受け付けた場合、前記管理情報記憶手段に記憶されている管理情報に基づいて前記路線の予約を実行する予約手段、として機能させるようにした。
【発明の効果】
【0010】
本発明によれば、乗継ぎの手続きを容易化した一連の長距離バスのような利用価値の高い高速バスサービスを実現できる。
直行ルート、鉄道・飛行機など他の交通手段に欠く地域において、高速バスを新たな交通手段として参入させることができる。
乗継ぎを利用した新たな移動形態を提供できる。
また、予約処理の円滑化、共同運行路線の予約処理の効率化を図ることができる。
直行ルート、鉄道・飛行機など他の交通手段に欠く地域において、高速バスを新たな交通手段として参入させることができる。
乗継ぎを利用した新たな移動形態を提供できる。
また、予約処理の円滑化、共同運行路線の予約処理の効率化を図ることができる。
【図面の簡単な説明】
【0011】
【図1】本発明の一実施形態に係る高速バスシステムの概略図である。
【図2】サーバのハードウェア構成図である。
【図3】利用者端末のハードウェア構成図である。
【図4】サーバの機能構成図である。
【図5】グルーピング情報の一例を示す図表である。
【図6】グルーピングに基づくルート検索の説明図である。
【図7】特別乗継ルートの説明図である。
【図8】ルート検索の処理手順を示すシーケンスチャートである。
【図9】ルート検索画面の一例を示す図である。
【図10】検索結果画面の一例を示す図である。
【図11】便候補表示・選択画面の一例を示す図である。
【図12】予約・決済の処理手順を示すシーケンスチャートである。
【図13】料金情報表示画面の一例を示す図である。
【図14】予約画面の一例を示す図である。
【図15】予約結果画面の一例を示す図である。
【図16】決済実行画面の一例を示す図である。
【図17】予約変更の処理手順を示すシーケンスチャートである。
【図18】予約取消の処理手順を示すシーケンスチャートである。
【図19】レコメンド表示画面の一例を示す図である。
【図20】表示画面の他の一例（その１）を示す図である。
【図21】表示画面の他の一例（その２）を示す図である。
【図22】表示画面の他の一例（その３）を示す図である。
【図23】予約システムの連携（予約連携）の説明図である。
【図24】予約連携において発生する問題を説明するための図である。（ａ）は新規予約時に発生する問題を示す図であり、（ｂ）は人数変更・予約取消時に発生する問題を示す図である。
【図25】他の実施形態に係るサーバの機能構成図である。
【図26】他の実施形態に係る高速バスシステムの説明図である。
【図27】販売前の座席情報の取得（Ａ１）を示す図である。
【図28】販売前の販売座席の設定（Ａ２）を示す図である。
【図29】販売（予約）開始後の座席情報（Ａ３）を示す図である。
【図30】販売（予約）開始後の販売座席の追加・削除（Ａ４）を示す図である。
【図31】空席情報の取得（Ｂ１）を示す図である。
【図32】席もらいの依頼（Ｂ２）を示す図である。
【図33】席もらいの実行（Ｂ３）を示す図である。
【図34】席もらいの自動化（Ｂ４）を示す図である。
【発明を実施するための形態】
【0012】
本発明の高速バスシステムの好ましい実施形態について説明する。
【0013】
図１は、本発明の一実施形態に係る高速バスシステムの概略図である。
同図に示すように、本実施形態の高速バスシステムは、主に、サーバ１と、利用者端末２と、予約システムと、決済システムとにより構成される。
予約システムは、情報処理装置からなる予約サーバ３を備え、実質的には当該予約サーバ３の動作によって、後述する予約処理を実行可能に構成されている。
決済システムは、情報処理装置からなる決済サーバ４を備え、実質的には当該決済サーバ４の動作によって、後述する決済処理を実行可能に構成されている。
各装置は、インターネット９を介して相互に通信可能に接続されている。
同図に示すように、本実施形態の高速バスシステムは、主に、サーバ１と、利用者端末２と、予約システムと、決済システムとにより構成される。
予約システムは、情報処理装置からなる予約サーバ３を備え、実質的には当該予約サーバ３の動作によって、後述する予約処理を実行可能に構成されている。
決済システムは、情報処理装置からなる決済サーバ４を備え、実質的には当該決済サーバ４の動作によって、後述する決済処理を実行可能に構成されている。
各装置は、インターネット９を介して相互に通信可能に接続されている。
【0014】
図２は、サーバ１のハードウェア構成図である。
サーバ１は、制御部１０１と、メモリ１０２と、ストレージ１０３と、通信部１０４と、を備えた情報処理装置（コンピュータ）である。
制御部１０１は、プログラム（高速バス処理プログラムを含む）を実行するプロセッサであり、サーバ１の各部を制御し、サーバ１の機能を実現する処理を行う。制御部１０１にはＣＰＵ（Central Processing Unit）が備えられている。
メモリ１０２は、コンピュータが読み取り可能な記憶媒体であり、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などによって構成される。
ストレージ１０３は、コンピュータが読み取り可能な記憶媒体であり、ＳＳＤ（Solid State Drive）やハードディスクなどによって構成される。
メモリ１０２及び／又はストレージ１０３には、制御部１０１により実行されるプログラムが記憶される。
通信部１０４は、インターネット９に接続され、当該インターネット９を介して利用者端末２、予約サーバ３、決済サーバ４と通信を行う。
サーバ１は、制御部１０１と、メモリ１０２と、ストレージ１０３と、通信部１０４と、を備えた情報処理装置（コンピュータ）である。
制御部１０１は、プログラム（高速バス処理プログラムを含む）を実行するプロセッサであり、サーバ１の各部を制御し、サーバ１の機能を実現する処理を行う。制御部１０１にはＣＰＵ（Central Processing Unit）が備えられている。
メモリ１０２は、コンピュータが読み取り可能な記憶媒体であり、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などによって構成される。
ストレージ１０３は、コンピュータが読み取り可能な記憶媒体であり、ＳＳＤ（Solid State Drive）やハードディスクなどによって構成される。
メモリ１０２及び／又はストレージ１０３には、制御部１０１により実行されるプログラムが記憶される。
通信部１０４は、インターネット９に接続され、当該インターネット９を介して利用者端末２、予約サーバ３、決済サーバ４と通信を行う。
【0015】
図３は、利用者端末２のハードウェア構成図である。
利用者端末２は、制御部２０１と、メモリ２０２と、ストレージ２０３と、操作部２０４と、表示部２０５と、通信部２０６と、を備えた、スマートフォン、タブレット端末、パーソナルコンピュータなどの情報処理装置（コンピュータ）である。
制御部２０１は、プログラムを実行するプロセッサであり、利用者端末２の各部を制御し、利用者端末２の機能を実現する処理を行う。制御部２０１にはＣＰＵ（Central Processing Unit）が用いられる。
メモリ２０２は、コンピュータが読み取り可能な記憶媒体であり、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などによって構成される。
ストレージ２０３は、コンピュータが読み取り可能な記憶媒体であり、ＳＳＤ（Solid State Drive）やハードディスクなどによって構成される。
メモリ２０２及び／又はストレージ２０３には、制御部２０１により実行されるプログラムが記憶される。
操作部２０４は、利用者端末２の操作に用いられる。操作部２０４は、例えばパーソナルコンピュータにおけるキーボードやマウス、スマートフォンやタブレット端末におけるタッチパネルなどが該当する。
表示部２０５は、サーバ１から受信した情報や各種画面を表示する（図９，１０，１１，１３～１６，１９）。表示部２０５には、例えば液晶ディスプレイやタッチパネルが用いられる。
通信部２０６は、インターネット９に接続され、当該インターネット９を介してサーバ１と通信を行う。
利用者端末２には、Ｗｅｂブラウザがインストールされている。
利用者端末２は、制御部２０１と、メモリ２０２と、ストレージ２０３と、操作部２０４と、表示部２０５と、通信部２０６と、を備えた、スマートフォン、タブレット端末、パーソナルコンピュータなどの情報処理装置（コンピュータ）である。
制御部２０１は、プログラムを実行するプロセッサであり、利用者端末２の各部を制御し、利用者端末２の機能を実現する処理を行う。制御部２０１にはＣＰＵ（Central Processing Unit）が用いられる。
メモリ２０２は、コンピュータが読み取り可能な記憶媒体であり、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などによって構成される。
ストレージ２０３は、コンピュータが読み取り可能な記憶媒体であり、ＳＳＤ（Solid State Drive）やハードディスクなどによって構成される。
メモリ２０２及び／又はストレージ２０３には、制御部２０１により実行されるプログラムが記憶される。
操作部２０４は、利用者端末２の操作に用いられる。操作部２０４は、例えばパーソナルコンピュータにおけるキーボードやマウス、スマートフォンやタブレット端末におけるタッチパネルなどが該当する。
表示部２０５は、サーバ１から受信した情報や各種画面を表示する（図９，１０，１１，１３～１６，１９）。表示部２０５には、例えば液晶ディスプレイやタッチパネルが用いられる。
通信部２０６は、インターネット９に接続され、当該インターネット９を介してサーバ１と通信を行う。
利用者端末２には、Ｗｅｂブラウザがインストールされている。
【0016】
予約サーバ３は、サーバ１と同様のハードウェア構成を備えた情報処理装置であり、予約システムと同義である。
予約サーバ３は、第１路線の高速バスＡの運営を行うバス会社Ａが管理する予約サーバ３Ａ、第２路線の高速バスＢの運営を行うバス会社Ｂが管理する予約サーバ３Ｂなど、複数存在する。
予約サーバ３Ａは、従来から高速バスＡや第１路線の予約サイトＡを運営している。
このため、利用者は、従来から、情報端末を用いて予約サイトＡにアクセスして高速バスＡやその路線Ａの予約処理を行うことができることを前提としている。
予約サーバ３Ｂは、従来から高速バスＢや第２路線の予約サイトＢを運営している。
このため、利用者は、従来から、情報端末を用いて予約サイトＢにアクセスして高速バスＢやその路線Ｂの予約処理を行うことができることを前提としている。
このように、予約サーバ３は、高速バスの運営者、当該運営者が運営する高速バスや路線に応じて複数設けられている。
予約サーバ３は、インターネット９を介してサーバ１と通信を行う。
なお、予約サーバ３は、サーバ１と同様のハードウェア構成であるため、詳細な説明を省略する。
予約サーバ３は、第１路線の高速バスＡの運営を行うバス会社Ａが管理する予約サーバ３Ａ、第２路線の高速バスＢの運営を行うバス会社Ｂが管理する予約サーバ３Ｂなど、複数存在する。
予約サーバ３Ａは、従来から高速バスＡや第１路線の予約サイトＡを運営している。
このため、利用者は、従来から、情報端末を用いて予約サイトＡにアクセスして高速バスＡやその路線Ａの予約処理を行うことができることを前提としている。
予約サーバ３Ｂは、従来から高速バスＢや第２路線の予約サイトＢを運営している。
このため、利用者は、従来から、情報端末を用いて予約サイトＢにアクセスして高速バスＢやその路線Ｂの予約処理を行うことができることを前提としている。
このように、予約サーバ３は、高速バスの運営者、当該運営者が運営する高速バスや路線に応じて複数設けられている。
予約サーバ３は、インターネット９を介してサーバ１と通信を行う。
なお、予約サーバ３は、サーバ１と同様のハードウェア構成であるため、詳細な説明を省略する。
【0017】
決済サーバ４は、サーバ１と同様のハードウェア構成を備えた情報処理装置であり、決済システムと同義である。
決済サーバ４は、サーバ１で予約処理された案件に対する決済処理を行う。
本実施形態の決済サーバ４は、クレジットカード会社により運営されており、クレジットカード決済を可能とする。
なお、クレジットカード決済に代えて又は加えて、他の決済方法（銀行振込、電子マネー決済、コンビニ決済等）を用いることもできる。
決済サーバ４は、サーバ１や予約サーバ３と同様のハードウェア構成であるため、詳細な説明を省略する。
決済サーバ４は、サーバ１で予約処理された案件に対する決済処理を行う。
本実施形態の決済サーバ４は、クレジットカード会社により運営されており、クレジットカード決済を可能とする。
なお、クレジットカード決済に代えて又は加えて、他の決済方法（銀行振込、電子マネー決済、コンビニ決済等）を用いることもできる。
決済サーバ４は、サーバ１や予約サーバ３と同様のハードウェア構成であるため、詳細な説明を省略する。
【0018】
図４は、サーバ１の機能構成図である。
同図に示すように、サーバ１（制御部１０１）は、記憶手段１１、抽出手段１２、表示制御手段１３、予約手段１４、決済手段１５、予約変更手段１６、予約取消手段１７、及び、特典付与手段１８を備えている。
同図に示すように、サーバ１（制御部１０１）は、記憶手段１１、抽出手段１２、表示制御手段１３、予約手段１４、決済手段１５、予約変更手段１６、予約取消手段１７、及び、特典付与手段１８を備えている。
【0019】
記憶手段１１は、全国に現存する高速バスの路線情報を予め記憶（格納）している。
路線情報は、予約サーバ３が管理している路線情報と共通する。
このため、記憶手段１１には、各予約サーバ３が管理している路線情報を取得して記憶させておけばよい。例えば、各予約サーバ３において、路線情報の更新時に、更新後の路線情報を予約サーバ３から送信させたり、ＡＰＩ連携により、適時、サーバ１から路線情報を取得したりして更新してもよい。予約サーバ３に限らず、高速バスの路線情報を提供している情報公開サービス（情報公開サーバ）から路線情報を取得しても良い。
路線情報は、具体的には、路線の名称、各停留所の名称や配置順序、各停留所の地域名、路線の始まり及び終わりの地域名、運営バス会社等、路線に関する様々な情報を識別可能に構成されており、且つ、各情報は相互に紐づけられている。
このため、制御部１０１は、路線情報を参照することで、例えば、現存する高速バスの路線の名称、各停留所の名称や配置順序、各停留所の地域名、路線の始まり及び終わりの地域名、運営バス会社等を認識することができる。
路線情報は、予約サーバ３が管理している路線情報と共通する。
このため、記憶手段１１には、各予約サーバ３が管理している路線情報を取得して記憶させておけばよい。例えば、各予約サーバ３において、路線情報の更新時に、更新後の路線情報を予約サーバ３から送信させたり、ＡＰＩ連携により、適時、サーバ１から路線情報を取得したりして更新してもよい。予約サーバ３に限らず、高速バスの路線情報を提供している情報公開サービス（情報公開サーバ）から路線情報を取得しても良い。
路線情報は、具体的には、路線の名称、各停留所の名称や配置順序、各停留所の地域名、路線の始まり及び終わりの地域名、運営バス会社等、路線に関する様々な情報を識別可能に構成されており、且つ、各情報は相互に紐づけられている。
このため、制御部１０１は、路線情報を参照することで、例えば、現存する高速バスの路線の名称、各停留所の名称や配置順序、各停留所の地域名、路線の始まり及び終わりの地域名、運営バス会社等を認識することができる。
【0020】
特に、本実施形態に係るサーバ１において、路線情報は、直行ルートだけでなく乗継ルートの検索ができるように、乗継ぎの対象となる路線同士をグルーピングしている。
「直行ルート」は乗継ぎを必要としない路線のことであり、「乗継ルート」は乗継ぎを必要とする路線のことである。
「グルーピング」は、基本的には、一路線の終わりの地域や停留所と、他路線の始まりの地域や停留所とが同じ場合、これら２つの路線を直列的に紐づけて記憶するものである。
この２つの路線の説明は一例であり、３つ以上の路線を直列的に紐づけてグルーピングさせることができる。
「直行ルート」は乗継ぎを必要としない路線のことであり、「乗継ルート」は乗継ぎを必要とする路線のことである。
「グルーピング」は、基本的には、一路線の終わりの地域や停留所と、他路線の始まりの地域や停留所とが同じ場合、これら２つの路線を直列的に紐づけて記憶するものである。
この２つの路線の説明は一例であり、３つ以上の路線を直列的に紐づけてグルーピングさせることができる。
【0021】
図５は、グルーピング情報の一例を示す図である。
グルーピング情報について、図５の１行目を例に説明する。
このグルーピング情報は、「東京→大阪」路線の終わり地域と、「大阪→岡山」路線及び「大阪→広島」路線の始まり地域とが同じ「大阪」であることから、「東京→大阪」路線（先行路線）と「大阪→岡山」路線及び「大阪→広島」路線（後行路線）とを同じグループとして紐づけた情報である。なお、「〇〇→□□」は路線の名称を示し、〇〇は路線の始まりの地域名を示し、□□は路線の終わりの地域名を示す。
これにより、「東京→大阪」路線を高速バスで移動し、大阪で降車し他の高速バスに乗継ぎして岡山に向かう乗継ルートや、「東京→大阪」路線を高速バスで移動し、大阪で降車し他の高速バスに乗継ぎして広島に向かう乗継ルートが設定（登録）される。
乗継ルートの設定や登録（記憶）は、上述のルールに従うことで、コンピュータにより自動的に実行させてもよく、人為的に行ってもよい。
人為的に行うことで、必要と思われる乗継ルートだけを設定することができる。
コンピュータ処理の場合、無用な乗継ルートが多数設定される可能性があるが、後述する方法（乗継数の制限など）を組み合わせたり、人為的に間引くことで無用な乗継ルートを減らすことができる。
グルーピング情報は、路線情報の一部を構成する情報として記憶手段１１に記憶されている。
グルーピング情報について、図５の１行目を例に説明する。
このグルーピング情報は、「東京→大阪」路線の終わり地域と、「大阪→岡山」路線及び「大阪→広島」路線の始まり地域とが同じ「大阪」であることから、「東京→大阪」路線（先行路線）と「大阪→岡山」路線及び「大阪→広島」路線（後行路線）とを同じグループとして紐づけた情報である。なお、「〇〇→□□」は路線の名称を示し、〇〇は路線の始まりの地域名を示し、□□は路線の終わりの地域名を示す。
これにより、「東京→大阪」路線を高速バスで移動し、大阪で降車し他の高速バスに乗継ぎして岡山に向かう乗継ルートや、「東京→大阪」路線を高速バスで移動し、大阪で降車し他の高速バスに乗継ぎして広島に向かう乗継ルートが設定（登録）される。
乗継ルートの設定や登録（記憶）は、上述のルールに従うことで、コンピュータにより自動的に実行させてもよく、人為的に行ってもよい。
人為的に行うことで、必要と思われる乗継ルートだけを設定することができる。
コンピュータ処理の場合、無用な乗継ルートが多数設定される可能性があるが、後述する方法（乗継数の制限など）を組み合わせたり、人為的に間引くことで無用な乗継ルートを減らすことができる。
グルーピング情報は、路線情報の一部を構成する情報として記憶手段１１に記憶されている。
【0022】
抽出手段１２は、利用者端末２により入力された情報に基づき、利用者が利用可能なルート（以下、「利用可能ルート」ともいう）を、記憶手段１１に記憶されている線路情報から抽出する。
抽出手段１２は、直行ルートだけでなく、乗継ルートの抽出も可能である。
「乗継ルート（乗継路線ともいう）」は、先行路線（第１路線）と後行路線（第２路線）を含む複数の路線の間で乗継ぎを伴うルート（利用可能ルート）と定義することもできる。
「複数の路線」であるため、２つのルートの乗継ぎに限らず、３つ以上のルートの乗継ぎを含む。
つまり、利用可能ルートには、２つのルートをつなぐ乗継ルートだけでなく、３つ以上のルートをつなぐ乗継ルートを含む。
抽出手段１２は、直行ルートだけでなく、乗継ルートの抽出も可能である。
「乗継ルート（乗継路線ともいう）」は、先行路線（第１路線）と後行路線（第２路線）を含む複数の路線の間で乗継ぎを伴うルート（利用可能ルート）と定義することもできる。
「複数の路線」であるため、２つのルートの乗継ぎに限らず、３つ以上のルートの乗継ぎを含む。
つまり、利用可能ルートには、２つのルートをつなぐ乗継ルートだけでなく、３つ以上のルートをつなぐ乗継ルートを含む。
【0023】
図６は、本実施形態に係るサーバ１（抽出手段１２）において実行される、グルーピングに基づくルート検索の説明図である。
以下、「東京→岡山」を検索条件としてルート検索した場合について説明する。
なお、「検索条件」は、利用者が利用者端末２を入力操作することで設定できる。つまり、利用者端末２で検索条件（出発地：東京及び目的地：岡山）が入力された場合、利用者端末２は、入力された検索条件情報をサーバ１に送信する。
サーバ１では、利用者端末２から送信された検索条件情報を通信部１０４が受信し、当該検索条件情報に基づき検索条件を設定することができる。
以下、「東京→岡山」を検索条件としてルート検索した場合について説明する。
なお、「検索条件」は、利用者が利用者端末２を入力操作することで設定できる。つまり、利用者端末２で検索条件（出発地：東京及び目的地：岡山）が入力された場合、利用者端末２は、入力された検索条件情報をサーバ１に送信する。
サーバ１では、利用者端末２から送信された検索条件情報を通信部１０４が受信し、当該検索条件情報に基づき検索条件を設定することができる。
【0024】
検索条件が「東京→岡山」の場合、まず、制御部１０１（抽出部１２）は、記憶手段１１に記憶されている路線情報（グルーピング情報を含む）を参照し、「東京」を始まりの地域とする路線（第１路線）を抽出する。
これにより、「東京→大阪」、「東京→神戸」、「東京→岡山」の路線が第１路線として抽出されたものとする。
ただし、抽出された路線の終わりの地域が「出発地と同じ」路線は除外する。
このように、抽出された路線の終わりの地域が「出発地と同じ」場合にその路線を除外するルールを「第１ルール」という。
なお、上記第１路線のなかに第１ルールに該当する路線はないため、第１ルールに基づき除外される路線はない。
また、抽出された路線の終わりの地域が「目的地と同じ」場合、抽出手段１２は、その路線を利用可能ルートとして抽出する。利用可能ルートとして抽出された路線の下位のルート検索は実行せず終了する。
このように、抽出された路線の終わりの地域が「目的地と同じ」場合にその路線を利用可能ルートとして抽出し、その時点で、ルート検索を終了するルールを「第２ルール」という。
前記第１路線のなかに第２ルールに該当する路線は「東京→岡山」である。
このため、抽出手段１２は、「東京→岡山」路線の直行ルートを利用可能ルートとして抽出する。「東京→岡山」の下位のルート検索は実行せず終了する。
これにより、「東京→大阪」、「東京→神戸」、「東京→岡山」の路線が第１路線として抽出されたものとする。
ただし、抽出された路線の終わりの地域が「出発地と同じ」路線は除外する。
このように、抽出された路線の終わりの地域が「出発地と同じ」場合にその路線を除外するルールを「第１ルール」という。
なお、上記第１路線のなかに第１ルールに該当する路線はないため、第１ルールに基づき除外される路線はない。
また、抽出された路線の終わりの地域が「目的地と同じ」場合、抽出手段１２は、その路線を利用可能ルートとして抽出する。利用可能ルートとして抽出された路線の下位のルート検索は実行せず終了する。
このように、抽出された路線の終わりの地域が「目的地と同じ」場合にその路線を利用可能ルートとして抽出し、その時点で、ルート検索を終了するルールを「第２ルール」という。
前記第１路線のなかに第２ルールに該当する路線は「東京→岡山」である。
このため、抽出手段１２は、「東京→岡山」路線の直行ルートを利用可能ルートとして抽出する。「東京→岡山」の下位のルート検索は実行せず終了する。
【0025】
次に、制御部１０１（抽出部１２）は、第１路線の終わりの地域を始まりの地域とする路線（第２路線）を抽出する。つまり、先行路線「東京→大阪」と「東京→神戸」のそれぞれについて、後行路線（第２路線）を抽出する。
「東京→大阪」路線の場合、終わりの地域は「大阪」であるため、「大阪」を始まりの地域とする路線を抽出する。これにより、「大阪→東京」、「大阪→岡山」、「大阪→広島」が第２路線として抽出されたものとする。
ただし、第１ルールに基づき、抽出された路線の終わりの地域が出発地と同じである「大阪→東京」路線は除外される。
「東京→神戸」路線の場合、終わりの地域は「神戸」であるため、「神戸」を始まりの地域とする路線を抽出する。これにより、「神戸→東京」、「神戸→岡山」が第２路線として抽出されたものとする。
ただし、第１ルールに基づき、抽出された路線の終わりの地域が出発地と同じである「神戸→東京」路線は除外される。
この結果、「大阪→岡山」路線及び「神戸→岡山」路線は、路線の終わりの地域が目的地と同じであるため、第２ルールに基づき、利用可能ルート（の一部）として抽出される。
つまり、この場合、「東京→大阪」→「大阪→岡山」の乗継ルート及び「東京→神戸」→「神戸→岡山」の乗継ルートが、利用可能ルートとして抽出される。また、各路線のルート検索を終了する。
「東京→大阪」路線の場合、終わりの地域は「大阪」であるため、「大阪」を始まりの地域とする路線を抽出する。これにより、「大阪→東京」、「大阪→岡山」、「大阪→広島」が第２路線として抽出されたものとする。
ただし、第１ルールに基づき、抽出された路線の終わりの地域が出発地と同じである「大阪→東京」路線は除外される。
「東京→神戸」路線の場合、終わりの地域は「神戸」であるため、「神戸」を始まりの地域とする路線を抽出する。これにより、「神戸→東京」、「神戸→岡山」が第２路線として抽出されたものとする。
ただし、第１ルールに基づき、抽出された路線の終わりの地域が出発地と同じである「神戸→東京」路線は除外される。
この結果、「大阪→岡山」路線及び「神戸→岡山」路線は、路線の終わりの地域が目的地と同じであるため、第２ルールに基づき、利用可能ルート（の一部）として抽出される。
つまり、この場合、「東京→大阪」→「大阪→岡山」の乗継ルート及び「東京→神戸」→「神戸→岡山」の乗継ルートが、利用可能ルートとして抽出される。また、各路線のルート検索を終了する。
【0026】
次に、制御部１０１（抽出部１２）は、第２路線の終わりの地域を始まりの地域とする路線（第３路線）を抽出する。つまり、先行路線である「大阪→広島」路線の後行路線（第３路線）を抽出する。
「大阪→広島」路線の場合、終わりの地域は「広島」であるため、「広島」を始まりの地域とする路線を出する。これにより、「広島→岡山」路線が抽出されたものとする。
「広島→岡山」路線は、路線の終わりの地域が目的地と同じであるため、第２ルールに基づき、利用可能ルート（の一部）として抽出される。
つまり、この場合、抽出手段１２は、「東京→大阪」→「大阪→広島」→「広島→岡山」の乗継ルートを利用可能ルートとして抽出する。また、ルート検索を終了する。
このようにルート検索では、第１路線→第２路線→第３路線→・・・という順序で、第１及び第２ルートを適用しながら、検索対象の路線がなくなるまで、段階的に利用可能ルートを抽出する処理を実行する。
まとめると、「東京→岡山」を検索条件としてルート検索を行った結果、「東京→大阪」→「大阪→岡山」（図６のＡ１→Ａ３→Ａ５）、「東京→大阪」→「大阪→広島」→「広島→岡山」（図６のＡ１→Ａ３→Ａ６→Ａ８）、及び、「東京→神戸」→「神戸→岡山」（図６のＢ１→Ｂ３→Ｂ５）の乗継ルート、並びに、「東京→岡山」（図６のＣ１→Ｃ３）の直行ルートが、利用可能ルートとして抽出される。
「大阪→広島」路線の場合、終わりの地域は「広島」であるため、「広島」を始まりの地域とする路線を出する。これにより、「広島→岡山」路線が抽出されたものとする。
「広島→岡山」路線は、路線の終わりの地域が目的地と同じであるため、第２ルールに基づき、利用可能ルート（の一部）として抽出される。
つまり、この場合、抽出手段１２は、「東京→大阪」→「大阪→広島」→「広島→岡山」の乗継ルートを利用可能ルートとして抽出する。また、ルート検索を終了する。
このようにルート検索では、第１路線→第２路線→第３路線→・・・という順序で、第１及び第２ルートを適用しながら、検索対象の路線がなくなるまで、段階的に利用可能ルートを抽出する処理を実行する。
まとめると、「東京→岡山」を検索条件としてルート検索を行った結果、「東京→大阪」→「大阪→岡山」（図６のＡ１→Ａ３→Ａ５）、「東京→大阪」→「大阪→広島」→「広島→岡山」（図６のＡ１→Ａ３→Ａ６→Ａ８）、及び、「東京→神戸」→「神戸→岡山」（図６のＢ１→Ｂ３→Ｂ５）の乗継ルート、並びに、「東京→岡山」（図６のＣ１→Ｃ３）の直行ルートが、利用可能ルートとして抽出される。
【0027】
ところで、前述の第１ルール及び第２ルールに従いつつ、第１路線の終わり地域と第２路線の始まり地域が同じとなる路線の組合せをグルーピングしても、当該組合せは多数存在するため、単にコンピュータ処理により利用可能ルートを抽出しても無用な利用可能ルートが多数抽出されかねない問題がある。
この問題に対しては、乗継数を特定数に制限することで対処することができる。
すなわち、抽出手段１２は、乗継数が特定数以下の乗継ルートを利用可能ルートとして抽出し、乗継数が特定数を超過する乗継ルートは利用可能ルートとして抽出しないようにしている。
そうすると、仮に、「特定数＝２」に設定した場合、上述した「東京→大阪」→「大阪→広島」→「広島→岡山」（図６のＡ１→Ａ３→Ａ６→Ａ８）のルートは乗継数が「３」であるため、利用可能ルートとして抽出されなくなる。
この問題に対しては、乗継数を特定数に制限することで対処することができる。
すなわち、抽出手段１２は、乗継数が特定数以下の乗継ルートを利用可能ルートとして抽出し、乗継数が特定数を超過する乗継ルートは利用可能ルートとして抽出しないようにしている。
そうすると、仮に、「特定数＝２」に設定した場合、上述した「東京→大阪」→「大阪→広島」→「広島→岡山」（図６のＡ１→Ａ３→Ａ６→Ａ８）のルートは乗継数が「３」であるため、利用可能ルートとして抽出されなくなる。
【0028】
なお、乗継数の制限に限らず、他の方法によっても利用可能ルートを限定することにもできる。
例えば、グルーピング情報を手動で設定する。一例として、バス事業者、旅行業者、利用者の観点から、乗継ぎの需要が想定される路線の組合せ（グルーピング）を人為的に検出し、当該グルーピング情報を記憶手段１１に記憶させる。
例えば、過去の利用履歴から「広島～岡山」間の移動に高速バスを利用する利用者が多い場合や、事前のインタビューやアンケートの調査により「広島」の人気が高い場合で、且つ、「岡山」を発着地とする場合には、「岡山」から１バスストップ（近くの地域）の「広島」を乗継地に設定する。
これにより、前述のように、「東京→大阪」→「大阪→広島」→「広島→岡山」（図６のＡ１→Ａ３→Ａ６→Ａ８）のルートが乗継数の制限によって抽出されない場合でも、例外的に当該ルートを利用可能ルートとして抽出することができる。
例えば、グルーピング情報を手動で設定する。一例として、バス事業者、旅行業者、利用者の観点から、乗継ぎの需要が想定される路線の組合せ（グルーピング）を人為的に検出し、当該グルーピング情報を記憶手段１１に記憶させる。
例えば、過去の利用履歴から「広島～岡山」間の移動に高速バスを利用する利用者が多い場合や、事前のインタビューやアンケートの調査により「広島」の人気が高い場合で、且つ、「岡山」を発着地とする場合には、「岡山」から１バスストップ（近くの地域）の「広島」を乗継地に設定する。
これにより、前述のように、「東京→大阪」→「大阪→広島」→「広島→岡山」（図６のＡ１→Ａ３→Ａ６→Ａ８）のルートが乗継数の制限によって抽出されない場合でも、例外的に当該ルートを利用可能ルートとして抽出することができる。
【0029】
前述の「東京→大阪」→「大阪→広島」→「広島→岡山」（図６のＡ１→Ａ３→Ａ６→Ａ８）のルートは、大阪から一旦岡山（目的地）を通り過ぎ、広島に到着した後、当該広島で別の高速バスに乗り継いで岡山（目的地）に向かうという、行き戻りの乗継ルート（以下、特別乗継ルートと称する）である。
図７は、特別乗継ルートの説明図である。
同図に示すように、特別乗継ルートは、言い換えると、出発地（東京）から乗継地（広島）までの距離が、出発地（東京）から目的地（岡山）までの距離よりも離れた乗継ルートである。
さらに言い換えると、特別乗継ルートは、先行ルート「大阪→広島」と後行ルート「広島→岡山」とにおいて「広島～岡山」区間（一部区間）において重複した乗継ルートでもある。
このような特別乗継ルートは、一見すると無用に感じられる。
図７は、特別乗継ルートの説明図である。
同図に示すように、特別乗継ルートは、言い換えると、出発地（東京）から乗継地（広島）までの距離が、出発地（東京）から目的地（岡山）までの距離よりも離れた乗継ルートである。
さらに言い換えると、特別乗継ルートは、先行ルート「大阪→広島」と後行ルート「広島→岡山」とにおいて「広島～岡山」区間（一部区間）において重複した乗継ルートでもある。
このような特別乗継ルートは、一見すると無用に感じられる。
【0030】
しかしながら、例えば、広島に実家がある東京在住の利用者は、ビジネス目的で岡山に行く必要がある場合でも、一旦、広島に帰省した後に、岡山に出張することが可能になる。
乗継ぎまでの時間を調整したり、乗継ぎを翌日に設定することも可能なので、利用者は、乗継地での滞在時間をより有効に活用することができる。
このようなサービスは、高速バスを含め、従来の交通サービスでは提供されておらず、仮に実現可能だとしても潜在していた。
このため、従来の利用者は、せっかく実家の近くまで来たのに帰省できないもどかしさを何かしら感じていたが、規定の観念や常識によって帰省を断念していたと思われる。
本実施形態の高速バスシステムによれば、目的地に到着する前に目的地よりも遠い地域に移動可能な乗継ルートを提供する新たなサービスを実現できるので、従来の交通サービスにおいて潜在する課題を解決することができる。
乗継ぎまでの時間を調整したり、乗継ぎを翌日に設定することも可能なので、利用者は、乗継地での滞在時間をより有効に活用することができる。
このようなサービスは、高速バスを含め、従来の交通サービスでは提供されておらず、仮に実現可能だとしても潜在していた。
このため、従来の利用者は、せっかく実家の近くまで来たのに帰省できないもどかしさを何かしら感じていたが、規定の観念や常識によって帰省を断念していたと思われる。
本実施形態の高速バスシステムによれば、目的地に到着する前に目的地よりも遠い地域に移動可能な乗継ルートを提供する新たなサービスを実現できるので、従来の交通サービスにおいて潜在する課題を解決することができる。
【0031】
停留所名に絞った検索条件に基づくルート検索について説明する。
停留所に基づくルート検索は、上述の地域に基づくルート検索とほぼ共通する。
このため、地域に基づくルート検索と共通する部分の説明は省略し、以下、停留所に基づくルート検索が理解できる程度に説明をとどめる。
停留所に基づくルート検索は、上述の地域に基づくルート検索とほぼ共通する。
このため、地域に基づくルート検索と共通する部分の説明は省略し、以下、停留所に基づくルート検索が理解できる程度に説明をとどめる。
【0032】
停留所に基づくルート検索は、利用者端末２の操作において、出発地及び目的地を停留所で指定する。
例えば、「東京」には「東京駅」という停留所があり、岡山には「岡山インター」と「岡山駅」という停留所があり、且つ、「東京駅→岡山インター」及び「東京駅→岡山駅」という路線がある場合、出発地として「東京駅」を指定し、目的地として「岡山インター」や「岡山駅」を指定することができる。
例えば、「東京」には「東京駅」という停留所があり、岡山には「岡山インター」と「岡山駅」という停留所があり、且つ、「東京駅→岡山インター」及び「東京駅→岡山駅」という路線がある場合、出発地として「東京駅」を指定し、目的地として「岡山インター」や「岡山駅」を指定することができる。
【0033】
このような理由から、路線情報において、各停留所名と地域名とは相互に紐づけて記憶されている。
例えば、「大阪」には「ＯＣＡＴ」や「梅田タワー」という停留所が存在するため、路線情報において、「大阪」（地域名）と「ＯＣＡＴ」や「梅田タワー」（停留所名）とは紐づけて記憶されている。
同様に、「岡山」には「岡山駅」や「岡山インター」という停留所が存在するため、路線情報において、「岡山」（地域名）と「岡山インター」（停留所名）「岡山」とは紐づけて記憶されている。
同様に、「神戸」には「神戸三宮」や「神戸駅」という停留所が存在するため、路線情報において、「神戸」（地域名）と「神戸三宮」や「神戸駅」（停留所名）とは紐づけて記憶されている。
「東京」には「東京駅」という停留所しか存在せず、「広島」には「広島駅」という停留所しか存在しないものとする。このため、「東京」（地域名）と「東京駅」（停留所名）、及び、「広島」（地域名）と「広島駅」（停留所名）は、それぞれ紐づけて記憶されている。
例えば、「大阪」には「ＯＣＡＴ」や「梅田タワー」という停留所が存在するため、路線情報において、「大阪」（地域名）と「ＯＣＡＴ」や「梅田タワー」（停留所名）とは紐づけて記憶されている。
同様に、「岡山」には「岡山駅」や「岡山インター」という停留所が存在するため、路線情報において、「岡山」（地域名）と「岡山インター」（停留所名）「岡山」とは紐づけて記憶されている。
同様に、「神戸」には「神戸三宮」や「神戸駅」という停留所が存在するため、路線情報において、「神戸」（地域名）と「神戸三宮」や「神戸駅」（停留所名）とは紐づけて記憶されている。
「東京」には「東京駅」という停留所しか存在せず、「広島」には「広島駅」という停留所しか存在しないものとする。このため、「東京」（地域名）と「東京駅」（停留所名）、及び、「広島」（地域名）と「広島駅」（停留所名）は、それぞれ紐づけて記憶されている。
【0034】
また、路線情報において、「東京→大阪」（地域名）に対応する停留所ベースの路線として「東京駅→梅田タワー」と「東京駅→ＯＣＡＴ」が存在するものとする。
同様に、「大阪→岡山」（地域名）に対応する停留所ベースの路線として「ＯＣＡＴ→岡山駅」と「ＯＣＡＴ→岡山インター」（停留所名）が存在するものとする。
同様に、「大阪→広島」（地域名）に対応する停留所ベースの路線として「ＯＣＡＴ→広島駅」（停留所名）が存在するものとする。
同様に、「東京→神戸」（地域名）に対応する停留所ベースの路線として「東京駅→神戸三宮」と「東京駅→神戸駅」（停留所名）が存在するものとする。
同様に、「神戸→岡山」（地域名）に対応する停留所ベースの路線として「神戸駅→岡山インター」と「神戸駅→岡山駅」（停留所名）が存在するものとする。
同様に、「東京→岡山」（地域名）に対応する停留所ベースの路線として「東京駅→岡山インター」と「東京駅→岡山駅」（停留所名）が存在するものとする。
同様に、「大阪→岡山」（地域名）に対応する停留所ベースの路線として「ＯＣＡＴ→岡山駅」と「ＯＣＡＴ→岡山インター」（停留所名）が存在するものとする。
同様に、「大阪→広島」（地域名）に対応する停留所ベースの路線として「ＯＣＡＴ→広島駅」（停留所名）が存在するものとする。
同様に、「東京→神戸」（地域名）に対応する停留所ベースの路線として「東京駅→神戸三宮」と「東京駅→神戸駅」（停留所名）が存在するものとする。
同様に、「神戸→岡山」（地域名）に対応する停留所ベースの路線として「神戸駅→岡山インター」と「神戸駅→岡山駅」（停留所名）が存在するものとする。
同様に、「東京→岡山」（地域名）に対応する停留所ベースの路線として「東京駅→岡山インター」と「東京駅→岡山駅」（停留所名）が存在するものとする。
【0035】
このような前提のもと、「東京駅→岡山駅」の検索条件でルート検索が実行された場合、上述した地域名に基づくルート検索と同様の処理を実行する。
なお、「第１ルール」は、「抽出された路線の終わりの停留所と同じである場合にその路線は除外するルール」と読み替えて適用する。
また、「第２ルール」は、「抽出された路線の終わりの停留所が目的地と同じ場合にその路線を利用可能ルートとして抽出し、その時点で、ルート検索を終了するルール」と読み替えて適用する。
この結果、「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→岡山駅」（図６のＡ１→Ａ３→Ａ５）、「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→広島駅」→「広島駅→岡山駅」（図６のＡ１→Ａ３→Ａ６→Ａ８）、及び、「東京駅→神戸駅」→「神戸駅→岡山駅」（図６のＢ１→Ｂ３→Ｂ５）の乗継ルート、並びに、「東京駅→岡山駅」（図６のＣ１→Ｃ３）の直行ルートが、利用可能ルートとして抽出される。
なお、「第１ルール」は、「抽出された路線の終わりの停留所と同じである場合にその路線は除外するルール」と読み替えて適用する。
また、「第２ルール」は、「抽出された路線の終わりの停留所が目的地と同じ場合にその路線を利用可能ルートとして抽出し、その時点で、ルート検索を終了するルール」と読み替えて適用する。
この結果、「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→岡山駅」（図６のＡ１→Ａ３→Ａ５）、「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→広島駅」→「広島駅→岡山駅」（図６のＡ１→Ａ３→Ａ６→Ａ８）、及び、「東京駅→神戸駅」→「神戸駅→岡山駅」（図６のＢ１→Ｂ３→Ｂ５）の乗継ルート、並びに、「東京駅→岡山駅」（図６のＣ１→Ｃ３）の直行ルートが、利用可能ルートとして抽出される。
【0036】
表示制御手段１３は、サーバ１が出力した情報を利用者端末２に表示させる機能である。
具体的には、利用者端末２に備えられているＷｅｂブラウザにより、サーバ１が送信した情報を表示部２０５（Ｗｅｂブラウザ上）に表示させることができる。
表示制御手段１３は、例えば、抽出手段１２が抽出した利用可能ルートの情報を利用者端末２に表示させることができる。
この場合、サーバ１（通信部１０４）が、抽出された利用可能ルートの情報を利用者端末２に送信する。
利用者端末２は、サーバ１から送信された利用可能ルートの情報を表示部２０５に表示する（図１０参照）。
具体的には、利用者端末２に備えられているＷｅｂブラウザにより、サーバ１が送信した情報を表示部２０５（Ｗｅｂブラウザ上）に表示させることができる。
表示制御手段１３は、例えば、抽出手段１２が抽出した利用可能ルートの情報を利用者端末２に表示させることができる。
この場合、サーバ１（通信部１０４）が、抽出された利用可能ルートの情報を利用者端末２に送信する。
利用者端末２は、サーバ１から送信された利用可能ルートの情報を表示部２０５に表示する（図１０参照）。
【0037】
予約手段１４は、利用者端末２の操作に応じて、利用可能ルートの予約処理を実行する。
予約手段１４は、利用者端末２の操作に応じて、乗継ルートを構成する複数の路線の予約処理を一括で実行することができる。
この「一括の予約処理」は、複数の路線の予約処理をそれぞれ管轄する複数の予約サーバ３との連携により実行する。
具体的には、サーバ１は、従来から「東京駅→ＯＣＡＴ」路線の予約処理を担っている予約サーバ３Ａと、従来から「ＯＣＡＴ→岡山駅」路線の予約処理を担っている予約サーバ３Ｂと連携しているので、「東京駅→ＯＣＡＴ」路線の予約処理については予約サーバ３Ａに対し予約依頼情報を送信し、「ＯＣＡＴ→岡山駅」路線の予約処理については予約サーバ３Ｂに対し予約依頼情報を送信する。
予約サーバ３Ａは、「東京駅→ＯＣＡＴ」路線の予約依頼情報を受信すると当該「東京駅→ＯＣＡＴ」路線の予約処理を実行し、予約サーバ３Ｂは、「ＯＣＡＴ→岡山駅」路線の予約依頼情報を受信すると当該「ＯＣＡＴ→岡山駅」路線の予約処理を実行する。
つまり、サーバ１は、対象となる路線の予約処理を担う予約サーバ３に予約依頼情報を送信して予約処理を依頼すれば、予約サーバ３において予約処理が実行される。
直行ルートの路線の予約処理も当然に実行できる。
この場合、サーバ１は、直行ルートの路線の予約処理を担う予約サーバ３に対し予約依頼情報を送信して予約処理を依頼すればよい。
予約手段１４は、利用者端末２の操作に応じて、乗継ルートを構成する複数の路線の予約処理を一括で実行することができる。
この「一括の予約処理」は、複数の路線の予約処理をそれぞれ管轄する複数の予約サーバ３との連携により実行する。
具体的には、サーバ１は、従来から「東京駅→ＯＣＡＴ」路線の予約処理を担っている予約サーバ３Ａと、従来から「ＯＣＡＴ→岡山駅」路線の予約処理を担っている予約サーバ３Ｂと連携しているので、「東京駅→ＯＣＡＴ」路線の予約処理については予約サーバ３Ａに対し予約依頼情報を送信し、「ＯＣＡＴ→岡山駅」路線の予約処理については予約サーバ３Ｂに対し予約依頼情報を送信する。
予約サーバ３Ａは、「東京駅→ＯＣＡＴ」路線の予約依頼情報を受信すると当該「東京駅→ＯＣＡＴ」路線の予約処理を実行し、予約サーバ３Ｂは、「ＯＣＡＴ→岡山駅」路線の予約依頼情報を受信すると当該「ＯＣＡＴ→岡山駅」路線の予約処理を実行する。
つまり、サーバ１は、対象となる路線の予約処理を担う予約サーバ３に予約依頼情報を送信して予約処理を依頼すれば、予約サーバ３において予約処理が実行される。
直行ルートの路線の予約処理も当然に実行できる。
この場合、サーバ１は、直行ルートの路線の予約処理を担う予約サーバ３に対し予約依頼情報を送信して予約処理を依頼すればよい。
【0038】
決済手段１５は、利用者端末２の操作に応じて、決済処理を実行する。
決済手段１５は、利用者端末２の操作に応じて、予約された複数の路線に関する決済処理を一括で実行することができる。
この「一括の決済処理」は、サーバ１と決済サーバ４とが連携することで実現している。
これは、決済サーバ４が、例えば、クレジット会社が管理・運営する決済処理装置だからである。
このため、サーバ１は、決済に必要な情報（利用者の氏名、金額、カード番号、有効期限、セキュリティコード等）を利用者端末２から受信して、当該情報を含む決済依頼情報を決済サーバ４に送信して決済処理を依頼すれば、決済サーバ４において決済処理が実行される。
なお、本実施形態の高速バスシステムは、１台の決済サーバ４を備えているが、クレジット会社毎に決済システムが存在する場合は、各決済システムが備える各決済サーバ４との連携が必要になる。
例えば、高速バスＡや第１路線の料金（第１料金）に対する決済（支払い）はクレジットカードＡしか使えずその決済処理は決済サーバ４Ａが実行可能であり、高速バスＢや第２路線の料金（第２料金）に対する決済（支払い）はクレジットカードＢしか使えずその決済処理は決済サーバ４Ｂが実行可能である場合、サーバ１は、第１料金の決済処理については決済サーバ４Ａに決済依頼情報を送信し、第２料金の決済処理については決済サーバ４Ｂに決済依頼情報を送信することになる。
決済手段１５は、利用者端末２の操作に応じて、予約された複数の路線に関する決済処理を一括で実行することができる。
この「一括の決済処理」は、サーバ１と決済サーバ４とが連携することで実現している。
これは、決済サーバ４が、例えば、クレジット会社が管理・運営する決済処理装置だからである。
このため、サーバ１は、決済に必要な情報（利用者の氏名、金額、カード番号、有効期限、セキュリティコード等）を利用者端末２から受信して、当該情報を含む決済依頼情報を決済サーバ４に送信して決済処理を依頼すれば、決済サーバ４において決済処理が実行される。
なお、本実施形態の高速バスシステムは、１台の決済サーバ４を備えているが、クレジット会社毎に決済システムが存在する場合は、各決済システムが備える各決済サーバ４との連携が必要になる。
例えば、高速バスＡや第１路線の料金（第１料金）に対する決済（支払い）はクレジットカードＡしか使えずその決済処理は決済サーバ４Ａが実行可能であり、高速バスＢや第２路線の料金（第２料金）に対する決済（支払い）はクレジットカードＢしか使えずその決済処理は決済サーバ４Ｂが実行可能である場合、サーバ１は、第１料金の決済処理については決済サーバ４Ａに決済依頼情報を送信し、第２料金の決済処理については決済サーバ４Ｂに決済依頼情報を送信することになる。
【0039】
予約変更手段１６は、利用者端末２の操作に応じて、予約変更の処理を実行する。
予約変更手段１６は、利用者端末２の操作に応じて、予約された複数の路線に関する予約変更処理を一括で実行することができる。
予約取消手段１７は、利用者端末２の操作に応じて、予約の取消処理を実行することができる。
予約取消手段１７は、利用者端末２の操作に応じて、予約された複数の路線に関する取消処理を一括で実行することができる。
予約変更手段１６及び予約取消手段１７の詳細については後述する（図１７，図１８）。
予約変更手段１６は、利用者端末２の操作に応じて、予約された複数の路線に関する予約変更処理を一括で実行することができる。
予約取消手段１７は、利用者端末２の操作に応じて、予約の取消処理を実行することができる。
予約取消手段１７は、利用者端末２の操作に応じて、予約された複数の路線に関する取消処理を一括で実行することができる。
予約変更手段１６及び予約取消手段１７の詳細については後述する（図１７，図１８）。
【0040】
特典付与手段１８は、乗継ルートの利用者に対し料金の割引きやポイント付与などの特典を付与する。
特に、特典付与手段１８は、乗継ルートの利用に際し、乗継数が第１数である乗継ルートの利用者に対するよりも、乗継数が第１数より多い第２数である乗継ルートの利用者に対する方が、多くの特典を付与するようにできる。
具体的には、乗継数１回の割引率はＸ％、乗継数２回の割引率はＹ％（≧Ｘ％）、乗継数３回の割引率はＺ％（≧Ｙ％）に設定するなど、乗継数が多いほど割引率を多く設定してもよい。
割引額は、予約時の状況に応じて変動（例えば、閑散期は繁忙期に比べ割引率を多くしたり、空席が多い場合に割引率を多くするなど）してもよい。
特別乗継ルートには、通常の乗継ルートよりも割引率を多くすることもできる。この場合、先行ルートと後行ルートとの重複距離が長いほど割引率を多くしてもよい。
このほか、路線の距離、利用時期、過去の乗継ぎを含めた乗継累計数などの他の要素を組合せて割引額を設定することもできる。管理者が任意の割引額や割引率を設定することもできる。
これにより、乗継ルートを安価に利用し易くでき、利用者の増加等を通して高速バスの利用価値を高めることができる。
特に、特典付与手段１８は、乗継ルートの利用に際し、乗継数が第１数である乗継ルートの利用者に対するよりも、乗継数が第１数より多い第２数である乗継ルートの利用者に対する方が、多くの特典を付与するようにできる。
具体的には、乗継数１回の割引率はＸ％、乗継数２回の割引率はＹ％（≧Ｘ％）、乗継数３回の割引率はＺ％（≧Ｙ％）に設定するなど、乗継数が多いほど割引率を多く設定してもよい。
割引額は、予約時の状況に応じて変動（例えば、閑散期は繁忙期に比べ割引率を多くしたり、空席が多い場合に割引率を多くするなど）してもよい。
特別乗継ルートには、通常の乗継ルートよりも割引率を多くすることもできる。この場合、先行ルートと後行ルートとの重複距離が長いほど割引率を多くしてもよい。
このほか、路線の距離、利用時期、過去の乗継ぎを含めた乗継累計数などの他の要素を組合せて割引額を設定することもできる。管理者が任意の割引額や割引率を設定することもできる。
これにより、乗継ルートを安価に利用し易くでき、利用者の増加等を通して高速バスの利用価値を高めることができる。
【0041】
予約サーバ３の機能については、公知の高速バスの予約システムを活用するため、詳細な説明を省略する。
決済サーバ４の機能については、クレジットカード決済など、公知の決済システムを活用するため、詳細な説明を省略する。
決済サーバ４の機能については、クレジットカード決済など、公知の決済システムを活用するため、詳細な説明を省略する。
【0042】
（処理手順）
高速バスシステムにおける具体的な処理手順（高速バス処理方法）について説明する。
具体的には、「ルート検索」、「予約及び決済」、「予約変更」、及び、「予約取消」について順に説明する。
高速バスシステムにおける具体的な処理手順（高速バス処理方法）について説明する。
具体的には、「ルート検索」、「予約及び決済」、「予約変更」、及び、「予約取消」について順に説明する。
【0043】
（ルート検索）
ルート検索の処理手順について説明する。
図８は、ルート検索の処理手順を示すシーケンスチャートである。
同図に示すように、ルート検索の処理では、まず、検索条件情報の入力を実行する（Ｓ１０１）。
検索条件情報の入力は、利用者が利用者端末２を操作することで実行される。
図９は、利用者端末２（表示部２０５）に表示されるルート検索画面の一例を示す図である。
ルート検索画面は、サーバ１により管理されるＷｅｂ画面であり、利用者端末２のＷｅｂブラウザで所定のＵＲＬ（Uniform Resource Locator）を入力することで表示させることができる。
ルート検索画面では、ルート検索に必要な検索条件の情報を入力する。
例えば、検索条件として、出発地、目的地及び出発日を入力する（図９のｄ１～ｄ３）。
出発地及び目的地は、例えばプルダウン表示させることにより、選択操作により地域名を入力したり、地域を選択するとその地域に存在する停留所名を選択操作により入力するようにできる（図９のｄ１，ｄ２）。
出発地及び目的地は、地図上に表示される停留所のマーク（図９のｄ５）を選択操作（クリック操作やタップ操作）することで入力することもできる（図９のｄ４）。
出発日は、アイコンにリンクされたカレンダーを介して入力したり、出発日欄に直接入力することもできる（図９のｄ３）。
本処理手順では、出発地「東京駅」、目的地「岡山駅」、出発日「２０２４年２月１日」が検索条件として入力されたものとする（図９）。
なお、出発日は、この段階で入力しなくてもよく、例えば予約直前に入力しても良い。
また、検索条件として他の情報（例えば、出発時刻、到着日、到着時刻、経由地、乗継ぎあり／なし、人数など）を入力してもよい。
利用者端末２（通信部２０６）は、入力された検索条件情報（出発地、目的地及び出発日）をサーバ１に送信する。
ルート検索の処理手順について説明する。
図８は、ルート検索の処理手順を示すシーケンスチャートである。
同図に示すように、ルート検索の処理では、まず、検索条件情報の入力を実行する（Ｓ１０１）。
検索条件情報の入力は、利用者が利用者端末２を操作することで実行される。
図９は、利用者端末２（表示部２０５）に表示されるルート検索画面の一例を示す図である。
ルート検索画面は、サーバ１により管理されるＷｅｂ画面であり、利用者端末２のＷｅｂブラウザで所定のＵＲＬ（Uniform Resource Locator）を入力することで表示させることができる。
ルート検索画面では、ルート検索に必要な検索条件の情報を入力する。
例えば、検索条件として、出発地、目的地及び出発日を入力する（図９のｄ１～ｄ３）。
出発地及び目的地は、例えばプルダウン表示させることにより、選択操作により地域名を入力したり、地域を選択するとその地域に存在する停留所名を選択操作により入力するようにできる（図９のｄ１，ｄ２）。
出発地及び目的地は、地図上に表示される停留所のマーク（図９のｄ５）を選択操作（クリック操作やタップ操作）することで入力することもできる（図９のｄ４）。
出発日は、アイコンにリンクされたカレンダーを介して入力したり、出発日欄に直接入力することもできる（図９のｄ３）。
本処理手順では、出発地「東京駅」、目的地「岡山駅」、出発日「２０２４年２月１日」が検索条件として入力されたものとする（図９）。
なお、出発日は、この段階で入力しなくてもよく、例えば予約直前に入力しても良い。
また、検索条件として他の情報（例えば、出発時刻、到着日、到着時刻、経由地、乗継ぎあり／なし、人数など）を入力してもよい。
利用者端末２（通信部２０６）は、入力された検索条件情報（出発地、目的地及び出発日）をサーバ１に送信する。
【0044】
サーバ１（抽出手段１２）は、利用者端末２から送信された検索条件情報を受信すると、ルート検索を実行する（Ｓ１０２）。
本例において、ルート検索は、出発地「東京駅」、目的地「岡山駅」に基づいて、抽出手段１２が利用可能ルートを抽出する。「出発日」は予約時に必要な情報なのでサーバ１で保持しておく。
ルート検索の結果、（１）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→岡山駅」、（２）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→広島駅」→「広島駅→岡山駅」、（３）「東京駅→神戸駅」→「神戸駅→岡山駅」、（４）「東京駅→岡山駅」の４つの利用可能ルートが検出（抽出）される。（１）～（３）は乗継ルートで、（４）は直行ルートである。
ルート検索の説明は既述したので省略する。
サーバ１は、ルート検索の検索結果情報を利用者端末２に送信する（Ｓ１０３）。
具体的には、上述の（１）～（４）の利用可能ルートの情報を送信する。
本例において、ルート検索は、出発地「東京駅」、目的地「岡山駅」に基づいて、抽出手段１２が利用可能ルートを抽出する。「出発日」は予約時に必要な情報なのでサーバ１で保持しておく。
ルート検索の結果、（１）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→岡山駅」、（２）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→広島駅」→「広島駅→岡山駅」、（３）「東京駅→神戸駅」→「神戸駅→岡山駅」、（４）「東京駅→岡山駅」の４つの利用可能ルートが検出（抽出）される。（１）～（３）は乗継ルートで、（４）は直行ルートである。
ルート検索の説明は既述したので省略する。
サーバ１は、ルート検索の検索結果情報を利用者端末２に送信する（Ｓ１０３）。
具体的には、上述の（１）～（４）の利用可能ルートの情報を送信する。
【0045】
利用者端末２は、サーバ１から送信された検索結果情報を受信すると、検索結果を表示部２０５に表示する（Ｓ１０４）。
図１０は、利用者端末２の表示部２０５に表示される検索結果画面の一例を示す図である。
同図に示すように、検索結果画面には、上述の（１）～（４）の利用可能ルートの情報が表示される（ｄ１１）。
すなわち、（１）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→岡山駅」、（２）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→広島駅」→「広島駅→岡山駅」、（３）「東京駅→神戸駅」→「神戸駅→岡山駅」、（４）「東京駅→岡山駅」の４つの利用可能ルートが選択可能に表示される。
図１０は、利用者端末２の表示部２０５に表示される検索結果画面の一例を示す図である。
同図に示すように、検索結果画面には、上述の（１）～（４）の利用可能ルートの情報が表示される（ｄ１１）。
すなわち、（１）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→岡山駅」、（２）「東京駅→ＯＣＡＴ」→「ＯＣＡＴ→広島駅」→「広島駅→岡山駅」、（３）「東京駅→神戸駅」→「神戸駅→岡山駅」、（４）「東京駅→岡山駅」の４つの利用可能ルートが選択可能に表示される。
【0046】
次に、ルートの選択を実行する（Ｓ１０５）。
具体的には、利用者端末２において、検索結果画面（図１０）において表示されている（１）～（４）のルートの中から利用者が望むルートを選択操作する。
本処理手順では、（１）「東京駅→ＯＣＡＴ」（第１路線）→「ＯＣＡＴ→岡山駅」（第２路線）の乗継ルートが選択されたものとする。
利用者端末２は、選択されたルートの情報をサーバ１に送信する。
具体的には、利用者端末２において、検索結果画面（図１０）において表示されている（１）～（４）のルートの中から利用者が望むルートを選択操作する。
本処理手順では、（１）「東京駅→ＯＣＡＴ」（第１路線）→「ＯＣＡＴ→岡山駅」（第２路線）の乗継ルートが選択されたものとする。
利用者端末２は、選択されたルートの情報をサーバ１に送信する。
【0047】
続いて、サーバ１は、利用者端末２から送信された乗継ルートの情報を受信すると、便確認情報を各予約サーバ３に送信する（Ｓ１０６）。
具体的には、第１路線情報及び出発日を含む便確認情報を予約サーバ３Ａに送信し、第２路線情報及び出発日を含む便確認情報を予約サーバ３Ｂに送信する。
これは、第１路線「東京駅→ＯＣＡＴ」は、従来から予約サーバ３Ａが便管理を担っており、第２路線「ＯＣＡＴ→岡山駅」は、従来から予約サーバ３Ｂが便管理を担っているからである。
つまり、サーバ１では便管理は実行していないため、便管理をしている予約サーバ３に便確認を依頼する。
便確認情報に含ませる「出発日」は、Ｓ１０１において受信しサーバ１において保持させていた出発日である。なお、この「出発日」は、Ｓ１０１において受信した情報に限らず、例えば、Ｓ１０５のルート選択時に利用者端末２側で入力・送信させた出発日でもよい。
なお、第２路線の出発時刻は、第１路線の到着時刻より後で、且つ、当該到着時刻から所定時間内の時刻であることが好ましい。
このため、サーバ１は、予約サーバ３Ａから第１路線の便情報を受信した後、当該便情報に含まれる第１路線の到着時刻を便確認情報に含ませて予約サーバ３Ｂに送信する（図示省略）。
このほか、第１路線の到着時刻と第２路線の出発時刻を加味したグルーピングを設定しておいてもよい。
具体的には、第１路線情報及び出発日を含む便確認情報を予約サーバ３Ａに送信し、第２路線情報及び出発日を含む便確認情報を予約サーバ３Ｂに送信する。
これは、第１路線「東京駅→ＯＣＡＴ」は、従来から予約サーバ３Ａが便管理を担っており、第２路線「ＯＣＡＴ→岡山駅」は、従来から予約サーバ３Ｂが便管理を担っているからである。
つまり、サーバ１では便管理は実行していないため、便管理をしている予約サーバ３に便確認を依頼する。
便確認情報に含ませる「出発日」は、Ｓ１０１において受信しサーバ１において保持させていた出発日である。なお、この「出発日」は、Ｓ１０１において受信した情報に限らず、例えば、Ｓ１０５のルート選択時に利用者端末２側で入力・送信させた出発日でもよい。
なお、第２路線の出発時刻は、第１路線の到着時刻より後で、且つ、当該到着時刻から所定時間内の時刻であることが好ましい。
このため、サーバ１は、予約サーバ３Ａから第１路線の便情報を受信した後、当該便情報に含まれる第１路線の到着時刻を便確認情報に含ませて予約サーバ３Ｂに送信する（図示省略）。
このほか、第１路線の到着時刻と第２路線の出発時刻を加味したグルーピングを設定しておいてもよい。
【0048】
各予約サーバ３は、サーバ１から便確認情報を受信すると、各路線に関する便情報（利用可能な発着時刻、金額、空席状況）を検索し、サーバ１に送信する。
予約サーバ３Ａは、第１路線に関する便情報を検索し、検索結果としての便情報をサーバ１に送信し（Ｓ１０７）、予約サーバ３Ｂは、第２路線に関する便情報を検索し、検索結果としての便情報をサーバ１に送信する（Ｓ１０８）。
本処理手順では、第１路線の便情報として、「2024/2/1_22:10-06:44_7,800円_残席６」が検索され、第２路線の便情報として「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」が検索されたものとする。
なお、検索結果としての便の数を設定したり制限することもできる。
便情報の検索は、従来の予約システムに備えられている公知の機能であるため、詳細な説明を省略する。
予約サーバ３Ａは、第１路線に関する便情報を検索し、検索結果としての便情報をサーバ１に送信し（Ｓ１０７）、予約サーバ３Ｂは、第２路線に関する便情報を検索し、検索結果としての便情報をサーバ１に送信する（Ｓ１０８）。
本処理手順では、第１路線の便情報として、「2024/2/1_22:10-06:44_7,800円_残席６」が検索され、第２路線の便情報として「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」が検索されたものとする。
なお、検索結果としての便の数を設定したり制限することもできる。
便情報の検索は、従来の予約システムに備えられている公知の機能であるため、詳細な説明を省略する。
【0049】
次に、サーバ１は、全路線に関する便情報を利用者端末２に送信する（Ｓ１０９）。
具体的には、サーバ１が、予約サーバ３Ａ及び３Ｂから受信した第１路線に関する便情報と第２路線に関する便情報を利用者端末２に送信する。
つまり、第１路線の便情報として、「2024/2/1_22:10-06:44_7,800円_残席６」が送信され、第２路線の便情報として「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」が送信される。
具体的には、サーバ１が、予約サーバ３Ａ及び３Ｂから受信した第１路線に関する便情報と第２路線に関する便情報を利用者端末２に送信する。
つまり、第１路線の便情報として、「2024/2/1_22:10-06:44_7,800円_残席６」が送信され、第２路線の便情報として「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」が送信される。
【0050】
利用者端末２は、サーバ１から受信した便情報を表示部２０５に表示する（Ｓ１１０）。
つまり、第１路線の便情報「2024/2/1_22:10-06:44_7,800円_残席６」、及び、第２路線の便情報「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」を表示する。
図１１は、便候補表示・選択画面の一例を示す図である。
同図に示すように、便候補の表示・選択画面には、１便目に関する便候補情報を表示する（ｄ２１）と共に、２便目に関する便候補情報を表示する（ｄ２２）。
具体的には、便候補情報として、１便目_東京→大阪、乗車日_2024年2月1日（月）、区間_東京駅→ＯＣＡＴ、便候補１_22:10→6:44、料金_7,800円、残席_６が表示され（ｄ２１）、２便目_大阪→岡山、乗車日_2024年2月2日（月）、区間_ＯＣＡＴ→岡山駅、便候補１_9:30→12:30、料金_2,900円、残席_２、及び、便候補２_10:30→13:30、料金_3,000円、残席_５が表示される（ｄ２２）。
つまり、第１路線の便情報「2024/2/1_22:10-06:44_7,800円_残席６」、及び、第２路線の便情報「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」を表示する。
図１１は、便候補表示・選択画面の一例を示す図である。
同図に示すように、便候補の表示・選択画面には、１便目に関する便候補情報を表示する（ｄ２１）と共に、２便目に関する便候補情報を表示する（ｄ２２）。
具体的には、便候補情報として、１便目_東京→大阪、乗車日_2024年2月1日（月）、区間_東京駅→ＯＣＡＴ、便候補１_22:10→6:44、料金_7,800円、残席_６が表示され（ｄ２１）、２便目_大阪→岡山、乗車日_2024年2月2日（月）、区間_ＯＣＡＴ→岡山駅、便候補１_9:30→12:30、料金_2,900円、残席_２、及び、便候補２_10:30→13:30、料金_3,000円、残席_５が表示される（ｄ２２）。
【0051】
（予約及び決済）
予約及び決済の処理手順について説明する。
図１２は、予約・決済の処理手順を示すシーケンスチャートである。
同図に示すように、予約の処理では、まず、便の選択を実行する（Ｓ２０１）。
具体的には、便候補表示・選択画面（図１１）に表示されている便候補の中から利用者が希望する便を選択する。
図１１に示すように、便候補表示・選択画面には、便ごとに、便候補を選択可能なチェックボックスが設けられているので、利用者は、希望する便候補のチェックボックスを選択操作することで便を選択できる。
本処理手順では、１便目は「東京駅_22:10」発・「ＯＣＡＴ_6:44」着の便候補１が選択され、２便目は「ＯＣＡＴ_10:30」発・「岡山駅_13:30」着の便候補２が選択されたものとする（図１１）。
利用者端末２は、選択された便情報（乗車便情報）をサーバ１に送信する。
具体的には、乗車便情報として、［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］及び［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］を送信する。
予約及び決済の処理手順について説明する。
図１２は、予約・決済の処理手順を示すシーケンスチャートである。
同図に示すように、予約の処理では、まず、便の選択を実行する（Ｓ２０１）。
具体的には、便候補表示・選択画面（図１１）に表示されている便候補の中から利用者が希望する便を選択する。
図１１に示すように、便候補表示・選択画面には、便ごとに、便候補を選択可能なチェックボックスが設けられているので、利用者は、希望する便候補のチェックボックスを選択操作することで便を選択できる。
本処理手順では、１便目は「東京駅_22:10」発・「ＯＣＡＴ_6:44」着の便候補１が選択され、２便目は「ＯＣＡＴ_10:30」発・「岡山駅_13:30」着の便候補２が選択されたものとする（図１１）。
利用者端末２は、選択された便情報（乗車便情報）をサーバ１に送信する。
具体的には、乗車便情報として、［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］及び［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］を送信する。
【0052】
サーバ１は、利用者端末２から乗車便情報を受信すると、割引額を計算する（Ｓ２０２）。
乗継ルートは、乗継ぎの特典として特定の割引き（乗継割引）が適用されるからである。
乗継割引は、乗継数が多いほど割引額が多くなるように設定できる。
例えば、乗継数１回の割引率Ｘ％、乗継数２回の割引率Ｙ％（≧Ｘ％）、乗継数３回の割引率Ｚ％（≧Ｙ％）の場合など、乗継数に応じた割引率を料金に掛けて割引額や料金を計算する。
閑散期と繁忙期とで異なる割引率や割引額を適用したり、空席に応じた割引率や割引額を適用することもできる。
特別乗継ルートの利用者には、通常の乗継ルートよりも多い割引率や割引額を適用することもできる。
本処理手順においては、１便目の料金7,800円及び２便目の料金3,000円の合計10,800円の標準料金に対し、割引額200円が適用された結果、差引料金は10,600円と算出されたものとする。
サーバ１は、標準料金、割引額、差引料金などの料金情報を利用者端末２に送信する（Ｓ２０３）。
乗継ルートは、乗継ぎの特典として特定の割引き（乗継割引）が適用されるからである。
乗継割引は、乗継数が多いほど割引額が多くなるように設定できる。
例えば、乗継数１回の割引率Ｘ％、乗継数２回の割引率Ｙ％（≧Ｘ％）、乗継数３回の割引率Ｚ％（≧Ｙ％）の場合など、乗継数に応じた割引率を料金に掛けて割引額や料金を計算する。
閑散期と繁忙期とで異なる割引率や割引額を適用したり、空席に応じた割引率や割引額を適用することもできる。
特別乗継ルートの利用者には、通常の乗継ルートよりも多い割引率や割引額を適用することもできる。
本処理手順においては、１便目の料金7,800円及び２便目の料金3,000円の合計10,800円の標準料金に対し、割引額200円が適用された結果、差引料金は10,600円と算出されたものとする。
サーバ１は、標準料金、割引額、差引料金などの料金情報を利用者端末２に送信する（Ｓ２０３）。
【0053】
利用者端末２は、サーバ１から料金情報を受信すると、表示部２０５に当該料金情報を表示する（Ｓ２０４）。
図１３は、利用者端末２（表示部２０５）において表示される料金情報表示画面の一例である。
同図に示すように、料金情報表示画面では、標準料金、割引額、差引料金を表示させることができる（ｄ３３）。
本処理手順において、標準料金10,800円、割引額200円、差引料金10,600円が表示される。
料金情報表示画面には、１便目の標準料金（7,800円）を表示することもでき（ｄ３１）、２便目の標準料金（3,000円）を表示することもできる（ｄ３２）。
図１３は、利用者端末２（表示部２０５）において表示される料金情報表示画面の一例である。
同図に示すように、料金情報表示画面では、標準料金、割引額、差引料金を表示させることができる（ｄ３３）。
本処理手順において、標準料金10,800円、割引額200円、差引料金10,600円が表示される。
料金情報表示画面には、１便目の標準料金（7,800円）を表示することもでき（ｄ３１）、２便目の標準料金（3,000円）を表示することもできる（ｄ３２）。
【0054】
次に、利用者端末２において、予約の申し込みを行う（Ｓ２０５）。
具体的には、料金情報表示画面に表示される「予約へ進む」ボタンを選択操作することで、予約画面に移行する。
図１４は、予約画面の一例を示す図である。
図１４に示すように、予約画面では、利用者の個人情報（氏名や連絡先等）の入力欄が設けられている（ｄ４１）。
本処理手順では、「氏名：山田太郎」及び「メールアドレス：yamada@bus.com」が入力されたものとする（ログインせずに予約する場合）。
ログインを介して予約の申し込みを行うこともできる。
例えば、予約画面に表示されているＳＮＳログインボタン（ｄ４２）を選択操作することで、ＳＮＳ連携により自動的にログイン→予約申し込みを実行することもできる。
利用者端末２は、予約の申し込みが終了すると、予約情報をサーバ１に送信する。
本処理手順では、個人情報（氏名、連絡先等）及び乗車便情報（［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］、［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］）を送信する。
具体的には、料金情報表示画面に表示される「予約へ進む」ボタンを選択操作することで、予約画面に移行する。
図１４は、予約画面の一例を示す図である。
図１４に示すように、予約画面では、利用者の個人情報（氏名や連絡先等）の入力欄が設けられている（ｄ４１）。
本処理手順では、「氏名：山田太郎」及び「メールアドレス：yamada@bus.com」が入力されたものとする（ログインせずに予約する場合）。
ログインを介して予約の申し込みを行うこともできる。
例えば、予約画面に表示されているＳＮＳログインボタン（ｄ４２）を選択操作することで、ＳＮＳ連携により自動的にログイン→予約申し込みを実行することもできる。
利用者端末２は、予約の申し込みが終了すると、予約情報をサーバ１に送信する。
本処理手順では、個人情報（氏名、連絡先等）及び乗車便情報（［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］、［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］）を送信する。
【0055】
サーバ１は、利用者端末２から送信された予約情報を受信すると、予約依頼情報を予約サーバ３に送信する（Ｓ２０６、Ｓ２０８）。
具体的には、第１路線（「東京駅→ＯＣＡＴ」）に関する予約依頼情報を予約サーバ３Ａに送信し、第２路線（「ＯＣＡＴ→岡山駅」）に関する予約依頼情報を予約サーバ３Ｂに送信する。
これは、第１路線「東京駅→ＯＣＡＴ」は、従来から予約サーバ３Ａが便の予約処理を担っており、第２路線「ＯＣＡＴ→岡山駅」は、従来から予約サーバ３Ｂが便の予約処理を担っているからである。
つまり、サーバ１では予約処理は実行していないため、従来から予約処理を担っている予約サーバ３に予約依頼情報を送信して予約処理を依頼する。
具体的には、第１路線（「東京駅→ＯＣＡＴ」）に関する予約依頼情報を予約サーバ３Ａに送信し、第２路線（「ＯＣＡＴ→岡山駅」）に関する予約依頼情報を予約サーバ３Ｂに送信する。
これは、第１路線「東京駅→ＯＣＡＴ」は、従来から予約サーバ３Ａが便の予約処理を担っており、第２路線「ＯＣＡＴ→岡山駅」は、従来から予約サーバ３Ｂが便の予約処理を担っているからである。
つまり、サーバ１では予約処理は実行していないため、従来から予約処理を担っている予約サーバ３に予約依頼情報を送信して予約処理を依頼する。
【0056】
予約サーバ３Ａは、サーバ１から予約依頼情報を受信すると、第１路線に対する予約処理を実行する（Ｓ２０７）。
予約サーバ３Ａは、予約処理を完了すると、予約結果を示す予約番号をサーバ１に送信する。
予約サーバ３Ｂは、サーバ１から予約依頼情報を受信すると、第２路線に対する予約処理を実行する（Ｓ２０９）。
予約サーバ３Ｂは、予約処理を完了すると、予約結果を示す予約番号をサーバ１に送信する。
これにより、［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］と［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］の乗車便の予約が実行される。
予約サーバ３Ａは、予約処理を完了すると、予約結果を示す予約番号をサーバ１に送信する。
予約サーバ３Ｂは、サーバ１から予約依頼情報を受信すると、第２路線に対する予約処理を実行する（Ｓ２０９）。
予約サーバ３Ｂは、予約処理を完了すると、予約結果を示す予約番号をサーバ１に送信する。
これにより、［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］と［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］の乗車便の予約が実行される。
【0057】
つまり、第１路線の予約処理は、第１事業者により運営されている予約サーバ３Ａ（第１装置）により実行可能であり、第２路線の予約処理は、第１事業者とは異なる第２事業者により運営されている予約サーバ３Ｂ（第２装置）により実行可能であるところ、予約手段１４は、第１路線の予約処理を予約サーバ３Ａ（第１装置）に実行させると共に、第２路線の予約処理を予約サーバ３Ｂ（第２装置）に実行させることで、第１路線と第２路線とから構成される乗継ルートの予約処理を一括で実行可能にしている。
【0058】
サーバ１は、各予約サーバ３から予約結果を受信すると、予約情報と予約管理番号を利用者端末２に送信する（Ｓ２１０）。
予約管理番号は、サーバ１により管理される。
予約管理番号は、例えば、予約サーバ３Ａから受信した予約番号と予約サーバ３Ｂから受信した予約番号とを組み合わせた番号でもよく、新たに採番した番号を予約番号と紐づけて管理してもよい。
予約管理番号は、サーバ１により管理される。
予約管理番号は、例えば、予約サーバ３Ａから受信した予約番号と予約サーバ３Ｂから受信した予約番号とを組み合わせた番号でもよく、新たに採番した番号を予約番号と紐づけて管理してもよい。
【0059】
利用者端末２は、サーバ１から送信された予約結果（予約管理番号）を受信すると、表示部２０５に予約結果（予約管理番号）を表示する（Ｓ２１１）。
図１５は、予約結果画面の一例を示す図である。
同図に示すように、予約結果画面には、予約結果を示す予約管理番号「１２３４５６」が利用者端末２（表示部２０５）に表示される（ｄ５１）。
これにより、利用者は予約が完了したことを把握できる。
図１５は、予約結果画面の一例を示す図である。
同図に示すように、予約結果画面には、予約結果を示す予約管理番号「１２３４５６」が利用者端末２（表示部２０５）に表示される（ｄ５１）。
これにより、利用者は予約が完了したことを把握できる。
【0060】
次に、利用者端末２において決済情報を入力する（Ｓ２１２）。
決済情報は、決済実行画面を介して入力することができる。
図１６は、決済実行画面の一例を示す図である。
決済実行画面は、予約結果画面（図１５）の「決済へ進む」ボタンを選択操作することで表示させることができる。
同図に示すように、決済実行画面は、決済情報として料金の表示（ｄ６１）及びクレジットカード情報（カード番号、有効期限、セキュリティコード）の入力欄（ｄ６２）が設けられている。
なお、決済情報に利用者の氏名を加えることもできる。
利用者は、入力欄に必要な決済情報を入力する。
本処理手順では、「カード番号：1234-5678-9021、有効期限：2026/5/2、セキュリティコード：＊＊＊」が決済情報として入力されたものとする（図１６）。
利用者端末２は、入力された決済情報（料金を含む）をサーバ１に送信する。
決済情報は、決済実行画面を介して入力することができる。
図１６は、決済実行画面の一例を示す図である。
決済実行画面は、予約結果画面（図１５）の「決済へ進む」ボタンを選択操作することで表示させることができる。
同図に示すように、決済実行画面は、決済情報として料金の表示（ｄ６１）及びクレジットカード情報（カード番号、有効期限、セキュリティコード）の入力欄（ｄ６２）が設けられている。
なお、決済情報に利用者の氏名を加えることもできる。
利用者は、入力欄に必要な決済情報を入力する。
本処理手順では、「カード番号：1234-5678-9021、有効期限：2026/5/2、セキュリティコード：＊＊＊」が決済情報として入力されたものとする（図１６）。
利用者端末２は、入力された決済情報（料金を含む）をサーバ１に送信する。
【0061】
サーバ１は、利用者端末２から送信された決済情報を受信すると、決済情報を含む決済依頼情報を決済サーバ４に送信する（Ｓ２１３）。
【0062】
決済サーバ４は、サーバ１から送信された決済依頼情報を受信すると、決済情報に基づいて決済処理を実行する（Ｓ２１４）。
これにより、料金10,600円がクレジット決済される。
すなわち、決済手段１５は、決済処理を予約処理に続けて一連に実行することになる。
決済サーバ４は、決済結果をサーバ１に送信する。
これにより、料金10,600円がクレジット決済される。
すなわち、決済手段１５は、決済処理を予約処理に続けて一連に実行することになる。
決済サーバ４は、決済結果をサーバ１に送信する。
【0063】
サーバ１は、決済サーバ４から送信された決済結果を受信すると、当該決済結果を利用者端末２に送信する（Ｓ２１５）。
利用者端末２は、サーバ１から送信された決済結果を受信すると、当該決済結果を表示部２０５に表示する（Ｓ２１６）。
これにより、利用者は、決済が完了したことを把握できる。
利用者端末２は、サーバ１から送信された決済結果を受信すると、当該決済結果を表示部２０５に表示する（Ｓ２１６）。
これにより、利用者は、決済が完了したことを把握できる。
【0064】
このように、本実施形態の高速バスシステムにおいては、高速バスの予約及び決済を一連且つ一括で実行可能にしている。
【0065】
（予約変更）
予約変更の処理手順について説明する。
図１７は、予約変更の処理手順を示すシーケンスチャートである。
同図に示すように、予約変更は、サーバ１から受信した予約情報を表示部２０５に表示した状況で実行できる。
例えば、サーバ１から受信した予約情報（予約済みの１便目［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］と２便目［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］の乗車便情報）を表示した予約結果画面（図１５）を予約変更画面１として兼用することができる。
すなわち、予約変更においては、まず、利用者端末２の表示部２０５に予約変更画面１を表示させる（Ｓ３０１）。
予約変更の処理手順について説明する。
図１７は、予約変更の処理手順を示すシーケンスチャートである。
同図に示すように、予約変更は、サーバ１から受信した予約情報を表示部２０５に表示した状況で実行できる。
例えば、サーバ１から受信した予約情報（予約済みの１便目［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］と２便目［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］の乗車便情報）を表示した予約結果画面（図１５）を予約変更画面１として兼用することができる。
すなわち、予約変更においては、まず、利用者端末２の表示部２０５に予約変更画面１を表示させる（Ｓ３０１）。
【0066】
次に、予約変更操作１を行う（Ｓ３０２）。
予約変更操作１は、具体的には、変更元便情報（つまり旧便情報）を指定する操作であり、予約変更画面１上に１便目と２便目の便情報が表示されている場合、そのうちの一方又は双方を変更対象として選択することができる。
本処理手順では、２便目（［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］）が選択されたものとする。
利用者端末２は、変更元便情報をサーバ１に送信する。
予約変更操作１は、具体的には、変更元便情報（つまり旧便情報）を指定する操作であり、予約変更画面１上に１便目と２便目の便情報が表示されている場合、そのうちの一方又は双方を変更対象として選択することができる。
本処理手順では、２便目（［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］）が選択されたものとする。
利用者端末２は、変更元便情報をサーバ１に送信する。
【0067】
サーバ１は、利用者端末２から送信された変更元便情報を受信すると、当該変更元便情報を対応する予約サーバ３に送信する（Ｓ３０３）。
本処理手順では、「ＯＣＡＴ→岡山駅」路線の予約処理を担っている予約サーバ３Ｂに変更元便情報を送信する。
本処理手順では、「ＯＣＡＴ→岡山駅」路線の予約処理を担っている予約サーバ３Ｂに変更元便情報を送信する。
【0068】
予約サーバ３Ｂは、サーバ１から変更元便情報を受信すると、変更候補の便情報をサーバ１に送信する（Ｓ３０４）。
具体的には、予約サーバ３Ｂが、変更元便情報に含まれる変更対象の便の出発地及び到着地並びに出発日に基づいて改めて便検索を実行し、その検索結果を変更候補の便情報としてサーバ１に送信する。
本処理手順では、「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」が検出され、変更候補の便情報として送信される。
具体的には、予約サーバ３Ｂが、変更元便情報に含まれる変更対象の便の出発地及び到着地並びに出発日に基づいて改めて便検索を実行し、その検索結果を変更候補の便情報としてサーバ１に送信する。
本処理手順では、「2024/2/2_09:30-12:30_2,900円_残席２」と「2024/2/2_10:30-13:30_3,000円_残席５」が検出され、変更候補の便情報として送信される。
【0069】
サーバ１は、予約サーバ３Ｂから送信された便情報を受信すると、当該便情報を利用者端末２に送信する（Ｓ３０５）。
【0070】
利用者端末２は、サーバ１から送信された便情報を受信すると、当該便情報を表示部２０５に表示する（Ｓ３０６）。
利用者端末２は、便候補表示・選択画面（図１１）を予約変更画面２として兼用して便情報を表示することができる。
利用者端末２は、便候補表示・選択画面（図１１）を予約変更画面２として兼用して便情報を表示することができる。
【0071】
次に、予約変更操作２を行う（Ｓ３０７）。
予約変更操作２は、具体的には、変更先便情報（つまり新便情報）を指定する操作であり、例えば、予約変更画面２上に２つの便候補が表示されている場合、そのうちの一方又は双方を選択することができる。
本処理手順では、便候補１「2024/2/2_9:30-12:30」と便候補２「2024/2/2_10:30-13:30」のうち、便候補１が変更先便情報として選択されたものとする。
利用者端末２は、変更先便情報をサーバ１に送信する。
予約変更操作２は、具体的には、変更先便情報（つまり新便情報）を指定する操作であり、例えば、予約変更画面２上に２つの便候補が表示されている場合、そのうちの一方又は双方を選択することができる。
本処理手順では、便候補１「2024/2/2_9:30-12:30」と便候補２「2024/2/2_10:30-13:30」のうち、便候補１が変更先便情報として選択されたものとする。
利用者端末２は、変更先便情報をサーバ１に送信する。
【0072】
サーバ１は、利用者端末２から送信された変更先便情報を受信すると、割引額を計算する（Ｓ３０８）。
割引額の計算は、Ｓ２０２と同様であるため説明を省略する。
サーバ１は、標準料金、割引額、差引料金などの料金情報を利用者端末２に送信する。
具体的には、標準料金10,700円、割引額200円、差引料金10,500円などの料金情報が送信される。
割引額の計算は、Ｓ２０２と同様であるため説明を省略する。
サーバ１は、標準料金、割引額、差引料金などの料金情報を利用者端末２に送信する。
具体的には、標準料金10,700円、割引額200円、差引料金10,500円などの料金情報が送信される。
【0073】
利用者端末２は、サーバ１から送信された料金情報を受信すると、当該料金情報を表示部２０５に表示する（Ｓ３０９）。
料金情報は、料金情報表示画面（図１３）に表示する。
ただし、差引料金が「10,500円」（ｄ３３）に変更される。
料金情報は、料金情報表示画面（図１３）に表示する。
ただし、差引料金が「10,500円」（ｄ３３）に変更される。
【0074】
次に、利用者端末２において、予約の申し込みを行う（Ｓ３１０）。
具体的には、料金情報表示画面（図１３）の「予約へ進む」ボタンを選択操作する。
これにより、利用者端末２は、変更情報をサーバ１に送信する。
変更情報には、変更先便情報及び料金情報が含まれる。
具体的には、料金情報表示画面（図１３）の「予約へ進む」ボタンを選択操作する。
これにより、利用者端末２は、変更情報をサーバ１に送信する。
変更情報には、変更先便情報及び料金情報が含まれる。
【0075】
サーバ１は、利用者端末２から送信された変更情報を受信すると、当該変更情報を予約サーバ３Ｂに送信する（Ｓ３１１）。
予約サーバ３Ｂは、サーバ１から送信された変更情報を受信すると、予約変更処理を実行する（Ｓ３１２）。
具体的には、変更元便情報「2024/2/2_9:30-12:30」を変更先便情報「2024/2/2_10:30-13:30」に変更する。
これにより、予約変更が実行される。
予約サーバ３Ｂは、変更結果をサーバ１に送信する。
予約サーバ３Ｂは、サーバ１から送信された変更情報を受信すると、予約変更処理を実行する（Ｓ３１２）。
具体的には、変更元便情報「2024/2/2_9:30-12:30」を変更先便情報「2024/2/2_10:30-13:30」に変更する。
これにより、予約変更が実行される。
予約サーバ３Ｂは、変更結果をサーバ１に送信する。
【0076】
サーバ１は、予約サーバ３Ｂから変更結果を受信すると、決済依頼情報（料金情報を含む）を決済サーバ４に送信する（Ｓ３１３）。
決済依頼情報は、Ｓ２１２の際に利用者端末２から受信し、保持している決済情報を用いるが、料金は10,500円である。
決済依頼情報は、Ｓ２１２の際に利用者端末２から受信し、保持している決済情報を用いるが、料金は10,500円である。
【0077】
決済サーバ４は、サーバ１から送信された決済依頼情報を受信すると、決済処理を実行する（Ｓ３１４）。
これにより、料金10,500円がクレジット決済される。
決済サーバ４は、決済結果をサーバ１に送信する。
これにより、料金10,500円がクレジット決済される。
決済サーバ４は、決済結果をサーバ１に送信する。
【0078】
サーバ１は、決済サーバ４から送信された決済結果を受信すると、変更内容を含む変更結果を利用者端末２に送信する（Ｓ３１５）。
利用者端末２は、サーバ１から送信された変更結果を受信すると、当該変更結果を表示部２０５に表示する（Ｓ３１６）。変更結果の図示は省略する。
利用者端末２は、サーバ１から送信された変更結果を受信すると、当該変更結果を表示部２０５に表示する（Ｓ３１６）。変更結果の図示は省略する。
【0079】
（予約取消）
予約取消の処理手順について説明する。
図１８は、予約取消の処理手順を示すシーケンスチャートである。
同図に示すように、予約取消は、サーバ１から受信した予約情報を表示部２０５に表示した状況で実行できる。
例えば、サーバ１から受信した予約情報（予約済みの１便目［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］と２便目［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］の乗車便情報）を表示した予約結果画面（図１５）に「予約取消」ボタンが追加された画面（予約取消画面）を表示した状況で予約取消を実行することができる。
すなわち、予約取消においては、まず、利用者端末２の表示部２０５に予約取消画面（図示省略）を表示させる（Ｓ４０１）。
予約取消の処理手順について説明する。
図１８は、予約取消の処理手順を示すシーケンスチャートである。
同図に示すように、予約取消は、サーバ１から受信した予約情報を表示部２０５に表示した状況で実行できる。
例えば、サーバ１から受信した予約情報（予約済みの１便目［東京駅→ＯＣＡＴ_2024/2/1_22:10-06:44］と２便目［ＯＣＡＴ→岡山駅_2024/2/2_10:30-13:30］の乗車便情報）を表示した予約結果画面（図１５）に「予約取消」ボタンが追加された画面（予約取消画面）を表示した状況で予約取消を実行することができる。
すなわち、予約取消においては、まず、利用者端末２の表示部２０５に予約取消画面（図示省略）を表示させる（Ｓ４０１）。
【0080】
次に、予約取消操作を行う（Ｓ４０２）。
具体的には、「予約取消ボタン」を選択操作する。
予約取消操作に応じ、利用者端末２は、取消情報をサーバ１に送信する。
具体的には、「予約取消ボタン」を選択操作する。
予約取消操作に応じ、利用者端末２は、取消情報をサーバ１に送信する。
【0081】
サーバ１は、利用者端末２から送信された取消情報を受信すると手数料を計算する（Ｓ４０３）。
続いて、サーバ１は、取消情報を予約サーバ３Ａに送信する（Ｓ４０４）と共に、取消情報を予約サーバ３Ｂに送信する（Ｓ４０６）。
予約サーバ３Ａは、サーバ１から送信された取消情報を受信すると、予約取消処理を実行する（Ｓ４０５）。予約サーバ３Ａは、取消結果をサーバ１に送信する。
予約サーバ３Ｂは、サーバ１から送信された取消情報を受信すると、予約取消処理を実行する（Ｓ４０７）。予約サーバ３Ｂは、取消結果をサーバ１に送信する。
続いて、サーバ１は、取消情報を予約サーバ３Ａに送信する（Ｓ４０４）と共に、取消情報を予約サーバ３Ｂに送信する（Ｓ４０６）。
予約サーバ３Ａは、サーバ１から送信された取消情報を受信すると、予約取消処理を実行する（Ｓ４０５）。予約サーバ３Ａは、取消結果をサーバ１に送信する。
予約サーバ３Ｂは、サーバ１から送信された取消情報を受信すると、予約取消処理を実行する（Ｓ４０７）。予約サーバ３Ｂは、取消結果をサーバ１に送信する。
【0082】
サーバ１は、予約サーバ３Ａ及び３Ｂから取消結果を受信すると、決済サーバ４に決済依頼情報を送信する（Ｓ４０８）。
決済依頼情報は、Ｓ２１２の際に利用者端末２から受信し、保持している決済情報を用いるが、料金はＳ４０３において計算した手数料である。
決済依頼情報は、Ｓ２１２の際に利用者端末２から受信し、保持している決済情報を用いるが、料金はＳ４０３において計算した手数料である。
【0083】
決済サーバ４は、サーバ１から送信された決済依頼情報を受信すると、決済処理を実行する（Ｓ４０９）。
これにより、手数料がクレジット決済される。
決済サーバ４は、決済結果をサーバ１に送信する。
これにより、手数料がクレジット決済される。
決済サーバ４は、決済結果をサーバ１に送信する。
【0084】
サーバ１は、決済サーバ４から送信された決済結果を受信すると、取消内容を含む取消結果を利用者端末２に送信する（Ｓ４１０）。
利用者端末２は、サーバ１から送信された取消結果を受信すると、当該取消結果を表示部２０５に表示する（Ｓ４１１）。取消結果の図示は省略する。
利用者端末２は、サーバ１から送信された取消結果を受信すると、当該取消結果を表示部２０５に表示する（Ｓ４１１）。取消結果の図示は省略する。
【0085】
このように、本実施形態の高速バスシステムにおいては、高速バスの予約取消を一括で実行可能にしている。
つまり、仮に乗継ルートの予約を行ったとして、その予約を取り消す場合、従来は、複数の窓口にアクセスしてそれぞれ個別に予約取消の手続きを行わなければならなかったが、本実施形態のバスシステムによれば、その手続きを一括で行うことができる。
つまり、仮に乗継ルートの予約を行ったとして、その予約を取り消す場合、従来は、複数の窓口にアクセスしてそれぞれ個別に予約取消の手続きを行わなければならなかったが、本実施形態のバスシステムによれば、その手続きを一括で行うことができる。
【0086】
（レコメンド情報表示）
レコメンド情報の表示処理について説明する。
本実施形態の高速バスシステムでは、高速バスの利用者に様々なリコメンド情報を提供するようにしている。
具体的には、サーバ１は、会員である利用者がログインした状態での、ルート検索や予約の履歴情報を会員毎に取得・保存しており、当該履歴情報に基づく分析によって、会員が興味をもちそうなおすすめ情報（レコメンド情報）を生成し、適時、利用者端末２を介して会員に通知するようにしている。
特に、乗継ルートを予約した会員に対しては、ログイン中にはレコメンド情報をＷｅｂブラウザを介して利用者端末２に表示させたり、非ログイン中は、予め登録しているメールアドレス宛にレコメンド情報を送信するようにしている。
レコメンド情報の表示処理について説明する。
本実施形態の高速バスシステムでは、高速バスの利用者に様々なリコメンド情報を提供するようにしている。
具体的には、サーバ１は、会員である利用者がログインした状態での、ルート検索や予約の履歴情報を会員毎に取得・保存しており、当該履歴情報に基づく分析によって、会員が興味をもちそうなおすすめ情報（レコメンド情報）を生成し、適時、利用者端末２を介して会員に通知するようにしている。
特に、乗継ルートを予約した会員に対しては、ログイン中にはレコメンド情報をＷｅｂブラウザを介して利用者端末２に表示させたり、非ログイン中は、予め登録しているメールアドレス宛にレコメンド情報を送信するようにしている。
【0087】
図１９は、レコメンド表示画面の一例を示す図である。
図１９は、会員である山田さんが、２０２４年２月１日が出発日で、且つ、乗車乗継地が「大阪」の乗継ルートを予約した場合に、予約後から出発日までの間に山田さんのメールアドレス宛にサーバ１から送信されるレコメンド情報である。
同図に示すレコメンド情報は、山田さんが乗継ルートを予約しており、山田さんが乗継地で乗継ぐ時期に対応したおすすめ情報であることが示唆されている。
具体的には、「おすすめイベント」（ｄ７１）、「おすすめグルメ」（ｄ７２）、「おすすめスポット」（ｄ７３）などがある。
「おすすめイベント」情報は、乗継地だけでなく、乗継ぎの時期に対応したレコメンド情報となっている。
「おすすめグルメ」や「おすすめスポット」の情報も同様であり、特に、「おすすめスポット」情報は、乗継地の到着時刻が早朝であること、且つ、前日の夜間に出発していること、そのため、利用者は寝不足である可能性が高い、などをサーバ１が認識又は分析した結果を反映した情報となっている。
図１９は、会員である山田さんが、２０２４年２月１日が出発日で、且つ、乗車乗継地が「大阪」の乗継ルートを予約した場合に、予約後から出発日までの間に山田さんのメールアドレス宛にサーバ１から送信されるレコメンド情報である。
同図に示すレコメンド情報は、山田さんが乗継ルートを予約しており、山田さんが乗継地で乗継ぐ時期に対応したおすすめ情報であることが示唆されている。
具体的には、「おすすめイベント」（ｄ７１）、「おすすめグルメ」（ｄ７２）、「おすすめスポット」（ｄ７３）などがある。
「おすすめイベント」情報は、乗継地だけでなく、乗継ぎの時期に対応したレコメンド情報となっている。
「おすすめグルメ」や「おすすめスポット」の情報も同様であり、特に、「おすすめスポット」情報は、乗継地の到着時刻が早朝であること、且つ、前日の夜間に出発していること、そのため、利用者は寝不足である可能性が高い、などをサーバ１が認識又は分析した結果を反映した情報となっている。
【0088】
レコメンド情報は、高速バスの利用前、利用中、利用後という条件に対応付けて生成することもできる。
「高速バスの利用前」のレコメンド情報としては、例えば、会員に対し、おすすめのスポット等と最寄りの停留所をセットにすることで高速バスの予約を促す情報をサーバ１に生成させ、電子メール等にて利用者端末２に通知することを例示できる。
「高速バスの利用中」のレコメンド情報としては、例えば、高速バス便を予約中の会員に対し、乗車前や乗車中に最適なレコメンド情報をサーバ１に生成させて、適時、電子メール等にて利用者端末２に通知することを例示できる。詳しくは、時刻や利用者端末２のＧＰＳ情報から利用者の現在位置を特定できるため、当該現在位置に応じた各種情報（例えば、富士山の近くを移動中に、富士山に関する動画やＷｅｂサイトの情報等）を利用者端末２に送信する。
「高速バスの利用後」のレコメンド情報としては、例えば、高速バスの利用直後の会員に対し、次回の予約につながるようなレコメンド情報（例えば、人気のマスコットキャラクターから「また利用してね」などのメッセージ）をサーバ１に生成させて、チャット等にて利用者端末２に通知することを例示できる。
「高速バスの利用前」のレコメンド情報としては、例えば、会員に対し、おすすめのスポット等と最寄りの停留所をセットにすることで高速バスの予約を促す情報をサーバ１に生成させ、電子メール等にて利用者端末２に通知することを例示できる。
「高速バスの利用中」のレコメンド情報としては、例えば、高速バス便を予約中の会員に対し、乗車前や乗車中に最適なレコメンド情報をサーバ１に生成させて、適時、電子メール等にて利用者端末２に通知することを例示できる。詳しくは、時刻や利用者端末２のＧＰＳ情報から利用者の現在位置を特定できるため、当該現在位置に応じた各種情報（例えば、富士山の近くを移動中に、富士山に関する動画やＷｅｂサイトの情報等）を利用者端末２に送信する。
「高速バスの利用後」のレコメンド情報としては、例えば、高速バスの利用直後の会員に対し、次回の予約につながるようなレコメンド情報（例えば、人気のマスコットキャラクターから「また利用してね」などのメッセージ）をサーバ１に生成させて、チャット等にて利用者端末２に通知することを例示できる。
【0089】
利用者端末２における他の表示例について説明する。
図２０は、ルート検索の検索結果画面の他の表示例（その１）を示す図である。
同図に示すように、ルート検索結果の表示順を利用者が選択するようにできる（ｄ８１）。
具体的には、「所要時間」と「料金」のいずれかを選択できるようにし、「所要時間」が選択された場合は、所要時間が短い順に便情報を並べて表示し、「料金」が選択された場合は、料金が安い順に便情報を並べて表示するようにする。
さらに、「乗継あり／乗継なし」の一方を選択して便情報の絞り込みを行うこともできる。
例えば、乗継ぎを好む利用者や許容する利用者は「乗継あり」を選択すればよく、乗継ぎを好まない利用者や許容しない利用者は「乗継なし」を選択すればよい。
図２０は、ルート検索の検索結果画面の他の表示例（その１）を示す図である。
同図に示すように、ルート検索結果の表示順を利用者が選択するようにできる（ｄ８１）。
具体的には、「所要時間」と「料金」のいずれかを選択できるようにし、「所要時間」が選択された場合は、所要時間が短い順に便情報を並べて表示し、「料金」が選択された場合は、料金が安い順に便情報を並べて表示するようにする。
さらに、「乗継あり／乗継なし」の一方を選択して便情報の絞り込みを行うこともできる。
例えば、乗継ぎを好む利用者や許容する利用者は「乗継あり」を選択すればよく、乗継ぎを好まない利用者や許容しない利用者は「乗継なし」を選択すればよい。
【0090】
図２１は、ルート検索の検索結果画面の他の表示例（その２）を示す図である。
同図に示すように、「乗継数の多い順」と「乗継数の少ない順」のいずれかを選択できるようにして、選択された順に便情報を並べて表示させることもできる（ｄ８２）。このような表示制御機能は、サーバ１により制御する。
例えば「乗継数の多い順」が選択された場合、サーバ１の表示制御手段１３が、乗継数の多い便情報を上位に表示させることができる。
つまり、表示制御手段１３は、乗継数が第１数である乗継ルートよりも、乗継数が前記第１数より多い第２数である乗継ルートを、利用者端末２において上位に表示させる。
同図に示すように、「乗継数の多い順」と「乗継数の少ない順」のいずれかを選択できるようにして、選択された順に便情報を並べて表示させることもできる（ｄ８２）。このような表示制御機能は、サーバ１により制御する。
例えば「乗継数の多い順」が選択された場合、サーバ１の表示制御手段１３が、乗継数の多い便情報を上位に表示させることができる。
つまり、表示制御手段１３は、乗継数が第１数である乗継ルートよりも、乗継数が前記第１数より多い第２数である乗継ルートを、利用者端末２において上位に表示させる。
【0091】
図２２は、ルート検索の検索結果画面の他の表示例（その３）を示す図である。
同図に示すように、乗継割引額を表示してもよい。
具体的には、乗継ルートに対して乗継割引（ｄ８３）を表示し、直行ルートに対しては乗継割引額を表示しない。
また、乗継数が多い乗継ルートに対する乗継割引は、乗継数が少ない乗継ルートに対する乗継割引よりも多くすることができる。
つまり、乗継数が多い乗継ルートに対する乗継割引は相対的に多い割引額が適用されて表示されることになる。
同図に示すように、乗継割引額を表示してもよい。
具体的には、乗継ルートに対して乗継割引（ｄ８３）を表示し、直行ルートに対しては乗継割引額を表示しない。
また、乗継数が多い乗継ルートに対する乗継割引は、乗継数が少ない乗継ルートに対する乗継割引よりも多くすることができる。
つまり、乗継数が多い乗継ルートに対する乗継割引は相対的に多い割引額が適用されて表示されることになる。
【0092】
これにより、乗継ぎを好む利用者や、乗継数を多くすることで安価な料金で高速バスを利用したい利用者に対応した表示が可能になる。
なお、従来は、乗継数に応じて便の表示順を並び替えることはなかった。
また、仮に、そのようなことがあったとしても、「乗継ぎ＝不便」という既成概念があるため、乗継数を多い順で表示することは想定されていなかった。
本実施形態の高速バスシステムによれば、乗継ぎの利便を向上したことで「乗継ぎ＝不便」という観念をなくすことに加え、図２０～図２２に示すような表示態様によって、乗継ぎを積極的に利用したい利用者にとってさらに利便性を向上させることができる。
なお、従来は、乗継数に応じて便の表示順を並び替えることはなかった。
また、仮に、そのようなことがあったとしても、「乗継ぎ＝不便」という既成概念があるため、乗継数を多い順で表示することは想定されていなかった。
本実施形態の高速バスシステムによれば、乗継ぎの利便を向上したことで「乗継ぎ＝不便」という観念をなくすことに加え、図２０～図２２に示すような表示態様によって、乗継ぎを積極的に利用したい利用者にとってさらに利便性を向上させることができる。
【0093】
以上説明したように、本実施形態の高速バスシステムは、高速バスの利用者が所持する利用者端末２を備えた高速バスシステムにおいて、現存する高速バスの路線情報を記憶する記憶手段１１と、利用者端末２により入力された情報に基づき、前記利用者が利用可能な路線である利用可能ルートを前記路線情報から抽出する抽出手段１２と、前記抽出した利用可能ルートの情報を利用者端末２に表示させる表示制御手段１３と、利用者端末２の操作に応じて、前記利用可能ルートの予約処理を実行可能な予約手段１４と、を備え、抽出手段１２は、第１路線と第２路線を含む複数路線の間で乗継ぎを伴う乗継ルートを前記利用可能ルートとして抽出可能であり、予約手段１４は、利用者端末２の操作に応じて、前記乗継ルートを構成する複数の路線の予約処理を一括で実行可能にしている。
すなわち、乗継ルートの予約処理を１つのＷｅｂサイトを介した操作に応じて一括で実行するようにしており、さらに、予約処理に続けて、決済処理を一連且つ一括で行うようにしている。
これにより、予約や決済の手続きが容易になり、乗継ルートを一連の長距離バスのような利用価値の高い高速バスサービスとして提供できる。
また、本実施形態の高速バスシステムにはバス事業者相互の連携・協力が必要になるところ、このような連携・協力を通してバス事業全体の興隆を図ることができる。
また、バス事業者が抱える実車距離制限やいわゆる２０２４年問題の解決を図ることができる。
また、直行ルート、鉄道・飛行機など他の交通手段に欠く地域において、乗継ぎを伴う高速バスサービスを新たな交通手段として参入を図ることができる。
また、本実施形態の高速バスシステムによれば、新たな移動態様や旅行態様を提案できる。
これに対し、従来は、乗継ぎに伴う手続きの煩わしさがあったが、本発明の高速バスシステムによれば、上述の構成を備えることで、このような従来の問題を解決できる。
つまり、従来は、仮に乗継ぎを行う場合でも、複数の窓口でそれぞれ予約を行わなければならなかったが、本実施形態の高速バスシステムによれば、それぞれの予約を一括で処理することができ、さらに、決済を一連・一括に行え、加えて、変更処理や取消しも一括で処理することができる。
すなわち、乗継ルートの予約処理を１つのＷｅｂサイトを介した操作に応じて一括で実行するようにしており、さらに、予約処理に続けて、決済処理を一連且つ一括で行うようにしている。
これにより、予約や決済の手続きが容易になり、乗継ルートを一連の長距離バスのような利用価値の高い高速バスサービスとして提供できる。
また、本実施形態の高速バスシステムにはバス事業者相互の連携・協力が必要になるところ、このような連携・協力を通してバス事業全体の興隆を図ることができる。
また、バス事業者が抱える実車距離制限やいわゆる２０２４年問題の解決を図ることができる。
また、直行ルート、鉄道・飛行機など他の交通手段に欠く地域において、乗継ぎを伴う高速バスサービスを新たな交通手段として参入を図ることができる。
また、本実施形態の高速バスシステムによれば、新たな移動態様や旅行態様を提案できる。
これに対し、従来は、乗継ぎに伴う手続きの煩わしさがあったが、本発明の高速バスシステムによれば、上述の構成を備えることで、このような従来の問題を解決できる。
つまり、従来は、仮に乗継ぎを行う場合でも、複数の窓口でそれぞれ予約を行わなければならなかったが、本実施形態の高速バスシステムによれば、それぞれの予約を一括で処理することができ、さらに、決済を一連・一括に行え、加えて、変更処理や取消しも一括で処理することができる。
【0094】
（他の実施形態）
本発明の他の実施形態について説明する。
前述の実施形態では、高速バスの予約は、既存の予約システム（予約サーバ）との連携（予約連携という）により実行することについて説明した。
予約連携は、２つの予約システムと連携する場合や、３つ以上の予約システムと連携する場合が想定される。
本発明の他の実施形態について説明する。
前述の実施形態では、高速バスの予約は、既存の予約システム（予約サーバ）との連携（予約連携という）により実行することについて説明した。
予約連携は、２つの予約システムと連携する場合や、３つ以上の予約システムと連携する場合が想定される。
【0095】
図２３は、予約連携の説明図である。
具体的には、図２３は、予約連携により３路線を乗り継ぐ乗継ルートの予約を行う場合の処理を模式的に示した図である。このため、図２３は、３つの予約システムと連携する場合を想定している。
つまり、図２３は、利用者が、利用者端末２を操作して、第１路線（バスＡ）・第２路線（バスＢ）・第３路線（バスＣ）からなる乗継ルートの予約を行う場合を想定している。
前提として、第１路線はバス会社Ａが運営する予約システムＡ（予約サーバＡ）で管理されており、第２路線はバス会社Ｂが運営する予約システムＢ（予約サーバＢ）で管理されており、第３路線はバス会社Ｃが運営する予約システムＣ（予約サーバＣ）で管理されているものとする。
つまり、バス会社Ａ（第１運営者）により運営される第１路線の予約を実行可能な予約システムＡ（第１予約システム）と、バス会社Ｂ（第２運営者）により運営される第２路線の予約を実行可能な予約システムＢ（第２予約システム）と、を含む、複数の運営者により運営される複数の路線の各予約システムが存在しており、各予約システム（各予約サーバ）は、自システム内で運営・管理する路線の予約が可能であり、そのため、自路線の予約に必要な管理情報を保有（記憶）している。
この場合、前述の実施形態に係るサーバ１は、乗継ルートの予約を受け付けると、第１路線の予約を予約システムＡに依頼し、第２路線の予約を予約システムＢに依頼し、第３路線の予約を予約システムＣに依頼する。
座席の予約も同様であり、第１路線の座席の予約は予約システムＡに依頼し、第２路線の座席の予約は予約システムＢに依頼し、第３路線の座席の予約は予約システムＣに依頼する。
各予約システムは依頼内容に従って路線や座席の予約を実行する。
サーバ１は、各予約システムから予約結果を含む情報（予約結果情報）を受信すると、予約結果を利用者端末２に通知する。サーバ１は、予約結果情報を、ログその他の用途のために保存する。
ところが、このような予約連携によると、以下の問題が生じることを発明者らが突き止めた。
具体的には、図２３は、予約連携により３路線を乗り継ぐ乗継ルートの予約を行う場合の処理を模式的に示した図である。このため、図２３は、３つの予約システムと連携する場合を想定している。
つまり、図２３は、利用者が、利用者端末２を操作して、第１路線（バスＡ）・第２路線（バスＢ）・第３路線（バスＣ）からなる乗継ルートの予約を行う場合を想定している。
前提として、第１路線はバス会社Ａが運営する予約システムＡ（予約サーバＡ）で管理されており、第２路線はバス会社Ｂが運営する予約システムＢ（予約サーバＢ）で管理されており、第３路線はバス会社Ｃが運営する予約システムＣ（予約サーバＣ）で管理されているものとする。
つまり、バス会社Ａ（第１運営者）により運営される第１路線の予約を実行可能な予約システムＡ（第１予約システム）と、バス会社Ｂ（第２運営者）により運営される第２路線の予約を実行可能な予約システムＢ（第２予約システム）と、を含む、複数の運営者により運営される複数の路線の各予約システムが存在しており、各予約システム（各予約サーバ）は、自システム内で運営・管理する路線の予約が可能であり、そのため、自路線の予約に必要な管理情報を保有（記憶）している。
この場合、前述の実施形態に係るサーバ１は、乗継ルートの予約を受け付けると、第１路線の予約を予約システムＡに依頼し、第２路線の予約を予約システムＢに依頼し、第３路線の予約を予約システムＣに依頼する。
座席の予約も同様であり、第１路線の座席の予約は予約システムＡに依頼し、第２路線の座席の予約は予約システムＢに依頼し、第３路線の座席の予約は予約システムＣに依頼する。
各予約システムは依頼内容に従って路線や座席の予約を実行する。
サーバ１は、各予約システムから予約結果を含む情報（予約結果情報）を受信すると、予約結果を利用者端末２に通知する。サーバ１は、予約結果情報を、ログその他の用途のために保存する。
ところが、このような予約連携によると、以下の問題が生じることを発明者らが突き止めた。
【0096】
図２４は、予約連携において発生する問題を説明するための図である。
図２４（ａ）は、新規予約時に発生する問題を示す図である。
具体的には、新規予約の際、予約システムＡと予約システムＢとの連携に基づく予約は問題なく処理できたが、予約システムＣとの連携において問題が発生して路線又は座席の予約が失敗したケースを示している。
この場合、利用者は、再度予約操作を行う必要があるため利便性が低下し、成功した予約システムＡ，Ｂの予約の削除が必要になる、などの問題が生じる。
図２４（ｂ）は、予約後に人数変更や予約取消の際に発生する問題を示す図である。
具体的は、予約システムＡと予約システムＣとの連携に基づく予約取消（予約削除）は問題なく処理できたが、予約システムＢとの連携において問題が発生して予約取消が失敗したケースを示している。
この場合、利用者端末に対しては「成功」の旨を通知するところ、予約システムＢの予約を取り消す（削除する）必要がある。つまり、予約システムＢの取り消しを何らかの方法で実行しなければ全体として予約取消が完了しないため、当該予約システムＢの取り消すための管理の仕組みが必要になるという問題が生じる。
予約人数の変更は、当初の予約人数を取り消した後に正しい予約人数を記憶する仕組みであるため、予約取消の場合と同様の問題が生じる。
そこで、調査・分析を進めた結果、これらの問題は、サーバ１と予約システムとの通信やＡＰＩ連携、つまり、予約連携における不具合が原因で発生し易いことを発明者らが突き止めた。
図２４（ａ）は、新規予約時に発生する問題を示す図である。
具体的には、新規予約の際、予約システムＡと予約システムＢとの連携に基づく予約は問題なく処理できたが、予約システムＣとの連携において問題が発生して路線又は座席の予約が失敗したケースを示している。
この場合、利用者は、再度予約操作を行う必要があるため利便性が低下し、成功した予約システムＡ，Ｂの予約の削除が必要になる、などの問題が生じる。
図２４（ｂ）は、予約後に人数変更や予約取消の際に発生する問題を示す図である。
具体的は、予約システムＡと予約システムＣとの連携に基づく予約取消（予約削除）は問題なく処理できたが、予約システムＢとの連携において問題が発生して予約取消が失敗したケースを示している。
この場合、利用者端末に対しては「成功」の旨を通知するところ、予約システムＢの予約を取り消す（削除する）必要がある。つまり、予約システムＢの取り消しを何らかの方法で実行しなければ全体として予約取消が完了しないため、当該予約システムＢの取り消すための管理の仕組みが必要になるという問題が生じる。
予約人数の変更は、当初の予約人数を取り消した後に正しい予約人数を記憶する仕組みであるため、予約取消の場合と同様の問題が生じる。
そこで、調査・分析を進めた結果、これらの問題は、サーバ１と予約システムとの通信やＡＰＩ連携、つまり、予約連携における不具合が原因で発生し易いことを発明者らが突き止めた。
【0097】
そして、これらの問題を解決すべく、予約連携に代わる新たな構成を本発明の他の実施形態として構築した。
図２５は、他の実施形態に係るサーバ１の機能構成図である。
図２５に示すように、他の実施形態に係るサーバ１（制御部１０１）は、管理情報記憶手段１９０、予約受付手段１９１、予約手段１９２、座席予約受付手段１９３、座席予約手段１９４、特定情報記憶手段１９５、座席予約制御手段１９６、及び、変更手段１９７を備えている。
なお、予約手段１９２は、前述の予約手段１４と路線の予約という共通の機能を備えるも、予約システムとの連携によらない予約を特徴とするため、便宜上、用語は同一として符号を異ならせた。
図２５は、他の実施形態に係るサーバ１の機能構成図である。
図２５に示すように、他の実施形態に係るサーバ１（制御部１０１）は、管理情報記憶手段１９０、予約受付手段１９１、予約手段１９２、座席予約受付手段１９３、座席予約手段１９４、特定情報記憶手段１９５、座席予約制御手段１９６、及び、変更手段１９７を備えている。
なお、予約手段１９２は、前述の予約手段１４と路線の予約という共通の機能を備えるも、予約システムとの連携によらない予約を特徴とするため、便宜上、用語は同一として符号を異ならせた。
【0098】
管理情報記憶手段１９０は、予約システム（予約サーバ）が記憶している管理情報を記憶する。
つまり、従来から、予約システムＡは、第１路線の予約に必要な第１管理情報を記憶し、予約システムＢは、第２路線の予約に必要な第２管理情報を記憶するところ、サーバ１は、各予約システムが記憶している路線の予約に必要な管理情報を予め記憶するようにした。
これにより、サーバ１だけで予約を受け付けたり、予約を実行できる。
また、予約システムの構成はそのままなので、必要に応じ、予約システムにおいても予約を受け付けたり、予約を実行できる。
つまり、従来から、予約システムＡは、第１路線の予約に必要な第１管理情報を記憶し、予約システムＢは、第２路線の予約に必要な第２管理情報を記憶するところ、サーバ１は、各予約システムが記憶している路線の予約に必要な管理情報を予め記憶するようにした。
これにより、サーバ１だけで予約を受け付けたり、予約を実行できる。
また、予約システムの構成はそのままなので、必要に応じ、予約システムにおいても予約を受け付けたり、予約を実行できる。
【0099】
サーバ１の予約受付手段１９１は、路線の予約を受け付ける。
サーバ１の予約手段１９２は、予約受付手段１９１により路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている管理情報に基づいて路線の予約を実行する。
予約手段１９２は、例えば、予約受付手段１９１が第１路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第１管理情報に基づいて第１路線の予約を実行し、予約受付手段１９１が第２路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第２管理情報に基づいて第２路線の予約を実行する。
サーバ１の予約手段１９２は、予約受付手段１９１により路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている管理情報に基づいて路線の予約を実行する。
予約手段１９２は、例えば、予約受付手段１９１が第１路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第１管理情報に基づいて第１路線の予約を実行し、予約受付手段１９１が第２路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第２管理情報に基づいて第２路線の予約を実行する。
【0100】
サーバ１は、高速バスの座席を、路線の予約と共に又は個別に予約することができる。
このため、管理情報には、座席の予約に必要な情報（座席情報）が含まれている。
座席情報として、例えば、座席番号、空席／予約済を示す空席情報などがある。
サーバ１の座席予約受付手段１９３は、座席の予約を受け付ける。
サーバ１の座席予約手段１９４は、座席予約受付手段１９３により座席の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている座席情報に基づいて座席の予約を実行する。
サーバ１の座席予約手段１９４は、例えば、座席予約受付手段１９３が第１座席の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第１座席情報に基づいて第１座席の予約を実行し、座席予約受付手段１９３が第２座席の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第２座席情報に基づいて第２座席の予約を実行する。
このため、管理情報には、座席の予約に必要な情報（座席情報）が含まれている。
座席情報として、例えば、座席番号、空席／予約済を示す空席情報などがある。
サーバ１の座席予約受付手段１９３は、座席の予約を受け付ける。
サーバ１の座席予約手段１９４は、座席予約受付手段１９３により座席の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている座席情報に基づいて座席の予約を実行する。
サーバ１の座席予約手段１９４は、例えば、座席予約受付手段１９３が第１座席の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第１座席情報に基づいて第１座席の予約を実行し、座席予約受付手段１９３が第２座席の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている第２座席情報に基づいて第２座席の予約を実行する。
【0101】
図２６は、他の実施形態に係る高速バスシステムの説明図である。
図２６や既述にて示すように、他の実施形態では、路線や座席の予約に必要な管理情報をサーバ１で事前に取得（事前記憶）することにより、サーバ１だけで予約を実行できるようにした。
サーバ１は、各予約システム（予約サーバ）と、通信可能に接続されており、各予約システムに記憶されている管理情報（座席マップを特定可能な座席情報を含む）を各予約システムから受信して取得する。
予約受付手段１９１は、利用者端末２の操作に応じ、利用者端末２から送信された予約情報を受信する。
例えば、サーバ１は、予約システムＡにおいて運営されるバスＡの第１路線、予約システムＢにおいて運営されるバスＢの第２路線、予約システムＣにおいて運営されるバスＣの第３路線からなる乗継ルートや座席の予約を受け付けた場合、各予約システムとの連携を行うことなく、事前記憶した各予約システムの管理情報に基づいて、予約を実行する。
すなわち、本高速バスシステムによれば、サーバ１は、自らが路線や座席の予約を行うことができるため、座席予約に関する予約連携に伴う問題の発生を未然に防ぐことができる。
図２６や既述にて示すように、他の実施形態では、路線や座席の予約に必要な管理情報をサーバ１で事前に取得（事前記憶）することにより、サーバ１だけで予約を実行できるようにした。
サーバ１は、各予約システム（予約サーバ）と、通信可能に接続されており、各予約システムに記憶されている管理情報（座席マップを特定可能な座席情報を含む）を各予約システムから受信して取得する。
予約受付手段１９１は、利用者端末２の操作に応じ、利用者端末２から送信された予約情報を受信する。
例えば、サーバ１は、予約システムＡにおいて運営されるバスＡの第１路線、予約システムＢにおいて運営されるバスＢの第２路線、予約システムＣにおいて運営されるバスＣの第３路線からなる乗継ルートや座席の予約を受け付けた場合、各予約システムとの連携を行うことなく、事前記憶した各予約システムの管理情報に基づいて、予約を実行する。
すなわち、本高速バスシステムによれば、サーバ１は、自らが路線や座席の予約を行うことができるため、座席予約に関する予約連携に伴う問題の発生を未然に防ぐことができる。
【0102】
なお、各予約サーバは、上述したサーバ１と同様の構成を備えている（図示省略）。
すなわち、予約サーバは、管理情報記憶手段１９０に相当する手段が、自システム管理下の路線の予約に必要な情報を記憶しており、予約受付手段１９１に相当する手段が、自システム管理下の路線の予約を受け付け、予約手段１９２に相当する手段が前記受け付けた路線を予約でき、座席予約受付手段１９３に相当する手段が座席の予約を受け付け、座席予約手段１９４に相当する手段が前記受け付けた座席を予約することができる。
これにより、予約サーバは、自システムが管理する路線や座席の予約を実行できる構成を従来から備えている。
すなわち、予約サーバは、管理情報記憶手段１９０に相当する手段が、自システム管理下の路線の予約に必要な情報を記憶しており、予約受付手段１９１に相当する手段が、自システム管理下の路線の予約を受け付け、予約手段１９２に相当する手段が前記受け付けた路線を予約でき、座席予約受付手段１９３に相当する手段が座席の予約を受け付け、座席予約手段１９４に相当する手段が前記受け付けた座席を予約することができる。
これにより、予約サーバは、自システムが管理する路線や座席の予約を実行できる構成を従来から備えている。
【0103】
（共同運行路線の座席の管理・予約）
「共同運行路線」は、複数のバス会社（運営者）が共同運行する路線のことをいう。
共同運行路線は、つまりは、運営者Ａ（第１運営者）及び運営者Ｂ（第２運営者）を含む複数の運営者が共同して１台の高速バスを運行する路線のことをいう。
この場合、例えば、運営者Ａは、高速バスの前方半分の座席（前部座席）を管理し、運営者Ｂは、同じ高速バスの後方半分の座席（後部座席）を管理する、という運用が想定される。
つまり、この場合、運営者Ａが運営する予約システムＡにおいて前部座席の予約（販売）を担い、運営者Ｂが運営する予約システムＢにおいて後部座席の予約（販売）を担うことになる。
このため、他の実施形態において、共同運行路線の座席の管理・予約は、サーバ１で一括実行するのではなく、各運営者に割り振られた座席の予約を、対応する各予約システムで実行するものとし、サーバ１では各運営者（各予約システム）がどの座席を販売するか（予約を受け付けるか）を判断可能な座席情報を管理・共有することを基本機能として提供することとした。
本高速バスシステムは、本機能を備えることで、従来各予約システムが個別・人為的に行っていた座席の管理や予約の円滑化を図るものである。
また、本高速バスシステムは、本機能を備えることで、第三運営者の立場で座席の予約を担うことができる機能も提供できるようにした。
言い換えると、他の実施形態に係る機能は、あくまで共同運行路線における「座席」の管理や予約であり、「共同運行路線」の管理や予約は含まれない。これらの機能は、各予約システムにより個別に行わせればよい。
「共同運行路線」は、複数のバス会社（運営者）が共同運行する路線のことをいう。
共同運行路線は、つまりは、運営者Ａ（第１運営者）及び運営者Ｂ（第２運営者）を含む複数の運営者が共同して１台の高速バスを運行する路線のことをいう。
この場合、例えば、運営者Ａは、高速バスの前方半分の座席（前部座席）を管理し、運営者Ｂは、同じ高速バスの後方半分の座席（後部座席）を管理する、という運用が想定される。
つまり、この場合、運営者Ａが運営する予約システムＡにおいて前部座席の予約（販売）を担い、運営者Ｂが運営する予約システムＢにおいて後部座席の予約（販売）を担うことになる。
このため、他の実施形態において、共同運行路線の座席の管理・予約は、サーバ１で一括実行するのではなく、各運営者に割り振られた座席の予約を、対応する各予約システムで実行するものとし、サーバ１では各運営者（各予約システム）がどの座席を販売するか（予約を受け付けるか）を判断可能な座席情報を管理・共有することを基本機能として提供することとした。
本高速バスシステムは、本機能を備えることで、従来各予約システムが個別・人為的に行っていた座席の管理や予約の円滑化を図るものである。
また、本高速バスシステムは、本機能を備えることで、第三運営者の立場で座席の予約を担うことができる機能も提供できるようにした。
言い換えると、他の実施形態に係る機能は、あくまで共同運行路線における「座席」の管理や予約であり、「共同運行路線」の管理や予約は含まれない。これらの機能は、各予約システムにより個別に行わせればよい。
【0104】
（共同運行路線の座席管理）
上述のように、共同運行路線で運行される高速バスの座席は、複数の運営者によってそれぞれ管理されることから、各予約システムで、座席の予約に必要な情報を管理（記憶）している。
このため、サーバ１は、管理情報記憶手段１９０が、予約システムが管理（記憶）している座席の予約に必要な情報（座席情報）を記憶し、特定情報記憶手段１９５が、特定の運営者が管理している座席であることを示す特定情報を、当該座席を示す情報に対応付けて記憶するようにした。
具体的には、特定情報記憶手段１９５は、運営者Ａ（第１運営者）の販売座席であることを示す運営者Ａ情報を座席番号に対応付けて記憶し、運営者Ｂ（第２運営者）の販売座席であることを示す運営者Ｂ情報を座席番号に対応付けて記憶する。
これにより、サーバ１において、各運営者（各予約システム）が、どの座席を販売（予約）可能かを識別できる。
具体的には、座席予約制御手段１９６は、座席情報に特定情報が設定されている座席（設定：対応付けて記憶されていることをいう）については、サーバ１が備える予約手段１９２を実行不能に制御し、予約システムにおける予約を許容するようにした。
より具体的には、ある座席の座席番号に運営者Ａ情報が設定されている場合、サーバ１や予約システムＢにおいて、その座席の販売（予約）を行えず、予約システムＡにおいて販売（予約）を行えるようにした。
また、ある座席の座席番号に運営者Ｂ情報が設定されている場合、サーバ１や予約システムＡにおいて、その座席の販売（予約）を行えず、予約システムＢにおいて販売（予約）を行えるようにした。
なお、上述は、共同運営者が２者の場合だが、３者以上でも適用できる。例えば、共同運営者が３者の場合は、さらに、予約システムＣが管理（記憶）している座席情報を取得し、当該座席情報に運営者Ｃ情報を対応付けて記憶すればよい。
上述のように、共同運行路線で運行される高速バスの座席は、複数の運営者によってそれぞれ管理されることから、各予約システムで、座席の予約に必要な情報を管理（記憶）している。
このため、サーバ１は、管理情報記憶手段１９０が、予約システムが管理（記憶）している座席の予約に必要な情報（座席情報）を記憶し、特定情報記憶手段１９５が、特定の運営者が管理している座席であることを示す特定情報を、当該座席を示す情報に対応付けて記憶するようにした。
具体的には、特定情報記憶手段１９５は、運営者Ａ（第１運営者）の販売座席であることを示す運営者Ａ情報を座席番号に対応付けて記憶し、運営者Ｂ（第２運営者）の販売座席であることを示す運営者Ｂ情報を座席番号に対応付けて記憶する。
これにより、サーバ１において、各運営者（各予約システム）が、どの座席を販売（予約）可能かを識別できる。
具体的には、座席予約制御手段１９６は、座席情報に特定情報が設定されている座席（設定：対応付けて記憶されていることをいう）については、サーバ１が備える予約手段１９２を実行不能に制御し、予約システムにおける予約を許容するようにした。
より具体的には、ある座席の座席番号に運営者Ａ情報が設定されている場合、サーバ１や予約システムＢにおいて、その座席の販売（予約）を行えず、予約システムＡにおいて販売（予約）を行えるようにした。
また、ある座席の座席番号に運営者Ｂ情報が設定されている場合、サーバ１や予約システムＡにおいて、その座席の販売（予約）を行えず、予約システムＢにおいて販売（予約）を行えるようにした。
なお、上述は、共同運営者が２者の場合だが、３者以上でも適用できる。例えば、共同運営者が３者の場合は、さらに、予約システムＣが管理（記憶）している座席情報を取得し、当該座席情報に運営者Ｃ情報を対応付けて記憶すればよい。
【0105】
（共同運行路線における座席管理の詳細）
共同運行路線の座席管理の詳細について説明する。
図２７～図３０は、共同運営者（二者）の販売座席の管理や共同運営者に第三運営者を追加する処理（Ａ）を示す図である。
共同運行路線の座席管理の詳細について説明する。
図２７～図３０は、共同運営者（二者）の販売座席の管理や共同運営者に第三運営者を追加する処理（Ａ）を示す図である。
【0106】
図２７は、販売前の座席情報の取得（Ａ１）を示す図である。
図２７に示すように、座席の販売前（予約受付前）は、サーバ１は、予め、各予約システム（各運営者）、すなわち、各予約サーバにおいて管理している座席情報を取得し記憶する（管理情報記憶手段１９０）。
「座席情報」は、座席の予約に必要な情報であり、例えば、座席番号、予約済／空席を示す空席情報、どの運営者（予約システム）の販売座席かを示す特定情報などが含まれる。
本例では、座席番号Ａ～Ｄ・１～４が運営者Ａの販売座席であることを示す座席情報が予約システムＡ（予約サーバＡ）において記憶されており、座席番号Ａ～Ｄ・５～１１が運営者Ｂの販売座席であることを示す座席情報が予約システムＢ（予約サーバＢ）において記憶されている。
また、サーバ１は、各予約サーバとインターネット等を介して通信可能に接続されており、当該通信を介して座席情報を取得することができる。
このため、サーバ１は、特定情報記憶手段１９５が、各予約サーバから取得（受信）した座席情報を記憶する。
具体的には、座席番号Ａ～Ｄ・１～４には、予約システムＡ（運営者Ａ）の販売座席であることを示す特定情報（運営者Ａ情報）を対応付けて記憶し、座席番号Ａ～Ｄ・５～１１には、予約システムＢ（運営者Ｂ）の販売座席であることを示す特定情報（運営者Ｂ情報）を対応付けて記憶する。
なお、座席販売する運営者情報の代わりに、又は、共に、座席販売しない運営者情報を用いても良く、座席販売する運営者情報又は座席販売しない運営者情報に、「販売可」情報や「販売不可」情報を対応付けて記憶してもよい。
座席情報には、予約済みか空席かを示す空席情報が含まれる。
このため、サーバ１において、空席情報は座席番号に対応付けて記憶する。
これにより、サーバ１は、各販売座席が、予約済みか空席かを判定することができる。
図２７に示すように、座席の販売前（予約受付前）は、サーバ１は、予め、各予約システム（各運営者）、すなわち、各予約サーバにおいて管理している座席情報を取得し記憶する（管理情報記憶手段１９０）。
「座席情報」は、座席の予約に必要な情報であり、例えば、座席番号、予約済／空席を示す空席情報、どの運営者（予約システム）の販売座席かを示す特定情報などが含まれる。
本例では、座席番号Ａ～Ｄ・１～４が運営者Ａの販売座席であることを示す座席情報が予約システムＡ（予約サーバＡ）において記憶されており、座席番号Ａ～Ｄ・５～１１が運営者Ｂの販売座席であることを示す座席情報が予約システムＢ（予約サーバＢ）において記憶されている。
また、サーバ１は、各予約サーバとインターネット等を介して通信可能に接続されており、当該通信を介して座席情報を取得することができる。
このため、サーバ１は、特定情報記憶手段１９５が、各予約サーバから取得（受信）した座席情報を記憶する。
具体的には、座席番号Ａ～Ｄ・１～４には、予約システムＡ（運営者Ａ）の販売座席であることを示す特定情報（運営者Ａ情報）を対応付けて記憶し、座席番号Ａ～Ｄ・５～１１には、予約システムＢ（運営者Ｂ）の販売座席であることを示す特定情報（運営者Ｂ情報）を対応付けて記憶する。
なお、座席販売する運営者情報の代わりに、又は、共に、座席販売しない運営者情報を用いても良く、座席販売する運営者情報又は座席販売しない運営者情報に、「販売可」情報や「販売不可」情報を対応付けて記憶してもよい。
座席情報には、予約済みか空席かを示す空席情報が含まれる。
このため、サーバ１において、空席情報は座席番号に対応付けて記憶する。
これにより、サーバ１は、各販売座席が、予約済みか空席かを判定することができる。
【0107】
サーバ１は、このような座席情報に基づいて運営者毎（予約システム毎）に座席マップを生成することができる。
座席マップは、どの運営者の販売座席であるか、予約済みか空席か、を、座席番号及び座席位置がわかるように視覚化した情報である（図２７～図３４）。
各運営者は、それぞれ管理端末を有しており、サーバ１は、当該管理端末に各予約システムで予約可能な座席（販売座席）をマップ表示させることができる。
例えば、各運営者に対しそれぞれ固有のアカウントを設け、サーバ１は、予め設定したアカウント情報（ユーザＩＤ等）の入力が確認（認証）できると、その運営者の座席マップを管理端末上にＷｅｂ表示させる。
管理端末は、サーバ１の管理端末や、サーバ１とＷｅｂ接続可能な予約システムの管理端末を想定している。
座席マップは、どの運営者の販売座席であるか、予約済みか空席か、を、座席番号及び座席位置がわかるように視覚化した情報である（図２７～図３４）。
各運営者は、それぞれ管理端末を有しており、サーバ１は、当該管理端末に各予約システムで予約可能な座席（販売座席）をマップ表示させることができる。
例えば、各運営者に対しそれぞれ固有のアカウントを設け、サーバ１は、予め設定したアカウント情報（ユーザＩＤ等）の入力が確認（認証）できると、その運営者の座席マップを管理端末上にＷｅｂ表示させる。
管理端末は、サーバ１の管理端末や、サーバ１とＷｅｂ接続可能な予約システムの管理端末を想定している。
【0108】
図２７（ａ）は、予約システムＡの管理端末に表示される座席マップであり、図２７（ｂ）は、予約システムＢの管理端末に表示される座席マップである。
図２７（ｃ）は、サーバ１の管理端末（サーバ端末ともいう）に表示される座席マップである。この座席マップは、各運営者の販売座席や空席情報を識別可能に表示することができることから「全運営者座席マップ」ともいう。
便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
図２７（ａ）に示す座席マップは、予約システムＡの販売座席（運営者Ａにおいて販売可能な座席）と非販売座席（運営者Ａにおいて販売不可能な座席）とが区別して表示される。便宜上、販売座席は「薄墨」で図示し、非販売座席は「×」で図示している。
図２７（ａ）に示す座席マップは、基本的には、予約システムＡの管理端末で閲覧することを想定している。
図２７（ｂ）に示す座席マップは、予約システムＢの販売座席（運営者Ｂにおいて販売可能な座席）と非販売座席（運営者Ｂにおいて販売不可能な座席）とが区別して表示される。便宜上、販売座席は「網掛け」で図示し、非販売座席は「×」で図示している。
図２７（ｂ）に示す座席マップは、基本的には、予約システムＢの管理端末で閲覧することを想定している。
図２７（ｃ）に示す全運営者座席マップは、予約システムＡにおける販売座席（予約システムＡにおいて販売可能な座席：薄墨）と予約システムＢにおける販売座席（予約システムＢにおいて販売可能な座席：網掛け）とが区別して表示されている。
全運営者座席マップは、サーバ端末に表示したものをサーバ１の管理者（サーバ管理者ともいう）が閲覧することを想定しているが、これに限らず、各運営者（運営者Ａや運営者Ｂ）が各予約システムの管理端末にＷｅｂ表示してもよい。
図２７（ｃ）は、サーバ１の管理端末（サーバ端末ともいう）に表示される座席マップである。この座席マップは、各運営者の販売座席や空席情報を識別可能に表示することができることから「全運営者座席マップ」ともいう。
便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
図２７（ａ）に示す座席マップは、予約システムＡの販売座席（運営者Ａにおいて販売可能な座席）と非販売座席（運営者Ａにおいて販売不可能な座席）とが区別して表示される。便宜上、販売座席は「薄墨」で図示し、非販売座席は「×」で図示している。
図２７（ａ）に示す座席マップは、基本的には、予約システムＡの管理端末で閲覧することを想定している。
図２７（ｂ）に示す座席マップは、予約システムＢの販売座席（運営者Ｂにおいて販売可能な座席）と非販売座席（運営者Ｂにおいて販売不可能な座席）とが区別して表示される。便宜上、販売座席は「網掛け」で図示し、非販売座席は「×」で図示している。
図２７（ｂ）に示す座席マップは、基本的には、予約システムＢの管理端末で閲覧することを想定している。
図２７（ｃ）に示す全運営者座席マップは、予約システムＡにおける販売座席（予約システムＡにおいて販売可能な座席：薄墨）と予約システムＢにおける販売座席（予約システムＢにおいて販売可能な座席：網掛け）とが区別して表示されている。
全運営者座席マップは、サーバ端末に表示したものをサーバ１の管理者（サーバ管理者ともいう）が閲覧することを想定しているが、これに限らず、各運営者（運営者Ａや運営者Ｂ）が各予約システムの管理端末にＷｅｂ表示してもよい。
【0109】
これらの座席マップによれば、運営者Ａは、Ａ～Ｄ・１～４の座席が販売座席であり、Ａ～Ｄ・５～１１の座席が非販売座席であることを認識でき（図２７（ａ））、さらに、当該非販売座席が運営者Ｂの販売座席であることを認識することができる（図２７（ｃ））。
また、運営者Ｂは、Ａ～Ｄ・５～１１の座席が販売座席であり、Ａ～Ｄ・１～４の座席が非販売座席であることを認識でき（図２７（ｂ））、さら、当該非販売座席が運営者Ａの販売座席であることを認識することができる（図２７（ｃ））。
また、サーバ管理者は、Ａ～Ｄ・１～４は予約システムＡの販売座席で、Ａ～Ｄ・５～１１は予約システムＢの販売座席であることを認識することができる（図２７（ｃ））。
また、運営者Ｂは、Ａ～Ｄ・５～１１の座席が販売座席であり、Ａ～Ｄ・１～４の座席が非販売座席であることを認識でき（図２７（ｂ））、さら、当該非販売座席が運営者Ａの販売座席であることを認識することができる（図２７（ｃ））。
また、サーバ管理者は、Ａ～Ｄ・１～４は予約システムＡの販売座席で、Ａ～Ｄ・５～１１は予約システムＢの販売座席であることを認識することができる（図２７（ｃ））。
【0110】
図２７に示すように、予約システムＡと予約システムＢとで販売座席を配分している場合、サーバ１側で予約を受け付けたり予約を実行することはできない。
このことから、サーバ１の座席予約制御手段１９６は、特定情報が設定された座席に対する座席予約受付手段１９３や座席予約手段１９４というサーバ１の機能を実行不能に制御する。
つまり、図２７（ｃ）に示す座席マップの状態は、サーバ１（本高速バスシステム）において１座席も座席の販売（予約）が実行できない状態を示している。
他方、図２７（ｃ）は、予約システムＡにおいてＡ～Ｄ・１～４の座席の予約が実行でき、予約システムＢにおいてＡ～Ｄ・５～１１の座席の予約が実行できる状態を示している。
このことから、サーバ１の座席予約制御手段１９６は、特定情報が設定された座席に対する座席予約受付手段１９３や座席予約手段１９４というサーバ１の機能を実行不能に制御する。
つまり、図２７（ｃ）に示す座席マップの状態は、サーバ１（本高速バスシステム）において１座席も座席の販売（予約）が実行できない状態を示している。
他方、図２７（ｃ）は、予約システムＡにおいてＡ～Ｄ・１～４の座席の予約が実行でき、予約システムＢにおいてＡ～Ｄ・５～１１の座席の予約が実行できる状態を示している。
【0111】
ただし、本実施形態において、サーバ管理者は、運営者（第三運営者ともいう）を兼ねることができるようにしている。
具体的には、各運営者の同意を得ていることを前提として、サーバ管理者を第三運営者として追加することが可能であり、そうすることで、サーバ１において、第三運営者でも座席の予約を受け付けて実行できるようにしている。
以下、サーバ端末の管理者（第三運営者）を追加する方法について説明する。
具体的には、各運営者の同意を得ていることを前提として、サーバ管理者を第三運営者として追加することが可能であり、そうすることで、サーバ１において、第三運営者でも座席の予約を受け付けて実行できるようにしている。
以下、サーバ端末の管理者（第三運営者）を追加する方法について説明する。
【0112】
図２８は、販売前の座席情報の設定（Ａ２）を示す図である。
具体的には、座席情報の取得（Ａ１）後に、第三運営者の販売座席を追加する場合の設定方法を示す図である。
図２８（ａ）は、予約システムＡの管理端末に表示される座席マップであり、図２８（ｂ）は、予約システムＢの管理端末に表示される座席マップであり、図２８（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
より具体的には、サーバ１は、販売座席が予約システムＡと予約システムＢとに割り振られている状態において、予約システムの販売座席の座席情報に「販売不可」情報を設定するか、第三運営者の座席情報であることを示す情報を設定することで、当該販売座席を当該予約システムから第三運営者に移動する処理を実行する。
例えば、管理端末の操作により、サーバ１は、記憶している予約システムＡの販売座席の座席番号：Ａ～Ｄ・３～４（破線部）に、「販売不可」情報又は「サーバ管理者情報」を対応付けて記憶する。
これにより、サーバ１は、Ａ～Ｄ・３～４の座席を、サーバ管理者の販売座席として追加（設定）する処理を実行すると共に、予約システムＡ（予約サーバＡ）に対し、Ａ～Ｄ・３～４の座席が予約システムＡ（運営者Ａ）の販売座席ではない旨の情報を送信する。
同様に、管理端末の操作により、サーバ１は、記憶している予約システムＢの販売座席の座席番号：Ａ～Ｄ・５～６（破線部）に、「販売不可」情報又は「サーバ管理者情報」を対応付けて記憶する。
これにより、サーバ１は、Ａ～Ｄ・５～６の座席を、サーバ管理者の販売座席として追加（設定）する処理を実行すると共に、予約システムＢ（予約サーバＢ）に対し、Ａ～Ｄ・５～６の座席が予約システムＢ（運営者Ｂ）の販売座席ではない旨の情報を送信する。
具体的には、座席情報の取得（Ａ１）後に、第三運営者の販売座席を追加する場合の設定方法を示す図である。
図２８（ａ）は、予約システムＡの管理端末に表示される座席マップであり、図２８（ｂ）は、予約システムＢの管理端末に表示される座席マップであり、図２８（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
より具体的には、サーバ１は、販売座席が予約システムＡと予約システムＢとに割り振られている状態において、予約システムの販売座席の座席情報に「販売不可」情報を設定するか、第三運営者の座席情報であることを示す情報を設定することで、当該販売座席を当該予約システムから第三運営者に移動する処理を実行する。
例えば、管理端末の操作により、サーバ１は、記憶している予約システムＡの販売座席の座席番号：Ａ～Ｄ・３～４（破線部）に、「販売不可」情報又は「サーバ管理者情報」を対応付けて記憶する。
これにより、サーバ１は、Ａ～Ｄ・３～４の座席を、サーバ管理者の販売座席として追加（設定）する処理を実行すると共に、予約システムＡ（予約サーバＡ）に対し、Ａ～Ｄ・３～４の座席が予約システムＡ（運営者Ａ）の販売座席ではない旨の情報を送信する。
同様に、管理端末の操作により、サーバ１は、記憶している予約システムＢの販売座席の座席番号：Ａ～Ｄ・５～６（破線部）に、「販売不可」情報又は「サーバ管理者情報」を対応付けて記憶する。
これにより、サーバ１は、Ａ～Ｄ・５～６の座席を、サーバ管理者の販売座席として追加（設定）する処理を実行すると共に、予約システムＢ（予約サーバＢ）に対し、Ａ～Ｄ・５～６の座席が予約システムＢ（運営者Ｂ）の販売座席ではない旨の情報を送信する。
【0113】
図２９は、販売（予約）開始後の座席情報（Ａ３）を示す図である。
具体的には、図２９は、図２８に示す設定（操作）を行った後の座席マップを示している。
図２９（ａ）は、予約システムＡの管理端末に表示された座席マップであり、図２９（ｂ）は、予約システムＢの管理端末に表示された座席マップであり、図２９（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
全運営者座席マップの「空白」座席は販売座席を示す。
図２９（ａ）に示すように、Ａ～Ｄ・３～４は非販売座席（×）として表示され、図２９（ｃ）に示すように、Ａ～Ｄ・３～４は販売座席（空白）として表示されている。
つまり、図２９（ａ）、（ｃ）は、Ａ～Ｄ・３～４の販売座席が、予約システムＡ（運営者Ａ）からサーバ管理者（第三運営者）に移動したことを示している。
図２９（ｂ）に示すように、Ａ～Ｄ・５～６は非販売座席（×）として表示され、図２９（ｃ）に示すように、Ａ～Ｄ・５～６は販売座席（空白）として表示されている。
つまり、図２９（ｂ）、（ｃ）は、Ａ～Ｄ・５～６の販売座席が、予約システムＢ（運営者Ｂ）からサーバ管理者（第三運営者）に移動したことを示している。
このため、図２９に示す状態では、サーバ管理者（第三管理者）は、サーバ１を介して、Ａ～Ｄ・３～６の座席の予約（販売）を受け付けたり実行することができる。
すなわち、特定情報記憶手段１９５は、第三運営者（サーバ管理者）が管理する座席であることを示す特定情報を、当該座席を示す情報に対応付けて記憶し、座席予約制御手段１９６は、前記特定情報が対応付けられている座席に対し、座席予約手段１９４を実行可能に制御する。
具体的には、図２９は、図２８に示す設定（操作）を行った後の座席マップを示している。
図２９（ａ）は、予約システムＡの管理端末に表示された座席マップであり、図２９（ｂ）は、予約システムＢの管理端末に表示された座席マップであり、図２９（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
全運営者座席マップの「空白」座席は販売座席を示す。
図２９（ａ）に示すように、Ａ～Ｄ・３～４は非販売座席（×）として表示され、図２９（ｃ）に示すように、Ａ～Ｄ・３～４は販売座席（空白）として表示されている。
つまり、図２９（ａ）、（ｃ）は、Ａ～Ｄ・３～４の販売座席が、予約システムＡ（運営者Ａ）からサーバ管理者（第三運営者）に移動したことを示している。
図２９（ｂ）に示すように、Ａ～Ｄ・５～６は非販売座席（×）として表示され、図２９（ｃ）に示すように、Ａ～Ｄ・５～６は販売座席（空白）として表示されている。
つまり、図２９（ｂ）、（ｃ）は、Ａ～Ｄ・５～６の販売座席が、予約システムＢ（運営者Ｂ）からサーバ管理者（第三運営者）に移動したことを示している。
このため、図２９に示す状態では、サーバ管理者（第三管理者）は、サーバ１を介して、Ａ～Ｄ・３～６の座席の予約（販売）を受け付けたり実行することができる。
すなわち、特定情報記憶手段１９５は、第三運営者（サーバ管理者）が管理する座席であることを示す特定情報を、当該座席を示す情報に対応付けて記憶し、座席予約制御手段１９６は、前記特定情報が対応付けられている座席に対し、座席予約手段１９４を実行可能に制御する。
【0114】
図３０は、販売（予約）開始後の販売座席の追加・削除（Ａ４）を示す図である。
具体的には、図２９に示す販売座席の移動が実行されたの座席マップを示している。
図３０（ａ）は、予約システムＡの管理端末に表示された座席マップであり、図３０（ｂ）は、予約システムＢの管理端末に表示された座席マップであり、図３０（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
本高速バスシステムにおいて、座席の販売開始後は、空席に限り販売座席を追加・削除することができる。
「空席」に限定したのは、共同運行において、空席があっても予約することはできない、という従来の課題を解決するためである。
最新の「空席情報」は、予約システムで管理（記憶）しているため、サーバ１は、必要に応じ、予約システムから「空席情報」を送信させる。
サーバ１は、予約システムから送信させた「空席情報」を受信すると、当該「空席情報」を座席番号に対応付けて記憶する。
これにより、サーバ１において販売座席が、空席か予約済かといった空席状態を把握することができる。
例えば、図３０（ａ），（ｃ）は、Ｃ～Ｄ・１～２は予約システムＡの販売座席であり（薄墨）、かつ、空席であることを示している。
また、図３０（ｂ），（ｃ）は、Ｄ・５～６は予約システムＢの販売座席であり（網掛け）、かつ、空席であることを示している。
具体的には、図２９に示す販売座席の移動が実行されたの座席マップを示している。
図３０（ａ）は、予約システムＡの管理端末に表示された座席マップであり、図３０（ｂ）は、予約システムＢの管理端末に表示された座席マップであり、図３０（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける情報の送受信を模式的に示している。
本高速バスシステムにおいて、座席の販売開始後は、空席に限り販売座席を追加・削除することができる。
「空席」に限定したのは、共同運行において、空席があっても予約することはできない、という従来の課題を解決するためである。
最新の「空席情報」は、予約システムで管理（記憶）しているため、サーバ１は、必要に応じ、予約システムから「空席情報」を送信させる。
サーバ１は、予約システムから送信させた「空席情報」を受信すると、当該「空席情報」を座席番号に対応付けて記憶する。
これにより、サーバ１において販売座席が、空席か予約済かといった空席状態を把握することができる。
例えば、図３０（ａ），（ｃ）は、Ｃ～Ｄ・１～２は予約システムＡの販売座席であり（薄墨）、かつ、空席であることを示している。
また、図３０（ｂ），（ｃ）は、Ｄ・５～６は予約システムＢの販売座席であり（網掛け）、かつ、空席であることを示している。
【0115】
ここで、管理端末の操作に応じ、予約システムの販売座席（空席）を非販売座席に変更すると共に、サーバ管理者の対応座席を非販売座席から販売座席に変更することができる。
具体的には、管理端末の操作に応じ、サーバ１は、予約システムの販売座席（空席）の座席番号に対しサーバ管理者の販売座席であることを示す情報を設定する。
これにより、サーバ１は、予約サーバに対し、対応する座席がサーバ管理者の販売座席であることを示す情報を送信する。
例えば、図３０（ａ），（ｃ）に示すように、サーバ１において、予約システムＡの販売座席の座席番号：Ｄ・１～２に対しサーバ管理者の販売座席であることを示す情報を対応付けて記憶すると、サーバ１は、Ｄ・１～２の座席がサーバ管理者の販売座席であることを認識可能になり、予約サーバＡにおいても、Ｄ・１～２の座席が予約システムＡの販売座席でないことを認識可能になる。
これにより、サーバ管理者の販売座席としてＤ・１～２を追加することができる。
すなわち、サーバ１の変更手段１９７は、運営者Ａ（一の運営者）が管理している座席を示す情報に所定の特定情報（他の運営者が管理している座席であることを示す情報）を対応付けて記憶させることで、前記座席を第三運営者（他の運営者）が管理する座席に変更することができる。
この結果、サーバ管理者は、サーバ１を介してＤ・１～２の座席の予約を受け付けたり実行することが可能になる。
具体的には、管理端末の操作に応じ、サーバ１は、予約システムの販売座席（空席）の座席番号に対しサーバ管理者の販売座席であることを示す情報を設定する。
これにより、サーバ１は、予約サーバに対し、対応する座席がサーバ管理者の販売座席であることを示す情報を送信する。
例えば、図３０（ａ），（ｃ）に示すように、サーバ１において、予約システムＡの販売座席の座席番号：Ｄ・１～２に対しサーバ管理者の販売座席であることを示す情報を対応付けて記憶すると、サーバ１は、Ｄ・１～２の座席がサーバ管理者の販売座席であることを認識可能になり、予約サーバＡにおいても、Ｄ・１～２の座席が予約システムＡの販売座席でないことを認識可能になる。
これにより、サーバ管理者の販売座席としてＤ・１～２を追加することができる。
すなわち、サーバ１の変更手段１９７は、運営者Ａ（一の運営者）が管理している座席を示す情報に所定の特定情報（他の運営者が管理している座席であることを示す情報）を対応付けて記憶させることで、前記座席を第三運営者（他の運営者）が管理する座席に変更することができる。
この結果、サーバ管理者は、サーバ１を介してＤ・１～２の座席の予約を受け付けたり実行することが可能になる。
【0116】
また、管理端末の操作に応じ、サーバ管理者の販売座席（空席）を非販売座席に変更すると共に、予約システムの対応座席を非販売座席から販売座席に変更することができる。
具体的には、管理端末の操作に応じ、サーバ１は、サーバ管理者の販売座席（空席）の座席番号に対し予約システムの販売座席であることを示す情報を設定する。
これにより、サーバ１は、予約サーバに対し、対応する座席が予約システムの販売座席であることを示す情報又はを送信する。
例えば、図３０（ｂ），（ｃ）に示すように、サーバ１において、サーバ管理者の販売座席の座席番号：Ｄ・５～６に対し予約システムＢの販売座席であることを示す情報を対応付けて記憶すると、サーバ１は、Ｄ・５～６の座席がサーバ管理者の販売座席でないことを認識可能になり、予約サーバＢにおいても、Ｄ・５～６の座席が予約システムＢの販売座席であることを認識可能になる。
これにより、サーバ管理者の販売座席からＤ・５～６を削除することができる。
すなわち、サーバ１の変更手段１９７は、一の運営者が管理している座席を示す情報に所定の特定情報を対応付けて記憶させることで、前記座席を他の運営者が管理する座席に変更することができる。
この結果、サーバ管理者は、サーバ１を介して、Ｄ・５～６の座席の予約を受け付けたり予約を実行することが不可能になる。
このようにすることで、ある運営者の管理下では販売（予約）されずに空席のまま残っていた座席を、他の運営者（第３運営者を含む）により販売できることができる。
このため、共同運行において空席があるのに予約できないという、従来の課題を解決することができる。
具体的には、管理端末の操作に応じ、サーバ１は、サーバ管理者の販売座席（空席）の座席番号に対し予約システムの販売座席であることを示す情報を設定する。
これにより、サーバ１は、予約サーバに対し、対応する座席が予約システムの販売座席であることを示す情報又はを送信する。
例えば、図３０（ｂ），（ｃ）に示すように、サーバ１において、サーバ管理者の販売座席の座席番号：Ｄ・５～６に対し予約システムＢの販売座席であることを示す情報を対応付けて記憶すると、サーバ１は、Ｄ・５～６の座席がサーバ管理者の販売座席でないことを認識可能になり、予約サーバＢにおいても、Ｄ・５～６の座席が予約システムＢの販売座席であることを認識可能になる。
これにより、サーバ管理者の販売座席からＤ・５～６を削除することができる。
すなわち、サーバ１の変更手段１９７は、一の運営者が管理している座席を示す情報に所定の特定情報を対応付けて記憶させることで、前記座席を他の運営者が管理する座席に変更することができる。
この結果、サーバ管理者は、サーバ１を介して、Ｄ・５～６の座席の予約を受け付けたり予約を実行することが不可能になる。
このようにすることで、ある運営者の管理下では販売（予約）されずに空席のまま残っていた座席を、他の運営者（第３運営者を含む）により販売できることができる。
このため、共同運行において空席があるのに予約できないという、従来の課題を解決することができる。
【0117】
図３１～３４は、共同運営者間の販売座席の移動（Ｂ）を示す図である。
図３１は、空席情報の取得（Ｂ１）を示す図である。
図３１（ａ）は、予約システムＡの管理端末に表示された座席マップであり、図３１（ｂ）は、予約システムＢの管理端末に表示された座席マップであり、図３１（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける空席情報の送受信を模式的に示している。
前述のとおり、「空席情報」は、予約システムで管理（記憶）しているため、サーバ１は、必要に応じ、予約システムから「空席情報」を取得（受信）し、座席番号に対応付けて記憶することができる（図３０と同様）。
これにより、サーバ１は、販売座席について、空席か予約済かといった空席状態を把握することができる。
サーバ１は、空席情報だけを取得すればよく、予約情報の取得は不要である。
例えば、図３１（ａ），（ｃ）に示すように、Ｃ～Ｄ・１～４の座席は予約システムＡの販売座席で空席であることを示す空席情報を予約システムＡから取得し、図３１（ｂ），（ｃ）に示すように、Ａ～Ｄ・５～６及び９～１１の座席は予約システムＢの販売座席で空席（であることを示す空席情報を予約システムＢから取得する。
これにより、予約システムＢの管理者は、管理端末に図３１（ｂ）や図３１（ｃ）に示す座席マップを表示させることで、Ｃ～Ｄ・１～２の座席が予約システムＡの販売座席で空席であることを把握することができる。
「空席情報」を取得するのは、共同運行において、空席があっても予約することはできない、という従来の課題を解決するためである。
図３１は、空席情報の取得（Ｂ１）を示す図である。
図３１（ａ）は、予約システムＡの管理端末に表示された座席マップであり、図３１（ｂ）は、予約システムＢの管理端末に表示された座席マップであり、図３１（ｃ）は、全運営者座席マップである。
ただし、便宜上、図中の矢印は、サーバ１と各予約サーバとにおける空席情報の送受信を模式的に示している。
前述のとおり、「空席情報」は、予約システムで管理（記憶）しているため、サーバ１は、必要に応じ、予約システムから「空席情報」を取得（受信）し、座席番号に対応付けて記憶することができる（図３０と同様）。
これにより、サーバ１は、販売座席について、空席か予約済かといった空席状態を把握することができる。
サーバ１は、空席情報だけを取得すればよく、予約情報の取得は不要である。
例えば、図３１（ａ），（ｃ）に示すように、Ｃ～Ｄ・１～４の座席は予約システムＡの販売座席で空席であることを示す空席情報を予約システムＡから取得し、図３１（ｂ），（ｃ）に示すように、Ａ～Ｄ・５～６及び９～１１の座席は予約システムＢの販売座席で空席（であることを示す空席情報を予約システムＢから取得する。
これにより、予約システムＢの管理者は、管理端末に図３１（ｂ）や図３１（ｃ）に示す座席マップを表示させることで、Ｃ～Ｄ・１～２の座席が予約システムＡの販売座席で空席であることを把握することができる。
「空席情報」を取得するのは、共同運行において、空席があっても予約することはできない、という従来の課題を解決するためである。
【0118】
図３２は、席もらいの依頼（Ｂ２）を示す図である。
図３２に示すように、管理端末を操作することで、席もらい（一の予約システムの販売座席を他の予約システムの販売座席に変更すること）の依頼を行うことができる。
図３２の中央に示す全運営者座席マップは、前述のとおり、予約システムの管理端末にＷｅｂ表示させることができる。
このため、予約システムＢの管理者は、管理端末に表示した全運営者座席マップを見てＣ～Ｄ・１～２の座席が予約システムＡの販売座席であり、かつ、空席であることを把握することができる。
そこで、一例として、予約システムＢ側から予約システムＡ側に対し、Ｃ～Ｄ・１～２の販売座席（空席）について席もらいの依頼を行う場合について説明する。
この場合、予約システムＢの管理端末において、席もらいの依頼操作を行うことができる。
これに伴い、席もらいの依頼情報（Ｃ～Ｄ・１～２の販売座席に対し席もらいを依頼する旨の情報）が、管理端末からサーバ１に対し出力される。
サーバ１は、管理端末から出力された依頼情報を入力する。これにより、サーバ１は、席もらいの依頼を受け付ける。
サーバ１は、入力した依頼情報に基づき、予約システムＢ側から予約システムＡ側に対する席もらいを受け付けたことを認識する。
サーバ１は、当該認識に基づき、入力した依頼情報を予約システムＡ（予約サーバＡ）の管理端末に出力して表示させる。
これにより、予約システムＡの管理者は、管理端末を介して依頼情報の内容（Ｃ～Ｄ・１～２の販売座席に対し席もらいの依頼）を把握することができる。
なお、図３２に示す「席もらいの依頼」に係る破線は、実質的な席もらいの依頼の流れを分かり易くするためのイメージ図であり、実際の情報処理の流れを示すものではない。「承認・却下」に係る破線も同様である。
図３２に示すように、管理端末を操作することで、席もらい（一の予約システムの販売座席を他の予約システムの販売座席に変更すること）の依頼を行うことができる。
図３２の中央に示す全運営者座席マップは、前述のとおり、予約システムの管理端末にＷｅｂ表示させることができる。
このため、予約システムＢの管理者は、管理端末に表示した全運営者座席マップを見てＣ～Ｄ・１～２の座席が予約システムＡの販売座席であり、かつ、空席であることを把握することができる。
そこで、一例として、予約システムＢ側から予約システムＡ側に対し、Ｃ～Ｄ・１～２の販売座席（空席）について席もらいの依頼を行う場合について説明する。
この場合、予約システムＢの管理端末において、席もらいの依頼操作を行うことができる。
これに伴い、席もらいの依頼情報（Ｃ～Ｄ・１～２の販売座席に対し席もらいを依頼する旨の情報）が、管理端末からサーバ１に対し出力される。
サーバ１は、管理端末から出力された依頼情報を入力する。これにより、サーバ１は、席もらいの依頼を受け付ける。
サーバ１は、入力した依頼情報に基づき、予約システムＢ側から予約システムＡ側に対する席もらいを受け付けたことを認識する。
サーバ１は、当該認識に基づき、入力した依頼情報を予約システムＡ（予約サーバＡ）の管理端末に出力して表示させる。
これにより、予約システムＡの管理者は、管理端末を介して依頼情報の内容（Ｃ～Ｄ・１～２の販売座席に対し席もらいの依頼）を把握することができる。
なお、図３２に示す「席もらいの依頼」に係る破線は、実質的な席もらいの依頼の流れを分かり易くするためのイメージ図であり、実際の情報処理の流れを示すものではない。「承認・却下」に係る破線も同様である。
【0119】
席もらいの依頼情報を見た予約システムＡの管理者は、当該依頼に対し、承認又は却下の回答を管理端末を操作して行う。この操作は、サーバ１から提供されるＷｅｂページ上で行うことができる。
例えば、「却下」の操作が行われた場合、サーバ１は、予約システムＢの管理端末に対し「却下」情報を送信する。
これにより、予約システムＢの管理者は、管理端末を介して席もらいの依頼が却下されたことを把握することができる。
他方、「承認」の操作が行われた場合、サーバ１は、席もらいを実行する。
「席もらいの実行」については、図３３を参照しながら説明する。
例えば、「却下」の操作が行われた場合、サーバ１は、予約システムＢの管理端末に対し「却下」情報を送信する。
これにより、予約システムＢの管理者は、管理端末を介して席もらいの依頼が却下されたことを把握することができる。
他方、「承認」の操作が行われた場合、サーバ１は、席もらいを実行する。
「席もらいの実行」については、図３３を参照しながら説明する。
【0120】
図３３は、席もらいの実行（Ｂ３）を示す図である。
席もらいは、具体的には、サーバ１において、Ｃ～Ｄ・１～２の座席番号に運営者Ｂ情報を対応付けて記憶する。
すなわち、サーバ１の変更手段１９７は、運営者Ａ（一の運営者）が管理している座席に対し所定の特定情報を記憶させることで、前記座席を運営者Ｂ（他の運営者）が管理する座席に変更する。
これにより、Ｃ～Ｄ・１～２の販売座席が予約システムＡから予約システムＢに移動する。つまり、席もらいが実行される。
このようにすることで、予約システムＡ（運営者Ａ）では販売（予約）されずに空席のまま残っていた座席を、予約システムＢ（運営者Ｂ）で販売（予約）できるようになる。
このため、共同運行において空席があるのに予約できないという、従来の課題を解決することができる。
席もらいは、具体的には、サーバ１において、Ｃ～Ｄ・１～２の座席番号に運営者Ｂ情報を対応付けて記憶する。
すなわち、サーバ１の変更手段１９７は、運営者Ａ（一の運営者）が管理している座席に対し所定の特定情報を記憶させることで、前記座席を運営者Ｂ（他の運営者）が管理する座席に変更する。
これにより、Ｃ～Ｄ・１～２の販売座席が予約システムＡから予約システムＢに移動する。つまり、席もらいが実行される。
このようにすることで、予約システムＡ（運営者Ａ）では販売（予約）されずに空席のまま残っていた座席を、予約システムＢ（運営者Ｂ）で販売（予約）できるようになる。
このため、共同運行において空席があるのに予約できないという、従来の課題を解決することができる。
【0121】
図３４は、席もらいの自動化（Ｂ４）を示す図である。
前述の席もらい（図３３等）は、一部手動により実行するが、図３４に示す席もらいは、所定条件が成立したことを契機に自動実行するものである。
具体的には、一の運営者（例えば運営者Ａ）の販売座席（空席）が一定数以下になり、かつ、他の運営者（例えば運営者Ｂ）の販売座席（空席）が所定数以上ある場合に、特定数の販売座席（空席）を他の運営者の予約システム（予約システムＢ）から一の運営者の予約システム（予約システムＡ）に自動的に変更（移動）する。
例えば、図３４に示すように、サーバ１は、予約システムＢの販売座席（空席）が２席（一定数以下）になったこと、及び、予約システムＡの販売座席（空席）が８席（所定数以上）あること、を判断したため、前方の４席：Ｃ～Ｄ・１～２の販売座席（空席）を選択して、予約システムＡから予約システムＢに変更するようにできる。、
具体的には、図３３に示す場合と同様に、サーバ１において、Ｃ～Ｄ・１～２の座席番号に運営者Ｂ情報を対応付けて記憶すればよい。
なお、「一定数」、「所定数」、「特定数」は任意値を設定することができ、固定値でも変動値でもよい。
例えば、移動する販売座席数は、移動元の予約システムの販売座席（空席）のｘ％（例えば３０％）でもよく、「一定数」及び「所定数」との関係に基づいて決定してもよい。
これにより、共同運行において空席があるのに予約できないという、従来の課題を、人手をかけずに効率よく解決することができる。
前述の席もらい（図３３等）は、一部手動により実行するが、図３４に示す席もらいは、所定条件が成立したことを契機に自動実行するものである。
具体的には、一の運営者（例えば運営者Ａ）の販売座席（空席）が一定数以下になり、かつ、他の運営者（例えば運営者Ｂ）の販売座席（空席）が所定数以上ある場合に、特定数の販売座席（空席）を他の運営者の予約システム（予約システムＢ）から一の運営者の予約システム（予約システムＡ）に自動的に変更（移動）する。
例えば、図３４に示すように、サーバ１は、予約システムＢの販売座席（空席）が２席（一定数以下）になったこと、及び、予約システムＡの販売座席（空席）が８席（所定数以上）あること、を判断したため、前方の４席：Ｃ～Ｄ・１～２の販売座席（空席）を選択して、予約システムＡから予約システムＢに変更するようにできる。、
具体的には、図３３に示す場合と同様に、サーバ１において、Ｃ～Ｄ・１～２の座席番号に運営者Ｂ情報を対応付けて記憶すればよい。
なお、「一定数」、「所定数」、「特定数」は任意値を設定することができ、固定値でも変動値でもよい。
例えば、移動する販売座席数は、移動元の予約システムの販売座席（空席）のｘ％（例えば３０％）でもよく、「一定数」及び「所定数」との関係に基づいて決定してもよい。
これにより、共同運行において空席があるのに予約できないという、従来の課題を、人手をかけずに効率よく解決することができる。
【0122】
以上、本発明の好ましい実施形態について説明したが、本発明は上述した実施形態にのみ限定されるものではなく、本発明の範囲で種々の変更実施が可能であることは言うまでもない。
例えば、システムの構成は、上述の実施形態に限らず、一装置の構成の一部又は全部を他の装置が備えることもできる。
具体的には、本発明の高速バス処理プログラムは、主にサーバ１に備えられているが、サーバ１が備えるプログラムの一部を利用者端末２、予約サーバ３、決済サーバ４を含め外部の装置に備えさせても良い。
また、サーバ１の記憶手段１１に記憶される情報の一部又は全部を他の装置が記憶し、サーバ１と通信可能に接続していればよい。
また、予約サーバ３や決済サーバ４の機能の一部をサーバ１が備えても良い。
また、予約サーバ３と決済サーバ４の一方の機能の一部又は全部を他方が備えても良い。
また、サーバ１と１又は一部の予約サーバ３とが同じ事業者により運営される装置であってもよい。
例えば、システムの構成は、上述の実施形態に限らず、一装置の構成の一部又は全部を他の装置が備えることもできる。
具体的には、本発明の高速バス処理プログラムは、主にサーバ１に備えられているが、サーバ１が備えるプログラムの一部を利用者端末２、予約サーバ３、決済サーバ４を含め外部の装置に備えさせても良い。
また、サーバ１の記憶手段１１に記憶される情報の一部又は全部を他の装置が記憶し、サーバ１と通信可能に接続していればよい。
また、予約サーバ３や決済サーバ４の機能の一部をサーバ１が備えても良い。
また、予約サーバ３と決済サーバ４の一方の機能の一部又は全部を他方が備えても良い。
また、サーバ１と１又は一部の予約サーバ３とが同じ事業者により運営される装置であってもよい。
【0123】
また、特別乗継ルートは、説明の便宜上、地域名に基づいて説明したが、停留所ベースで実現することができる。その場合、地域名を停留所名に置き換えればよい。
また、予約サーバ３において管理する便情報（空席状況や金額を含む）をサーバ１が管理するようにしてもよい。
この場合、サーバ１は、路線情報の送信（図８のＳ１０６等）や予約依頼情報の送信（図１２のＳ２０６、Ｓ２０８等）を実行せず、実質、サーバ１が自身で予約処理を実行するようにもできる。
また、予約サーバ３において管理する便情報（空席状況や金額を含む）をサーバ１が管理するようにしてもよい。
この場合、サーバ１は、路線情報の送信（図８のＳ１０６等）や予約依頼情報の送信（図１２のＳ２０６、Ｓ２０８等）を実行せず、実質、サーバ１が自身で予約処理を実行するようにもできる。
【0124】
また、上述の実施形態は高速バスの乗継ぎに係るシステムだが、高速バスだけに限らず、飛行機、新幹線など他の交通手段との相互の乗継ぎに係るシステムに拡張することもできる。
また、他の実施形態において、座席連携は乗継ルートに限らず通常ルートの予約処理にも適用できる。
また、他の実施形態において、共同運営者が二者の場合を例示して説明したが、３者以上でも適用できる。
また、１つの予約システムを運営する運営者と、第三運営者（サーバ管理者）との二者の共同運行路線の場合にも適用できる。
また、席もらいの自動化は、ＡＩ（Artificial Intelligence：人工知能）を用いて実行してもよい。
例えば、予約システムＡ及び予約システムＢの販売座席数及び席もらい数の過去の実績を学習（機械学習又はディープラーニングなど）させ、一方システムの販売座席数が特定数になった場合に、他方システムにわたす席もらい数を出力可能なモデル（プログラム）を生成し、当該モデルに一方システム又は双方システムの販売座席数や販売座席残数を一定時間毎に入力することで、最適な席もらい数とタイミングで席もらいを自動実行するようにしてもよい。
また、他の実施形態において、座席連携は乗継ルートに限らず通常ルートの予約処理にも適用できる。
また、他の実施形態において、共同運営者が二者の場合を例示して説明したが、３者以上でも適用できる。
また、１つの予約システムを運営する運営者と、第三運営者（サーバ管理者）との二者の共同運行路線の場合にも適用できる。
また、席もらいの自動化は、ＡＩ（Artificial Intelligence：人工知能）を用いて実行してもよい。
例えば、予約システムＡ及び予約システムＢの販売座席数及び席もらい数の過去の実績を学習（機械学習又はディープラーニングなど）させ、一方システムの販売座席数が特定数になった場合に、他方システムにわたす席もらい数を出力可能なモデル（プログラム）を生成し、当該モデルに一方システム又は双方システムの販売座席数や販売座席残数を一定時間毎に入力することで、最適な席もらい数とタイミングで席もらいを自動実行するようにしてもよい。
【符号の説明】
【0125】
１：サーバ、１０１：制御部、１０２：メモリ、１０３：ストレージ、１０４：通信部、１１：記憶手段、１２：抽出手段、１３：表示制御手段、１４：予約手段、１５：決済手段、１６：予約変更手段、１７：予約取消手段、１８：特典付与手段、１９０：管理情報記憶手段、１９１：予約受付手段、１９２：予約手段、１９３：座席予約受付手段、１９４：座席予約手段、１９５：特定情報記憶手段、１９６：座席予約制御手段、１９７：変更手段、２：利用者端末、２０１：制御部、２０２：メモリ、２０３：ストレージ、２０４：操作部、２０５：表示部、２０６：通信部、３：予約システム（予約サーバ）、４：決済システム（決済サーバ）、９：インターネット
【要約】
【課題】高速バスサービスにおける予約処理の円滑化、共同運行路線の予約処理の効率化を図る。
【解決手段】 複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバ１と、を備えた高速バスシステムにおいて、サーバ１は、前記予約システムが記憶している管理情報を記憶する管理情報記憶手段１９０と、路線の予約を受け付ける予約受付手段１９１と、予約受付手段１９１により路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている管理情報に基づいて前記路線の予約を実行する予約手段１９２と、を備えた。
【選択図】図１
【解決手段】 複数の運営者により運営される複数の路線の予約に必要な管理情報をそれぞれ記憶する各予約システムと、サーバ１と、を備えた高速バスシステムにおいて、サーバ１は、前記予約システムが記憶している管理情報を記憶する管理情報記憶手段１９０と、路線の予約を受け付ける予約受付手段１９１と、予約受付手段１９１により路線の予約を受け付けた場合、管理情報記憶手段１９０に記憶されている管理情報に基づいて前記路線の予約を実行する予約手段１９２と、を備えた。
【選択図】図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図30】
【図31】
【図32】
【図33】
【図34】
