JP2002342422A

JP2002342422A - 旅行情報管理システム

Info

Publication number: JP2002342422A
Application number: JP2001147927A
Authority: JP
Inventors: Hiroshi Kato; 弘加藤
Original assignee: Comnet Enterprise Kk
Current assignee: Comnet Enterprise Kk
Priority date: 2001-05-17
Filing date: 2001-05-17
Publication date: 2002-11-29

Abstract

(57)【要約】【課題】旅行代理店とランドオペレータとの間に発生す
る、見積もり・手配・変更・取消・決済・精算などの一
連業務をシステム化すること。【解決手段】本発明による旅行情報管理システムは、旅
行代理店３とランドオペレータ５からそれぞれ送信され
る情報を処理するサーバー１１と、このサーバに接続さ
れ、少なくとも旅行に関する発着日、行き先、申込者を
特定する情報、管理ステータスを含む、ツアー管理デー
タベース１５と、ツアー管理データベースに接続され、
そのデータベースに格納された情報が変更された履歴を
管理する変更履歴管理データベース１５とを具備する。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、国境を越える旅行
（海外旅行）における旅行業者及びランドオペレータの
業務について、インターネット等の通信網を通して、処
理するシステム及び方法にかかるものである。

【０００２】

【従来の技術】旅行業者が海外旅行を催行する場合にお
いては、現地における滞在費を事前に見積もる必要があ
る。ここで、旅行業者とは、典型的には旅行業法２条に
規定する業務を業として行う者をいうが、登録・未登録
を問わない。また、滞在費とは、たとえば、ホテル代、
移動・観光に要するバス代、ガイド料、入場料、食事
代、荷物運搬料などをいう。旅行業者が直接現地の代理
店にアクセスする場合には、言語・習慣の差異により困
難が生じたり、現地事情による予期せぬ事態に対処不能
な場合が生じる。かかる理由により、ランドオペレータ
という業務が存在する。ランドオペレータは、日本の旅
行業者から依頼を受けて担当地域に関するホテル・ガイ
ド等の手配を行う者であり、ツアーオペレータとも呼ば
れる。ランドオペレータは、上述した困難性を除去し、
結果として、旅行業者・ランドオペレータ間の交渉や情
報伝達をスムーズにする役割を担うものである。

【０００３】海外旅行を催行するためには一般的には以
下のようなプロセスを経る（図１２参照）。日本の旅行業者は、日程表及び条件書を日本語で作
成し、複数のランドオペレータに対して、当該ツアーの
滞在費算出を依頼する（見積依頼）。ランドオペレータは旅行業者の依頼に基づき、滞在
費を算出し、旅行業者へ提示する（見積回答）。旅行業者は、各ランドオペレータからの見積書を集
約し、条件・金額を検討した上で、もっとも条件のいい
ランドオペレータを選択し、発注する（契約締結）。受注したランドオペレータは独自の手配システムを
利用して、現地に存在する営業所に手配内容を送信する
（調整）。手配が完了すると、最終金額が確定し、ランドオペ
レータは旅行業者へ請求書(Invoice)を郵送する。旅行業者は、請求書に基づき銀行振込などで決済を
行う。

【０００４】このように、ツアーの催行においては大き
く分類して、上記ないしのステージ（オファーステ
ージ）、上記のステージ（調整ステージ）、旅行者が
実際に旅行をしているステージ、上記、のステージ
（決済ステージ）の各ステージから構成されている。

【０００５】上記ないしにおいても基本的にはfax
のやりとりであり、書面の管理コストが著しかった。特
に、においては、旅行業者は各ランドオペレータに対
してfaxを送らなければならず、手間がかかるととも
に、通信費用は膨大なものになっていた。このような事
由により、多数のfaxでのやりとりが発生し、通常、手
配の開始から出発まで５０ないし１００往復程度の文書
のやりとりがなされている。

【０００６】また、において、複数のランドオペレー
タからあがってきた見積書は、手作業で比較されていた
ため、そのための時間とコストは無視できないものであ
った。ランドオペレータ側においても、書面の蓄積によ
る情報管理コストの増大や人的コストの増大を招いてお
り、日本語で送られてきた書面を英語等、現地において
通用力のある言語に翻訳して書面を作成しなければなら
なかったので、翻訳にかかるコスト等も甚大であった。

【０００７】さらに、上記のステージで、ユーザが旅
行の内容を変更したり、人員の増減を申し出たり、キャ
ンセルなどが発生する。このやりとりは、従来、電話と
faxで行っており、膨大な量の書面が発生するのが常で
あった。また、このような旅行内容の変更等が生じない
場合においても、見積書・日程書など、書面によるやり
とりが多く、情報の管理という点で支障を来していた。

【０００８】これらのコストは最終的にはすべてユーザ
である旅行者に上乗せされる形となっていたので、ユー
ザは、実際に享受できるサービス以上の対価を支払って
いることになり、旅行費用の増大や旅行業者離れを招い
ていた。

【０００９】さらに、請求書(invoice)の発送による請
求方法においては、未着・行方不明という問題が絶えな
い。このような送金延滞のリスクをヘッジするために、
これをコストに上乗せして請求するという慣習になって
おり、ツアー代金の高騰を招いている。決済において
も、銀行振込等の手段を用いていたために、手間やコス
トがかかるという問題点が生じている上に、為替予約を
せずに米ドル建てで決済を行うので、当初見積り時より
も送金時に円安になると現地のランドオペレータに対す
る送金を拒んだりするなどのトラブルが発生しやすかっ
た。

【００１０】

【発明が解決しようとする課題】本件発明においては、
旅行業者とランドオペレータの間のかかる手続を一括で
処理可能なシステムを構築することを目的とする。

【００１１】また、本件発明においては、旅行業者とラ
ンドオペレータとの間に発生する、見積もり・手配・変
更・取消・決済・精算などの一連業務の少なくとも一部
をシステム化することにより、海外旅行にまつわる管理
コストなどを低減させることを目的とする。

【００１２】

【課題を解決するための手段】本発明は、旅行業者とラ
ンドオペレータとの間の情報を管理する旅行情報管理シ
ステムを提供する。この旅行情報管理システム（以下、
本システムという）は、旅行業者とランドオペレータか
らそれぞれ送信される情報を処理するサーバーと、この
サーバに接続され、少なくとも旅行に関する発着日、行
き先、申込者を特定する情報、管理ステータスを含む、
ツアー管理データベースと、ツアー管理データベースに
接続され、そのデータベースに格納された情報が変更さ
れた履歴を管理する変更履歴管理データベースとを具備
する。ここで、管理ステータスとは、前述したオファー
ステージ・調整ステージ・決済ステージ等、そのツアー
の進捗ステージを特定・示唆する情報であって、旅行手
配にかかる情報管理上有用なものをいう。

【００１３】また、ツアー管理データベースは、旅行業
者とランドオペレータとの間の送金処理に関する情報を
含むことができる。なお、旅行業者とランドオペレータ
との間の送金処理に関する情報については、ツアー管理
データベースに接続された別の決済データベースを設け
てもよい。決済データベース又はこれに相当する部分に
は、旅行業者とランドオペレータがあらかじめ合意した
為替レートに関する情報を含ませることにより、為替の
変動による支払人のリスクをヘッジする機能を持たせる
ことが可能である。

【００１４】また、旅行業者が提示する旅行に関する条
件情報と、これに対してアクセスした複数のランドオペ
レータが提示したこの旅行に関するオファー条件情報を
比較するマッチングエンジンをサーバには設けることが
可能である。このマッチングエンジンの比較の結果に基
づいて、サーバは旅行者の希望に添っていると思われる
一つ以上のランドオペレータを選択し、そのランドオペ
レータに関する情報と提示条件を旅行業者に対して通知
する。

【００１５】

【作用】本発明にかかるシステムを採用することによ
り、従前、手作業で行っていた旅行に関する手配業務が
自動化され、管理コストの大幅な低減を図ることが可能
となる。

【００１６】

【発明の実施の形態】本発明にかかる実施の形態を図1
ないし図１１を用いて説明する。図１は、本発明の実施
の形態にかかるシステムを開示している。本実施の形態
にかかる旅行手配システム１(以下、「本システム」とい
う)は、サーバー１１、マッチングエンジン１３，デー
タベース１５，検索エンジン１７を含む。また、本実施
の形態にかかる本システム１は、インターネットその他
の通信網２を介して、他の事業体が保有するサーバシス
テムに接続されている。他の事業体としては、たとえ
ば、旅行業者３，ランドオペレータ５、銀行６などが考
えられる。旅行業者３は、旅行者であるユーザ４との窓
口として、ユーザ４から旅行の依頼を受ける。また、ラ
ンドオペレータ５，７には、日本国内で営業するランド
オペレータ５と現地で営業するランドオペレータ７があ
る。日本国内で営業するランドオペレータ５（国内ラン
ドオペレータという）は、本実施の形態にかかる本シス
テム１にアクセスして、旅行業者３から出されるツアー
オファー等の情報を入手し、現地で営業するランドオペ
レータ７（現地ランドオペレータという）に対して、手
配を依頼する。

【００１７】本実施の形態にかかる旅行手配システム１
の中心となるのはサーバー１１であり、旅行業者３や国
内ランドオペレータ５との間で情報を送受信し、各種デ
ータベース１５に格納し、必要に応じてマッチングエン
ジン１３や検索エンジン１７に対して指令を送る。マッ
チングエンジン１３は、たとえば、複数の国内ランドオ
ペレータがある旅行について条件を提示した場合に、旅
行者の条件と整合する条件を提示した国内ランドオペレ
ータを選出する。これにより、従来、手作業により国内
ランドオペレータから出された条件を比較し、国内ラン
ドオペレータを選定していた作業をシステム化すること
が可能となる。また、検索エンジン１７は、特定の条件
を指定して所望のツアーや旅行者を検索するときなどに
使用されるエンジンである。

【００１８】なお、図１においては、銀行サーバはイン
ターネット等の公衆回線に接続されているが、本システ
ムとの間に結ばれた専用回線に接続されていても構わな
い。特に、送金情報の処理の場面では、このような接続
がセキュリティの観点から好ましい。

【００１９】図２には、データベース１５の中身を開示
する。データベース１５は、ツアー管理データベース２
１，変更履歴管理データベース２３，顧客リストデータ
ベース２５の少なくとも三つから構成されている。ツア
ー管理データベース２１は、ツアーの条件・行き先・日
程・申込者・処理段階（ステータス）などが含まれてい
る。また、変更履歴管理データベース２３は、旅行者の
要望や事情の変更に応じて、ツアー条件等が変更された
場合の変更履歴を管理するデータベースである。顧客リ
ストデータベース２５は、旅行者に関する属性（氏名・
住所・年齢・性別など）とその旅行者が過去に本ツアー
管理システムを介して申し込んだ旅行とが結びつけられ
ている。これらのデータベースの共通項目として、本シ
ステムが各ツアー毎に設定するツアー番号が付与されて
おり、関連づけがなされている。なお、本システムの他
の実施形態として、ツアー代金の決済にかかる決済デー
タベース２７をツアー管理データベース２１の外部に設
けてもよい。

【００２０】図3にはツアー管理データベース２１の詳
細を開示する。ツアー管理データベースは本実施の形態
による旅行手配システムのインデックス的な機能を有す
るデータベースであり、旅行業者とランドオペレータが
必要に応じて参照し、ツアーの内容や手配の状況（ステ
ータス）に関する情報を入手したり、これに情報を入力
することによって一覧性を維持しつつ、情報の交換をす
ることができる。ツアー管理データベースは、ツアー番
号（＃）に関するフィールドを有している。ツアー番号
は本実施の形態による旅行手配システムの管理者が付与
するとおし番号であり、本システムにより管理されてい
るツアーはすべてこの番号が付与されている。また、ツ
アー管理データベースには、担当する旅行業者と国内ラ
ンドオペレータ(Ｌ／Ｏ)にかかるフィールドを有してい
ることが望ましい。ただし、これらのフィールドは、特
に設けず、別のデータベースを構築してリンクをさせて
も構わない。ツアー管理データベースにはツアー基本情
報に関するフィールドが設けられている。ツアー基本情
報としては、ツアーの発着日時の他、行き先、申込者
（代表者）などがあげられるが、これらに限定されるも
のではない。例えば、ランドオペレータに対する打診の
際に用いる情報として「予算」の欄を設けてもよい。ツ
アー基本情報としては、ツアーの内容・条件その他を特
定する基本的な情報を含むことができる。さらに、ツア
ー管理データベースには、ツアーの調整等がいかなる段
階にあるかを示すステータス情報が掲載されている。

【００２１】ステータス情報としては、たとえば、以下
のようなものが考えられる。Ｌ／Ｏ照会中旅行業者が旅行者から入手した希望ツアー条件をツアー
管理データベースにアップロードした段階をいう。この
段階のものについては、国内ランドオペレータに対する
オファーがなされており、国内ランドオペレータは、提
供できる条件・価格等を本システムオペレータに対して
提示することができる。調整中その旅行を担当するランドオペレータが決定され、ラン
ドオペレータにより詳細条件についての予約設定がなさ
れている段階をいう。この段階のものについては、旅行
者の希望その他に応じて旅行条件等の変更がなされるこ
とがある。旅行条件等の変更については、変更履歴管理
データベース（後述）によって記録されている。日程確定調整段階が終了し、出発直前ツアー未了又はツアー催行
中の段階をいう。このステージの多くは、出発日直前
か、ツアー催行中である。インボイス未発行旅行が終了し、現地ランドオペレータからインボイスが
まだ発行されていない段階をいう。なお、後述するよう
に、本システムではインボイスも電子情報として、本シ
ステムで送信・管理することができる。インボイス発行済み／代金未納旅行が終了し、現地ランドオペレータからインボイスは
発行されているが、旅行業者からその代金が未納の段階
をいう。好適な実施例では、旅行代金は毎月単位で集計
されて特定の旅行業者から特定の現地ランドオペレータ
に対して送金される。よって、〆の期日が未到来の場合
はこのステータスとなる。また、現地ランドオペレータ
の手配に不備があり、旅行者からクレームが出されてい
る場合や、当初の見積もりとインボイスに記載された額
が異なっている場合など、何らかの問題が生じている場
合もこのステータスとして表示される。インボイス発行済み／代金完納インボイスに記載された請求額通りに送金がされた段階
をいう。好適な実施例においては、この段階のものは数
ヶ月間ツアー管理データベースに保管され、後に、ツア
ー実績データベース(図示せず)など過去ログを蓄積する
データベースに格納される。

【００２２】図４と図５は、それぞれ、旅程に関するデ
ータベース、部屋割りに関するデータベースである。こ
れらは、ツアー管理データベースのサブデータベースと
して、ツアー管理データベースにリンクされている。旅
程に関するデータベースは、好適な実施例においては、
ツアー管理データベースに表示された特定のツアーに関
するツアー基本情報のフィールドをクリックすることに
より表示される。また、旅程に関するデータベースに
は、ホテルのフィールドが設けられているが、このフィ
ールドをクリックすると、その日時に宿泊するホテルの
部屋割りに関するデータベースが表示される。部屋割り
に関するデータベースは、図５に示すように、旅行者の
部屋割りが示されており、好適な実施例では、部屋番号
（これは実際のものでなくてもよく、とりあえずのナン
バリングでよい）、宿泊者氏名、部屋の種類などから構
成される。

【００２３】ランドオペレータが決まると、オファース
テージから調整ステージに移行する。調整ステージにお
いては、国内ランドオペレータは旅行業者から提示され
た旅行の内容を実現するために、現地ランドオペレータ
と連絡を取り、旅行内容の調整を行う。このステージに
おいては、旅行者の要望や現地事情に応じて、一旦、仮
決めされた旅行条件等を変更すべき場合も生じる。この
ような旅行条件等の変更履歴を管理するために、ツアー
管理データベース２１は、変更履歴管理データベース２
３に接続されている。

【００２４】変更履歴管理データベース２３の一例を図
６に開示する。変更履歴管理データベースは、各ツアー
ごとに設けられており、ツアー番号のタグが設けられて
いる。好適な実施例において、変更履歴管理データベー
スは以下のようなフィールドから構成されている。

【００２５】・変更＃あるツアーにおいて変更ごと
に登録される通し番号・変更日時旅行者などから変更依頼がなされた日時・変更項目コードツアー管理データベースのうち、
どのフィールドが変更の対象となるかを示すコード。た
とえば、図６において、変更項目コード１１は、出発地
のフィールドであり、同１３は行き先のフィールドであ
ると定義されている。・変更前情報変更前に確定していたツアー管理デー
タベースの情報・変更後情報変更されるべき目的のツアー管理デー
タベースの情報・ステータス変更履歴管理データベースは、旅行者
や現地ランドオペレータからの変更依頼が登録される。
従って、変更が了承されるものと、拒否されるものがあ
り、また、すでにそのような結論が出ているものと、調
整中のものがあり得る。このようなステータスを格納す
るフィールドであり、「調整中」「完了」「拒否」など
からなる。

【００２６】なお変更履歴管理データベースのフィール
ド項目は以上に限定されるものではない。

【００２７】以上に沿って、たとえば、変更履歴＃１の
内容について説明するに、４月２５日に旅行者から出発
地（変更項目コード１１）について成田から関空に変更
依頼がなされた。この依頼については、現在調整中であ
り、まだ確定されていないということになる。本システ
ムでは、変更についてもデータベース上でやりとりし、
その過去ログもデータベース上で管理されており、いつ
でも参照可能なので、紙によるやりとりを大幅に減少で
きる。

【００２８】本システムを申し込んだ旅行者について
は、顧客リストデータベース２５に登録される。顧客リ
ストデータベースの目的は、旅行者の情報を一元的に管
理し、将来のマーケッティングに役立てるものである。
顧客リストデータベース２５の一例を図７に開示する。
顧客リストデータベースは、顧客番号（＃）によって、
顧客がナンバリングされており、顧客に関する基本的な
情報（氏名・住所・電話番号・メールアドレス）や属性
（性別・年齢・職業）を含む。また、本システムを通じ
て申し込んだツアー番号が登録されている。このツアー
番号はツアー管理データベースで使用されているツアー
番号と共通のものであることが望ましい。つまり、顧客
リストデータベース２５はツアー管理データベース２１
又ツアー番号を管理している他のデータベースとリンク
しているので、顧客の旅行の嗜好の傾向を分析すること
が可能である。この分析は人手によっても可能である
が、一定の精度の分析であれば何らかのアルゴリズムを
構築して行うことが可能である。サーバー１１には、そ
のような分析装置(分析エンジン)を内在させることがで
きる。

【００２９】分析エンジンによる分析の一例としては以
下のようなものが考えられる。

【００３０】顧客＃０１２３の顧客がツアー番号００
０２、１３５７、７８９０を経験しており、これらのツ
アーの共通点としてアジア系のビーチリゾートであり、
時期が７，８月に集中しているという傾向が見いだされ
たと仮定する。このような場合、顧客＃０１２３の顧客
は、再度ビーチリゾートのツアーに申し込む可能性が高
く、その時期もおおよそ特定できるから、その２ヶ月程
度前の５月頃に、顧客に７，８月のビーチリゾートに関
するツアー情報を電子メール等の手段によって送信する
ことによって、顧客獲得率が高くなる。このような分析
は、ツアー番号をインデックスとして、ツアー番号を管
理しているツアー管理データベースなどにアクセスし、
情報を抽出し、行き先や発着日時を分析するエンジンを
接続することにより可能である。

【００３１】ツアー管理データベースには、決済データ
ベース２７を接続することが可能である。決済データベ
ース２７の一例を図８に示す。決済データベースは、決
済ステージにおいてインボイスの送付状況、請求につい
ての問題の有無、支払い状況などを管理するデータベー
スである。これらの管理はツアーごとになされるもので
あるから、決済データベース２７は、ツアー管理データ
ベースの一部としてマージすることも可能である。

【００３２】図８を参照すると、決済データベース２７
は、ツアー＃、旅行業者、現地ランドオペレータなどの
情報の他に、送金すべき金額（請求額）、支払時期、ス
テータスなどの項目が設けられている。ステータスの項
目としては、たとえば、未送金、旅行業者承認済
み、送金済み、現地ランドオペレータ確認済みなど
の段階が考えられる。また、送金がされていない状態で
も、ツアーの内容に問題があり旅行者からクレーム等が
発生している場合や、事前の見積額と請求額とが異なる
場合など、旅行業者と現地ランドオペレータとの間に何
らかの問題が生じているという事情により送金がなされ
ていないケースも考えられる。このようなケースと、特
段の問題がなく、単に支払い時期が到来していないため
に未送金の状態になっているケースとは区別すべきであ
るから、トラブルフラグにかかるフィールドを設けるこ
とが望ましい。トラブルフラグにかかるフィールドは、
送金上の問題の有無を峻別するためのフィールドであ
り、たとえば、フラグが立っている場合は何らかの問題
が生じていることを示している。図示しないが、決済デ
ータベースにもサブデータベースを設けて、トラブルフ
ラグにかかるフィールドをクリックすると、具体的なト
ラブルが参照できるような構造にしてもよい。また、ト
ラブルフラグをトラブルの類型により色分けするなどし
てもよい。

【００３３】また、支払時期が経過しており、トラブル
フラグが立っていないツアーについては、旅行業者が支
払うべき時期が到来していながら、未払いになっている
のであるから、そのようなツアー番号について検索エン
ジンによって検索をかけ抽出し、催促を行うことも考え
られることである。

【００３４】次に、図9ないし図11を参照して、オファ
ーステージ、調整ステージ、決済ステージについてのス
キームのフローを説明する。

【００３５】図9には、オファーステージにおけるフロ
ーが開示されている。ステップ４１は、本システムによ
るスキームの範囲外である。このステップにおいては、
まず、旅行者（旅行を使用とする者）が旅行業者にコン
タクトし、旅行の条件及び日程を伝える。旅行の条件及
び日程とは、たとえば、発着日、行き先、旅行の目的
（リゾート、観光、ビジネス、留学など）、予算などが
基本的な情報であり、場合によって、それに添えて、旅
行者の特定の希望（シャトーホテルに宿泊したい、なる
べく予算を抑えてほしいなど）が含まれる。

【００３６】次に、ステップ43においては、旅行者から
条件・日程等をヒアリングした旅行業者がツアー管理デ
ータベースに条件・日程等をアップロードする。つま
り、旅行業者は、本システムにアクセスし、ツアー管理
データベースにツアー基本情報（図３参照）をわかる範
囲で入力する。ステップ４５では、ツアー管理データベ
ースにアクセスした国内ランドオペレータは、引き受け
ることのできそうなツアーについて条件を提示する。

【００３７】なお、本実施例においては、ツアー管理デ
ータベースに入力する形で、旅行業者と国内ランドオペ
レータがオファー情報を交換するが、別途、オファーの
ためのデータベースを構築することもよい。この場合、
オファーデータベースのフィールドとしては、ランドオ
ペレータの条件提示期限などが考えられる。ランドオペ
レータから条件提示があった場合であって、オファー提
示期限が経過している場合（ステップ４７）は、オファ
ーのマッチングが判断される（ステップ４９）。オファ
ーのマッチングは、ランドオペレータの提示した条件が
旅行者の依頼条件とマッチングしているかどうかを判断
するステップであり、複数のランドオペレータが条件提
示を行った場合は、マッチングにより最も好条件提示を
したランドオペレータを決定する（ステップ５１）。こ
のオファーのマッチングは、人間が判断することも可能
であるが、一定のアルゴリズムを採用することにより、
マッチングエンジンにより自動化することも可能であ
る。

【００３８】オファーのマッチングについては、複数の
項目を参酌して定めることができる。たとえば、旅行者
が東京発ニューヨーク行きの旅行について、５月１２日
前後を出発日として、５泊６日を希望し、予算を２０万
円以内と依頼を出した場合、Ａランドオペレータが５月
１３日発で予算１６万円、Ｂランドオペレータが５月１
２日発で予算２０万円、Ｃランドオペレータが５月１３
日発予算１９万円との条件提示を行った場合、予算の項
目だけを参酌してＡランドオペレータに決定するのでは
なく、出発日の項目のマッチングを勘案してＢランドオ
ペレータも併せて仮決定できる。また、本システムによ
れば、複数のランドオペレータから出された条件提示を
何らかの基準（例えば、見積額が安い順など）により一
覧表にし、旅行業者に提供することも可能である。この
場合、最終的には、旅行業者から旅行者にコンタクトを
とり、旅行者に最終的な選択権を与えることが通常とな
ろう。この場合でも、複数のランドオペレータ(場合に
よっては２０以上となる)から、２−３のランドオペレ
ータを選択するスキームはマッチングエンジンにより自
動化できるので、管理コストの大幅な削減ができる。

【００３９】このようにして、オファーのマッチングが
なされた後に、ステップ５１においては、国内ランドオ
ペレータが最終的に一社に決定される。そして、ステッ
プ５３において、ツアー管理データベースのステータス
が、「ランドオペレータ照会中」から「調整中」に変更
され、調整ステージへと移行する。オファーデータベー
スを採用して、ツアー管理データベースとは別のデータ
ベースでオファーを管理していた場合は、ランドオペレ
ータが決定されることにより、ツアー管理データベース
にツアーが登録される。ツアー番号（＃）については、
このときに付与することも可能である。

【００４０】次に、図１０に基づいて、調整ステージの
スキームについて説明する。調整ステージにおいては、
ツアーの内容は仮に決定しているものの、多くの小さな
変更がなされたり、時にはツアーのキャンセルがなされ
ることがある。これらについても、ツアー管理データベ
ースと変更履歴管理データベースとを用いることにより
管理される。

【００４１】ステップ６１では、旅行者から旅行業者に
対して、ツアー内容の変更が通知される。ツアー内容の
変更は、たとえば、発着日時の変更、延泊の依頼、旅程
の変更、人員の変更などである。旅行業者は、旅行者か
らこのような通知があると、ステップ６３でツアー管理
データベースに変更の内容を仮入力すると同時に、決定
された国内ランドオペレータに通知する。なお、国内ラ
ンドオペレータに対する連絡は、本システムの機能によ
り、旅行業者が変更を仮入力すると自動的に行われるよ
うにすることが望ましい。

【００４２】変更通知を受けた国内ランドオペレータ
は、場合によっては現地ランドオペレータにも確認しつ
つ、変更について対処可能かどうかを判断する（ステッ
プ６５）。変更について対処不能と判断した場合は、国
内ランドオペレータは旅行業者に対して通知を行い、旅
行業者は、旅行者と折衝を行う。一方、変更について、
対処可能であると判断した場合は、国内ランドオペレー
タはツアー管理データベースの仮入力を本入力に改め
る。仮入力と本入力との区別については、図示されてい
ないが、たとえば、仮入力の場合はそのツアーの行全体
を緑等、特定の色でハイライトを行い、本入力にする場
合は、ハイライトを消去するなどという手法で行うこと
が可能である。また、仮入力を本入力にするために、各
ツアーフィールドに関連してそのような機能を有するボ
タンなどを設けることも望ましい。

【００４３】国内ランドオペレータがツアー管理データ
ベースに対し、本入力である旨を指示した場合には、ツ
アー条件等が変更されたことになり、その情報が変更履
歴管理データベースに転送される。

【００４４】このような調整ステージにおいては、通
常、２０ないし５０回程度の変更がなされ、ツアーの内
容は確定する。旅行日時が迫り、あるいは、すでに旅行
が開始し、ツアー内容が確定した場合は、ツアー管理デ
ータベースのステータスを「調整中」から「内容確定」
にする。本システムの機能により、ツアーにかかる出発
日が到来した場合、自動的にこのようなステータス変更
を行うことが望ましい。

【００４５】ツアーが終了すると、ツアー代金の精算に
関する決済ステージに移行する。決済ステージにおける
スキームについて、図１１を用いて説明する。

【００４６】まず、ツアーが終了すると、現地ランドオ
ペレータはツアーに関する報告（ガイド報告）を行う
（ステップ７１）。この報告は文書で行うことも可能で
あるが、本システムの機能により、これを電子情報とし
て国内ランドオペレータが旅行業者及び本システムの管
理者に送信することも可能である。ガイド報告ととも
に、または、これと前後して、現地ランドオペレータは
請求書に相当するインボイスを旅行業者に対して送信す
る（ステップ７３）。同時に、現地ランドオペレータか
らの連絡を受けて、国内ランドオペレータはインボイス
を送信した旨を決済データベースにアップロードする
（ステップ８１）。なお、好適な実施例においては、イ
ンボイスの送信を省略し、決済データベースに請求額等
をアップロードすることのみによってランドオペレータ
から旅行業者に対する請求事実とすることも可能であ
る。決済データベースに対して請求額をアップロードし
た場合は、自動的にステータスは「未処理」として入力
される。また、本システムの仕様により、支払時期は入
力日から数えて３０日後の日付が属する月末をデフォル
ト値に設定することも可能である。

【００４７】本実施例においては、旅行業者は、インボ
イスを受信し、その請求額等が当初の取り決めた見積も
りと合致しているかどうかを判断する（ステップ７
５）。ガイド報告が旅行者にも送信されている場合は、
旅行者のレスポンスを待って、ツアーが期待通りに行わ
れたどうかの事情を聴取することも可能である。

【００４８】旅行業者による判断や旅行者からの応答を
加味して、旅行業者はインボイスに対して承認を与える
（ステップ７９）。この承認は、実際には、旅行業者に
よりステータスを「未処理」から「承認済み」に変更す
ることにより行われる。

【００４９】ツアーが当初企画されたとおりの内容どお
りに行われなかったり、旅行者からクレームがあった
り、請求額が当初の見積額と異なっている場合は、旅行
業者は承認を与えないことができる。この場合は、ステ
ップ７７により、現地ランドオペレータ等との間で再交
渉が行われる。また、旅行業者は、決済データベースの
該当ツアーにトラブルフラグをたてる。

【００５０】本システムの仕様により、特定の旅行業者
と特定のランドオペレータとの間の決済は月締めで行わ
れる。つまり、ステップ８３により、Ａという旅行業者
とＸというランドオペレータとの組み合わせを持つ決済
データが月ごとに集計され、旅行業者はこれを参照し
て、ランドオペレータに対して毎月の支払額を決定す
る。なお、本実施例によれば、説明したとおり、毎月締
めで支払いがなされるが、これは必須ではなく、支払い
が発生する都度、旅行業者の特定の口座からランドオペ
レータに対して送金が発生する等のシステムを採用する
ことは自由である。

【００５１】現地ランドオペレータに対する送金は、現
地通貨または米ドル建てにすることが通常である。そこ
で、本実施例においては、一つのオプションとして為替
の変動により支払いを遅延したりすることも可能であ
る。たとえば、旅行業者はあらかじめランドオペレータ
を決定する際に、送金の際の為替レートを予約すること
ができる。この場合は、ツアー管理データベースにその
ような予約為替レートのフィールドを設け、入力するこ
とも考えられる。

【００５２】送金を行わない場合は、送金待ちとなり、
決済データベースのステータス項目にはその旨の入力が
なされる（ステップ８７）。ステップ８９で送金がなさ
れると、決済データベースのステータスは送金済みと表
示される。その後、ステップ９１で現地ランドオペレー
タが送金を確認し、検収をあげる。現地ランドオペレー
タが検収をあげると、国内ランドオペレータに連絡し、
国内ランドオペレータは決済データベースのステータス
を「確認済み」とする（ステップ９３）。

【００５３】本実施例においてはランドオペレータが検
収を行う方式を開示したが、本システムを銀行システム
と直結し、資金の流れを管理する銀行が検収等を代行す
るようなシステムでもよい。

【００５４】本実施例においては、現地ランドオペレー
タはシステムに直接アクセスすることがない態様を開示
しているが、たとえば、本システムに翻訳エンジンを設
けることにより、現地ランドオペレータが直接旅行業者
とやりとりを行うようにしてもよい。この場合でも、本
発明の本質においては、何ら相違することがない。

【００５５】また、本実施例においては、インターネッ
ト等、オープンネットワークを前提としているが、金融
機関との決済情報のやりとりなどは一部、専用回線など
のクローズドネットワークで構築すればセキュリティ
上、優位性を保つことができる。

【００５６】

【発明の効果】以上のように、本発明においては、シス
テム上に構築されたいくつかのデータベースへ情報をア
ップロード、漸次更新することにより、旅行業者とラン
ドオペレータとの間に発生する手続を処理することがで
きる。よって、旅行業者とランドオペレータの間の手続
を一括で処理可能なシステムを構築することができる。

【図面の簡単な説明】

【図１】本発明にかかるシステムの全体図である。

【図２】本発明に使用されるデータベースの構成図であ
る。

【図３】ツアー管理データベースの概要図である。

【図４】旅程サブデータベースの概要図である。

【図５】部屋割りサブデータベースの概要図である。

【図６】変更履歴管理データベースの概要図である。

【図７】顧客リストデータベースの概要図である。

【図８】決済データベースの概要図である。

【図９】オファーステージのフロー図である。

【図１０】調整ステージのフロー図である。

【図１１】決済ステージのフロー図である。

【図１２】従前の業務フローを示す図である。

【符号の説明】

１本システム１１サーバ１３マッチングエンジン１５データベース１７検索エンジン２１ツアー管理データベース２３変更履歴管理データベース２５顧客リストデータベース２７決済データベース

Claims

【特許請求の範囲】

【請求項１】旅行業者とランドオペレータとの間の情
報を管理する旅行情報管理システムであって、前記情報
を処理するサーバーと、上記サーバに接続され、少なく
とも旅行に関する発着日、行き先、申込者を特定する情
報、管理ステータスを含む、第一のデータベースと、上
記第一のデータベースに接続され、上記第一のデータベ
ースに格納された情報が変更された履歴を管理する第二
のデータベースと、を具備する、旅行情報管理システ
ム。
【請求項２】上記第一のデータベースは、前記旅行業
者と前記ランドオペレータとの間の送金処理に関する情
報を含む、請求項１の旅行情報管理システム。
【請求項３】上記第一のデータベースに接続され、前
記旅行業者と前記ランドオペレータとの間の送金処理に
関する情報を含む第三のデータベースを具備する、請求
項１の旅行情報管理システム。
【請求項４】上記第一のデータベース又は上記第三の
データベースは、前記旅行業者と前記ランドオペレータ
が合意した為替レートに関する情報を含む、請求項２又
は３の旅行情報管理システム。
【請求項５】前記旅行業者が提示した一の旅行に関す
る第一の条件情報と、複数のランドオペレータが提示し
た前記一の旅行に関する第二の条件情報を比較し、前記
旅行業者に対して、前記複数のランドオペレータの中か
ら少なくとも一つのランドオペレータが提示した前記第
二の条件情報と、前記少なくとも一つのランドオペレー
タを特定する情報を通知する、請求項１ないし４の旅行
情報管理システム。