(57)【要約】【課題】  迅速にきめ細かいバスの手配、運用を行うこと。【解決手段】  バス手配運行サーバ１０１は、旅行会社端末１１１からアクセスを受けて、予約オファーを受信してデータベースに格納し管理するとともに、バス旅行企画案を提示して採用の判定を管理するバス手配管理モジュール２０１、予約に関連するデータを必要に応じて端末に送信して表示させたりするデータ送信モジュール２０２、バス会社端末に旅行企画のオファー内容等を送信したり、それに対応する企画案を受信したりしてバス会社関連の処理を行うバス運行管理モジュール２０３およびオファーと企画案との整合を取ったり、法定バス料金を算出したりして、バス予約の種々の管理を行う予約管理モジュール２０４を備える。【選択図】  図２
2018198061.tif 000002
【特許請求の範囲】
【請求項１】
バス手配または運行に関するマッチング希望と、該マッチング希望に対応するマッチング対応案とのマッチングをとるためのバス手配運行サーバであって、
マッチング希望者端末から希望する日時、目的地を含むバスのマッチング希望情報を受信し、該マッチング希望情報に対応してマッチング対応者端末から提示された料金を含むマッチング対応案を前記マッチング希望者端末に送信する希望者端末管理手段と、
前記マッチング希望情報を前記マッチング対応者端末に送信し、該マッチング希望情報に対応して提示された料金を含むマッチング対応案を前記マッチング対応者端末から受信する対応者管理手段と、
前記受信したマッチング対応者から提示されたマッチング対応案と、前記予約者端末から受信したマッチング希望情報との関連を処理する対応案処理手段と
を備えたことを特徴とするバス手配運行サーバ。
【請求項２】
前記対応案処理手段は、前記マッチング希望者端末から成約する旨の通知があったときは、採用可能な対応案を送信したマッチング対応者端末に通知することを特徴とする請求項１に記載のバス手配運行サーバ。
【請求項３】
前記マッチング対応者端末は、予め登録された複数のマッチング対応者の端末であり、
前記希望者端末管理手段は、前記マッチング対応者端末から提示された複数のマッチング対応案をリストにして前記マッチング希望者端末に送信することを特徴とする請求項１または２に記載のバス手配運行サーバ。
【請求項４】
バス手配運行サーバが、マッチング希望者からのマッチング希望に基づいてマッチング対応者の提示するマッチング対応案を提供するバス手配運行方法であって、
前記バス手配運行サーバにより、希望する日時、目的地を含むバスのマッチング希望情報をマッチング希望者端末から受信するステップと、
前記バス手配運行サーバにより、前記マッチング希望情報を受信すると、マッチング対応者端末に送信するステップと、
前記マッチング希望情報に対応して提示された料金を含むマッチング対応案を前記マッチング対応者端末から受信するステップと、
前記受信したマッチング対応者から提示されたマッチング対応案と、前記マッチング希望者端末から受信したマッチング希望情報との関連を処理するステップと、
前記マッチング希望情報に対応してマッチング対応者端末から提示された料金を含むマッチング対応案を前記マッチング希望者端末に送信するステップと
を備えたことを特徴とするバス手配運行方法。
【請求項５】
コンピュータに、マッチング希望者からのマッチング希望に基づいてマッチング対応者の提示するマッチング対応案を提供するバス手配運行方法を実行させるプログラムであって、該バス手配運行方法は、
希望する日時、目的地を含むバスのマッチング希望情報を、マッチング希望者端末から受信するステップと、
前記マッチング希望情報を受信すると、マッチング対応者端末に送信するステップと、
前記マッチング希望情報に対応して提示された料金を含むマッチング対応案を前記マッチング対応者端末から受信するステップと、
前記受信したマッチング対応者から提示されたマッチング対応案と、前記マッチング希望者端末から受信したマッチング希望情報との関連を処理するステップと、
前記マッチング希望情報に対応してマッチング対応者端末から提示された料金を含むマッチング対応案を前記マッチング希望者端末に送信するステップと
を備えたことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はバス手配運行方法、サーバおよびプログラムに関し、より具体的には、様々な状況で柔軟に対応できるバス手配運行方法、サーバおよびプログラムに関する。
【背景技術】
【０００２】
近年、様々な分野でインターネットを利用した予約システム、手配システムが運用されている。このようなシステムを使用することにより、人手による作業を省力化できるだけでなく、きめ細やかで柔軟な運行管理が可能になる。
【０００３】
種々な交通機関の中で、特にバスの予約、手配はシステム化が遅れていたが、特許文献１のようなバス手配システム、バス手配方法およびバス手配用プログラムが提案されている。特許文献１のバス手配システム、バス手配方法およびバス手配用プログラムは、乗客数の急激な変化を事前に把握してバス配車台数を増減させることを目的とし、利用者１はバスの利用情報を利用者端末１０からバス会社サーバ２０に送信し、バス会社サーバ２０は利用情報をバス路線別に集計し集計結果を該当する路線を担当する営業所３の営業所端末３０に送信し、営業所端末３０は集計結果を過去の路線別乗客数実績を格納する乗客数実績データベース３０２と比較してバス配車必要台数を路線別に算出し、営業所端末３０は増車が必要な路線の付近に配車可能なバスが存在するかを運転手端末４０から受信した位置情報をもとに判断し、バスが存在した場合にそのバスの運転手端末４０に配送指示を送信し、不足台数を画面表示するとともに、バス会社サーバ２０は主催者端末５０からイベント情報を、交通機関端末６０から事故情報を、それぞれ受信して上記と同様の処理を行うというものである。
【特許文献１】特開２００４−７０４８１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、従来のバス手配システム、バス手配方法およびバス手配用プログラムは、状況に応じて効率よくバスを手配するものだが、予め運行ルートは決まっており、片送り、片迎えなどの非効率な運用を解決できないという問題がある。また、バスの故障や事故などの不慮の事態に備えて柔軟にバスを手配することができないという問題がある。
【０００５】
本発明は上記従来の問題に鑑みてなされたものであり、予約者からバスの手配をスマートフォンやパソコンから受け取り、登録してあるバス会社などに送って可能な提案を受け付けて、バス会社等から提示された料金を含む応募案を応募者に提案してバスを手配することにより、迅速できめ細かいバスの手配運用を行うことができる。
【課題を解決するための手段】
【０００６】
請求項１に記載の発明は、バス手配または運行に関するマッチング希望と、マッチング希望に対応するマッチング対応案とのマッチングをとるためのバス手配運行サーバであって、マッチング希望者端末から希望する日時、目的地を含むバスのマッチング希望情報を受信し、マッチング希望情報に対応してマッチング対応者端末から提示された料金を含むマッチング対応案をマッチング希望者端末に送信する希望者端末管理手段と、マッチング希望情報をマッチング対応者端末に送信し、マッチング希望情報に対応して提示された料金を含むマッチング対応案をマッチング対応者端末から受信する対応者管理手段と、受信したマッチング対応者から提示されたマッチング対応案と、予約者端末から受信したマッチング希望情報との関連を処理する対応案処理手段とを備えたことを特徴とする。
【０００７】
請求項２に記載の発明は、請求項１に記載のバス手配運行サーバにおいて、対応案処理手段は、マッチング希望者端末から成約する旨の通知があったときは、採用可能な対応案を送信したマッチング対応者端末に通知することを特徴とする。
【０００８】
請求項３に記載の発明は、請求項１または２に記載のバス手配運行サーバにおいて、マッチング対応者端末は、予め登録された複数のマッチング対応者の端末であり、希望者端末管理手段は、マッチング対応者端末から提示された複数のマッチング対応案をリストにしてマッチング希望者端末に送信することを特徴とする。
【０００９】
請求項４に記載の発明は、バス手配運行サーバが、マッチング希望者からのマッチング希望に基づいてマッチング対応者の提示するマッチング対応案を提供するバス手配運行方法であって、バス手配運行サーバにより、希望する日時、目的地を含むバスのマッチング希望情報をマッチング希望者端末から受信するステップと、バス手配運行サーバにより、マッチング希望情報を受信すると、マッチング対応者端末に送信するステップと、マッチング希望情報に対応して提示された料金を含むマッチング対応案をマッチング対応者端末から受信するステップと、受信したマッチング対応者から提示されたマッチング対応案と、マッチング希望者端末から受信したマッチング希望情報との関連を処理するステップと、マッチング希望情報に対応してマッチング対応者端末から提示された料金を含むマッチング対応案をマッチング希望者端末に送信するステップとを備えたことを特徴とする。
【００１０】
請求項５に記載の発明は、コンピュータに、マッチング希望者からのマッチング希望に基づいてマッチング対応者の提示するマッチング対応案を提供するバス手配運行方法を実行させるプログラムであって、バス手配運行方法は、希望する日時、目的地を含むバスのマッチング希望情報をマッチング希望者端末から受信するステップと、マッチング希望情報を受信すると、マッチング対応者端末に送信するステップと、マッチング希望情報に対応して提示された料金を含むマッチング対応案をマッチング対応者端末から受信するステップと、受信したマッチング対応者から提示されたマッチング対応案と、マッチング希望者端末から受信したマッチング希望情報との関連を処理するステップと、マッチング希望情報に対応してマッチング対応者端末から提示された料金を含むマッチング対応案をマッチング希望者端末に送信するステップとを備えたことを特徴とする。
【発明の効果】
【００１１】
本発明によると、マッチング希望者端末から希望する日時、目的地を含むバスのマッチング希望情報を受信し、マッチング希望情報に対応してマッチング対応者端末から提示された料金を含むマッチング対応案をマッチング希望者端末に送信する希望者端末管理手段と、マッチング希望情報をマッチング対応者端末に送信し、マッチング希望情報に対応して提示された料金を含むマッチング対応案をマッチング対応者端末から受信する対応者管理手段と、受信したマッチング対応者から提示されたマッチング対応案と、予約者端末から受信したマッチング希望情報との関連を処理する対応案処理手段とを備えているので、迅速にきめ細かいバスの手配、運用を行うことができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態の全体のシステム構成図である。
【図２】本発明の一実施形態のサーバと旅行会社端末の一例の機能ブロック図である。
【図３】本発明の一実施形態のサーバとバス会社端末の一例の機能ブロック図である。
【図４】本発明の一実施形態の旅行会社端末における処理を示すフローチャートである。
【図５】本発明の一実施形態のバス会社端末における処理を示すフローチャートである。
【図６】本発明の一実施形態の端末入力時の画面表示の一例を示す図である。
【図７】本発明の一実施形態の端末入力時のバス種別等の指定の画面表示の一例を示す図である。
【図８】本発明の一実施形態のサーバと旅行会社端末の別の例の機能ブロック図である。
【発明を実施するための形態】
【００１３】
以下、本発明のバス手配運行方法、サーバおよびプログラムについて図面を参照して実施形態を説明する。なお、異なる図面でも、同一の処理、構成を示すときは同一の符号を用いる。
【００１４】
本発明は、バス運用についてマッチングを希望する個人や企業と、それに対応可能な企業とを結び付け、無駄なくバスを運行させるものであり、以下に詳述するように基本的に３つのパターンで使用される。すなわち、先ずマッチングの希望者として、旅行会社または一般企業の担当者若しくは個人を想定したバス旅行の企画提案の例であり、この場合マッチングに対応する企業は、旅行会社またはバス会社となる。次に、マッチングの希望者として、旅行会社または一般企業の担当者若しくは個人を想定し、バスの事故や故障等で代替のバスを緊急手配する例であり、この場合マッチングの対応する企業は、旅行会社またはバス会社となる。またマッチング希望者として、旅行会社またはバス会社を想定し、片送り、片迎えなどバスの運行に余裕があるときに必要とする企業にバスを提供するバス運行の公募の例であり、この場合マッチング希望に対応するマッチング対応者は、旅行会社または一般企業の担当者若しくは個人となる。
【００１５】
（第１実施形態）
まず、第１実施形態として旅行会社または一般企業の担当者若しくは個人をマッチングの希望者とするバス旅行の企画提案の例を説明する。本実施形態は、本発明を利用してバスの予約システムを実現するものであり、旅行会社等のオファーに対しバス会社等が応募してバス旅行の複数の企画案を提示し、所望の企画案があれば採用して成約するというものである。
【００１６】
（システム構成）
本実施形態では、図１に示すように、各端末との送受信や、データ管理、予約受付、手配処理、支払処理などバス予約手配に必要な処理を実行するバス手配運行サーバ１０１がネットワークに接続されており、ネットワーク１０３を介して利用者側の各端末１１１、１１２やバス管理者側のバス会社端末１２１に接続されている。本実施形態では、このサーバ１０１の機能は、クラウドを通じて各端末に提供することもできる。この場合、各端末ではブラウザや専用アプリを使用して主に入力、表示のみの処理を行い、データの管理、種々の処理は基本的にサーバ上で行われるが、クラウドの構成とせずインターネットや専用のネットワークを介して直接クライアントや端末などに提供するような構成とすることもできる。
【００１７】
本実施形態では、利用者側の端末として、旅行会社端末１１１やユーザ端末１１２が用いられるが、これらの端末はバスを予約する企業や個人が種々の入力や管理、決定などのために用いる。すなわち、一般に本システムの利用者は旅行代理店などのバスも含めた旅行の企画を行う旅行会社などの企業だが、その他にもバスの利用者である個人や企業の担当者が直接バスを手配する場合もあり、この場合はユーザ端末１１２を用いることができる。
【００１８】
また、バス管理者側としては、一般にバス会社端末１２１が使用されるが、バス会社以外でも、バスの運用や管理を行っている企業がバス会社端末１２１を使用して、応募案を提示することもできる。本実施形態のシステムでは、予めバス会社を登録しておき、本技術分野で知られた方法で登録されたバス会社の管理、バス会社端末１２１からシステムへのアクセス処理など必要な情報処理を行う。ユーザ側の端末も同様だが、一時的に登録せずに利用するようにすることもできる。ここでは、バス会社端末としているが、旅行会社がバスの運行、管理をする場合は旅行会社端末も含まれるようにすることができる。
【００１９】
端末１１１、１１２、１２１は、基本的に無線でネットワーク１０３に接続されており、例えばタブレット端末とすることができ、本実施形態でネットワーク１０３との接続は、携帯電話の回線や、Ｗｉ−ｆｉ、ＢＬＵＥＴＯＯＴＨ（登録商標）等の無線ネットワークにより行うことができる。ここで端末１１１、１１２、１２１はタブレット端末のほか、スマートフォン、あるいはモバイルパソコン等とすることができるが、基本的にネットワークを介してバス手配運行システムにアクセスして入力画面を表示、およびタッチパネル、マウスまたはキーボードで一定の入力操作をすることができれば、モバイルあるいはデスクトップのパソコン、専用端末などいずれの装置を用いることもできる。
【００２０】
また、本実施形態のサーバとしては、バス手配運行サーバ１０１のみで処理を行うようにしているが、これに限られず複数のサーバに分けて、機能分担させることもできる。
【００２１】
図２は、本発明の一実施形態のサーバおよび旅行会社端末の機能ブロック図である。バス手配運行サーバ１０１は、旅行会社端末１１１からアクセスを受けて、予約オファーを受信してデータベースに格納し管理するとともに、バス旅行企画案を提示して採用の判定を管理するバス手配管理モジュール２０１、予約に関連するデータを必要に応じて端末に送信して表示させたりするデータ送信モジュール２０２、バス会社端末に旅行企画のオファー内容等を送信したり、それに対応する企画案を受信したりしてバス会社関連の処理を行うバス運行管理モジュール２０３およびオファーと企画案との整合を取ったり、法定バス料金を算出したりして、バス予約の種々の管理を行う予約管理モジュール２０４を備える。
【００２２】
一方、旅行会社端末１１１は、入力された希望日時や旅程などのマッチング希望情報を入力させ、管理するデータ入力管理モジュール２０５、サーバから送信される表示データなどの受信および表示などを実行する表示データ受信モジュール２０６および企画案の内容を表示して、成約まで工程における入出力処理を行う手配画面表示モジュール２０７を備える。
【００２３】
図３は、本発明の一実施形態のサーバおよび旅行会社端末の機能ブロック図である。バス手配運行サーバ１０１は、旅行会社端末１１１からアクセスを受けて、予約オファーを受信してデータベースに格納し管理するとともに、バス旅行企画案を提示して採用の判定を管理するバス手配管理モジュール２０１、予約に関連するデータを必要に応じて端末に送信して表示させたりするデータ送信モジュール２０２、バス会社端末に旅行企画のオファー内容等を送信したり、それに対応する企画案を受信したりしてバスの運行に関する処理を行うバス運行管理モジュール２０３およびオファーと企画案との整合を取ったり、法定バス料金を算出したりしてバス予約の種々の管理を行う予約管理モジュール２０４を備える。
【００２４】
一方、バス会社端末１２１は、入力された料金を含むマッチング対応案である企画案を入力させ、管理するデータ入力管理モジュール３０１、サーバと送受信するデータなどの管理を実行するデータ送受信モジュール３０２および企画案の入力画面を表示して処理を行う応募案画面表示モジュール３０３を備える。
【００２５】
（本実施形態の旅行企画公募処理）
本発明の一実施形態で用いるバス手配運行サーバ１０１の具体的な動作及び処理に関し、図４を参照して本発明のマッチング希望情報の入力処理を説明する。図４は、本発明の一実施形態の旅行会社端末のデータ入力処理の一例のフローチャートである。旅行会社端末１１１からブラウザや専用アプリなどによりネットワーク経由でバス手配運行サーバ１０１に接続すると（ステップ４０１）、バス手配運行サーバ１０１のバス手配管理モジュール２０１は、図６及び７に示すようなマッチング希望情報である日時や行程などを含む手配条件入力画面を旅行会社端末１１１に送信し、旅行会社端末１１１では手配画面表示モジュール２０６により受信され、表示される（ステップ４０２）。
【００２６】
ユーザあるいはオペレータは、図６及び７に示すような入力画面を用いて、旅行企画の希望条件、例えば、日付６０２、時間６０３、乗車地６０４、経由地６０５および最終降車地６０６などを入力してルートを決定する。また、より正確な設定のため顧客が乗っていない区間（バスの車庫から出発地まで、最終下車地からバスの車庫まで）である回送距離、時間６０１も入力することができる。さらに以上の日時および行程に加え、図７に示すようにその他のバス関連の情報、例えばバス種別７０１、バス台数７０２、バス設備７０３および希望運転手数７０４などを設定することができる（ステップ４０３）。
【００２７】
以上のように、必要な条件が設定されると、バス手配運行サーバ１０１は、登録済みのバス会社や旅行会社に希望内容を送信し、対応可能なバス会社等からの見積もりを含む応募を受け付ける。この場合、バス手配運行サーバ１０１は、入力された条件の行程の出発地又は降車地を営業区域として登録してあるバス会社等だけに送信することもできる。さらに、応募の期限を付与して、期限管理をすることもでき、この場合期限内に応募されたものだけを採用することもできるし、さらに延長することもできる。
【００２８】
バス手配運行サーバ１０１では、マッチング対応案である応募を受信した場合（ステップ４０４）は、受信した各応募案の内容を図示しない一覧表にまとめ、旅行会社端末１１１に送信する。ここで、バス手配運行サーバ１０１は、希望内容または応募案に含まれる行程に基づいて、法定バス料金を計算しておき、見積もりを含む各バス会社等の提示内容とともに送信することもできるし、受信した応募案のうち法定バス料金内の正当な金額の見積もりのものだけを送信することもできる。
【００２９】
旅行会社端末１１１でバス会社等から提示された応募案を受信すると、その中から採用可能な案を特定し、成約する旨決定してバス手配運行サーバ１０１に通知する（ステップ４０５）。期限までに応募案が無かったり、採用可能な案が無かったりする場合は、再度条件を変更して入力するか、処理を終了する。
【００３０】
以上、マッチング希望情報である手配条件の入力などを行って、バス会社等からの応募案に基づき、バス旅行企画の予約を決定し処理を終了させる。以上の処理が終了すると、バス会社からの詳細情報の提示、料金の請求や支払処理など本技術分野で知られた通常の処理が行われる。例えば、バス手配運行サーバ１０１は、応募案に応答して旅行会社端末１１１から受諾の通知を受信すると、バス会社端末１２１にその旨通知し、このバス予約に関し料金の決済を行うこともできる。
【００３１】
（本実施形態の応募受付処理）
以下に、図５を参照して本発明の応募受付処理を説明する。図５は、本発明の一実施形態のバス会社端末における処理の一例のフローチャートである。
【００３２】
バス手配運行サーバ１０１は、上述のように旅行会社端末１１１からバス手配の公募を受けると、登録されているバス会社等にその旨メール等により通知する。バス会社端末１２１がバス手配公募メールを受信すると（ステップ５０１）、バス会社端末１２１からブラウザや専用アプリなどによりネットワーク経由でバス手配運行サーバ１０１に接続する（ステップ５０２）。
【００３３】
バス手配運行サーバ１０１のバス運行管理モジュール２０３は、応募案入力画面を生成し、データ送信モジュール２０２がバス会社端末１２１に送信するが、バス手配の公募が複数ある場合は、まず公募の一覧を表示して所望の公募を選択するとその詳細が表示されるようにすることもできる。送信された応募案入力画面は、データ送受信モジュール３０２により受信され、応募案画面表示モジュール３０３により表示される（ステップ５０３）。
【００３４】
バス会社等ではバス手配条件を検討して（ステップ５０４）、受諾可能であると判断すると（ステップ５０５）、料金を見積もって応募案を作成する（ステップ５０６）。
【００３５】
具体的な入力画面は図示しないが、基本的にバス手配条件はそのまま使用されるから、応募案入力画面の例としては、バス手配条件を表示しておいて、必要な場合には修正できるようにすることもできるが、バス手配条件を表示させておいて、見積もり入力だけするようにすることもできる。作成された応募案はバス手配運行サーバ１０１に送信され、上述のように旅行会社端末１１１に提示される。応募案が採用されると、バス手配運行サーバ１０１から通知があり、予約が成立すると、旅行会社への詳細情報の提示や、料金の請求処理など本技術分野で知られた通常の処理が行われる。
【００３６】
（第２実施形態）
第２実施形態として、旅行会社または一般企業の担当者若しくは個人のマッチングの希望者が、バスの事故や故障等で代替のバスを緊急手配する例を説明する。本実施形態は、構成は第１実施形態と類似するが、バス手配条件が限定されるのと、緊急性が必要で期限は即日か長くても数日以内となる。したがって、旅行会社端末１１１に表示される手配入力画面は、緊急手配に合わせたものになり、バス種別と台数の情報があれば、バスの設備等は不要とすることができる。また、故障、自己等緊急手配の理由も付加することができる。
【００３７】
本実施形態のマッチング希望情報の入力処理を説明する。まず、旅行会社端末１１１からブラウザや専用アプリなどによりネットワーク経由でバス手配運行サーバ１０１に接続すると、バス手配運行サーバ１０１のバス手配管理モジュール２０１は、マッチング希望情報である日時や行程などを含む手配条件入力画面を旅行会社端末１１１に送信し、旅行会社端末１１１では手配画面表示モジュール２０６により受信され、表示される。
【００３８】
ユーザあるいはオペレータは、緊急手配の希望条件、例えば、日付、時間、乗車地、経由地および最終降車地を入力してルートを決定する。さらに以上の日時および行程に加え、その他のバス関連の情報、例えばバス種別、バス台数などを設定することができる。
【００３９】
以上のように、必要な条件が設定されると、バス手配運行サーバ１０１は、登録済みのバス会社や旅行会社に希望内容を送信し、対応可能なバス会社等からの見積もりを含む応募案を受け付ける。この場合、緊急性が高いため、通常は、入力された条件の行程の出発地又は降車地を営業区域として登録してあるバス会社等だけに送信する。応募の期限を即日または数日とすることができる。
【００４０】
バス手配運行サーバ１０１では、マッチング対応案である応募案を受信した場合は、受信した各応募案の内容を図示しない一覧表にまとめ、旅行会社端末１１１に送信する。ここで、バス手配運行サーバ１０１は、希望内容または応募案に含まれる行程に基づいて、法定バス料金を計算しておき、見積もりを含む各バス会社等の提示内容とともに送信することもできるし、受信した応募案のうち法定バス料金内の正当な金額の見積もりのものだけを送信することもできる。
【００４１】
旅行会社端末１１１でバス会社等から提示された応募案を受信すると、その中から採用可能な案を特定し、成約する旨決定しバス手配運行サーバ１０１に通知する（ステップ４０５）。期限までに応募案が無かったり、採用可能な案が無かったりする場合は、再度条件を変更して入力するか、処理を終了する。
【００４２】
次に、本実施形態の応募受付処理を説明する。バス手配運行サーバ１０１は、上述のように旅行会社端末１１１からバス緊急手配の公募を受けると、登録されているバス会社等にその旨メール等により通知する。この場合、緊急である旨追加したり、緊急性の高い通信媒体を使用したりすることもできる。バス会社端末１２１がバス手配公募メールを受信すると、バス会社端末１２１からブラウザや専用アプリなどによりネットワーク経由でバス手配運行サーバ１０１に接続する。
【００４３】
バス手配運行サーバ１０１のバス運行管理モジュール２０３は、応募案入力画面を生成し、データ送信モジュール２０２がバス会社端末１２１に送信するが、バス手配の公募が複数ある場合は、まず公募の一覧を表示して所望の公募を選択するとその詳細が表示されるようにすることもできる。送信された応募案入力画面は、データ送受信モジュール３０２により受信され、応募案画面表示モジュール３０３により表示される。
【００４４】
バス会社等ではバス手配条件を検討して、受諾可能であると判断すると、料金を見積もって応募案を作成する。具体的な入力画面は図示しないが、緊急対応なので、基本的には、バス手配条件を表示させておいて、見積もり入力だけするようにする。作成された応募案はバス手配運行サーバ１０１に送信され、上述のように旅行会社端末１１１に提示される。応募案が採用されると、バス手配運行サーバ１０１から通知があり、予約が成立すると、旅行会社への詳細情報の提示や、料金の請求処理など本技術分野で知られた通常の処理が行われる。
【００４５】
（第３実施形態）
第３実施形態として、旅行会社またはバス会社であるマッチング希望者が、片送り、片迎えなどバスの運行に余裕があるときに、必要とする企業にバスの運行を提案する例を説明する。本実施形態は、構成が上述の第１実施形態および第２実施形態と異なり、旅行会社またはバス会社がバス運行の空き時間を埋める等のため、自己の余剰のリソースを提示して、マッチングが取れたバス会社等が提示された提案を採用する形になる。
【００４６】
すなわち、上述の第１実施形態では、バスの利用を所望する側がマッチング希望者であり、バスを提供する側はマッチング対応者になるが、本実施形態では、バスを提供する側がマッチング希望者になり、バスの利用者はマッチング対応者となる。以下では、マッチング希望者をバス会社とし、マッチング対応者を旅行会社として説明するが、これに限られず、マッチング希望者は、旅行会社とすることもでき、マッチング希望への対応者は、一般企業の担当者若しくは個人とすることもできる。
【００４７】
具体的には、例えば都内から空港へのバス運行が決まっていた場合、空港で乗客を降車させた後、空席で都心まで戻るのは非効率なので、空港から都心までのバスの運行を公募することにより、そのバス運行条件に合う利用者、つまりマッチング対応者がいれば、マッチングを図って効率の良いバスの運行が可能になる。バス運行の公募は、そのバスを利用可能な日時、場所を条件として提示するので、基本的にバス運行条件の入力は第１実施形態で説明したものと同様であるが、時間、場所以外に希望する料金も提示することができる。また、本実施形態では、マッチング希望者はバスを手配する側ではなく、運行者側になるので、提示する条件は、バス手配条件ではなく、バス運行条件と呼ぶ。
【００４８】
すなわち、例えば本実施形態では、第１実施形態と同様に基本的に日付、時間、乗車地、経由地および最終降車地などを入力して公募することができるが、これらの情報はあくまでバス運行条件であるので、場所も時間も対応可能な一定の範囲であり、そのような対応可能な範囲内で、応募者側は自己の都合に合わせて希望するルートを指定し、そのルートで希望する金額も指定する。
【００４９】
したがって、本実施形態の応募受付処理は、以下の通り第１実施形態とは若干異なる。図８のブロック図を参照して説明すると、バス手配運行サーバ１０１は、旅行会社やバス会社などのマッチング希望者からバス運行の公募を受けると、登録されているバス会社等にその旨メール等により通知する。旅行会社端末１１１がバス運行公募メールを受信すると、旅行会社端末１１１からブラウザや専用アプリなどによりネットワーク経由でバス手配運行サーバ１０１に接続する。
【００５０】
バス手配運行サーバ１０１のバス手配管理モジュール２０１は、応募案入力画面を生成し、データ送信モジュール２０２が旅行会社端末１１１に送信するが、バス運行の公募が複数ある場合は、まず公募の一覧を表示して所望の公募を選択するとその詳細が表示されるようにすることもできる。送信された応募案入力画面は、データ送受信モジュール８０２により受信され、応募案画面表示モジュール８０３により表示される。
【００５１】
旅行会社等ではバス運行条件を検討して、利用可能なバスがあれば、希望する料金を含めて応募案を作成する。具体的な入力画面は図示しないが、バス運行条件は日時、乗降車場所などそのバスが対応可能な範囲を示しているので、その可能な範囲から利用可能なルートがある場合は、具体的なルートと希望する料金を決定して、応募案入力画面で入力する。作成された応募案はバス手配運行サーバ１０１に送信され、マッチング希望者に提示される。応募案が複数ある場合は一覧表示され、マッチング希望者が採用すると、バス手配運行サーバ１０１から通知があり、予約が成立すると、バス会社への詳細情報の提示や、料金の請求処理など本技術分野で知られた通常の処理が行われる。
【００５２】
ここで、第１実施形態と同様に、バス手配運用サーバで法定バス料金を計算して応答案とともに提示したり、応答案を絞り込んだりすることができるが、この法定バス料金の算出は、正確性を考慮すると主に応募案に含まれるルートに基づいて実行するのが好ましい。
【図１】
2018198061.tif 000003
【図２】
2018198061.tif 000004
【図３】
2018198061.tif 000005
【図４】
2018198061.tif 000006
【図５】
2018198061.tif 000007
【図６】
2018198061.tif 000008
【図７】
2018198061.tif 000009
【図８】
2018198061.tif 000010