JP4550990B2

JP4550990B2 - Ride-on operation support system and method

Info

Publication number: JP4550990B2
Application number: JP2000340964A
Authority: JP
Inventors: 八千朗神薗; 真之助高橋; 茂樹原
Original assignee: 八千朗神薗
Priority date: 2000-11-08
Filing date: 2000-11-08
Publication date: 2010-09-22
Anticipated expiration: 2020-11-08
Also published as: JP2002150470A

Description

【０００１】
【発明の属する技術分野】
本発明は、乗合運行支援システム及びその方法に関し、より詳細には、オンライン・データベース管理システムにおいて、顧客から受け付けた運行依頼を取り纏めて乗合車両運行業者に通知することにより乗合車両の運行支援を行う乗合運行支援システム及びその方法に関する。
【０００２】
【従来の技術】
特定の日、特定の時間に出発する電車や飛行機に乗るために駅や空港に向かう場合は、電車やバスを乗り継いでいくのが通常である。１度乗ってしまえば乗り換えの必要などなく目的地まで運んでくれるタクシーは理想的な交通手段ではあるが、費用がかさむことから避けられることが多く、大きな荷物を抱えている場合や、何人かでまとまって目的地に向かう場合などに限って利用されることが多いのが実情である。
【０００３】
この理想的な交通手段であるタクシーをより安価に利用する方法として、いくつかの駅や空港では、特定の場所に移動したい乗客を何人か集め、所定の人数が集まった時点で出発し、決まった場所まで運ぶ、といった乗合タクシーの運行が行われている。
【０００４】
【発明が解決しようとする課題】
しかしながら、従来の乗合タクシーは、空港などの特定の場所において顧客を集客し、場当たり的にその顧客をグループ化して運行を決定するため、効率的な運行を行うことができなかった、という問題があった。また、現在、タクシーの運行予約はもっぱら電話、あるいはインターネットを介して行われているが、このようにしてなされた運行予約の処理と乗合車両運行業者との間での運行決定プロセスが確立していないため、今後予約件数が増加した場合、効率的に運行予約の処理を行うことができない、という問題もあった。
【０００５】
さらに、乗合タクシーを運行する乗合車両運行業者は多数あるものの、それらの運行状況を取り纏めるような運行決定システムが確立していないため、顧客は、希望する条件で乗合タクシーを運行する乗合車両運行業者を見つけ出すまで、料金や出発地などについて個々に問い合わせを行わなければならない、という問題もあった。
【０００６】
このような状況は、タクシーなどを運行する乗合車両運行会社にとっても問題となっていた。費用が嵩まなければタクシーを利用したいという潜在的な顧客は多いものの、タクシー運転手自身で顧客の乗車希望を取りまとめ、乗合客を発掘することは困難であり、乗合車両運行会社にあっては、数少ない利用客を発見するか、乗合タクシーの営業場所に出向いて乗合客を集めなければ収益機会を得ることができないという問題もあった。
【０００７】
本発明は、このような問題に鑑みてなされたもので、その目的とするところは、運行しやすい状態に纏めた複数の乗客をタクシーなどの乗合車両を運行する乗合車両運行業者に効率よく提供でき、顧客には、好きなときに、希望する場所から目的地まで希望する時間に楽に移動することのできる安価で新しい交通手段を提供できる乗合運行支援システムを提供することにある。
【０００８】
また本発明の目的は、乗合運行支援システムの備えるサーバと、業者用端末とに対し、運行しやすい状態に纏めた複数の乗客を乗合車両運行業者へ効率よく提供することを実現することのできるプログラムを提供することにある。また、顧客用端末に対し、好きなときに、希望する場所から目的地まで希望する時間に楽に移動することのできる安価で新しい交通手段の提供を実現することのできるプログラムを提供することにある。
【０００９】
また本発明の目的は、運行しやすい状態に纏めた複数の乗客を乗合車両運行業者に効率よく提供でき、顧客には、好きなときに、希望する場所から目的地まで希望する時間に楽に移動することのできる安価で新しい交通手段を提供できる乗合運行支援方法を提供することにある。
【００１０】
【課題を解決するための手段】
このような目的を達成するために、請求項１に記載の発明は、業者用端末及び顧客用端末に対し乗合情報を提供するサーバと、該サーバにネットワークを介して接続された前記業者用端末と前記顧客用端末とを備えた乗合運行支援システムにおける前記サーバにおいて、前記顧客用端末から受信した乗合車両に対する運行依頼を記憶する第１の記憶手段と、前記運行依頼を取り纏めて運行グループを生成する運行グループ生成手段と、前記運行グループ生成手段が生成した運行グループを記憶する第２の記憶手段と、前記業者用端末に対し、前記運行グループに対する運行を依頼する運行依頼信号を発信する依頼信号発信手段と、前記業者用端末から受信した前記運行グループに対する運行計画を記憶する第３の記憶手段と、前記顧客用端末からの前記運行計画に対する最終確認信号の受信に応答して、前記業者用端末に該運行計画に対する最終確認通知を発信する確認通知発信手段とを備えたサーバであることを特徴とする。
【００１１】
ここで「乗合車両」とは、タクシー、ハイヤー、貸切バス、乗合バス、乗合タクシーなどをいう。また、「運行依頼」とは、顧客が乗合車両の運行を依頼するために行う依頼をいい、出発日、出発希望時間、到着日、到着希望時間、駅や空港名などの目的地あるいは出発地、利用人数等を含むものをいう。「運行グループ」とは、１台の乗合車両が運行する顧客のグループをいう。
【００１２】
請求項２に記載の発明は、請求項１に記載のサーバにおいて、前記運行グループ生成手段は、前記運行依頼から処理対象となる運行依頼を抽出する第１の抽出手段と、前記第１の抽出手段の抽出した運行依頼から、最低乗客数を満たす運行依頼を抽出して運行グループを生成する第１のグルーピング手段とを備えたことを特徴とする。
【００１３】
ここで「最低乗客数」とは、乗合車両運行会社が１台の乗合車両を運行するにあたり、収益をあげることのできるであろう乗客の数をいう。
【００１４】
請求項３に記載の発明は、請求項２に記載のサーバにおいて、前記第１の抽出手段は、乗合車両乗車日と、到着希望時間または出発希望時間の属する時間帯とをキーとして処理対象となる運行依頼を抽出することを特徴とする。
【００１５】
請求項４に記載の発明は、請求項２に記載のサーバにおいて、前記第１の抽出手段は、前記顧客用端末から受信した運行依頼の含む乗合車両乗車日と、到着希望時間または出発希望時間の属する時間帯とをキーとして処理対象となる運行依頼を抽出することを特徴とする。
【００１６】
請求項５に記載の発明は、請求項２に記載のサーバにおいて、前記第１のグルーピング手段が運行グループの生成を行うことのできない場合、前記第１の抽出手段の抽出した運行依頼から、同じ固定場所と、所定の隣接度合いの出発地または到着地とを持つ隣接運行依頼を抽出する第２の抽出手段と、前記隣接運行依頼を取り纏めて、最低乗客数を満たす運行グループを生成する第２のグルーピング手段とを備えたことを特徴とする。
【００１７】
請求項６に記載の発明は、請求項５に記載のサーバにおいて、前記隣接度合いは、あらかじめ設定された隣接地区テーブルに基づいて定められることを特徴とする。
【００１８】
請求項７に記載の発明は、請求項６に記載のサーバにおいて、前記隣接地区テーブルは、郵便番号に基づいて地域を区分けし、該区分けごとに地区相互の隣接度合いを定めたものであることを特徴とする。
【００１９】
請求項８に記載の発明は、請求項１に記載のサーバにおいて、前記顧客用端末からの前記第２の記憶手段の記憶する運行計画への運行依頼の追加発注信号の受信に応答して、前記業者用端末に対し、該運行計画への追加運行依頼信号を発信する追加依頼信号発信手段を備えたことを特徴とする。
【００２０】
請求項９に記載の発明は、請求項１から８のいずれかに記載のサーバからの前記運行グループに対する運行を依頼する運行依頼信号の受信に応答して、該運行グループの含む運行依頼を出力する第１の出力手段と、該運行依頼に対する運行計画を入力する第１の入力手段と、該サーバから受信した前記運行計画に対する最終確認通知を出力する第２の出力手段と、前記サーバと前記運行依頼と前記運行計画と前記最終確認通知とを含む情報の交信を行う業者端末側入出力手段とを備えた業者用端末であることを特徴とする。
【００２１】
請求項１０に記載の発明は、請求項９に記載の業者用端末において、前記サーバの記憶する運行グループを検索する検索手段と、前記検索手段の検索した検索結果を出力する第３の出力手段と、前記検索手段の検索した運行グループの含む運行依頼に対する運行計画を入力する第２の入力手段とを備えたことを特徴とする。
【００２２】
請求項１１に記載の発明は、請求項９に記載の業者用端末において、前記サーバからの追加運行依頼信号の受信に応答して、該追加発注信号の含む運行依頼を出力する第４の出力手段と、該運行依頼に対する運行計画を入力する第３の入力手段とを備えたことを特徴とする。
【００２３】
請求項１２に記載の発明は、乗合車両の運行依頼を入力する入力手段と、請求項１から８のいずれかに記載のサーバから受信した前記運行依頼に対する運行計画を出力する第１の出力手段と、前記サーバに対して前記運行計画に対する最終確認を表示する最終確認信号を発信する最終確認信号発信手段と、前記サーバに対して前記運行依頼と前記運行計画とを含む情報の交信を行う顧客用端末側入出力手段とを備えた顧客用端末であることを特徴とする。
【００２４】
請求項１３に記載の発明は、請求項１２に記載の顧客用端末において、前記サーバの記憶する運行グループに対する運行計画を検索する検索手段と、前記検索手段の検索した運行計画に対し運行依頼の追加発注を指示する追加発注信号を発信する追加発注信号発信手段と、前記サーバから受信した前記追加発注への運行計画を出力する第２の出力手段とを備えたことを特徴とする。
【００２５】
請求項１４に記載の発明は、請求項１から８のいずれかに記載のサーバにおいて、前記顧客用端末から受信した乗合車両に対する運行依頼を記憶するとともに、該運行依頼を取り纏めて運行グループを生成するステップと、前記運行グループを記憶するとともに、前記業者用端末に対し、前記運行グループに対する運行を依頼する運行依頼信号を発信するステップと、前記業者用端末から受信した前記運行グループに対する運行計画を記憶するステップと、前記運行計画を前記顧客用端末に送信するステップと、前記顧客用端末からの前記運行計画に対する最終確認信号の受信に応答して前記業者用端末に最終確認通知を送信するステップとを実現させるプログラムであることを特徴とする。
【００２６】
請求項１５に記載の発明は、請求項１４に記載のプログラムにおいて、前記運行グループを生成するステップは、前記運行依頼から処理対象となる運行依頼を抽出するステップと、前記第１の抽出手段の抽出した運行依頼から、最低乗客数を満たす運行依頼を抽出して運行グループを生成するステップとを備えたことを特徴とする。
【００２７】
請求項１６に記載の発明は、請求項１５に記載のプログラムにおいて、前記運行依頼から処理対象となる運行依頼を抽出するステップは、乗合車両乗車日と、到着希望時間または出発希望時間の属する時間帯とをキーとして処理対象となる運行依頼を抽出することを特徴とする。
【００２８】
請求項１７に記載の発明は、請求項１５に記載のプログラムにおいて、前記運行依頼から処理対象となる運行依頼を抽出するステップは、前記顧客用端末から受信した運行依頼の含む乗合車両乗車日と、到着希望時間または出発希望時間の属する時間帯とをキーとして処理対象となる運行依頼を抽出することを特徴とする。
【００２９】
請求項１８に記載の発明は、請求項１５に記載のプログラムにおいて、前記最低乗客数を満たす運行依頼を抽出して運行グループを生成するステップにおいて、運行グループの生成を行うことのできない場合、前記抽出された運行依頼から、同じ固定場所と、所定の隣接度合いの出発地または到着地とを持つ隣接運行依頼を抽出するステップと、前記隣接運行依頼を取り纏めて、最低乗客数を満たす運行グループを生成するステップとを備えたことを特徴とする。
【００３０】
請求項１９に記載の発明は、請求項９から１１のいずれかに記載の業者用端末において、請求項１から８のいずれかに記載のサーバからの前記運行グループに対する運行を依頼する運行依頼信号の受信に応答して、該運行グループの含む運行依頼を出力するステップと、該運行依頼に対する運行計画の入力に応答して、前記業者端末側入出力手段を制御して前記サーバに該運行計画を送信するステップと、前記サーバから受信した前記運行計画に対する最終確認通知を出力するステップとを実現させるプログラムであることを特徴とする。
【００３１】
請求項２０に記載の発明は、請求項１９に記載のプログラムにおいて、前記サーバからの追加運行依頼信号の受信に応答して、該追加発注信号の含む運行依頼を出力するステップと、該運行依頼に対する運行計画の入力に応答して、前記業者端末側入出力手段を制御して前記サーバに該運行計画を送信するステップとを備えたことを特徴とする。
【００３２】
請求項２１に記載の発明は、請求項１０に記載の業者用端末において、請求項１から８のいずれかに記載のサーバの記憶する運行グループを検索し、検索結果を出力するステップと、前記検索結果に対する運行計画の入力に応答して前記サーバに該運行計画を送信するステップと、前記サーバから受信した前記運行計画に対する最終確認通知を出力するステップとを実現させるプログラムであることを特徴とする。
【００３３】
請求項２２に記載の発明は、請求項１２または１３に記載の顧客用端末において、乗合車両の運行依頼の入力に応答して、請求項１から８のいずれかに記載のサーバに該運行依頼を送信するステップと、前記サーバから受信した前記運行依頼に対する運行計画を出力するステップと、前記サーバから受信した前記運行計画に対する最終確認信号を前記サーバに対して発信するステップとを実現させるプログラムであることを特徴とする。
【００３４】
請求項２３に記載の発明は、請求項１３に記載の顧客用端末において、前記サーバの記憶する運行グループに対する運行計画を検索するステップと、前記検索手段の検索した運行計画に対し運行依頼の追加発注を指示する追加発注信号を発信するステップと、前記サーバから受信した前記追加発注に対する運行計画を出力するステップと、前記運行計画に対する最終確認信号を発信するステップと
を実現させるプログラムであることを特徴とする。
【００３５】
請求項２４に記載の発明は、請求項１４から２３のいずれかに記載のプログラムを格納するコンピュータ読取可能な記録媒体であることを特徴とする。
【００３６】
請求項２５に記載の発明は、請求項１から８のいずれかに記載のサーバと、該サーバにネットワークを介して接続された請求項９から１１のいずれかに記載の前記業者用端末と請求項１２または１３に記載の前記顧客用端末とを備えた乗合運行支援システムを用いて乗合運行の支援を行う方法であって、前記顧客用端末において、乗合車両への運行依頼を入力し、前記サーバに送信するステップと、前記サーバにおいて、前記顧客用端末から受信した前記運行依頼を取り纏めて運行グループを生成するステップと、前記サーバにおいて、前記運行グループを記憶するとともに、前記業者用端末に対し、前記運行グループに対する運行を依頼する運行依頼信号を発信するステップと、前記業者用端末において、前記サーバからの前記運行グループに対する運行を依頼する運行依頼信号の受信に応答して、該運行グループの含む運行依頼を出力するステップと、前記業者用端末において、該運行グループに対する運行計画の入力に応答して、前記第１の業者端末側入出力手段を制御して前記サーバに該運行計画を送信するステップと、前記サーバにおいて、前記業者用端末から受信した前記運行計画を記憶し、前記顧客用端末に送信するステップと、前記顧客用端末において、前記サーバから受信した前記運行計画に対する最終確認信号を前記サーバに対して発信するステップと、前記サーバにおいて、前記顧客用端末からの前記運行計画に対する最終確認信号の受信に応答して前記業者用端末に最終確認通知を送信するステップと、前記業者用端末において、前記サーバから受信した前記運行計画に対する最終確認通知を出力するステップとを備えた乗合運行支援方法であることを特徴とする。
【００３７】
【発明の実施の形態】
本発明の実施例について、以下に図面を参照しつつ詳細に説明する。
図１は、本発明の実施される乗合運行支援システムのシステム構成の一例を示す図である。乗合運行支援システムは、サービスセンタ１００と、顧客用端末３００と、業者用端末４００と、サービスセンタ１００と顧客用端末３００と業者用端末４００とを相互に接続するインターネットなどのネットワーク５００とを備える。
【００３８】
サービスセンタ１００は、乗合運行支援システムを運営管理するシステム管理者により管理されるものであり、顧客から受け付けた乗車要求を運行しやすいグループに取り纏め、業者用端末４００に提供する機能を有する。サービスセンタ１００は、ウェブページ用のＨＴＭＬデータ等を格納ＷＷＷサーバ１２０と、乗合グルーピング処理などを実現する処理プログラム実行時の演算処理を行なうデータベースサーバ１４０と、顧客の乗車要求情報などを格納するデータベース２００とを備える。
【００３９】
顧客用端末３００は、乗合運行支援システムを利用する顧客により使用される端末であり、乗合車両への運行依頼を行うことのできる端末であれば、顧客個人が所有する端末でも、顧客以外の他人の所有する端末でも、店舗などの特定の場所に設置された端末でもよい。業者用端末４００は、ハイヤーやタクシー、貸切バスなどの乗合車両の運行を行う乗合車両運行業者により使用される端末である。顧客用端末３００及び業者用端末４００は、いずれもインターネットなどのネットワーク５００を介してサービスセンタ１００にアクセスする機能を有する。
顧客用端末３００及び業者用端末４００の機器としては、ウェブ情報（ＨＴＭＬ文書などのマークアップランゲージ文書により規定される情報）を閲覧可能なブラウザソフトウェア（例えば、マイクロソフト社のインターネットエクスプローラ（商標）、ネットスケープ・コミュニケーション社のネットスケープ(商標)等）を搭載した市販のパーソナルコンピュータ、ＰＤＡ（Personal Data Assistance）等の情報処理装置や、無線呼出端末、ＰＨＳ端末、移動体通信端末のうちいずれかであってもよい。特に、移動体通信端末は、電子メール機能やインターネットへのアクセス機能を有する端末であってもよい（例えば、株式会社エヌ・ティ・ティ・ドコモ社が提供するｉモード（サービス名）端末等）。
【００４０】
ネットワーク５００は、サービスセンタ１００と、顧客用端末３００と業者用端末４００とを相互に接続する機能を有し、例えば、インターネットや、イントラネットや、ＬＡＮや、公衆電話網（アナログ／デジタルの双方を含む）や、ＰＤＣ／ＰＤＣ―Ｐ方式等の移動体通信回線交換網／移動体通信パケット交換網や、無線呼出網や、ＰＨＳ網や、衛星通信網等のうちいずれかを含んでもよい。
【００４１】
図２は、本実施例におけるサービスセンタにおけるデータベースサーバ及び該データベースの構成の一例を示す図である。
本実施例におけるのデータベースサーバ１４０は、少なくとも、バス１４４を介して相互に接続されたシステム全体を統括的に制御する主制御部（以下「ＣＰＵ」とする）１４２と、システム管理者が各種データを入力する入力手段である入力装置１４６と、入力データのモニタに用いる表示装置１４８と、各種監査結果その他のデータを出力する出力装置１５０と、通信回線（有線／無線、ＬＡＮ／インターネット、アナログ／デジタル等を含む）などに接続するモデムやターミナルアダプタなどからなる通信ポート１５２とから構成される。なお、入力装置１４６、表示装置１４８及び出力装置１５０は、それぞれ入出力インターフェースを介してＣＰＵ１４２に接続されていてもよい。なおＣＰＵ１４２は、ＯＳ（Operating System）等の制御プログラムを有し、本実施例における乗合グルーピング処理などを実現する処理プログラム実行時の演算処理を行なう。
【００４２】
データベース２００は、ハードディスク等の固定ディスク装置、フレキシブルディスク、光ディスクなどのストレージ手段であり、乗合グルーピング処理などの各種処理プログラムや、処理プログラムの実現に用いる各種のテーブル、データベース等を格納する。データベース２００は、第１の確定グループデータ２０２、事業者情報データ２０４、第２の確定グループデータ２０６、固定場所データ２０８、ステータスデータ２１０、第１の申込データ２１２、所属地区データ２１４、第２の申込データ２１６、郵便番号データ２１８、ユーザ情報データ２２０、隣接地区データ２２２などを、図２に示すように相互に関連した状態で格納している。
【００４３】
入力装置１４６は、システム管理者が各種データを入力する入力手段であり、画面上のメニューを選択しデータを入力するためのマウス等の各種ポインティングデバイスやキーボードやイメージスキャナなどからなる。表示装置１４８は、各種メニュー画面や、処理結果等を表示する機能を有し、例えばディスプレイ装置等である。出力装置１５０は、処理結果を紙等の媒体に出力する機能を有し、例えばプリンタ装置等である。通信ポート１５２は、他の端末等と通信回線を介してデータを通信する機能を有する。また、サービスセンタ１００は、既知のパーソナルコンピュータ、ワークステーション、ＰＨＳ端末、移動体通信端末、移動体通信端末またはＰＤＡ等の情報処理端末等の情報処理装置にプリンタやディスプレイやイメージスキャナ等の周辺装置を接続し、該情報処理装置に乗合運行支援システムにおける各種処理を実現させるソフトウェア（プログラム、データ等を含む）を実装することにより実現してもよい。
【００４４】
図３は、図２で示したデータベースの格納する各データベースの構造の一例を示す図である。第１の確定グループデータ２０２には、固定場所への運行を希望する運行依頼に関する情報が格納されており、例えば、乗合車両に乗車する構成員である顧客に対するグループＩＤ、当該グループを作成した作成日、当該グループの人数、出発地、到着地の固定場所ＩＤなどの情報が格納されている。第２の確定グループデータ２０６には、固定場所からの運行を希望する運行依頼に関する情報が格納されており、例えば、乗合車両に乗車する構成員である顧客に対するグループＩＤ、当該グループを作成した作成日、当該グループの人数、出発地の固定場所ＩＤ、到着地などの情報が格納されている。
【００４５】
事業者情報データ２０４には、事業者ＩＤ、パスワード、住所、電話番号などの情報が格納されている。固定場所データ２０８には、固定場所として指定されている駅名や空港名などの固定場所名とそのＩＤ、郵便番号などの情報が、図４の▲１▼に示すように相互に関連付けられた固定場所テーブルといった状態で格納されている。ステータスデータ２１０には、第１の確定グループデータ２０２あるいは第１の申込データ２１２などの各種データの状態を示すステータス名、ステータスＩＤなどの情報が、図４の▲３▼に示すように相互に関連付けられたステータステーブルといった状態で格納されている。
【００４６】
第１の申込データ２１２には、固定場所への運行を希望する顧客からの運行依頼に関する情報が格納されており、例えば、運行依頼を行なった申込日時、運行依頼に対して割り当てられた申込番号、運行依頼をしたユーザのユーザＩＤ、到着場所の固定場所ＩＤのほか、出発地の郵便番号や住所、出発日、出発希望時間などの情報が格納されている。第２の申込データ２１６には、固定場所からの運行を希望する顧客からの運行依頼に関する情報が格納されており、例えば、運行依頼を行なった申込日時、運行依頼に対して割り当てられた申込番号、運行依頼をしたユーザのユーザＩＤ、出発場所の固定場所ＩＤのほか、到着地の郵便番号や住所、到着日、到着希望時間などの情報が格納されている。
【００４７】
所属地区データ２１４には、それぞれの地区の住民特性などによる固定場所への利用頻度などに鑑み、各郵便番号が、特定の固定場所との関係においてランク付けがされ、図４の▲２▼に示すように相互に関連付けられた所属地区テーブルといった状態で格納されている。郵便番号データ２１８には、郵便番号と、各郵便番号に基づいて特定される隣接地区などの情報が、図５の▲１▼に示すように相互に関連付けられた郵便番号テーブルといった状態で格納されている。ユーザ情報データ２２０には、運行依頼を行ったユーザのユーザＩＤ、パスワード、住所、電話番号などの情報が格納されている。隣接地区データ２２２には、郵便番号、各郵便番号から特定される隣接地区郵便番号、隣接地区ランクなどの情報が、図５の▲２▼に示すように相互に関連付けられた隣接地区テーブルといった状態で格納されている。
【００４８】
なお、このように構成されたサービスセンタ１００を所有するシステム管理者は、例えばハイヤーやタクシー、貸切バスを保有し、乗合車両の運行を行っているタクシー会社などに対し、顧客の手配を専門に行う業者などであってもよく、また、タクシー会社自身であってもよい。
【００４９】
次に、このように構成された本実施形態における乗合運行支援システムの動作の一例について説明する。
乗合運行支援システムの動作の主なものとしては、顧客から受けた運行予約の取り纏めを行い、それに基づいて乗合車両の運行を行う予約依頼型と、予約依頼型での取り纏め処理に間に合わなかった運行依頼予約や、予約依頼型では取り纏め処理を行うことのできないような細かな運行依頼予約などの取り纏めを行う未確定依頼型と、急な出張などにより、あらかじめ乗合車両の運行予約を行うことのできなかった顧客が、自ら乗合車両の運行状況などをチェックし、既に運行の決定している乗合車両に対して、必要に応じて随時自らの運行依頼をいれていくリアルタイム依頼型とがある。
【００５０】
まず、本実施形態における基本的な処理過程である予約依頼型について説明する。
図６は、顧客から受けた運行予約の取り纏めを行い、それに基づいて乗合車両の運行を行うという、予約依頼型における処理過程の流れの一例を示す図である。
【００５１】
駅や空港へ向かう必要の生じた顧客は、自己の保有する顧客用端末３００からサービスセンタ１００にアクセスし、運行依頼を行う(Ｓ１)。顧客がサービスセンタ１００に運行依頼入力要求を行うと、サービスセンタ１００は顧客用端末３００にユーザＩＤとパスワードなどの認証情報の入力を促すので、まず顧客は、事前にサービスセンタ１００に登録してある認証情報の入力を行う。認証情報を受信すると、サービスセンタ１００のデータベースサーバ１４０は、データベース２００内のユーザ情報データ２２０を検索し、アクセスしてきた顧客に対する認証処理を行う。顧客が認証された場合には、顧客用端末３００には、図７に示すような運行依頼入力画面が送信されるので、顧客はこの運行依頼入力画面から必要事項の入力を行い、サービスセンタ１００に送信し、運行依頼を行なう。
【００５２】
運行依頼入力画面(図７)には、乗合車両に乗車する場所を入力する出発地入力欄７ａ、目的地を入力する到着地入力欄７ｂ、乗車日を入力する出発日入力欄７ｃ、出発希望時間入力欄７ｄ、目的地への到着日を入力する到着日入力欄７ｅなどのほか、飛行機などの出発時間に合わせて目的地に到着したい場合に入力する到着希望時間７ｆ、顧客とともに乗合車両へ乗車する人数を入力する申込人数入力欄７ｇ、前回利用した際の印象などから、運行業者を指定したい場合に入力を行う指定業者入力欄７ｈ、荷物の過多や、小さい子供の有無などの連絡時項を入力する要望事項入力欄７ｉなどが設けられており、顧客はここから少なくとも出発地と到着地、到着希望時間、申込人数の入力を行うことにより運行依頼を行う。図７に示すように、出発地入力欄７ａ、到着地入力欄７ｂ、指定業者入力欄７ｈなどは、あらかじめ登録されている選択肢の中から顧客が選択することにより入力を行う形としてもよい。なお、顧客用端末３００からサービスセンタ１００に運行依頼を行なうためには、顧客は事前にサービスセンタ１００に対して顧客名や住所、パスワードなどの顧客登録を行い、ユーザＩＤの交付を受けておく必要がある。
【００５３】
サービスセンタ１００は、顧客からの運行依頼を受信すると、データベース２００内の第１の申込データ２１２内に受信した情報を格納し、受信した運行依頼に一対一で対応する申込番号の付与を行なった後、顧客用端末３００に対し、顧客に自己が入力した運行依頼を確認させるために、図８に示すような申込内容確認画面を送信する(Ｓ２)。申込内容確認画面(図８)には、顧客が運行依頼入力画面(図７)において入力した事項が表示されている。運行依頼を変更する必要を発見した顧客は、この申込内容確認画面(図８)の「変更」ボタン８ａを選択することにより、一旦登録した運行依頼を変更することもできる。
【００５４】
サービスセンタ１００は、受信した運行依頼を取りまとめ、出発日、出発地、到着地などに基づいて、１つの運行で数人の乗客を効率よく乗車させ、かつ目的地に送り届けることのできるようないくつかの運行グループに割り振る、乗合グルーピング処理を行う（Ｓ３）。この乗合グルーピング処理については、後に詳述する。
【００５５】
次にサービスセンタ１００は、この乗合グルーピング処理(Ｓ３)によって作成した仮確定グループ（仮の運行グループ）に関する運行依頼情報をウェブ情報に掲載することにより、乗合車両運行業者に対してし、Ｓ２で作成したグループに対する車両の手配を行ってくれる乗合車両運行業者を求める運行依頼を行う（Ｓ４）。
【００５６】
乗合車両運行業者は、業者用端末４００からサービスセンタ１００内のＷＷＷサーバ１２０に随時アクセスし、仮確定グループに対する運行依頼情報が掲載されているか否か、運行依頼情報の検索を行う(Ｓ５)。仮確定グループに対する運行依頼情報が掲載されている場合には、業者用端末４００には、図９に示すような仮確定グループ一覧画面が表示される。仮確定グループ一覧画面(図９)には、サービスセンタ１００に登録されている仮確定グループの、グループ番号、到着地、到着希望時間、申込数、申込人数などの情報が掲示されている。仮確定グループ一覧(図９)の中に、関心のある運行依頼を発見した場合は、グループ番号表示欄９ａに表示されているグループ番号の中から関心のある仮確定グループを示すグループ番号を指定することにより、その仮確定グループの詳細情報を取得することができる。
【００５７】
図１０は、グループ番号「１００７」を持つ仮確定グループについての詳細情報を表示した運行グループ詳細表示画面である。運行グループ詳細表示画面(図１０)には、グループ「１００７」を構成している顧客についての、申込番号、顧客名、住所、電話番号、出発希望時間、到着希望時間、申込人数などの情報が表示されている。乗合車両運行業者は、仮確定グループについての詳細情報を取得した上で、運行依頼に応じようとする場合には、「受注及び運行計画作成」ボタン１０ａを操作することにより、運行グループ詳細表示画面(図１０)に表示された仮確定グループからの運行依頼に対する受注を行うことができる。
【００５８】
なお、乗合車両運行業者がサービスセンタ１００に運行依頼情報の検索要求を行うと、サービスセンタ１００は業者用端末４００にユーザＩＤとパスワードなどの認証情報の入力を促すので、乗合車両運行業者は、事前にサービスセンタ１００に登録してある認証情報の入力を行う。認証情報を受信すると、サービスセンタ１００のデータベースサーバ１４０は、データベース２００内の事業者情報データ２０４を検索し、アクセスしてきた乗合車両運行業者に対する認証処理を行う。乗合車両運行業者が認証された場合に、業者用端末４００に仮確定グループ一覧画面(図９)が送信される。したがって、乗合車両運行業者は事前にサービスセンタ１００に対して事業社名、住所、電話番号、パスワードなどを登録し、事業者ＩＤの交付を受けるといった事業者登録を行っておく必要がある。
【００５９】
乗合車両運行業者が、運行グループ詳細表示画面(図１０)の「受注及び運行計画作成」ボタン１０ａを操作することにより仮確定グループからの運行依頼に対する受注を行うと、業者用端末４００には、図１１に示すような運行計画入力画面が表示される。運行計画入力画面(図１１)には、仮確定グループを構成している顧客についての申込番号、顧客名、住所、電話番号、申込人数などの情報が表示されている。乗合車両運行業者は、仮確定グループの構成員である顧客の住所や目的地などを鑑み、適切なルートの選択を行い、目的地に間違いなく顧客の到着希望時間に到着することのできる出発予定時間と顧客との待ち合わせ場所とを選択し、出発予定時間入力欄１１ａから出発予定時間を、待ち合わせ場所入力欄１１ｂから待ち合わせ場所を入力し、料金表示欄１１ｃから運行依頼ごとに運賃を入力する。乗合車両運行業者は、運賃が表示された運行計画入力画面(図１１)の入力内容の確認を行った後、「登録ボタン」１１ｄを押すことにより、サービスセンタ１００に運行計画を送信する(Ｓ７)。
【００６０】
サービスセンタ１００は、データベース２００内の第１の確定グループデータ２０２内に業者用端末４００から受信した運行計画を格納し、それに基づき、顧客用端末３００に対して料金及び運行計画の通知を行う(Ｓ８)。このとき、業者用端末４００から受信した運行計画は、第１の申込データ２１２の記憶するかく運行依頼に対しても格納する。図１２は、顧客用端末３００に表示された料金及び運行計画通知画面の一例である。料金及び運行計画通知画面(図１２)には、顧客名と、申込番号と、その申し込み番号を持つ運行依頼をグルーピング処理したことにより付与されたグループＩＤと、料金と、乗合車両運行業者の指定した待ち合わせ場所と待ち合わせ時間とが表示されているので、顧客は表示内容の確認を行い、「最終確認」ボタン１２ａを操作することにより、運行確認を行う（Ｓ９)。顧客が運行確認を行うと、サービスセンタ１００から顧客用端末３００に対し、図１３に示すような申込確定確認画面が送信されることとなる。
【００６１】
顧客が運行確認を行い、顧客用端末３００に申込確定確認画面（図１３）の送信が行われると、業者用端末４００には、図１４に示すような運行グループ状況確認画面が送信され、これによりＳ７において乗合車両運行業者が送信した運行計画が最終決定される(Ｓ１０)。運行グループ状況確認画面(図１４)には、グループ番号、出発地、到着地、到着予定時間、グループを構成する顧客の申込番号、顧客名、顧客の住所、電話番号、申込人数などのほか、ステータス表示欄１４ａには表示されている各顧客の運行依頼のステータスが表示されている。ステータス表示欄１４ａに表示されるステータスとしては、図４の▲３▼に示す８段階があるが、Ｓ１０においては、各顧客の運行依頼は、各顧客から運行計画に対する最終確認が行われた段階にあるので、ユーザ確認が終わった段階であることを示すステータス「ユーザ確認」が表示されている。
【００６２】
乗合車両運行業者は、最終決定された運行計画に基づき、乗合車両の運行を行い（Ｓ１１）、顧客を目的地へと運び、顧客から運賃の支払を受ける(Ｓ１２)。
その後、乗合車両運行業者は、サービスセンタ１００に対し、運行結果の報告を行い、運行依頼情報を取得したことに対するシステム使用料などの支払を行う(Ｓ１３)。図１５は、乗合車両運行業者が、サービスセンタ１００に対し、運行結果の報告を行う際に入力を行う運行結果報告画面の一例を示す図である。運行結果報告画面(図１５)には、乗合車両運行業者がＳ７で送信を行った運行計画入力画面(図１１)における入力内容が表示されているので、万一実際の運行が運行計画と異なった場合には、人数入力欄１５ａ、出発時間入力欄１５ｂ、待ち合わせ場所入力欄１５ｃ、料金入力欄１５ｄ等から表示内容の修正を行い、「登録」ボタン１５ｅを操作することによりサービスセンタ１００に対して運行結果の報告を行う。
【００６３】
次に、図６のＳ３において行う乗合グルーピング処理について説明する。
図１６は、乗合グルーピング処理の処理手順の一例を示すフローチャートである。乗合グルーピング処理は、図１６に示すように、基本的には、運行依頼の選択(Ｓ１)と、乗合グルーピング結合処理１(Ｓ２)と、乗合グルーピング結合処理２(Ｓ３)とにより行われる。以下、詳細に説明する。
【００６４】
運行依頼の選択(Ｓ１)は、第１の申込データ２１２、あるいは第２の申込データ２１６に格納されている運行依頼のうち、出発到着希望時間が、グルーピング対象指定日のグルーピング指定時間帯にある運行依頼を選択することによって行う。固定場所への行きについての運行依頼に対する乗合グルーピング処理を行う場合は、第１の申込データ２１２に格納されている運行依頼を対象に行い、固定場所からの帰りについての運行依頼に対する乗合グルーピング処理を行う場合は、第２の申込データ２１６に格納されている運行依頼を対象に行う。グルーピング指定時間帯は、午前と午後の２つの時間帯に分けたりするだけでなく、１日を数時間ごとに区切り、いくつかの時間帯を設けたりなどすることにより、グルーピング指定時間帯を複数も受けることもできる。
【００６５】
図１７は、乗合グルーピング結合処理１の処理手順の一例を示すフローチャートであり、この乗合グルーピング結合処理１は、運行依頼の選択(図１６のＳ１)によって選択された運行依頼に対して以下の手順を踏むことによって行われる。
【００６６】
まず、乗合車両運行会社の設定した、乗合車両の運行費用に見合う最低乗客人数である最低乗客人数「ｃ」を満たす申込人数を持つ運行依頼の抽出を行う(Ｓ１)。この運行依頼の抽出は、運行依頼の選択(図１６のＳ１)と同様、固定場所への行きについて乗合グルーピング処理を行う場合は第１の申込データ２１２に格納されている運行依頼を対象に行い、固定場所からの帰りについて乗合グルーピング処理を行う場合は第２の申込データ２１６に格納されている運行依頼を対象に行う。
【００６７】
次に、抽出された運行依頼を一件と読み込み、その人数を「ｐ」とし(Ｓ２)、図１８に示す仮確定グループ決定処理を行う(Ｓ３)。そして、このような処理を、図１６の２のＳ１で抽出した全ての運行依頼に対して行った時点で乗合グルーピング処理１は完了となる(Ｓ４)。
【００６８】
図１８は、仮確定グループ決定処理の処理手順の一例を示すフローチャートである。仮確定グループ決定処理は、まず、乗合グルーピング結合処理１を示す図１７のＳ２において１件として読みこまれた運行依頼に対し、仮のグループＩＤを付与し、仮確定グループを作成する(Ｓ１)。そして、この仮確定グループの運行依頼に基づいて、固定場所ＩＤの付与、出発到着希望時間の抽出を行う。そして、この仮確定グループからの運行依頼に対し「仮確定グループ」状態であることを示すステータス３とし、固定場所ＩＤ、出発到着希望時間、とともに、データベース２００に格納する(Ｓ２)。ここで、仮確定グループの運行依頼を格納する先は、固定場所への行きについて乗合グルーピング処理を行っている場合は第１の確定グループデータ２０２、固定場所からの帰りについて乗合グルーピング処理を行っている場合は第２の確定グループデータ２０６となる。そして、申込番号を手がかりに、第１の申込データ２１２、あるいは第２の申込データ２１６の格納する仮のグループＩＤを付与された運行依頼のステータスを、第１の確定グループデータ２０２、あるいは第２の確定グループデータ２０６と同様に、「仮確定グループ」状態であることを示すステータス３に変更する(Ｓ３)。
【００６９】
なお、仮確定グループ決定処理(図１８)において、固定場所ＩＤは、固定場所への行きについて乗合グルーピング処理を行っている場合は到着地の、固定場所からの帰りについて乗合グルーピング処理を行っている場合は出発地の地名を、図４の▲１▼に示す固定場所データ２０８に照合することにより付与される。例えば、固定場所への行きについて乗合グルーピング処理を行っている場合に、目的地を羽田空港とする運行依頼については、東京国際空港(羽田)を指す固定場所ＩＤ「１」が付与され、目的地を成田空港とする運行依頼については、新東京国際空港(成田)を指す固定場所ＩＤ「２」が付与されることとなる。また、出発到着希望時間は、固定場所への行きについて乗合グルーピング処理を行っている場合は、到着希望日の到着希望時間に基づいて、固定場所からの帰りについて乗合グルーピング処理を行っている場合は、出発希望日の出発希望時間に基づいて定められる。
【００７０】
図１９は、乗合グルーピング結合処理２の処理手順の一例を示すフローチャートである。この乗合グルーピング結合処理２は、乗合グルーピング結合処理１(図１７)を終えた後の、仮のグループＩＤを付与されていない、ばらばらな状態にある運行依頼を相互に関連付け、仮確定グループを作成するためにを行うものである。
【００７１】
まず、乗合グルーピング結合処理２の対象となる運行依頼に対して、固定場所ＩＤの付与を行う(Ｓ１)。固定場所ＩＤは、仮確定グループ決定処理(図１８)における場合と同様、固定場所への行きについて乗合グルーピング処理を行っている場合は到着地の、固定場所からの帰りについて乗合グルーピング処理を行っている場合は出発地の地名を、図４の▲１▼に示す固定場所データ２０８に照合することにより付与される。例えば、固定場所からの帰りについて乗合グルーピング処理を行っている場合に、出発地を羽田空港とする運行依頼については、東京国際空港(羽田)を指す固定場所ＩＤ「１」が付与され、出発地を成田空港とする運行依頼については、新東京国際空港(成田)を指す固定場所ＩＤ「２」が付与されることとなる。
【００７２】
次に、所属地区データ２１４に格納されているテーブルに基づき、固定場所に所属する郵便番号がランク順に抽出される(Ｓ２)。例えば、目的地を羽田空港とする行きの運行依頼について乗合グルーピング処理を行っている場合には、固定場所ＩＤ「１」を持つ運行依頼に対しては、郵便番号「２２７−００５１」地域がランク１として、郵便番号「２２７−００６２」地域がランク２として抽出されることとなる。
【００７３】
そして、図１６のＳ１で運行依頼を選択する際に参照した指定時間帯(例えば指定時間帯「ａ−ｂ」)の開始時間を「ｇ」とする(Ｓ３)。次に仮確定グループを作成するために参照する最大参照地域を示す隣接地区ランクの最大値を「ｈ」、抽出時に参照する隣接地区のランクを「ｉ(抽出開始時の「ｉ」は、出発地あるいは到着地の郵便番号地域と一致することを示す「０」とする)」とする(Ｓ４)。ここで「ｈ」は、郵便番号テーブル（図５の▲１▼）の示す隣接地区Ａ、または隣接地区Ｂから参照する。例えば、郵便番号が「２２７−００５１」の地域については、郵便番号テーブル（図５の▲１▼）の示す隣接地区Ａのランクは「３」、隣接地区Ｂのランクは「５」となっている。よって、この地域の最大参照地域「ｈ」は、固定場所への行きについてグルーピングを行う場合は「３」、固定場所からのから帰りについてグルーピングを行う場合は「５」ということになる。
【００７４】
次に、乗合車両に同乗する顧客が、同乗客との関係で、例えば早めに目的地に到着することとなるような場合に、顧客が目的地で飛行機や電車に乗る時間まで待つこととなる時間幅を「ｋ(抽出開始時の「ｋ」は、全く待ち時間のない状態である「０」とする)」、顧客が許容し得るであろう「ｋ」の最大時間幅を「ｓ」とする(Ｓ５)。ここで「ｓ」は、郵便番号テーブル（図５の▲１▼）の示す、最大時間幅Ｅ、または最大時間幅Ｆから参照する。例えば、郵便番号が「２２７−００５１」の地域については、郵便番号テーブル（図５の▲１▼）の示す最大時間幅Ｅは「３０分」、最大時間幅Ｆは「６０分」となっている。よって、この地域の最大時間幅「ｓ」は、固定場所への行きについてグルーピングを行う場合は「３０分」、固定場所からのから帰りについてグルーピングを行う場合は「６０分」ということになる。
【００７５】
隣接地区データ２２２の格納するテーブルから隣接地区ランク「ｉ」までの郵便番号の検出を行った上で(Ｓ６)、指定時間帯「ａ-ｂ」の開始時間「ｇ」から、時間幅「ｋ」分の範囲内に出発到着希望時間を持ち、出発到着地郵便番号がＳ４で指定された隣接地区ランク「ｉ」内となっている郵便番号群の中にあり、かつ、第１の申込データ２１２、あるいは第２の申込データ２１６の格納する運行依頼のステータスが「未確定」状態を示す「０」となっている運行依頼の抽出を行い、合計人数を算出する(Ｓ７)。ここで、出発到着希望時間は、固定場所への行きについて乗合グルーピング処理を行っている場合は、到着希望日の到着希望時間であり、固定場所からの帰りについて乗合グルーピング処理を行っている場合は、出発希望日の出発希望時間である。
【００７６】
Ｓ８により抽出された運行依頼の合計人数を「ｍ」とし、以下の判断を行う(Ｓ８)。まず、「ｍ」が「０」を超えているか否かの判断を行う(Ｓ９)。「ｍ」が「０」以下である場合、すなわち運行依頼の抽出を行えなかった場合には、後述するＳ１９へと移り、一方「ｍ」が「０」を超えている場合、すなわち運行依頼の抽出があった場合には、「ｍ」が乗合車両運行会社の設定した、乗合車両の運行費用に見合う最低乗客人数である最低乗客人数ｃを満たしているか否かの判断を行う(Ｓ１０)。「ｍ」が「ｃ」未満である場合、すなわち最低乗客人数を有していない場合、後述するＳ１５へと移り、一方「ｍ」が「ｃ」以上、すなわち最低乗客人数を有している場合には、乗合車両運行会社が運行を予定している乗合車両１台あたりの乗車可能人数「ｄ」を「ｍ」が超えていないか否かの判断を行う(Ｓ１１)。
【００７７】
「ｍ」が「ｄ」を超えているような場合には、図２０に示す乗合グループ分割処理を行い、抽出した運行依頼を運行可能な人数に分割するような処理を行う(Ｓ１２)。一方、「ｍ」が「ｄ」以下である場合には、抽出した運行依頼を纏めて運行を行うことができることとなるので、「ｍ」を「ｐ」とし（Ｓ１４）、抽出した運行依頼に対して仮確定グループ決定処理(図１８)を行う（Ｓ１５）。すなわち、当該運行依頼に仮のグループＩＤを付与して仮確定グループを作成し(図１８のＳ１)、第１の確定グループデータ２０２、あるいは第２の確定グループデータ２０６に当該仮確定グループの運行依頼を格納し(図１８のＳ２)、第１の申込データ２１２、あるいは第２の申込データ２１６の格納する運行依頼のステータスを、「仮確定グループ」状態であることを示すステータス３に変更する(図１８のＳ３)。
【００７８】
「ｍ」が最低乗客人数「ｃ」を有していない場合、あるいは後述する乗合グループ分割処理(図２０)によって処理しきれなかった未処理分がある場合、あるいは抽出した運行依頼全てについて仮確定グループ決定処理(図１８)がなされた場合、最低乗客人数「ｃ」人以上乗車可能人数「ｄ」人以下となるようなグループを生成するために、時間幅「ｋ」を「ｔ」づつ広げて(Ｓ１６)、より広い時間幅を用いてＳ７の抽出処理を行う(Ｓ１７)。ここで、時間幅「ｔ」は、固定場所への行きについて乗合グルーピング処理を行っている場合は郵便番号データ２１８に格納されている図５の▲１▼に示す郵便番号テーブルの時間幅Ａを用い、固定場所からの帰りについて乗合グルーピング処理を行っている場合は、郵便番号データ２１８に格納されている図５の▲１▼に示す郵便番号テーブルの時間幅Ｂを用いて行う。そして、時間幅「ｋ」をすこしづつ、例えば時間幅「ｔ」づつ広げた結果、顧客が許容し得るであろう「ｋ」の最大時間幅「ｓ」を「ｋ」が超えてしまったような場合には、時間幅「ｋ」を拡大することによる再抽出をやめ、参照地域の拡大による再抽出、すなわち抽出時に参照する隣接地区のランク「ｉ」を「１」づつ拡大して(Ｓ１８)、より広い参照地域に対してＳ５からの抽出処理を行う(Ｓ１９)。
【００７９】
ここで参照地域「ｉ」を「１」づつ拡大した結果、仮確定グループを作成するために参照する最大抽出地域を示す隣接地区ランクの最大値「ｈ」を「ｉ」が超えてしまったような場合には、参照地域「ｉ」を拡大することによる再抽出をやめ、指定時間帯「ａ-ｂ」の開始時間「ｇ」に顧客が許容し得るであろう「ｋ」の最大時間幅「ｓ」を加えることにより指定時間帯の変更を行う(Ｓ２０)。そして、指定時間帯「ａ-ｂ」の開始時間「ｇ」に最大時間幅「ｓ」を加えた結果が指定時間帯「ａ-ｂ」の終了時間「ｂ」を超えてしまっているか否かの判断を行い(Ｓ２１)、超えてしまった場合には、固定場所の所属地区郵便番号にある郵便番号は全て参照したか否かのチェックを行い(Ｓ２２)、超えていない場合には、再度Ｓ３からの処理を行う。
【００８０】
そして、ｓ２２において、まだ参照を行っていない郵便番号があることが判明した場合には、再度Ｓ２からの処理を行い、一方、全ての郵便番号についての参照を終えている場合には、固定場所データ２０８に格納されている全ての固定場所について処理を終えているかの確認を行う(Ｓ２３)。そして、まだ処理を終えていない固定場所がある場合には、その固定場所についてＳ１からの処理を行い、全ての固定場所について処理を終えている場合には、乗合グループ結合処理２が終了となる。
【００８１】
次に、上述の乗合グループ結合処理２(図１９)のＳ１２、すなわち、乗合グループ結合処理２(図１９)のＳ１１において、乗合車両運行会社が運行を予定している乗合車両１台あたりの乗車可能人数「ｄ」を、Ｓ８により抽出された運行依頼の合計人数「ｍ」が超えている場合に行われる、乗合グループ分割処理について説明する。を行い、抽出した運行依頼を運行可能な人数に分割するような処理を行う(Ｓ１２)。
【００８２】
図２０は、乗合グループ分割処理の処理手順の一例を示すフローチャートである。
まず、乗合グループ結合処理２(図１９)のＳ１１において、乗合車両運行会社が運行を予定している乗合車両１台あたりの乗車可能人数「ｄ」を超えているＳ８により抽出された運行依頼の合計人数「ｍ」に対して、指定時間帯「ａ-ｂ」の開始時間「ｇ」から、時間幅「ｋ」分の範囲内に出発到着希望時間を持ち、出発到着地郵便番号がＳ４で指定された隣接地区ランク「ｉ」内となっている郵便番号群の中にあり、かつ、第１の申込データ２１２、あるいは第２の申込データ２１６の格納する運行依頼のステータスが「未確定」状態を示す「０」となっている運行依頼の抽出を行う(Ｓ１)。そして、抽出された運行依頼の合計人数を「ｎ」とする(Ｓ２)。次に、運行依頼の合計人数を「ｎ」が乗合車両１台あたりの乗車可能人数「ｄ」を超えているか否かの判断を行い(Ｓ３)、超えていない場合には、その運行依頼の合計人数を「ｎ」を「ｐ」とし(Ｓ４)、図１８に示す仮確定グループ決定処理を行い(Ｓ５)、運行依頼の合計人数を「ｎ」を「０」として処理を終了する(Ｓ６)。
【００８３】
一方、運行依頼の合計人数を「ｎ」が乗合車両１台あたりの乗車可能人数「ｄ」を超えている場合には、抽出している運行依頼を、最低乗客人数「ｃ」人以上乗車可能人数「ｄ」人以下になるように分割してグループを生成する(Ｓ７)。この運行依頼の合計人数「ｎ」の分割は、ステータスが「０」の運行依頼に対し、例えば申込日の早い順に抽出してグループを生成したり、利用回数などに基づく顧客ランクの高い順に抽出してグループを生成したり、運行依頼登録時に登録された要望事項に基づいてグループを作成したりすることなどにより行う。なお、１グループの人数を最低乗客人数「ｃ」人以上乗車可能人数「ｄ」人以下とするために、１つの運行依頼内の申込人数を分割することはできない。そして、合計人数を「ｎ」を分割することにより生成したグループの人数を「ｐ」とし(Ｓ８)、図１８に示す仮確定グループ決定処理を行い(Ｓ９)、運行依頼の合計人数を「ｎ」からグループ人数「ｐ」の控除を行い(Ｓ１０)、グループ人数「ｐ」の控除後の人数が最低乗客人数「ｃ」人以上か否かの判断を行う(Ｓ１１)。最低乗客人数「ｃ」人以上である場合には、さらに「ｎ」を分割してグループを作成できることとなることから、再度Ｓ３からの処理を行う。一方、最低乗客人数「ｃ」人未満である場合には、そこで乗合グループ分割処理が終了となる。
【００８４】
次に、未確定依頼型の処理過程について説明する。
未確定依頼型は、サービスセンタ１００が受け付けた運行依頼を事業者の運行ニーズに基づいて組み合わせ、運行ルートの決定を行うという点において、顧客の運行依頼に基づき運行ルートの組合せを行う上述の予約依頼型と異なるものである。そのため、予約依頼型での処理を前提とせずに未確定依頼型での処理を行うこととしても良い。また、既に２、３人からの運行依頼を受注してはいるが、まだ乗合車両の定員には余裕があるような乗合車両運行業者が、より運行の効率を上げようと、既に受注している運行依頼と近いルートでの運行を希望する顧客からの運行依頼を個別に受注するために利用することなどが考えられる。
【００８５】
図２１は、未確定依頼型における処理過程の流れの一例を示す図である。
駅や空港へ向かう必要の生じた顧客は、自己の保有する顧客用端末３００からサービスセンタ１００にアクセスし、運行依頼を行う(Ｓ１)。顧客がサービスセンタ１００に運行依頼入力要求を行うと、サービスセンタ１００は顧客用端末３００にユーザＩＤとパスワードなどの認証情報の入力を促すので、まず顧客は、事前にサービスセンタ１００に登録してある認証情報の入力を行う。認証情報を受信すると、サービスセンタ１００のデータベースサーバ１４０は、データベース２００内のユーザ情報データ２２０を検索し、アクセスしてきた顧客に対する認証処理を行う。顧客が認証された場合には、顧客用端末３００には、図７に示すような運行依頼入力画面が送信されるので、顧客はこの運行依頼入力画面から必要事項の入力を行い、サービスセンタ１００に送信し、運行依頼を行なう。
【００８６】
顧客は運行依頼入力画面(図７)から少なくとも出発地と到着地、到着希望時間、申込人数の入力を行うことにより運行依頼を行う。なお、予約依頼型同様、顧客用端末３００からサービスセンタ１００に運行依頼を行なうためには、顧客は事前にサービスセンタ１００に対して顧客名や住所、パスワードなどの顧客登録を行い、ユーザＩＤの交付を受けておく必要がある。
【００８７】
サービスセンタ１００は、顧客からの運行依頼を受信すると、データベース２００内の第１の申込データ２１２内に受信した情報を格納し、受信した運行依頼に一対一で対応する申込番号の付与を行なった後、顧客用端末３００に対し、顧客に自己が入力した運行依頼を確認させるために、図８に示すような申込内容確認画面を送信する(Ｓ２)。申込内容確認画面(図８)には、顧客が運行依頼入力画面(図７)において入力した事項が表示されている。運行依頼を変更する必要を発見した顧客は、この申込内容確認画面(図８)の「変更」ボタン８ａを選択することにより、一旦登録した運行依頼を変更することもできる。
【００８８】
乗合車両運行業者は、業者用端末４００からサービスセンタ１００内のＷＷＷサーバ１２０に随時アクセスし、顧客が登録した運行依頼情報の検索を行う(Ｓ３)。乗合車両運行業者からのアクセスを受け、サービスセンタ１００は業者用端末４００に対し、図２２に示すような未確定運行依頼一覧を送信する。未確定運行依頼一覧画面(図２２)には、サービスセンタ１００に登録されている各運行依頼の申込番号、到着地、到着希望時間、申込数、申込人数などの情報が掲示されている。乗合車両運行業者は、未確定運行依頼一覧画面(図２２)の中に、関心のある運行依頼を発見した場合は、申込番号表示欄２２ａに表示されている申込番号の中から関心のある運行依頼を示す申込番号を指定することにより、その運行依頼についての詳細情報を取得することができる。
【００８９】
図２３は、申込番号「０３１０」を持つ運行依頼についての詳細情報を表示した運行依頼詳細表示画面である。運行依頼詳細表示画面(図２３)には、運行依頼「００５４」についての、申込番号、顧客名、住所、電話番号、出発希望時間、到着希望時間、申込人数などの情報が表示されている。乗合車両運行業者は、運行依頼についての詳細情報を取得した上で運行依頼に応じようとする場合には、乗合車両運行業者が「受注及び運行計画作成」ボタン２３ａを操作することにより、業者用端末４００に表示される追加申込依頼受注登録画面(図２４)から運行計画を入力することによりその運行依頼に対する受注を行うことができる。
【００９０】
なお、乗合車両運行業者がサービスセンタ１００に運行依頼情報の検索要求を行うと、サービスセンタ１００は業者用端末４００にユーザＩＤとパスワードなどの認証情報の入力を促すので、乗合車両運行業者は、事前にサービスセンタ１００に登録してある認証情報の入力を行う。認証情報を受信すると、サービスセンタ１００のデータベースサーバ１４０は、データベース２００内の事業者情報データ２０４を検索し、アクセスしてきた乗合車両運行業者に対する認証処理を行う。乗合車両運行業者が認証された場合に、業者用端末４００に未確定運行依頼一覧画面(図２２)が送信されることとなる。したがって、乗合車両運行業者は事前にサービスセンタ１００に対して事業社名、住所、電話番号、パスワードなどを登録し、事業者ＩＤの交付を受けるといった事業者登録を行う必要がある。
【００９１】
乗合車両運行業者が、運行依頼詳細表示画面(図２３)の「受注及び運行計画作成」ボタン２３ａを操作することにより、業者用端末４００には図２４のような追加申込依頼受注登録画面が表示される。追加申込依頼受注登録画面（図２４）には、運行依頼を行った顧客についての申込番号、顧客名、住所、電話番号、申込人数などの情報が表示されている。乗合車両運行業者は、顧客の住所や目的地などを鑑み、適切なルートの選択を行い、目的地に間違いなく顧客の到着希望時間に到着することのできる出発予定時間と顧客との待ち合わせ場所とを選択し、確定グループ番号入力欄２４ａから運行依頼を追加しようとする運行計画の確定グループ番号（グループＩＤ）を入力する。そして、出発予定日入力欄２４ｂから出発予定日を、出発予定時間入力欄２４ｃから出発予定時間を、待ち合わせ場所入力欄２４ｄから待ち合わせ場所を、料金表示欄２４ｆから運賃をそれぞれ入力する。乗合車両運行業者は、追加申込依頼受注登録画面（図２４）の入力内容の確認を行った後、「登録ボタン」２４ｇを押すことにより、サービスセンタ１００に運行計画を送信し、未確定運行依頼の受注を行う(Ｓ４)。
【００９２】
サービスセンタ１００は、データベース２００内の第１の確定グループデータ２０２内に業者用端末４００から運行計画を受信した運行計画を格納し、それに基づき、顧客用端末３００に対して料金及び運行計画の通知を行う(Ｓ５)。図１２は、顧客用端末３００に表示された料金及び運行計画通知画面の一例である。
料金及び運行計画通知画面(図１２)には、顧客名と、申込番号と、その申し込み番号を持つ運行依頼をグルーピング処理したことにより付与されたグループＩＤと、料金と、乗合車両運行業者の指定した待ち合わせ場所と待ち合わせ時間とが表示されているので、顧客は表示内容の確認を行い、「最終確認」ボタン１２ａを操作することにより、運行確認を行う（Ｓ６)。顧客が運行確認を行うと、サービスセンタ１００から顧客用端末３００に対し、図１３に示すような申込確定確認画面が送信されることとなる。
【００９３】
顧客が運行確認を行い、顧客用端末３００に申込確定確認画面（図１３）の送信が行われると、業者用端末４００には、図１４に示すような運行グループ状況確認画面が送信され（Ｓ７）、これによりＳ４において乗合車両運行業者が送信した運行計画が最終決定される(Ｓ８)。運行グループ状況確認画面(図１４)には、今回受注を行なった申込番号「００５４」についての申込番号、出発地、到着地、到着予定時間、顧客名、顧客の住所、電話番号、申込人数などのほか、当該乗合車両運行業者が既に受注している他の運行依頼についての申込番号、出発地、到着地、到着予定時間、顧客名、顧客の住所、電話番号、申込人数などの情報も掲示されている。なお、ステータス表示欄１４ａには、各顧客から運行計画に対する最終確認が行われた段階であることを示すステータス「ユーザ確認」が表示されている。
【００９４】
乗合車両運行業者は、サービスセンタ１００から運行グループ状況確認画面(図１４)の業者用端末４００への送信により最終決定された運行グループにて、運行計画に基づいて乗合車両の運行を行い（Ｓ９）、顧客を目的地へと運び、顧客から運賃の支払を受ける(Ｓ１０)。その後、乗合車両運行業者は、サービスセンタ１００に対し、運行結果の報告を行い、運行依頼情報を取得したことに対するシステム使用料などの支払を行う(Ｓ１１)。図１５は、乗合車両運行業者が、サービスセンタ１００に対し、運行結果の報告を行う際に入力を行う運行結果報告画面の一例を示す図である。
【００９５】
次に、リアルタイム依頼型について説明する。リアルタイム依頼型は、顧客自らがサービスセンタ１００に既に決まっている他の運行計画の検索を行い、個々の運行計画に対する乗車の可否の判断を行い、同乗したい運行計画に発注を行うという点において、顧客の運行依頼に基づき運行ルートの組合せを行う予約依頼型や、事業者の運行ニーズに基づいて運行依頼を組み合わせる未確定依頼型と異なるものである。
【００９６】
図２５は、リアルタイム依頼型における処理過程の流れの一例を示す図である。
駅や空港へ向かう必要の生じた顧客は、自己の保有する顧客用端末３００からサービスセンタ１００にアクセスし、運行依頼を行う(Ｓ１)。顧客がサービスセンタ１００に運行依頼入力要求を行うと、サービスセンタ１００は顧客用端末３００にユーザＩＤとパスワードなどの認証情報の入力を促すので、まず顧客は、事前にサービスセンタ１００に登録してある認証情報の入力を行う。認証情報を受信すると、サービスセンタ１００のデータベースサーバ１４０は、データベース２００内のユーザ情報データ２２０を検索し、アクセスしてきた顧客に対する認証処理を行う。顧客が認証された場合には、顧客用端末３００には、図２６に示すようなリアルタイム運行依頼入力画面が送信されるので、顧客はこの運行依頼入力画面から必要事項の入力を行う。
【００９７】
リアルタイム運行依頼入力画面(図２６)には、図７の運行依頼入力画面同様、乗合車両に乗車する場所を入力する出発地入力欄２６ａ、目的地を入力する到着地入力欄２６ｂ、乗車日を入力する出発日入力欄２６ｃ、出発希望時間入力欄２６ｄ、目的地への到着日を入力する到着日入力欄２６ｅなどのほか、飛行機などの出発時間に合わせて目的地に到着したい場合に入力する到着希望時間２６ｆ、顧客とともに乗合車両へ乗車する人数を入力する申込人数入力欄２６ｇ、前回利用した際の印象などから、運行業者を指定したい場合に入力を行う指定業者入力欄２６ｈ、荷物の過多や、小さい子供の有無などの連絡時項を入力する要望事項入力欄２６ｉなどが設けられており、顧客はここから少なくとも出発地と到着地、到着希望時間、申込人数の入力を行うことにより運行依頼を行う。なお、予約依頼型同様、顧客用端末３００からサービスセンタ１００に運行依頼を行なうためには、顧客は事前にサービスセンタ１００に対して顧客名や住所、パスワードなどの顧客登録を行い、ユーザＩＤの交付を受けておく必要がある。
【００９８】
次に顧客は、リアルタイム運行依頼入力画面(図２６)にある「確定グループ一覧検索」ボタン２６ｊを操作することにより、既に運行の決定している他の運行計画の抽出を行う（Ｓ２）。図２７は、リアルタイム運行依頼入力画面(図２６)にある「確定グループ一覧検索」ボタン２６ｊを操作した顧客の顧客用端末３００にサービスセンタ１００から送信された運行決定グループ一覧画面を示す図である。運行決定グループ一覧画面（図２７）には、既に運行を行うことが決定されている運行計画のグループ番号、出発地、到着地、到着予定時間、指定業者、運行決定グループを構成している運行依頼の申込数、グループの合計人数などが表されている。顧客は、出発地や到着地、到着予定時間、合計人数などに鑑み、この運行決定グループ一覧画面（図２７）の中に、自分の運行依頼の追加を行うことのできそうな運行決定グループがあるか否かを探す。自分の運行依頼の追加を行うことのできそうな運行決定グループがあった場合は、グループ番号表示欄２７ａに表示されているグループ番号の中から自分の運行依頼の追加を行うことのできそうな運行決定グループを示すグループ番号を指定することにより、追加申込の発注を行う（Ｓ３）。
【００９９】
サービスセンタ１００は、顧客用端末３００から追加申込の発注を受けると、追加申込のされた既決定運行グループを運行する乗合車両運行業者の業者用端末４００に、図２８に示すような追加申込依頼一覧を送信し、決定運行への顧客追加依頼を行なう（Ｓ４）。
【０１００】
追加申込依頼一覧（図２８）には、サービスセンタ１００が受信した追加申込依頼についての申込番号、到着地、出発希望時間、到着希望時間、追加申込の行われた既決定運行グループのグループ番号、追加申込のされた人数などが表示されている。乗合車両運行業者は、既決定運行グループについての運行計画の確認を行い、追加申込に応じるか否かの判断を行う（Ｓ５）。追加申込に応じることができるか否か判断するにあたり、追加申込依頼一覧画面（図２８）の申込番号表示欄２８ａから、応じることのできそうな追加申込の申し込み番号を指定することにより、その追加申込についての詳細情報を取得することができる。
【０１０１】
図２９は、申込番号「４５０１」を持つ追加申込依頼についての詳細情報を表示した追加申込依頼詳細表示画面である。追加申込依頼詳細表示画面(図２９)には、申込番号「４５０１」を持つ追加申込についての、申込番号、顧客名、住所、電話番号、出発希望時間、到着希望時間、申込人数などの情報が表示されている。
乗合車両運行業者は、これら詳細情報を取得した上で、追加申込依頼に応じようとする場合には、「受注及び運行計画作成」ボタン２９ａを操作することにより受注を行うことができる。
【０１０２】
乗合車両運行業者が、「受注及び運行計画作成」ボタン２９ａを操作すると、業者用端末４００には、図３０に示すような追加申込依頼受注登録画面が表示される。追加申込依頼受注登録画面(図３０)には、追加申込依頼を行なった顧客についての申込番号、顧客名、到着地、到着希望時間、申込人数などの情報が表示されている。乗合車両運行業者は、既に運行を決定している運行計画に鑑み、追加申込依頼を追加するための適切なルートの選択を行い、目的地に間違いなく顧客の到着希望時間に到着することのできる出発予定時間と顧客との待ち合わせ場所とを選択し、出発予定日入力欄３０ａから出発予定日の、出発予定時間入力欄３０ｂから出発予定時間の、待ち合わせ場所入力欄３０ｂから待ち合わせ場所の、料金表示欄３０ｅから運賃の入力を行う。乗合車両運行業者は、追加申込依頼受注登録画面(図３０)の入力内容の確認を行った後、「登録ボタン」３０ｆを操作することにより、サービスセンタ１００に既決定運行計画に対する追加申込依頼への受注を送信する(Ｓ６)。
【０１０３】
サービスセンタ１００は、データベース２００内の第１の確定グループデータ２０２内に業者用端末４００から運行計画を受信した運行計画を格納し、それに基づき、顧客用端末３００に対して申込内容の確認と、料金及び運行計画の通知を行うための申込内容確認画面（図３１）を送信する(Ｓ７)。申込内容確認画面(図３１)には、顧客名と、申込番号と、出発地、到着地、到着希望時間、人数、追加申込依頼の追加された既決定運行グループのグループＩＤ、料金と、乗合車両運行業者の指定した待ち合わせ場所と待ち合わせ時間とが表示されているので、顧客は表示内容の確認を行い、「最終確認」ボタン３１ａを操作することにより、運行確認を行う（Ｓ８)。
【０１０４】
顧客が運行確認を行うと、業者用端末４００には、図１４に示すような運行グループ状況確認画面が送信され（Ｓ９）、これによりＳ７において乗合車両運行業者が送信した運行計画が最終決定される(Ｓ１０)。運行グループ状況確認画面(図１４)には、グループ番号、出発地、到着地、到着予定時間、グループを構成する顧客の申込番号、顧客名、顧客の住所、電話番号、申込人数、ステータスなどが表示されている。運行グループ状況確認画面(図１４)のステータス表示欄１４ａに表示されるステータスは、各顧客の運行依頼が、各顧客から運行計画に対する最終確認が行われた段階にあることを示すステータス「ユーザ確認」が表示されている。
【０１０５】
乗合車両運行業者は、最終決定された運行計画に基づき、乗合車両の運行を行い（Ｓ１１）、顧客を目的地へと運び、顧客から運賃の支払を受ける(Ｓ１２)。
その後、乗合車両運行業者は、サービスセンタ１００に対し、運行結果の報告を行い、運行依頼情報を取得したことに対するシステム使用料などの支払を行う(Ｓ１３)。図１５は、乗合車両運行業者が、サービスセンタ１００に対し、運行結果の報告を行う際に入力を行う運行結果報告画面の一例を示す図である。運行結果報告画面(図１５)には、乗合車両運行業者がＳ６で送信を行った追加申込依頼受注登録画面(図３０)における入力内容が表示されているので、万一実際の運行が運行計画と異なった場合には、出発時間入力欄１５ａ、待ち合わせ場所入力欄１５ｂ、料金入力欄１５ｃ、到着時間入力欄１５ｇから表示内容の修正を行い、「登録」ボタン１５ｄを操作することによりサービスセンタ１００に対して運行結果の報告を行う。
【０１０６】
次に、他の実施の形態について説明する。
上述した実施の形態においては、固定場所からの行きか帰りかでデータベースを分け、顧客用端末３００から入力された運行依頼が固定場所への行きである場合は第１の申込データ２１２に、固定場所からの帰りであれば第２の申込データ２１６２、また固定場所への行きについての運行決定グループに関する情報であれば第１の確定グループデータ２０２に、固定場所からの帰りについての運行決定グループに関する情報であれば第２の確定グループデータ２０６に、それぞれ分けて格納する場合を一例について説明したが、本発明はこの場合に限定されるものではなく、他の実施の形態においては、固定場所への行きか帰りかで格納するデータベースを分けることなく、１つのデータベースに運行依頼、または運行決定グループに関する情報を格納することも考えられる。
【０１０７】
上述した実施の形態においては、予約依頼型処理、未確定依頼型処理、リアルタイム依頼型処理のそれぞれを個別に説明したが、本発明はこの場合に限定されるものではなく、他の実施の形態においては、予約依頼型処理と未確定依頼型処理とリアルタイム依頼型処理とを組み合わせて、例えば予約依頼型処理を行った後に未確定依頼型処理を行ったり、あるいは未確定依頼型処理を行った後にリアルタイム依頼型処理を行ったり、予約依頼型処理を行った後にリアルタイム依頼型を行ったり、予約依頼型処理、未確定依頼型処理、リアルタイム依頼型処理の順に全ての形態の処理を行うこととしてもよい。
【０１０８】
また、上述した実施の形態においては、乗合グルーピング処理を行う際に参照する隣接地区データを設定するにあたり、郵便番号に基づいて隣接地区ランクを設定する場合を一例に説明したが、本発明はこの場合に限定されるものではなく、他の実施の形態においては、例えば電話番号の局番を用いたり、市販の地図データベースを用いて隣接地区データを設定することも考えられる。
【０１０９】
また、上述した実施の形態においては、運行グループを作成する際に、対象となる運行依頼の受付けをある時間で区切り、それら運行依頼の含む時間帯や、目的地などの基づいて乗合グルーピング処理を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施の形態においては、運行グループの作成にあたって運行依頼の受けつけ時間を区切ることなく、例えば顧客用端末３００から運行依頼を受け付け次第、その受けつけた運行依頼の含む時間帯や、目的地などに基づいて、随時運行グループを作成することも考えられる。
【０１１０】
また、上述の図２１に示した未確定依頼型の処理においては、乗合車両運行業者が運行依頼を追加受注する際、どの運行計画に追加して受注するのかをあらかじめ特定して受注を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施の形態においては、運行依頼の追加受注を行う際に、どの運行計画に追加して受注するのかを特定することなく、自由に運行依頼を受注させることも考えられる。その際には、追加申込依頼受注画面（図２４）の確定グループ番号入力欄２４ａから、確定グループ番号を入力することなく空白としたままサービスセンタ１００に運行計画を送信する、とすることが考えられる。
【０１１１】
また、上述の図２５に示すリアルタイム依頼型処理においては、顧客の運行依頼と全く異なる出発地、到着地などを持つ運行決定グループの表示も含めて表示する運行決定グループ一覧画面（図２７）の中から、顧客自らが自己の運行依頼の追加を行うことのできそうな運行決定グループを探し出し、追加申込の発注を行う場合を一例に説明したが、本発明はこの場合に限定されるものではない。他の実施の形態においては、顧客用端末３００からの確定グループ一覧検索要求の受信に応答して、サービスセンタ１００において顧客が図２５のＳ１において入力した運行依頼に含まれる出発地、到着地、乗車日などの情報をもとに顧客の運行依頼を追加することのできそうな運行確定グループの検索を行い、運行決定グループ一覧画面（図２７）を表示する顧客用端末３００の表示画面上に表示させ、その中から顧客に追加申込の発注を行わせることも考えられる。
【０１１２】
また、上述した実施の形態においては、顧客が、顧客用端末３００からサービスセンタ１００にアクセスする際に、顧客に対しユーザＩＤ、パスワードなどの認証情報を入力させ、認証処理を行う場合を一例に説明したが、本発明はこの場合に限定されるものではなく、他の実施の形態においては、アクセス時ではなく、運行依頼をサービスセンタ１００に送信する際にユーザＩＤ、パスワードなどの認証情報を入力させ、認証処理を行うことも考えられる。
【０１１３】
以上述べたように、本実施形態によれば、顧客用端末から入力された運行依頼をサーバが取り纏めることにより、乗合車両運行業者は、運行しやすい状態に纏められた複数の乗客を効率よく獲得できる。また、本実施形態によれば、顧客は、既に運行の決定している乗合グループに対して自己の運行依頼を追加できることにより、好きなときに希望する場所から目的地まで希望する時間に楽に移動することのできる、安価で新しい交通手段を得ることができる。
【０１１４】
【発明の効果】
以上述べたように、請求項１〜７、９、１２、１４〜１９、２２、２４、２５に記載の発明によれば、乗合車両運行業者は、運行しやすい状態に纏めた複数の乗客を効率よく取得でき、顧客は、好きなときに、希望する場所から目的地まで希望する時間に楽に移動することのできる安価で新しい交通手段を得ることができる。
【０１１５】
また、請求項１０、２１に記載の発明によれば、運行依頼の入力された時間や、利用人数、利用地域などの関係で運行グループ取り纏めの対象からはずれてしまったような運行依頼であっても、既に運行の決定している乗合グループに吸収することにより乗合車両の運行対象とすることができる。
【０１１６】
また、請求項８、１１、１３、２０、２３に記載の発明によれば、既に運行の決定している運行グループに対して顧客自身が自己の運行依頼を追加できることにより、顧客は、あらかじめ運行依頼の予約を行っていなくても、希望する場所から目的地まで希望する時間に楽に移動することのできる、安価で新しい交通手段を得ることができる。
【図面の簡単な説明】
【図１】本発明の実施される乗合運行支援システムのシステム構成の一例を示す図である。
【図２】本実施例におけるサービスセンタにおけるデータベースサーバ及び該データベースの構成の一例を示す図である。
【図３】データベースの格納する各データベースの構造の一例を示す図である。
【図４】データベースのデータ格納例を示す図である。
【図５】データベースのデータ格納例を示す図である。
【図６】予約依頼型における処理過程の流れの一例を示す図である。
【図７】運行依頼入力画面の一例を示す図である。
【図８】申込内容確認画面の一例を示す図である。
【図９】仮確定グループ一覧画面の一例を示す図である。
【図１０】運行グループ詳細表示画面の一例を示す図である。
【図１１】運行計画入力画面の一例を示す図である。
【図１２】料金及び運行計画通知画面の一例を示す図である。
【図１３】申込確定確認画面の一例を示す図である。
【図１４】運行グループ状況確認画面の一例を示す図である。
【図１５】運行結果報告画面の一例を示す図である。
【図１６】乗合グルーピング処理の処理手順の一例を示すフローチャートである。
【図１７】乗合グルーピング結合処理の処理手順の一例を示すフローチャートであ
【図１８】仮確定グループ決定処理の処理手順の一例を示すフローチャートである。
【図１９】乗合グルーピング結合処理の処理手順の一例を示すフローチャートである。
【図２０】乗合グループ分割処理の処理手順の一例を示すフローチャートである。
【図２１】未確定依頼型における処理過程の流れの一例を示す図である。
【図２２】未確定運行依頼一覧の一例を示す図である。
【図２３】運行依頼詳細表示画面の一例を示す図である。
【図２４】追加申込依頼受注登録画面の一例を示す図である。
【図２５】リアルタイム依頼型顧客における処理過程の流れの一例を示す図である。
【図２６】リアルタイム運行依頼入力画面の一例を示す図である。
【図２７】運行決定グループ一覧画面の一例を示す図である。
【図２８】追加申込依頼一覧の一例を示す図である。
【図２９】追加申込依頼詳細表示画面の一例を示す図である。
【図３０】追加申込依頼受注登録画面の一例を示す図である。
【図３１】申込内容確認画面の一例を示す図である。
【符号の説明】
１００サービスセンタ
１２０ＷＷＷサーバ
１４０データベースサーバ
１４２主制御部（ＣＰＵ）
１４４バス
１４６入力装置
１４８表示装置
１５０出力装置
１５２通信ポート
２００データベース
２０２第１の確定グループデータ
２０４事業者情報データ
２０６第２の確定グループデータ
２０８固定場所データ
２１０ステータスデータ
２１２第１の申込データ
２１４所属地区データ
２１６第２の申込データ
２１８郵便番号データ
２２０ユーザ情報データ
２２２隣接地区データ
３００顧客用端末
４００業者用端末
５００ネットワーク[0001]
BACKGROUND OF THE INVENTION
More particularly, the present invention relates to an operation support system and a method therefor, and more specifically, in an online database management system, operation support for a shared vehicle is performed by collecting operation requests received from customers and notifying a shared vehicle operator. The present invention relates to a riding operation support system and method.
[0002]
[Prior art]
When heading to a station or airport to get on a train or plane that departs on a specific day or at a specific time, it is normal to change trains or buses. A taxi that takes you to your destination with no need to transfer once is an ideal means of transportation, but it is often avoided because it is expensive and if you have large luggage or some people In fact, it is often used only when heading to the destination.
[0003]
As a way to use this ideal transportation taxi more cheaply, at some stations and airports, some passengers who want to move to a specific location are gathered and departed when a certain number of people gather. There is a shared taxi service that takes you to a certain place.
[0004]
[Problems to be solved by the invention]
However, the conventional shared taxi attracts customers at a specific location such as an airport and determines the operation by grouping the customers on an ad hoc basis. there were. Currently, taxi service reservations are made exclusively via telephone or the Internet, but the process of making reservations made in this way and the operation decision process between passenger car operators have been established. Therefore, there is a problem that if the number of reservations increases in the future, it is not possible to efficiently process the operation reservation.
[0005]
In addition, although there are many shared vehicle operators that operate shared taxis, there is no established operation decision system that can manage their operation status, so customers can operate shared taxis under the desired conditions. There was also a problem that we had to make individual inquiries about prices, departure places, etc. until we found a contractor.
[0006]
This situation has also been a problem for shared vehicle operating companies that operate taxis and the like. Although there are many potential customers who want to use a taxi if the cost does not increase, it is difficult for taxi drivers themselves to gather their customers' ride requests and find passengers. There was also a problem that a profit opportunity could not be obtained unless a few passengers were discovered or a passenger taxi was visited and collected.
[0007]
The present invention has been made in view of such problems, and the object of the present invention is to efficiently provide a plurality of passengers gathered in an easy-to-operate state to a shared vehicle operator who operates a shared vehicle such as a taxi. It is also possible to provide a passenger operation support system that can provide a low-cost new transportation means that can be easily moved from a desired place to a destination at a desired time when desired.
[0008]
Moreover, the objective of this invention can implement | achieve efficiently providing several passengers put together in the state which is easy to drive | operate with respect to the server with which a riding operation support system is provided, and the operator's terminal to a riding vehicle operator. To provide a program. Another object of the present invention is to provide a program that can provide a low-cost new transportation means that can easily move from a desired place to a destination at a desired time when desired. .
[0009]
In addition, the object of the present invention is to efficiently provide a plurality of passengers gathered in an easy-to-operate state to a shared vehicle operator, and it is easy for customers to move from a desired place to a destination at a desired time when they like. It is to provide a shared operation support method that can provide new transportation means at a low cost.
[0010]
[Means for Solving the Problems]
In order to achieve such an object, the invention described in claim 1 includes a server for providing ride information to a vendor terminal and a customer terminal, and the vendor terminal connected to the server via a network. And a server in the shared operation support system comprising the customer terminal, and a first storage means for storing the operation request for the shared vehicle received from the customer terminal, and generating the operation group by collecting the operation request Operation group generating means, second storage means for storing the operation group generated by the operation group generating means, and a request signal for transmitting an operation request signal for requesting operation for the operation group to the trader terminal. Sending means, third storage means for storing an operation plan for the operation group received from the supplier terminal, and the customer terminal In response to receiving the final confirmation signal to the trip plan of et, characterized in that it is a server that includes a confirmation notice transmitting means for transmitting a final confirmation notification to 該運 line plan to the skilled terminal.
[0011]
Here, “shared vehicle” means taxi, hire, chartered bus, shared bus, shared taxi and the like. “Operating request” refers to a request made by a customer to request operation of a shared vehicle. The departure date, desired departure time, arrival date, desired arrival time, destination or departure location such as a station or airport name, etc. , Including the number of users. “Operating group” refers to a group of customers operated by one shared vehicle.
[0012]
According to a second aspect of the present invention, in the server according to the first aspect, the operation group generation unit includes a first extraction unit that extracts an operation request to be processed from the operation request, and the first extraction. And a first grouping means for generating an operation group by extracting an operation request satisfying the minimum number of passengers from the operation request extracted by the means.
[0013]
Here, the “minimum number of passengers” refers to the number of passengers who will be able to make a profit when the shared vehicle operating company operates one shared vehicle.
[0014]
According to a third aspect of the present invention, in the server according to the second aspect, the first extraction unit is configured to process a vehicle as a processing object using a shared vehicle boarding date and a time zone to which a desired arrival time or a desired departure time belongs. The operation request is extracted.
[0015]
According to a fourth aspect of the present invention, in the server according to the second aspect, the first extracting means includes a shared vehicle boarding date and a desired arrival time or a desired departure time included in the operation request received from the customer terminal. The operation request to be processed is extracted using the time zone to which the key belongs as a key.
[0016]
The invention according to claim 5 is the same as the server according to claim 2, when the first grouping unit cannot generate the operation group, from the operation request extracted by the first extraction unit. A second extracting means for extracting an adjacent operation request having a fixed place and a departure or arrival place having a predetermined degree of adjacency; and a second operation group that generates the operation group that satisfies the minimum number of passengers by collecting the adjacent operation requests. And a grouping means.
[0017]
According to a sixth aspect of the present invention, in the server according to the fifth aspect, the degree of adjacency is determined based on a preset adjacent district table.
[0018]
According to a seventh aspect of the present invention, in the server according to the sixth aspect, the adjacent district table divides a region based on a zip code, and determines the degree of adjacency between the regions for each division. It is characterized by.
[0019]
The invention according to claim 8 is the server according to claim 1, in response to receiving the additional order signal of the operation request to the operation plan stored in the second storage means from the customer terminal, An additional request signal transmitting means for transmitting an additional operation request signal to the operation plan is provided to the vendor terminal.
[0020]
Invention of Claim 9 outputs the operation request which this operation group contains in response to reception of the operation request signal which requests the operation with respect to the said operation group from the server in any one of Claim 1-8 First output means, first input means for inputting an operation plan for the operation request, second output means for outputting a final confirmation notice for the operation plan received from the server, the server, and the It is a merchant terminal provided with a merchant terminal side input / output means for exchanging information including an operation request, the operation plan, and the final confirmation notice.
[0021]
A tenth aspect of the present invention is the trader terminal according to the ninth aspect, wherein the search means for searching for the operation group stored in the server and the third output means for outputting the search result searched by the search means. And a second input means for inputting an operation plan for an operation request included in the operation group searched by the search means.
[0022]
The invention according to claim 11 is the fourth output for outputting the operation request included in the additional ordering signal in response to the reception of the additional operation request signal from the server in the terminal for the trader according to claim 9. And a third input means for inputting an operation plan for the operation request.
[0023]
Invention of Claim 12 is the 1st output means which outputs the operation plan with respect to the said operation request received from the server in any one of Claim 1 to 8 which inputs the operation request of a shared vehicle A final confirmation signal transmitting means for transmitting a final confirmation signal for displaying a final confirmation for the operation plan to the server, and a customer for communicating information including the operation request and the operation plan to the server It is a customer's terminal provided with the terminal side input / output means.
[0024]
The invention according to claim 13 is the customer terminal according to claim 12, wherein the search means for searching for the operation plan for the operation group stored in the server, and the operation request for the operation plan searched by the search means. An additional order signal transmitting means for transmitting an additional order signal for instructing an additional order, and a second output means for outputting an operation plan for the additional order received from the server are provided.
[0025]
According to a fourteenth aspect of the present invention, in the server according to any one of the first to eighth aspects, an operation request for the shared vehicle received from the customer terminal is stored, and an operation group is generated by collecting the operation requests. Storing the operation group, sending an operation request signal for requesting operation to the operation group to the operator terminal, and an operation plan for the operation group received from the operator terminal. Storing the operation plan, transmitting the operation plan to the customer terminal, and transmitting a final confirmation notification to the vendor terminal in response to receiving a final confirmation signal for the operation plan from the customer terminal. It is a program that realizes the above.
[0026]
According to a fifteenth aspect of the present invention, in the program according to the fourteenth aspect, the step of generating the operation group includes a step of extracting an operation request to be processed from the operation request, and a step of the first extraction means. And a step of generating an operation group by extracting an operation request satisfying the minimum number of passengers from the extracted operation request.
[0027]
According to a sixteenth aspect of the present invention, in the program according to the fifteenth aspect, the step of extracting the operation request to be processed from the operation request includes: a ride date of the shared vehicle and a time to which the desired arrival time or the desired departure time belongs An operation request to be processed is extracted using a band as a key.
[0028]
According to a seventeenth aspect of the present invention, in the program according to the fifteenth aspect, the step of extracting an operation request to be processed from the operation request includes: a boarding date of the shared vehicle included in the operation request received from the customer terminal; The operation request to be processed is extracted using the time zone to which the desired arrival time or the desired departure time belongs as a key.
[0029]
The invention according to claim 18 is the program according to claim 15, wherein in the step of generating an operation group by extracting an operation request that satisfies the minimum number of passengers, an operation group cannot be generated, From the extracted operation requests, a step of extracting an adjacent operation request having the same fixed location and a starting or arriving place of a predetermined degree of adjacency, and an operation group satisfying the minimum number of passengers by collecting the adjacent operation requests. And a generating step.
[0030]
The invention according to claim 19 is an operation request signal for requesting operation for the operation group from the server according to any one of claims 1 to 8 in the terminal for a vendor according to any of claims 9 to 11. In response to receiving the operation request, the operation request included in the operation group is output, and in response to the operation plan input for the operation request, the operator terminal side input / output means is controlled to control the operation plan to the server. , And a step of outputting a final confirmation notification for the operation plan received from the server.
[0031]
The invention according to claim 20 is the program according to claim 19, wherein in response to receiving the additional operation request signal from the server, the operation request included in the additional order signal is output; and the operation request In response to the input of the operation plan for the device, the operator terminal side input / output means is controlled to transmit the operation plan to the server.
[0032]
The invention according to claim 21 is the merchant terminal according to claim 10, wherein the operation group stored in the server according to any one of claims 1 to 8 is searched and the search result is output; A program that realizes the steps of transmitting the operation plan to the server in response to the input of the operation plan for the search result, and outputting the final confirmation notice for the operation plan received from the server. To do.
[0033]
According to a twenty-second aspect of the present invention, in the customer terminal according to the twelfth or thirteenth aspect, the operation request is sent to the server according to any one of the first to eighth aspects in response to an input of the operation request for the shared vehicle. A program that realizes the steps of: transmitting an operation plan for the operation request received from the server; and transmitting a final confirmation signal for the operation plan received from the server to the server. It is characterized by being.
[0034]
According to a twenty-third aspect of the present invention, in the customer terminal according to the thirteenth aspect, a step of searching for an operation plan for an operation group stored in the server, and an operation request added to the operation plan searched by the search means Transmitting an additional order signal for instructing an order; outputting an operation plan for the additional order received from the server; transmitting a final confirmation signal for the operation plan;
It is the program which implement | achieves.
[0035]
A twenty-fourth aspect of the present invention is a computer-readable recording medium storing the program according to any one of the fourteenth to twenty-third aspects.
[0036]
A twenty-fifth aspect of the invention is the server according to any one of the first to eighth aspects, and the vendor terminal according to any one of the ninth to eleventh aspects connected to the server via a network. Item 14. A method for supporting a ride operation using a ride operation support system including the customer terminal according to item 12 or 13, wherein an operation request to a ride vehicle is input at the customer terminal, Transmitting to the server; in the server, generating the operation group by collecting the operation requests received from the customer terminal; and storing the operation group in the server; Sending an operation request signal for requesting operation for the operation group; and in the vendor terminal, the operation group from the server. In response to receiving an operation request signal for requesting an operation for the operation group, and outputting the operation request included in the operation group, and in response to an input of an operation plan for the operation group in the terminal for the merchant, the first Controlling the trader terminal side input / output means and transmitting the operation plan to the server; storing the operation plan received from the trader terminal in the server; and transmitting the operation plan to the customer terminal. And, at the customer terminal, transmitting a final confirmation signal for the operation plan received from the server to the server; and at the server, for receiving a final confirmation signal for the operation plan from the customer terminal. In response, sending a final confirmation notice to the merchant terminal; received from the server at the merchant terminal; Wherein the serial is vans operation support method comprising the steps of outputting a final confirmation notification to the trip plan.
[0037]
DETAILED DESCRIPTION OF THE INVENTION
Embodiments of the present invention will be described below in detail with reference to the drawings.
FIG. 1 is a diagram showing an example of a system configuration of a riding operation support system in which the present invention is implemented. The shared operation support system includes a service center 100, a customer terminal 300, a dealer terminal 400, and a network 500 such as the Internet that connects the service center 100, the customer terminal 300, and the dealer terminal 400 to each other. .
[0038]
The service center 100 is managed by a system administrator who manages and manages the shared operation support system. The service center 100 has a function of collecting boarding requests received from customers into easy-to-operate groups and providing them to the merchant terminal 400. The service center 100 stores HTML data for web pages and the like, a WWW server 120, a database server 140 that performs arithmetic processing when executing a processing program that realizes multiplicative grouping processing, and a database that stores customer boarding request information and the like 200.
[0039]
The customer terminal 300 is a terminal used by a customer who uses the shared operation support system, and can be a terminal that can make an operation request to a shared vehicle. Or a terminal installed in a specific place such as a store. The trader's terminal 400 is a terminal used by a shared vehicle operator who operates shared vehicles such as hire, taxis, and chartered buses. Each of the customer terminal 300 and the vendor terminal 400 has a function of accessing the service center 100 via the network 500 such as the Internet.
As the devices of the customer terminal 300 and the vendor terminal 400, browser software that can browse web information (information defined by markup language documents such as HTML documents) (for example, Internet Explorer (trademark) of Microsoft Corporation, Netscape)・ Even if it is a commercially available personal computer equipped with Communication Netscape (trademark), PDA (Personal Data Assistance) or other information processing apparatus, a wireless calling terminal, a PHS terminal, or a mobile communication terminal Good. In particular, the mobile communication terminal may be a terminal having an electronic mail function or an internet access function (for example, an i-mode (service name) terminal provided by NTT DoCoMo, Inc.). .
[0040]
The network 500 has a function of connecting the service center 100, the customer terminal 300 and the vendor terminal 400 to each other. For example, the Internet, an intranet, a LAN, a public telephone network (both analog / digital) Or a mobile communication circuit switching network / mobile communication packet switching network such as a PDC / PDC-P system, a wireless paging network, a PHS network, a satellite communication network, or the like.
[0041]
FIG. 2 is a diagram illustrating an example of a database server and a configuration of the database in the service center according to the present embodiment.
The database server 140 in this embodiment includes at least a main control unit (hereinafter referred to as “CPU”) 142 that comprehensively controls the entire system connected to each other via the bus 144, and various data An input device 146 that is an input means, a display device 148 used for monitoring input data, an output device 150 that outputs various audit results and other data, and a communication line (wired / wireless, LAN / Internet, analog / A communication port 152 including a modem, a terminal adapter, and the like that are connected to a digital terminal. Note that the input device 146, the display device 148, and the output device 150 may be connected to the CPU 142 via input / output interfaces, respectively. The CPU 142 has a control program such as an OS (Operating System), and performs arithmetic processing when executing a processing program that realizes multiplicative grouping processing in the present embodiment.
[0042]
The database 200 is a storage unit such as a fixed disk device such as a hard disk, a flexible disk, or an optical disk, and stores various processing programs such as multiplicative grouping processing, and various tables and databases used for realizing the processing programs. The database 200 includes first confirmed group data 202, business operator information data 204, second confirmed group data 206, fixed location data 208, status data 210, first application data 212, belonging district data 214, second Application data 216, postal code data 218, user information data 220, adjacent district data 222, and the like are stored in a mutually related state as shown in FIG.
[0043]
The input device 146 is an input means for the system administrator to input various data, and includes various pointing devices such as a mouse for selecting a menu on the screen and inputting data, a keyboard, an image scanner, and the like. The display device 148 has a function of displaying various menu screens, processing results, and the like, and is a display device, for example. The output device 150 has a function of outputting the processing result to a medium such as paper, and is, for example, a printer device. The communication port 152 has a function of communicating data with other terminals through a communication line. The service center 100 also includes known personal computers, workstations, PHS terminals, mobile communication terminals, mobile communication terminals, peripheral devices such as printers, displays, and image scanners, as well as information processing terminals such as PDAs. And connecting the information processing apparatus with software (including programs, data, etc.) that implements various processes in the riding operation support system.
[0044]
FIG. 3 is a diagram showing an example of the structure of each database stored in the database shown in FIG. In the first confirmed group data 202, information related to an operation request for operation to a fixed place is stored. For example, a group ID for a customer who is a member on a shared vehicle, a creation that creates the group Information such as the date, the number of people in the group, the departure place, and the fixed place ID of the arrival place are stored. In the second confirmed group data 206, information related to an operation request for operation from a fixed place is stored. For example, a group ID for a customer who is a member of a shared vehicle, a creation of the group Information such as the date, the number of people in the group, the fixed place ID of the departure place, and the arrival place are stored.
[0045]
The company information data 204 stores information such as company ID, password, address, and telephone number. In the fixed location data 208, fixed location names such as station names and airport names designated as fixed locations, and information such as IDs and postal codes are associated with each other as shown in (1) in FIG. It is stored as a location table. In the status data 210, information such as status names and status IDs indicating the states of various data such as the first confirmed group data 202 or the first application data 212 are mutually indicated as indicated by (3) in FIG. Stored in a state such as an associated status table.
[0046]
The first application data 212 stores information related to an operation request from a customer who wants to operate to a fixed place. For example, the application date and time when the operation request is made, and the application number assigned to the operation request. In addition to the user ID of the user who made the operation request and the fixed place ID of the arrival place, information such as the postal code and address of the departure place, the departure date, and the desired departure time are stored. The second application data 216 stores information related to operation requests from customers who wish to operate from a fixed location. For example, the application date and time when the operation request was made, and the application number assigned to the operation request. In addition to the user ID of the user who requested the operation and the fixed place ID of the departure place, information such as the postal code and address of the arrival place, the arrival date, and the desired arrival time are stored.
[0047]
In the affiliation district data 214, each zip code is ranked in relation to a specific fixed location in consideration of the frequency of use in a fixed location due to the characteristics of residents in each district, etc. As shown, it is stored in a state such as an affiliated district table associated with each other. In the zip code data 218, information such as the zip code and the adjacent district specified based on each zip code is stored in a state of a zip code table associated with each other as shown in (1) of FIG. ing. The user information data 220 stores information such as the user ID, password, address, and telephone number of the user who made the operation request. In the adjacent district data 222, information such as the zip code, the adjacent district zip code specified from each zip code, and the adjacent district rank are related to each other as shown in (2) of FIG. Is stored in.
[0048]
In addition, the system administrator who owns the service center 100 configured in this way specializes in customer arrangements to taxi companies that own hire, taxis, chartered buses, and operate shared vehicles. It may be a business operator or the taxi company itself.
[0049]
Next, an example of operation | movement of the riding together support system in this embodiment comprised in this way is demonstrated.
The main operation of the shared operation support system is to organize operation reservations received from customers, and based on that, the reservation request type that operates shared vehicles, and the operation that is not in time for the reservation request type It is possible to make reservations for shared vehicles in advance by request reservations and unconfirmed request types that organize detailed operation request reservations that cannot be handled by the reservation request type and sudden business trips. There is a real-time request type in which a customer who has not checked the operation status of the shared vehicle by himself / herself and enters his / her operation request as needed for the shared vehicle that has already been determined to operate.
[0050]
First, a reservation request type that is a basic processing process in the present embodiment will be described.
FIG. 6 is a diagram illustrating an example of a flow of a processing process in a reservation request type in which operation reservations received from customers are collected and a shared vehicle is operated based on the operation reservations.
[0051]
A customer who needs to go to the station or airport accesses the service center 100 from the customer terminal 300 owned by the customer and makes an operation request (S1). When the customer makes an operation request input request to the service center 100, the service center 100 prompts the customer terminal 300 to input authentication information such as a user ID and a password, so the customer first registers with the service center 100 in advance. Enter some authentication information. When the authentication information is received, the database server 140 of the service center 100 searches the user information data 220 in the database 200 and performs an authentication process for the accessing customer. When the customer is authenticated, an operation request input screen as shown in FIG. 7 is transmitted to the customer terminal 300, so that the customer inputs necessary items from the operation request input screen, and the service center 100 And request operation.
[0052]
In the operation request input screen (FIG. 7), a departure place input field 7a for inputting a place to board the shared vehicle, an arrival place input field 7b for inputting a destination, a departure date input field 7c for inputting a boarding date, a departure desired In addition to the time input field 7d, the arrival date input field 7e for inputting the arrival date at the destination, the desired arrival time 7f that is input when the user wants to arrive at the destination in accordance with the departure time of the airplane, etc., to the shared vehicle with the customer Application number input field 7g for entering the number of passengers, Designated supplier input field 7h to be entered when you want to specify the operator from the impression of the last use, etc. A request item input field 7i for inputting a term is provided, and a customer makes an operation request by inputting at least a departure place and an arrival place, a desired arrival time, and the number of applicants. As shown in FIG. 7, the departure place input field 7a, the arrival place input field 7b, the designated trader input field 7h, and the like may be input by the customer selecting from previously registered options. In order to make an operation request from the customer terminal 300 to the service center 100, the customer performs customer registration with the service center 100 in advance such as a customer name, an address, and a password, and receives a user ID. There is a need.
[0053]
When the service center 100 receives the operation request from the customer, the service center 100 stores the received information in the first application data 212 in the database 200 and assigns an application number corresponding to the received operation request on a one-to-one basis. After that, an application content confirmation screen as shown in FIG. 8 is transmitted to the customer terminal 300 in order to make the customer confirm the operation request input by the customer (S2). On the application content confirmation screen (FIG. 8), items entered by the customer on the operation request input screen (FIG. 7) are displayed. The customer who has found that the operation request needs to be changed can change the operation request once registered by selecting the “change” button 8a on the application content confirmation screen (FIG. 8).
[0054]
The service center 100 collects the received operation requests, and based on the departure date, departure place, arrival place, etc., the service center 100 can efficiently carry several passengers and deliver them to the destination in one operation. The grouping process for assigning to the operation group is performed (S3). This multiplication grouping process will be described in detail later.
[0055]
Next, the service center 100 publishes operation request information regarding the provisionally confirmed group (temporary operation group) created by the riding grouping process (S3) in the web information, so that the service center 100 handles the sharing vehicle operator in S2. An operation request is made for a shared vehicle operator who arranges vehicles for the created group (S4).
[0056]
The shared vehicle operator accesses the WWW server 120 in the service center 100 from time to time from the operator terminal 400, and searches for the operation request information as to whether or not the operation request information for the provisionally confirmed group is posted (S5). When the operation request information for the provisionally confirmed group is posted, a temporary confirmation group list screen as shown in FIG. On the temporary confirmation group list screen (FIG. 9), information such as the group number, arrival place, desired arrival time, number of applications, number of applicants, etc. of the temporary confirmation groups registered in the service center 100 is posted. In the temporary confirmation group list (Fig. 9), if an interesting service request is found, specify the group number indicating the temporary confirmation group of interest from the group numbers displayed in the group number display field 9a. By doing so, it is possible to acquire detailed information of the provisionally confirmed group.
[0057]
FIG. 10 is an operation group detail display screen that displays detailed information about the provisionally confirmed group having the group number “1007”. On the operation group details display screen (FIG. 10), information such as application number, customer name, address, telephone number, desired departure time, desired arrival time, number of applicants, etc., for the customers making up the group “1007” is displayed. It is displayed. When the shared vehicle operator acquires detailed information about the provisionally confirmed group and intends to respond to the operation request, the operation group detail display screen is operated by operating the “order and operation plan creation” button 10a. An order for the operation request from the temporary confirmation group displayed in FIG. 10 can be made.
[0058]
When the shared vehicle operator makes a search request for operation request information to the service center 100, the service center 100 prompts the operator terminal 400 to input authentication information such as a user ID and a password. The authentication information registered in the service center 100 in advance is input. When the authentication information is received, the database server 140 of the service center 100 searches the operator information data 204 in the database 200, and performs an authentication process for the accessing shared vehicle operator. When the shared vehicle operator is authenticated, the provisionally confirmed group list screen (FIG. 9) is transmitted to the vendor terminal 400. Therefore, it is necessary for the shared vehicle operator to register the business company name, address, telephone number, password, and the like with the service center 100 in advance and perform business registration such as receiving a business ID.
[0059]
When the shared vehicle operator performs an order for an operation request from the provisionally confirmed group by operating the “order received and operation plan creation” button 10a on the operation group detail display screen (FIG. 10), An operation plan input screen as shown in FIG. 11 is displayed. On the operation plan input screen (FIG. 11), information such as an application number, a customer name, an address, a telephone number, the number of applicants, etc., for the customers making up the provisional confirmation group is displayed. The shared vehicle operator will select the appropriate route in consideration of the address and destination of the customer who is a member of the provisional confirmation group, and will be able to arrive at the destination at the desired arrival time without fail. A time and a meeting place with the customer are selected, a scheduled departure time is input from the scheduled departure time input field 11a, a waiting place is input from the waiting place input field 11b, and a fare is input for each operation request from the charge display field 11c. The shared vehicle operator confirms the input contents on the operation plan input screen (FIG. 11) on which the fare is displayed, and then transmits the operation plan to the service center 100 by pressing the “registration button” 11d (S7). ).
[0060]
The service center 100 stores the operation plan received from the vendor terminal 400 in the first confirmed group data 202 in the database 200, and notifies the customer terminal 300 of the charge and the operation plan based on the operation plan (see FIG. S8). At this time, the operation plan received from the vendor terminal 400 is also stored for the operation request stored in the first application data 212. FIG. 12 is an example of the charge and operation plan notification screen displayed on the customer terminal 300. In the charge and operation plan notification screen (FIG. 12), the customer name, application number, group ID given by grouping the operation request with the application number, the charge, and the designation of the shared vehicle operator Since the waiting place and the waiting time are displayed, the customer confirms the display contents and operates the “final confirmation” button 12a to confirm the operation (S9). When the customer confirms the operation, an application confirmation confirmation screen as shown in FIG. 13 is transmitted from the service center 100 to the customer terminal 300.
[0061]
When the customer confirms the operation and the application confirmation confirmation screen (FIG. 13) is transmitted to the customer terminal 300, the operation group status confirmation screen as shown in FIG. Thus, the operation plan transmitted by the riding vehicle operator in S7 is finally determined (S10). On the operation group status confirmation screen (Fig. 14), in addition to the group number, departure location, arrival location, estimated arrival time, customer application number, customer name, customer address, telephone number, number of applicants, etc. In the status display column 14a, the status of the operation request of each displayed customer is displayed. As the status displayed in the status display column 14a, there are 8 stages shown in (3) in FIG. 4. In S10, the operation request of each customer is the stage when the final confirmation of the operation plan from each customer is performed. Therefore, the status “user confirmation” indicating that the user confirmation is completed is displayed.
[0062]
The shared vehicle operator operates the shared vehicle based on the final determined operation plan (S11), carries the customer to the destination, and receives payment of the fare from the customer (S12).
Thereafter, the shared vehicle operator reports the operation result to the service center 100 and pays the system usage fee for acquiring the operation request information (S13). FIG. 15 is a diagram illustrating an example of an operation result report screen that is input when a shared vehicle operator reports an operation result to the service center 100. On the operation result report screen (FIG. 15), since the input contents in the operation plan input screen (FIG. 11) transmitted by the shared vehicle operator in S7 are displayed, the actual operation should be different from the operation plan. In such a case, the display content is corrected from the number of people input field 15a, the departure time input field 15b, the waiting place input field 15c, the charge input field 15d, etc., and the "registration" button 15e is operated to Report the operation results.
[0063]
Next, the multiplication grouping process performed in S3 of FIG. 6 will be described.
FIG. 16 is a flowchart illustrating an example of a processing procedure of the multiplicative grouping processing. As shown in FIG. 16, the riding grouping process is basically performed by selecting an operation request (S1), a riding grouping combining process 1 (S2), and a riding grouping combining process 2 (S3). Details will be described below.
[0064]
In the operation request selection (S1), among the operation requests stored in the first application data 212 or the second application data 216, the desired departure and arrival time is in the grouping specified time zone on the grouping target specified date. This is done by selecting an operation request. When performing the grouping process for the travel request for the fixed place, the grouping process for the service request for the return from the fixed place is performed for the service request stored in the first application data 212. When performing, the operation request stored in the 2nd application data 216 is made into object. The grouping specified time zone can be divided into two time zones, AM and PM, as well as by dividing the day into several hours and setting several time zones. Can also be received.
[0065]
FIG. 17 is a flowchart showing an example of a processing procedure of the riding grouping combination process 1. This riding grouping combining process 1 is performed as follows for the operation request selected by the operation request selection (S1 in FIG. 16). It is done by stepping on.
[0066]
First, an operation request having an application number satisfying the minimum number of passengers “c”, which is the minimum number of passengers set for the operation cost of the shared vehicle set by the shared vehicle operating company, is extracted (S1). As in the case of selecting an operation request (S1 in FIG. 16), this operation request is extracted for the operation request stored in the first application data 212 when the ride grouping process is performed on the way to the fixed place. When the grouping process is performed for the return from the fixed place, the operation request stored in the second application data 216 is targeted.
[0067]
Next, the extracted operation request is read as one case, the number of persons is set to “p” (S2), and the provisionally confirmed group determination process shown in FIG. 18 is performed (S3). And when such a process is performed with respect to all the operation requests extracted by S1 of 2 of FIG. 16, the riding grouping process 1 is completed (S4).
[0068]
FIG. 18 is a flowchart illustrating an example of the processing procedure of the provisionally confirmed group determination process. In the temporary confirmation group determination process, first, a temporary group ID is assigned to the operation request read as one case in S2 of FIG. 17 showing the shared grouping combination process 1 to create a temporary confirmation group (S1). . And based on the operation request of this provisionally confirmed group, assignment of fixed place ID and extraction of departure arrival desired time are performed. Then, the operation request from the temporary confirmation group is set to status 3 indicating that it is in the “provisional confirmation group” state, and is stored in the database 200 together with the fixed place ID and the desired departure and arrival time (S2). Here, the destination for storing the operation request of the provisional confirmation group is the first confirmation group data 202 when the grouping process is performed on the way to the fixed place, and the grouping process is performed on the return from the fixed place. If there is, the second confirmed group data 206 is obtained. Then, using the application number as a clue, the status of the operation request given the temporary group ID stored in the first application data 212 or the second application data 216 is changed to the first confirmed group data 202 or the second Similarly to the confirmed group data 206, the status is changed to status 3 indicating the “provisional confirmed group” state (S3).
[0069]
In the provisional confirmation group determination process (FIG. 18), the fixed place ID is subjected to the multiplicative grouping process for the return from the fixed place when the multiplicative grouping process is performed for the fixed place. In this case, the place name of the departure place is given by collating with the fixed place data 208 shown in (1) of FIG. For example, when a grouping process is performed for going to a fixed place, a fixed place ID “1” indicating Tokyo International Airport (Haneda) is assigned to an operation request with the destination as Haneda Airport, and the destination is Will be given a fixed location ID “2” indicating New Tokyo International Airport (Narita). In addition, when the departure and arrival desired time is undergoing a grouping process for going to a fixed place, the grouping process for a return from a fixed place is performed based on the desired arrival time on the arrival date. This is determined based on the desired departure time at the departure desired sunrise.
[0070]
FIG. 19 is a flowchart illustrating an example of a processing procedure of the multiplicative grouping combination processing 2. This multiplicative grouping combining process 2 creates a temporary fixed group by associating disjoint operation requests that have not been assigned temporary group IDs after finishing multiplicative grouping combining process 1 (FIG. 17). To do.
[0071]
First, a fixed place ID is assigned to an operation request that is a target of the grouping grouping process 2 (S1). As in the case of the provisional fixed group determination process (FIG. 18), the fixed place ID is obtained by performing the grouping process on the return of the arrival place and the return from the fixed place when the grouping process is performed on the way to the fixed place. If there is, the place name of the departure place is given by collating with the fixed place data 208 shown in (1) of FIG. For example, when a grouping process is performed for a return from a fixed location, a fixed location ID “1” indicating Tokyo International Airport (Haneda) is assigned to an operation request with the departure location as Haneda Airport. Will be given a fixed location ID “2” indicating New Tokyo International Airport (Narita).
[0072]
Next, based on the table stored in the affiliated district data 214, the postal codes belonging to the fixed location are extracted in the rank order (S2). For example, when the grouping process is performed for an operation request destined for Haneda Airport as the destination, the postal code “227-0051” area is ranked for the operation request having the fixed place ID “1”. 1, the postal code “227-0062” area is extracted as rank 2.
[0073]
And the start time of the designated time zone (for example, designated time zone "ab") referred when selecting the operation request in S1 of FIG. 16 is set to "g" (S3). Next, “h” is set as the maximum value of the adjacent district rank indicating the maximum reference area to be referred to in order to create the provisional confirmation group, and “i (“ i ”at the start of extraction is“ "0" indicating that it matches the postal code area of the place or the arrival place) (S4). Here, “h” is referred to from the adjacent district A or the adjacent district B shown in the postal code table ((1) in FIG. 5). For example, in the area where the postal code is “227-0051”, the rank of the adjacent district A indicated by the postal code table ((1) in FIG. 5) is “3”, and the rank of the adjacent district B is “5”. Yes. Therefore, the maximum reference area “h” of this area is “3” when grouping is performed for going to a fixed place, and is “5” when grouping is performed for returning from a fixed place.
[0074]
Next, if the customer who rides in the shared vehicle is arriving at the destination earlier, for example, in relation to the passenger, the customer will wait until the time to get on the plane or train at the destination. The time width is “k” (“k” at the start of extraction is assumed to be “0”, which has no waiting time) ”, and the maximum time width of“ k ”that the customer can accept is“ s ”. (S5). Here, “s” is referred to from the maximum time width E or the maximum time width F shown in the postal code table ((1) in FIG. 5). For example, in the area where the postal code is “227-0051”, the maximum time width E shown in the postal code table ((1) in FIG. 5) is “30 minutes” and the maximum time width F is “60 minutes”. Yes. Therefore, the maximum time width “s” in this area is “30 minutes” when grouping for a fixed place, and “60 minutes” when returning from a fixed place.
[0075]
After detecting the zip codes from the table stored in the adjacent district data 222 to the adjacent district rank “i” (S6), the time width “k” is calculated from the start time “g” of the designated time zone “ab”. The first application data is within the zip code group that has the desired arrival time within the range of “” and the departure and arrival place zip code is in the adjacent district rank “i” specified in S4. 212, or the operation request in which the status of the operation request stored in the second application data 216 is “0” indicating the “indeterminate” state is extracted, and the total number of people is calculated (S7). Here, the departure and arrival desired time is the desired arrival time on the desired arrival date when the shared grouping process is performed for the way to the fixed place, and when the shared grouping process is performed for the return from the fixed place. The desired departure time from departure.
[0076]
The total number of operation requests extracted in S8 is set to “m”, and the following determination is made (S8). First, it is determined whether or not “m” exceeds “0” (S9). If “m” is equal to or less than “0”, that is, if the operation request cannot be extracted, the process proceeds to S19 described later, while if “m” exceeds “0”, that is, the operation request If there is an extraction, it is determined whether or not “m” satisfies the minimum number of passengers c set by the shared vehicle operating company, which is the minimum number of passengers corresponding to the operating cost of the shared vehicle (S10). When “m” is less than “c”, that is, when it does not have the minimum number of passengers, the process proceeds to S15 to be described later, while when “m” is equal to or more than “c”, that is, when it has the minimum number of passengers In step S11, it is determined whether or not “m” exceeds the number of passengers “d” that can be boarded per shared vehicle scheduled to be operated by the shared vehicle operating company.
[0077]
When “m” exceeds “d”, the riding group division process shown in FIG. 20 is performed, and the extracted operation request is divided into the number of people who can operate (S12). On the other hand, when “m” is equal to or less than “d”, the extracted operation requests can be operated together. Therefore, “m” is set to “p” (S14), and the extracted operation requests are included. On the other hand, provisional confirmation group determination processing (FIG. 18) is performed (S15). That is, a provisional group ID is assigned to the operation request to create a provisional confirmation group (S1 in FIG. 18), and the operation of the provisional confirmation group is added to the first confirmation group data 202 or the second confirmation group data 206. The request is stored (S2 in FIG. 18), and the status of the operation request stored in the first application data 212 or the second application data 216 is changed to status 3 indicating the “provisionally confirmed group” state. (S3 in FIG. 18).
[0078]
When “m” does not have the minimum number of passengers “c”, or when there is an unprocessed portion that could not be processed by the riding group division processing (FIG. 20) described later, or all of the extracted operation requests are provisionally confirmed When the group determination process (FIG. 18) is performed, the time width “k” is expanded by “t” in order to generate a group having the minimum number of passengers “c” and the maximum number of passengers “d”. (S16), the extraction process of S7 is performed using a wider time width (S17). Here, the time width “t” is the time width A of the zip code table shown in (1) of FIG. 5 stored in the zip code data 218 when the grouping process is performed for the way to the fixed place. When the grouping process is performed for the return from the fixed place, the time width B of the zip code table shown in (1) of FIG. 5 stored in the zip code data 218 is used. Then, as a result of expanding the time width “k” little by little, for example, by the time width “t”, it seems that “k” has exceeded the maximum time width “s” of “k” that the customer may allow. In this case, the re-extraction by expanding the time width “k” is stopped, and the re-extraction by expanding the reference area, that is, the rank “i” of the adjacent district referred to at the time of extraction is expanded by “1” (S18). ) The extraction process from S5 is performed on a wider reference area (S19).
[0079]
Here, as a result of expanding the reference area “i” by “1”, “i” seems to have exceeded the maximum value “h” of the adjacent district rank indicating the maximum extraction area to be referred to in order to create the provisionally confirmed group. In this case, the re-extraction by expanding the reference area “i” is stopped, and the maximum time width of “k” that the customer can accept at the start time “g” of the designated time zone “ab” The designated time zone is changed by adding "s" (S20). Whether or not the result of adding the maximum time width “s” to the start time “g” of the specified time zone “ab” exceeds the end time “b” of the specified time zone “ab” (S21), if it has exceeded, check whether all the zip codes in the affiliation zip code at the fixed location have been referenced (S22). The process from S3 is performed.
[0080]
If it is determined in s22 that there is a postal code that has not been referred to yet, the process from S2 is performed again. On the other hand, if all the postal codes have been referred, It is confirmed whether the processing has been completed for all the fixed locations stored in the data 208 (S23). If there is a fixed place that has not been processed yet, the process from S1 is performed for that fixed place, and if all the fixed places have been processed, the multiplicative group combining process 2 is completed. .
[0081]
Next, in S12 of the above-mentioned riding group combination process 2 (FIG. 19), that is, in S11 of the riding group combination process 2 (FIG. 19), the number of rides per shared vehicle scheduled to be operated by the ride vehicle operating company The riding group division process that is performed when the total number of persons “m” of the operation requests extracted in S8 exceeds the possible number of persons “d” will be described. And processing is performed to divide the extracted operation request into the number of people who can operate (S12).
[0082]
FIG. 20 is a flowchart illustrating an example of the processing procedure of the multiplicative group division processing.
First, in S11 of the riding group combination process 2 (FIG. 19), the operation request extracted in S8 exceeds the number of passengers “d” that can be boarded per shared vehicle scheduled by the riding company operating company. For the total number of people “m”, there is a desired departure arrival time within the range of the time width “k” from the start time “g” of the designated time zone “ab”, and the departure arrival place postal code is S4 The status of the operation request stored in the first application data 212 or the second application data 216 is in the postal code group within the designated adjacent district rank “i”, and “unconfirmed” The operation request which is “0” indicating the state is extracted (S1). Then, the total number of the extracted operation requests is set to “n” (S2). Next, it is determined whether or not the total number of operation requests “n” exceeds the number of passengers “d” that can be boarded per shared vehicle (S3). The total number of people is set to “n” as “p” (S4), the provisional confirmation group determination process shown in FIG. 18 is performed (S5), the total number of operation requests is set to “n” as “0”, and the process is terminated (S6). ).
[0083]
On the other hand, if “n” exceeds the total number of passengers that can be boarded per shared vehicle, “n”, the minimum number of passengers “c” can be boarded. A group is generated by dividing it so that the number of persons is “d” or less (S7). The division of the total number of people “n” in this operation request is, for example, extracted in order from the earliest application date for the operation request with the status “0”, or in order from the highest customer rank based on the number of uses. This is done by creating a group or creating a group based on the desired items registered at the time of operation request registration. Note that the number of applicants in one operation request cannot be divided so that the number of people in one group is the minimum number of passengers “c” or more and the number of passengers that can be boarded “d” or less. Then, the number of groups generated by dividing the total number of people by “n” is set to “p” (S8), the provisionally confirmed group determination process shown in FIG. 18 is performed (S9), and the total number of operation requests is set to “n”. ”Is subtracted from the group number“ p ”(S10), and it is determined whether the number of people after the deduction of the group number“ p ”is equal to or greater than the minimum number of passengers“ c ”(S11). If the number of passengers is at least “c” or more, “n” can be further divided to create a group, and the processing from S3 is performed again. On the other hand, when it is less than the minimum number of passengers “c”, the riding group division process ends there.
[0084]
Next, an unconfirmed request type process will be described.
In the unconfirmed request type, the operation request received by the service center 100 is combined based on the operator's operation needs, and the operation route is determined. It is different from the request type. Therefore, it is possible to perform an unconfirmed request type process without assuming a reservation request type process. In addition, passenger vehicle operators who have already received orders for operation from a few people, but still have room for passenger vehicles, have already received orders to increase the efficiency of operation. For example, it may be used to receive an order for an operation request from a customer who wants to operate on a route close to the current operation request.
[0085]
FIG. 21 is a diagram illustrating an example of the flow of processing in the unconfirmed request type.
A customer who needs to go to the station or airport accesses the service center 100 from the customer terminal 300 owned by the customer and makes an operation request (S1). When the customer makes an operation request input request to the service center 100, the service center 100 prompts the customer terminal 300 to input authentication information such as a user ID and a password, so the customer first registers with the service center 100 in advance. Enter some authentication information. When the authentication information is received, the database server 140 of the service center 100 searches the user information data 220 in the database 200 and performs an authentication process for the accessing customer. When the customer is authenticated, an operation request input screen as shown in FIG. 7 is transmitted to the customer terminal 300, so that the customer inputs necessary items from the operation request input screen, and the service center 100 And request operation.
[0086]
The customer makes an operation request by inputting at least a departure place and an arrival place, a desired arrival time, and the number of applicants from the operation request input screen (FIG. 7). As with the reservation request type, in order to make an operation request from the customer terminal 300 to the service center 100, the customer registers the customer name, address, password, etc. with the service center 100 in advance, and the user ID It is necessary to receive a grant.
[0087]
When the service center 100 receives the operation request from the customer, the service center 100 stores the received information in the first application data 212 in the database 200 and assigns an application number corresponding to the received operation request on a one-to-one basis. After that, an application content confirmation screen as shown in FIG. 8 is transmitted to the customer terminal 300 in order to make the customer confirm the operation request input by the customer (S2). On the application content confirmation screen (FIG. 8), items entered by the customer on the operation request input screen (FIG. 7) are displayed. The customer who has found that the operation request needs to be changed can change the operation request once registered by selecting the “change” button 8a on the application content confirmation screen (FIG. 8).
[0088]
A shared vehicle operator accesses the WWW server 120 in the service center 100 from the operator terminal 400 as needed, and searches for operation request information registered by the customer (S3). In response to the access from the shared vehicle operator, the service center 100 transmits an unconfirmed operation request list as shown in FIG. On the unconfirmed operation request list screen (FIG. 22), information such as the application number, arrival location, desired arrival time, number of applications, number of applicants, etc. of each operation request registered in the service center 100 is posted. When a shared vehicle operator finds an operation request of interest on the unconfirmed operation request list screen (FIG. 22), the operation of interest from the application numbers displayed in the application number display field 22a. By specifying the application number indicating the request, it is possible to acquire detailed information about the operation request.
[0089]
FIG. 23 is an operation request detail display screen displaying detailed information about an operation request having an application number “0310”. The operation request detail display screen (FIG. 23) displays information such as an application number, a customer name, an address, a telephone number, a desired departure time, a desired arrival time, and the number of applicants for the operation request “0054”. When the shared vehicle operator obtains detailed information about the operation request and intends to respond to the operation request, the shared vehicle operator operates the “order and operation plan creation” button 23a to By inputting an operation plan from the additional application request order registration screen (FIG. 24) displayed on the terminal 400, an order for the operation request can be made.
[0090]
When the shared vehicle operator makes a search request for operation request information to the service center 100, the service center 100 prompts the operator terminal 400 to input authentication information such as a user ID and a password. The authentication information registered in the service center 100 in advance is input. When the authentication information is received, the database server 140 of the service center 100 searches the operator information data 204 in the database 200, and performs an authentication process for the accessing shared vehicle operator. When the riding vehicle operator is authenticated, the unconfirmed operation request list screen (FIG. 22) is transmitted to the supplier terminal 400. Therefore, it is necessary for the shared vehicle operator to register the business company name, address, telephone number, password, and the like with the service center 100 in advance and receive business company ID.
[0091]
When the passenger vehicle operator operates the “order and operation plan creation” button 23a on the operation request detail display screen (FIG. 23), an additional application request order registration screen as shown in FIG. Is done. On the additional application request order registration screen (FIG. 24), information such as an application number, a customer name, an address, a telephone number, and the number of applicants for the customer who has requested the operation is displayed. The shared vehicle operator will select the appropriate route in consideration of the customer's address and destination, etc., and will be able to arrive at the destination at the customer's desired arrival time and the meeting place with the customer. And enter the confirmed group number (group ID) of the operation plan to which the operation request is to be added from the confirmed group number input field 24a. Then, the scheduled departure date is input from the scheduled departure date input field 24b, the scheduled departure time from the scheduled departure time input field 24c, the waiting place from the waiting place input field 24d, and the fare from the charge display field 24f. After confirming the input contents of the additional application request order registration screen (FIG. 24), the shared vehicle operator transmits the operation plan to the service center 100 by pressing the “registration button” 24g, and the unconfirmed operation request. Is received (S4).
[0092]
The service center 100 stores the operation plan received from the operator terminal 400 in the first confirmed group data 202 in the database 200, and notifies the customer terminal 300 of the charge and the operation plan based on the operation plan. (S5). FIG. 12 is an example of the charge and operation plan notification screen displayed on the customer terminal 300.
In the charge and operation plan notification screen (FIG. 12), the customer name, application number, group ID given by grouping the operation request with the application number, the charge, and the designation of the shared vehicle operator Since the waiting place and the waiting time are displayed, the customer confirms the displayed contents and confirms the operation by operating the “final confirmation” button 12a (S6). When the customer confirms the operation, an application confirmation confirmation screen as shown in FIG. 13 is transmitted from the service center 100 to the customer terminal 300.
[0093]
When the customer confirms the operation and the application confirmation confirmation screen (FIG. 13) is transmitted to the customer terminal 300, the operation group status confirmation screen as shown in FIG. 14 is transmitted to the vendor terminal 400 (S7). Thus, the operation plan transmitted by the riding vehicle operator in S4 is finally determined (S8). On the operation group status confirmation screen (FIG. 14), the application number, departure location, arrival location, estimated arrival time, customer name, customer address, telephone number, number of applicants, etc. for the application number “0054” for which the order has been received this time In addition, information such as application number, departure place, arrival place, estimated time of arrival, customer name, customer address, telephone number, number of applicants, etc. for other operation requests that have already been ordered by the relevant vehicle operator will be posted. Has been. In the status display column 14a, a status “user confirmation” indicating that the final confirmation of the operation plan from each customer has been performed is displayed.
[0094]
The shared vehicle operator operates the shared vehicle based on the operation plan in the operation group finally determined from the service center 100 by transmitting the operation group status confirmation screen (FIG. 14) to the operator terminal 400 (S9). ) Carry the customer to the destination and receive the fare payment from the customer (S10). Thereafter, the shared vehicle operator reports the operation result to the service center 100 and pays a system usage fee for acquiring the operation request information (S11). FIG. 15 is a diagram illustrating an example of an operation result report screen that is input when a shared vehicle operator reports an operation result to the service center 100.
[0095]
Next, the real-time request type will be described. In the real-time request type, the customer himself / herself searches for other operation plans already determined in the service center 100, determines whether or not each operation plan can be boarded, and places an order for the operation plan that he / she wants to ride. This is different from a reservation request type in which operation routes are combined based on a customer's operation request and an unconfirmed request type in which operation requests are combined based on the operator's operation needs.
[0096]
FIG. 25 is a diagram illustrating an example of the flow of processing in the real-time request type.
A customer who needs to go to the station or airport accesses the service center 100 from the customer terminal 300 owned by the customer and makes an operation request (S1). When the customer makes an operation request input request to the service center 100, the service center 100 prompts the customer terminal 300 to input authentication information such as a user ID and a password, so the customer first registers with the service center 100 in advance. Enter some authentication information. When the authentication information is received, the database server 140 of the service center 100 searches the user information data 220 in the database 200 and performs an authentication process for the accessing customer. When the customer is authenticated, a real-time operation request input screen as shown in FIG. 26 is transmitted to the customer terminal 300, and the customer inputs necessary items from the operation request input screen.
[0097]
In the real-time operation request input screen (FIG. 26), as in the operation request input screen of FIG. 7, the departure place input field 26a for inputting the place to board the shared vehicle, the arrival place input field 26b for inputting the destination, and the boarding date are displayed. In addition to the departure date input field 26c to be input, the desired departure time input field 26d, the arrival date input field 26e for inputting the arrival date to the destination, etc. Desired arrival time 26f, application number input field 26g for inputting the number of people to ride in the shared vehicle together with the customer, designation supplier input field 26h for inputting the operator when it is desired to specify an operator from the last impression, etc. There is also a request entry field 26i for entering a contact time item such as the presence or absence of a small child. Performing a service request by performing a number of input. As with the reservation request type, in order to make an operation request from the customer terminal 300 to the service center 100, the customer registers the customer name, address, password, etc. with the service center 100 in advance, and the user ID It is necessary to receive a grant.
[0098]
Next, the customer operates the “determined group list search” button 26j on the real-time operation request input screen (FIG. 26) to extract other operation plans that have already been determined to operate (S2). FIG. 27 is a diagram showing an operation determination group list screen transmitted from the service center 100 to the customer terminal 300 of the customer who operates the “determined group list search” button 26j on the real-time operation request input screen (FIG. 26). . On the operation determination group list screen (FIG. 27), the operation numbers constituting the operation plan group number, departure point, arrival point, estimated arrival time, designated contractor, operation determination group that have already been determined to operate. The number of applications for the request and the total number of people in the group are shown. In view of the departure place, arrival place, estimated arrival time, total number of people, etc., the operation decision group that is likely to be able to add its own operation request is displayed in this operation decision group list screen (FIG. 27). Look for it. If there is an operation decision group that is likely to add its own operation request, it is possible to add its own operation request from among the group numbers displayed in the group number display field 27a. By specifying a group number indicating the operation determination group, an additional application is placed (S3).
[0099]
When the service center 100 receives an order for an additional application from the customer terminal 300, the service center 100 requests an additional application request as shown in FIG. The list is transmitted, and a customer addition request is made for the determined operation (S4).
[0100]
The additional application request list (FIG. 28) includes an application number for the additional application request received by the service center 100, an arrival location, a desired departure time, a desired arrival time, a group number of a determined operation group for which an additional application has been made, The number of people who applied for additional information is displayed. The shared vehicle operator confirms the operation plan for the already determined operation group and determines whether or not to accept the additional application (S5). In determining whether or not an additional application can be accepted, by adding an application number of an additional application that is likely to be accepted from the application number display field 28a of the additional application request list screen (FIG. 28), the addition is added. Detailed information about the application can be obtained.
[0101]
FIG. 29 is an additional application request detail display screen displaying detailed information about an additional application request having an application number “4501”. In the additional application request detail display screen (FIG. 29), information such as application number, customer name, address, telephone number, desired departure time, desired arrival time, number of applicants, etc. for the additional application having the application number “4501” is displayed. It is displayed.
The shared vehicle operator can obtain an order by operating the “order and operation plan creation” button 29a in order to respond to the additional application request after acquiring the detailed information.
[0102]
When the shared vehicle operator operates the “order and operation plan creation” button 29a, an additional application request order registration screen as shown in FIG. On the additional application request order registration screen (FIG. 30), information such as an application number, a customer name, an arrival place, a desired arrival time, the number of applicants, etc., for the customer who has made an additional application request is displayed. The shared vehicle operator can select the appropriate route to add the additional application request in view of the operation plan that has already been determined, and can arrive at the destination at the desired arrival time without fail. Select the scheduled departure time and the meeting place with the customer, and display the charges from the scheduled departure date input field 30a to the scheduled departure date, the scheduled departure time input field 30b to the scheduled departure time, and the waiting place input field 30b to the waiting location. Enter the fare from the column 30e. The shared vehicle operator confirms the input contents of the additional application request order registration screen (FIG. 30) and then operates the “registration button” 30f to request the service center 100 to add an application for the determined operation plan. Is received (S6).
[0103]
The service center 100 stores the operation plan received from the operator terminal 400 in the first confirmed group data 202 in the database 200, and based on this, confirms the application content to the customer terminal 300, An application content confirmation screen (FIG. 31) for notification of a charge and an operation plan is transmitted (S7). On the application details confirmation screen (Fig. 31), the customer name, application number, departure place, arrival place, desired arrival time, number of people, group ID of the determined operation group to which additional application requests have been added, charge, and sharing Since the meeting place designated by the vehicle operator and the meeting time are displayed, the customer confirms the displayed contents and confirms the operation by operating the “final confirmation” button 31a (S8).
[0104]
When the customer confirms the operation, an operation group status confirmation screen as shown in FIG. 14 is transmitted to the operator terminal 400 (S9), whereby the operation plan transmitted by the riding vehicle operator is finally determined in S7. (S10). On the operation group status confirmation screen (FIG. 14), the group number, departure place, arrival place, estimated arrival time, customer application number, customer name, customer address, telephone number, number of applicants, status, etc. constituting the group are displayed. It is displayed. The status displayed in the status display field 14a of the operation group status confirmation screen (FIG. 14) is a status “user confirmation” indicating that each customer's operation request is in a stage where the final confirmation of the operation plan has been made by each customer. Is displayed.
[0105]
The shared vehicle operator operates the shared vehicle based on the final determined operation plan (S11), carries the customer to the destination, and receives payment of the fare from the customer (S12).
Thereafter, the shared vehicle operator reports the operation result to the service center 100 and pays the system usage fee for acquiring the operation request information (S13). FIG. 15 is a diagram illustrating an example of an operation result report screen that is input when a shared vehicle operator reports an operation result to the service center 100. On the operation result report screen (Fig. 15), the input contents in the additional application request order registration screen (Fig. 30) sent by the shared vehicle operator in S6 are displayed. If it is different from the above, the display contents are corrected from the departure time input field 15a, the meeting place input field 15b, the charge input field 15c, and the arrival time input field 15g, and the service center 100 is operated by operating the “Register” button 15d. Report the operation results to.
[0106]
Next, another embodiment will be described.
In the above-described embodiment, the database is divided depending on whether or not the vehicle is going from the fixed location. When the operation request input from the customer terminal 300 is directed to the fixed location, the first application data 212 is fixed. If it is a return from a place, it will be 2nd application data 2162, and if it is information about the operation decision group about going to a fixed place, it will be related to the first decision group data 202 about an operation decision group about the return from a fixed place. In the case of information, the case where the information is stored separately in the second confirmed group data 206 has been described as an example. However, the present invention is not limited to this case. In other embodiments, the information is stored in a fixed place. It is not related to the database to be stored depending on whether it is going or not. It is also conceivable to store the broadcast.
[0107]
In the above-described embodiment, the reservation request type process, the unconfirmed request type process, and the real-time request type process are individually described. However, the present invention is not limited to this case, and other embodiments are described. In, for example, the reservation request type process, the unconfirmed request type process, and the real time request type process are combined, for example, the reservation request type process is performed and then the unconfirmed request type process is performed, or the unconfirmed request type process is performed Perform real-time request type processing later, perform real-time request type processing after performing reservation request type processing, and perform all types of processing in the order of reservation request type processing, unconfirmed request type processing, real-time request type processing Also good.
[0108]
Further, in the above-described embodiment, the case where the adjacent district rank is set based on the zip code has been described as an example in setting the adjacent district data to be referred to when performing the riding grouping process. However, the present invention is not limited to this case, and in other embodiments, for example, it is conceivable to set the adjacent district data using a telephone number or using a commercially available map database.
[0109]
In the above-described embodiment, when creating an operation group, the reception of the target operation request is divided by a certain time, and the grouping process is performed based on the time zone included in the operation request, the destination, and the like. Although the case where it performs is demonstrated to an example, this invention is not limited to this case. In another embodiment, the time for accepting an operation request is not divided when creating an operation group. For example, as soon as an operation request is received from the terminal 300 for a customer, the time period included in the accepted operation request, the destination, etc. Based on this, it is possible to create a service group at any time.
[0110]
Further, in the unconfirmed request type process shown in FIG. 21 described above, when the shared vehicle operator receives an additional order for an operation request, the operation plan is specified in advance and the order is specified and received. However, the present invention is not limited to this case. In another embodiment, when an additional order for an operation request is given, it is also possible to freely accept an operation request without specifying which operation plan to receive an order for. In that case, it is considered that the operation plan is transmitted to the service center 100 without entering the confirmed group number from the confirmed group number input field 24a on the additional application request order screen (FIG. 24). It is done.
[0111]
In the real-time request type processing shown in FIG. 25 described above, an operation determination group list screen (FIG. 27) for displaying the operation determination group having a departure place and an arrival place that are completely different from the customer's operation request. The case where the customer himself / herself finds an operation decision group that is likely to be able to add his own operation request and orders an additional application is described as an example, but the present invention is not limited to this case Absent. In another embodiment, in response to receiving the confirmed group list search request from the customer terminal 300, the departure point, the arrival point, and the destination included in the operation request input by the customer in S1 of FIG. On the display screen of the customer terminal 300 that searches for an operation confirmed group that can add a customer operation request based on information such as the boarding date and displays the operation determination group list screen (FIG. 27). It is also possible to display the information and make the customer place an order for additional application.
[0112]
Further, in the above-described embodiment, when the customer accesses the service center 100 from the customer terminal 300, the customer inputs authentication information such as a user ID and a password, and performs an authentication process as an example. As described above, the present invention is not limited to this case, and in other embodiments, authentication information such as a user ID and a password is not transmitted when an operation request is transmitted to the service center 100, not at the time of access. It is also conceivable to perform an authentication process by inputting.
[0113]
As described above, according to the present embodiment, the server collects the operation requests input from the customer terminal, so that the shared vehicle operator can efficiently collect a plurality of passengers that are easily operated. Can be acquired. In addition, according to the present embodiment, the customer can easily move from the desired place to the destination at the desired time when he / she can add his / her own operation request to the riding group that has already been determined to operate. You can get cheap and new transportation.
[0114]
【The invention's effect】
As described above, according to the inventions described in claims 1 to 7, 9, 12, 14 to 19, 22, 24, and 25, the shared vehicle operator trades a plurality of passengers that are easily operated. It can be acquired efficiently, and the customer can obtain an inexpensive new transportation means that can easily move from a desired place to a destination at a desired time when desired.
[0115]
Further, according to the inventions according to claims 10 and 21, the operation request is such that the operation group is not included in the operation group management due to the input time of the operation request, the number of users, the use area, and the like. In addition, it is possible to make it an operation target of a shared vehicle by absorbing it in a shared group that has already been determined to operate.
[0116]
Further, according to the inventions described in claims 8, 11, 13, 20, and 23, since the customer can add his / her own operation request to the operation group that has already been determined to operate, the customer can operate in advance. Even if the reservation for the request is not made, it is possible to obtain an inexpensive new transportation means that can easily move from the desired place to the destination at the desired time.
[Brief description of the drawings]
FIG. 1 is a diagram showing an example of a system configuration of a riding operation support system in which the present invention is implemented.
FIG. 2 is a diagram illustrating an example of a database server and a configuration of the database in a service center according to the present embodiment.
FIG. 3 is a diagram showing an example of the structure of each database stored in the database.
FIG. 4 is a diagram illustrating an example of data storage in a database.
FIG. 5 is a diagram showing an example of data storage in a database.
FIG. 6 is a diagram illustrating an example of a flow of processing steps in a reservation request type.
FIG. 7 is a diagram illustrating an example of an operation request input screen.
FIG. 8 is a diagram showing an example of an application content confirmation screen.
FIG. 9 is a diagram illustrating an example of a provisionally confirmed group list screen.
FIG. 10 is a diagram showing an example of an operation group details display screen.
FIG. 11 is a diagram showing an example of an operation plan input screen.
FIG. 12 is a diagram showing an example of a charge and operation plan notification screen.
FIG. 13 is a diagram showing an example of an application confirmation confirmation screen.
FIG. 14 is a diagram showing an example of an operation group status confirmation screen.
FIG. 15 is a diagram showing an example of an operation result report screen.
FIG. 16 is a flowchart illustrating an example of a processing procedure of multiplicative grouping processing;
FIG. 17 is a flowchart illustrating an example of a processing procedure of multiplicative grouping combining processing;
FIG. 18 is a flowchart illustrating an example of a processing procedure for provisional confirmation group determination processing;
FIG. 19 is a flowchart illustrating an example of a processing procedure of multiplicative grouping combining processing.
FIG. 20 is a flowchart illustrating an example of a processing procedure of multiplicative group division processing.
FIG. 21 is a diagram illustrating an example of a flow of processing in an indeterminate request type.
FIG. 22 is a diagram showing an example of an unconfirmed operation request list.
FIG. 23 is a diagram showing an example of an operation request detail display screen.
FIG. 24 is a diagram showing an example of an additional application request order registration screen.
FIG. 25 is a diagram showing an example of the flow of processing in a real-time request type customer.
FIG. 26 is a diagram showing an example of a real-time operation request input screen.
FIG. 27 is a diagram illustrating an example of an operation determination group list screen.
FIG. 28 is a diagram showing an example of a list of additional application requests.
FIG. 29 is a diagram showing an example of an additional application request detail display screen.
FIG. 30 is a diagram illustrating an example of an additional application request order registration screen.
FIG. 31 is a diagram showing an example of an application content confirmation screen.
[Explanation of symbols]
100 service center
120 WWW server
140 Database server
142 Main control unit (CPU)
144 bus
146 Input device
148 display device
150 output device
152 communication port
200 database
202 First confirmed group data
204 Business information data
206 Second confirmed group data
208 Fixed location data
210 Status data
212 First application data
214 Affiliation data
216 Second application data
218 Zip code data
220 User information data
222 Adjacent district data
300 Customer terminal
400 Trader's terminal
500 networks

Claims

In the server in the riding operation support system comprising the server for providing the ride information to the terminal for the trader and the terminal for the customer, the trader terminal connected to the server via the network, and the terminal for the customer.
First storage means for storing an operation request for a shared vehicle received from the customer terminal;
An operation group generating means for generating an operation group by collecting the operation requests;
Second storage means for storing the operation group generated by the operation group generation means;
Request signal transmission means for transmitting an operation request signal for requesting operation for the operation group to the terminal for the trader;
Third storage means for storing an operation plan for the operation group received from the vendor terminal;
A server comprising: a confirmation notification transmitting means for transmitting a final confirmation notification for the operation plan to the vendor terminal in response to receiving a final confirmation signal for the operation plan from the customer terminal.

The operation group generation means includes
First extraction means for extracting an operation request to be processed from the operation request;
2. The server according to claim 1, further comprising a first grouping unit configured to extract an operation request satisfying the minimum number of passengers from the operation request extracted by the first extraction unit and generate an operation group. .

3. The server according to claim 2, wherein the first extraction unit extracts an operation request to be processed by using a shared vehicle boarding date and a desired arrival time or a time zone to which a desired departure time belongs as a key. .

The first extracting means extracts an operation request to be processed by using a shared vehicle boarding date included in the operation request received from the customer terminal and a time zone to which the desired arrival time or the desired departure time belongs as keys. The server according to claim 2.

If the first grouping unit cannot generate a service group, the adjacent one having the same fixed location and the starting or arriving location with a predetermined degree of adjacency from the service request extracted by the first extracting unit A second extraction means for extracting a service request;
The server according to claim 2, further comprising a second grouping unit that collects the adjacent operation requests and generates an operation group that satisfies the minimum number of passengers.

6. The server according to claim 5, wherein the degree of adjacency is determined based on a preset adjoining district table.

The server according to claim 6, wherein the adjacent district table divides regions based on a zip code, and determines the degree of adjacency between the districts for each division.

In response to receiving an additional order signal for an operation request for the operation plan stored in the second storage means from the customer terminal, an additional operation request signal for the operation plan is transmitted to the terminal for the trader. The server according to claim 1, further comprising an additional request signal transmitting means.

In response to reception of an operation request signal for requesting operation for the operation group from the server according to claim 1, first output means for outputting an operation request included in the operation group;
First input means for inputting an operation plan for the operation request;
Second output means for outputting a final confirmation notice for the operation plan received from the server;
A merchant terminal comprising: a merchant terminal side input / output means for communicating information including the server, the operation request, the operation plan, and the final confirmation notice.

Search means for searching for operation groups stored in the server;
Third output means for outputting a search result searched by the search means;
The vendor terminal according to claim 9, further comprising: a second input unit that inputs an operation plan for an operation request included in the operation group searched by the search unit.

A fourth output means for outputting an operation request included in the additional order signal in response to reception of the additional operation request signal from the server;
The terminal for traders according to claim 9, further comprising third input means for inputting an operation plan for the operation request.

An input means for inputting an operation request for a shared vehicle;
First output means for outputting an operation plan for the operation request received from the server according to claim 1;
A final confirmation signal transmitting means for transmitting a final confirmation signal for displaying a final confirmation for the operation plan to the server;
A customer terminal comprising: a customer terminal side input / output means for communicating information including the operation request and the operation plan to the server.

Search means for searching an operation plan for an operation group stored in the server;
An additional order signal transmission means for transmitting an additional order signal for instructing an additional order of an operation request for the operation plan searched by the search means;
The customer terminal according to claim 12, further comprising: a second output unit that outputs an operation plan for the additional order received from the server.

The server according to any one of claims 1 to 8,
Storing an operation request for the shared vehicle received from the customer terminal, and generating an operation group by collecting the operation request;
Storing the operation group and transmitting an operation request signal for requesting operation for the operation group to the terminal for the trader;
Storing an operation plan for the operation group received from the vendor terminal;
Transmitting the operation plan to the customer terminal;
And a step of transmitting a final confirmation notification to the vendor terminal in response to receiving a final confirmation signal for the operation plan from the customer terminal.

The step of generating the operation group includes:
Extracting an operation request to be processed from the operation request;
The program according to claim 14, further comprising: extracting an operation request satisfying the minimum number of passengers from the operation request extracted by the first extraction unit to generate an operation group.

The step of extracting the operation request to be processed from the operation request is characterized in that the operation request to be processed is extracted using the date of boarding of the shared vehicle and the time zone to which the desired arrival time or the desired departure time belongs as a key. The program according to claim 15.

The step of extracting the operation request to be processed from the operation request is a processing object by using as a key the boarding date of the shared vehicle included in the operation request received from the customer terminal and the time zone to which the desired arrival time or the desired departure time belongs. The program according to claim 15, wherein an operation request is extracted.

In the step of generating an operation group by extracting an operation request that satisfies the minimum number of passengers, if the operation group cannot be generated, the same fixed location and a predetermined degree of departure from the extracted operation request Extracting an adjacent service request with a place or destination; and
The program according to claim 15, further comprising a step of collecting the adjacent operation requests and generating an operation group satisfying the minimum number of passengers.

The vendor terminal according to any one of claims 9 to 11,
In response to receiving an operation request signal for requesting operation for the operation group from the server according to claim 1, outputting an operation request included in the operation group;
In response to an operation plan input for the operation request, controlling the supplier terminal side input / output means and transmitting the operation plan to the server;
And a step of outputting a final confirmation notice for the operation plan received from the server.

In response to receiving an additional operation request signal from the server, outputting an operation request including the additional order signal;
20. The program according to claim 19, further comprising a step of controlling the supplier terminal side input / output means and transmitting the operation plan to the server in response to an operation plan input for the operation request. .

In the terminal for traders according to claim 10,
Searching for an operation group stored in the server according to any one of claims 1 to 8, and outputting a search result;
Transmitting the operation plan to the server in response to an input of the operation plan for the search result;
And a step of outputting a final confirmation notice for the operation plan received from the server.

The customer terminal according to claim 12 or 13,
In response to the input of the operation request for the shared vehicle, the step of transmitting the operation request to the server according to any one of claims 1 to 8,
Outputting an operation plan for the operation request received from the server;
And a step of transmitting to the server a final confirmation signal for the operation plan received from the server.

The customer terminal according to claim 13,
Searching for an operation plan for an operation group stored in the server;
Sending an additional order signal for instructing an additional order for an operation request for the operation plan searched by the search means;
Outputting an operation plan for the additional order received from the server;
And a step of transmitting a final confirmation signal for the operation plan.

24. A computer-readable recording medium storing the program according to claim 14.

The server according to any one of claims 1 to 8, the customer terminal according to any one of claims 9 to 11 and the customer according to claim 12 or 13 connected to the server via a network. A method of supporting a shared operation using a shared operation support system equipped with a terminal,
In the customer terminal, inputting an operation request to a shared vehicle and transmitting to the server;
In the server, a step of collecting an operation group received from the customer terminal and generating an operation group;
In the server, the operation group is stored, and the operation terminal signal for requesting operation for the operation group is transmitted to the trader terminal;
In the merchant terminal, in response to receiving an operation request signal for requesting operation for the operation group from the server, outputting an operation request included in the operation group;
In the merchant terminal, in response to an operation plan input for the operation group, controlling the first merchant terminal side input / output means and transmitting the operation plan to the server;
In the server, storing the operation plan received from the vendor terminal, and transmitting to the customer terminal;
In the customer terminal, sending a final confirmation signal for the operation plan received from the server to the server;
In the server, in response to receiving a final confirmation signal for the operation plan from the customer terminal, transmitting a final confirmation notification to the vendor terminal;
The said operation terminal is provided with the step which outputs the notification of the last confirmation with respect to the said operation plan received from the said server in the said terminal for traders.