(57)【要約】【課題】一つの認証により、複数の旅行機関システムとの間でデータ中継を行い、検索結果・予約結果をユーザー端末において受信可能なシステムの提供。【解決手段】旅行商品の手配を行う検索予約サーバーと、旅行商品・サービスを提供する旅行機関が備える旅行機関システムと、両者を結合して機能させる結合サーバーとから構成される。検索予約サーバーは、ユーザー情報記憶手段と、認証手段と、認証データ中継手段と、コンテンツ表示手段と、検索条件受信抽出手段と、予約指示受信手段と、データ受信手段とを備える。結合サーバーは、複数の旅行機関システムとの間でのデータ送受信の中継を行う。【選択図】  図１
2004192357.tif 000002
【特許請求の範囲】
【請求項１】
交通機関、宿泊施設などの旅行商品の手配を行う検索予約サーバーと、交通機関・宿泊施設などの旅行商品・サービスを提供する旅行機関が備える旅行機関システムと、検索予約サーバーおよび旅行機関システムとの間のデータ中継を行い両者を結合して機能させる結合サーバーとを含み構成され、ユーザー端末装置からアクセスされデータ処理を行うシステムであって、
前記の検索予約サーバーは、
ユーザーに関する情報を記憶するユーザー情報記憶手段と、
ユーザー端末からのアクセスに対し認証を行う認証手段と、
あらかじめ記憶されている所定のユーザー情報に対応付けられて記憶された、複数の旅行機関システムごとに設定された認証データを参照し、旅行機関システムとの間での認証データ送受信の中継を行う認証データ中継手段と、
ユーザー端末からのコンテンツ配信要求に応答してコンテンツ送信・データ検索・その他のデータ処理を行うコンテンツ表示手段と、
ユーザー端末から送信される、交通機関・宿泊施設などの旅行商品の検索条件を受信または抽出する検索条件受信抽出手段と、
ユーザー端末から送信される、交通機関・宿泊施設などの旅行商品の予約指示を受信する予約指示受信手段と、
結合サーバーからデータ処理の結果を受信するデータ受信手段とを少なくとも備え、
前記の結合サーバーは、あらかじめ記憶されている所定のユーザー情報と、受信した検索条件または予約指示を含むデータを、複数の旅行機関システムごとに、所定のデータ項目のそれぞれを中継先の各旅行機関システムのデータに対応付けて送信し、旅行機関システムとの間でのデータ送受信の中継を行うデータ中継手段を少なくとも備え、
ユーザー端末から検索予約サーバーに検索条件・予約指示の送信をすることにより、複数の旅行機関システムとの間でデータ中継を行い、検索結果・予約結果をユーザー端末において受信可能なことを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項２】
請求項１に記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織を識別するユーザー組織情報と、組織に属するユーザー個人を識別するユーザー個人情報とが記憶されたことを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項３】
請求項１または２のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、ユーザー個人または法人などの組織に対応して上限金額データが記憶されており、前記の検索条件受信抽出手段が、ユーザー情報を参照して、ユーザーに対応する検索条件を生成することを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項４】
請求項１または２のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、ユーザー個人または法人などの組織に対応して上限金額データが記憶されており、前記のコンテンツ表示手段が、ユーザー情報を参照して、上限金額を超えるか否かを判定してコンテンツを生成し表示することを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項５】
請求項１〜４のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織に対応して出張規定データが記憶されており、前記の検索条件受信抽出手段が、ユーザー情報を参照して、ユーザーに対応する検索条件を生成することを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項６】
請求項１〜４のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織に対応して出張規定データが記憶されており、前記のコンテンツ表示手段が、ユーザー情報を参照して、出張規定に適合するか否かを判定してコンテンツを生成し表示することを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項７】
請求項１〜６のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織に対応して優待証データまたは組織割引データが記憶されており、前記の検索条件受信抽出手段が、ユーザー組織情報およびユーザー個人情報を抽出することにより、検索条件の生成、または検索結果の生成、または予約結果の生成において、ユーザーに対応する優待証データまたは組織割引データを反映することを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項８】
請求項１〜７のいずれかに記載の発明において、
前記システムにはさらに、複数の旅行機関システムとの間でデータ中継を行い予約された利用料金情報をユーザー情報に関連付けて記憶する利用料金記憶手段が備えられたことを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項９】
請求項１〜８のいずれかに記載の発明において、
前記のデータ中継手段は、所定のデータ項目を含む検索結果を複数の旅行機関システムから受信して、コンテンツ表示手段により複数の旅行機関システムの検索結果を同時に表示させるとともに、表示されるコンテンツにはＯＰＥＮ手配指示または予約指示の入力手段が含まれることを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項１０】
請求項９に記載の発明において、
コンテンツ表示手段により表示される、複数の旅行機関システムの所定のデータ項目を含む検索結果には、行程を示すスケジュールデータが含まれることを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【請求項１１】
請求項９または１０のいずれかに記載の発明において、
コンテンツ表示手段により表示される、複数の旅行機関システムの所定のデータ項目を含む検索結果には、行程を示す路線データが含まれることを特徴とする、結合サーバーを用いた旅行商品検索・予約システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、結合サーバーを用いた旅行商品検索・予約システムに関する。
【０００２】
【従来の技術】
近年、パーソナルコンピュータやインターネットの利用の普及に伴い、電子商取引や企業間取引などが活発に行われ、また企業内などにおけるシステムも様々なものが開発されている。
このような中で、旅行や宿泊、あるいはこれらを利用する出張などに際して、交通機関や宿泊施設、その他の関連する旅行商品やサービスの検索や、予約などをインターネットを利用して行うことも可能になっている。
たとえば、旅行代理店のＷＥＢサイトや、交通機関・宿泊施設のＷＥＢサイトなどにおいて、データを検索したり、予約を行ったりするものである。
また、社内のシステムの一例としては、出張申請やその稟議・承認、あるいは出張旅費の精算、また経理部署などの担当部署と旅行会社との間における手配や請求などの処理を行うような例である。
【０００３】
たとえば特開２００１−２６５９５１「旅行商品または、該旅行商品に係る運送座席の販売システム」においては、航空機などの運送機関を利用する旅行商品の販売に関して、旅行社、運送会社、消費者間の取引きを容易にするためのシステムが提案されている。
運送会社または運送会社から委託を受けた者が開設するインターネットのホームページにおいて、消費者が旅行の目的、地域、費用、時期、期間などの希望条件を入力し、希望条件に合致するかまたはそれに近い旅行商品を表示し、その詳細情報の表示や、各旅行商品それぞれの問合せ先の旅行社が開設するホームページへの誘導、当該旅行社の名称・電話番号等の表示などを行うものである。
しかしながら、この出願は、旅行商品の検索等を行うシステムではあるものの、検索の結果、その旅行商品を取り扱う旅行者に関する情報が抽出されるだけであり、さらに検索等の技術は既に知られていた技術である。
【０００４】
【発明が解決しようとする課題】
ＷＥＢサイトにおいて直接、交通機関の検索や予約までをユーザーが行えるシステムとしては、特開２００２−１１７２６６「航空券予約販売システム」においては、国際航空会社における航空券の空き状況を、複雑な操作や特定のシステムを利用しないで簡単にアクセスして把握することができる航空券予約販売システムが提案されている。
各航空会社が発行している航空券を主体とした航空券情報が蓄積されているデータベースを備えた航空券情報サーバーと、航空座席予約及び照会を行う航空座席予約・照会サーバーとから構成される。航空座席予約・照会サーバーは航空券情報サーバーに専用回線で接続して航空券情報を受信できるようにすると共に、所定のネットワーク上において航空券を専門に扱う旅行代理店を含むエンドユーザが航空券情報に基いて航空券料金の閲覧及び航空座席予約ができるシステムである。
この出願は、エンドユーザーが航空券情報の検索や、予約、運賃の算定、付帯サービス情報の取得などをするものである。
航空会社の航空券を専門に扱うサーバーから航空券を主体とした航空情報を収集し、その収集した航空情報をエンドユーザであっても自ら航空空席情報及び複数にわたる航空券の航空料金とを対比して閲覧できるため、専門的な旅行会社に限定されることなく、一般のエンドユーザであっても、例えば値段の相違する複数の国際航空券、当該航空券に付随するホテル等のサービス等をエンドユーザ側で総合的に選択できるようになるというものである。
【０００５】
このように、たとえば旅行や出張などを想定すれば明らかであるが、出発地・予定地・中継地などがあり、そのルートには様々な交通機関を利用することが一般的に考えられる。また、利用するそれぞれの交通機関について、日時や料金、その他の様々な希望条件を満たすものをユーザーは探す必要があり、座席の予約が必要であるものは空席の照会をそれぞれについてしなければならない。
さらに、宿泊施設についても同様であり、１か所の地域においても、複数の宿泊施設の中から日時や料金、その他の様々な希望条件を満たすものをユーザーは探す必要があり、空室の照会をそれぞれについてしなければならない。
【０００６】
また、航空会社などの交通機関や宿泊施設等を予約するために、ユーザーが検索・予約の仲介を行う旅行会社のシステムに対し依頼した場合にも、依頼を受けた旅行会社においては、自動的に複数の様々な各交通機関・宿泊施設等にアクセスして検索・予約などを行えるわけではない。
すなわち、複数の交通機関や宿泊施設等のシステムを利用して検索・予約等を行うためには、それぞれのシステムに対し順次、認証処理を経てログインし、検索や予約などを行った後にログアウトし、順次次のシステムにログインとログアウトを繰り返す処理をしなければならない。そのためのユーザーＩＤやパスワードなどをいくつも使い分ける必要があった。
特に、たとえば航空券情報の検索や予約においては、同じ出発地空港から到着地空港まで搭乗する場合にも、複数の航空会社の便が就航しているため、紙の時刻表や、あるいは仮に時刻表情報を公開しているＷＥＢサイトなどがあって確認はできたとしても、航空会社のシステムに対する予約などは、結局それぞれのシステムに対し順次、認証処理を経てログインし、検索や予約などを行った後にログアウトしなければならない。
【０００７】
また、特開２００１−１１８０１０「予約システム」においては、開発、維持、運用コストが少なく、在庫情報や、運賃体系の変更などをリアルタイムに反映でき、複数の会社のシステムを統合的に扱える予約システムが提案されている。
この出願も上記出願と同様に、エンドユーザーが航空券情報の検索や、予約、運賃の算定、付帯サービス情報の取得などをするためのシステムである。この出願においては、仲介をするサーバー（ハンドリングサーバー）は、複数の航空会社の情報を同時に検索するものの、予約は複数の航空会社のそれぞれに対して行われ、決済もそれぞれの航空会社のシステムにおいて行われるものである。
しかしながら、「顧客が異なる複数社の商品を選択した場合は、それぞれの商品を取り扱う航空会社に対する決済画面を同時に表示し、決済を行うこともできる」とされているように、あくまでも航空会社のシステムとの間の情報の仲介だけを行うようにされており、ハンドリングサーバーと各航空会社のシステム間のやりとりは、インターネット技術（ＦＯＲＭタグなど）を利用して行うことで、標準性、開発容易性、拡張容易性を実現しているものの、ＸＭＬ技術などのタグが異なるシステム間でのデータ検索等を想定した技術である。
【０００８】
さらに、上記出願は情報の仲介をするだけであるために、それぞれの商品を取り扱う航空会社に対する決済画面を同時に表示し、決済を行うこともできるものの、決済は別々に行われるものであり、仲介するシステムにおいて、一元的に決済が可能にされているものではない。
また、どの航空会社などのシステムにアクセスするかといった判断は、ユーザー自身が判断して行う必要があり、仲介するサーバーにおいて自動的に行われるものではない。またそれぞれのシステムに対するログインの際のユーザーＩＤなどの認証処理、認証データの管理方法が不明であり、結局はそれぞれのシステムに対し順次、認証処理を経てログインし、検索や予約などを行った後にログアウトしなければならない。
さらに、複数の会社に対し検索を行った場合にも、上記出願は航空会社に限られているために、鉄道、バス、その他の交通機関なども含めた同時検索、同時予約が行えるわけではないが、実際の旅行や出張に際しての手配には、こうした複数の交通機関はもとより、宿泊施設、レンタカー、その他の旅行商品・サービスなども含めて、同時検索、同時予約が行えることが望まれる。
さらに、上記出願においては、検索結果はそれぞれの会社ごとの結果が表示されるものである。しかしながら、実際の旅行や出張に際しての手配には、こうした複数の交通機関はもとより、宿泊施設、レンタカー、その他の旅行商品・サービスなども含めて、スケジュール順の表示や、ルート別の表示などの様々な表示方法を、複数の会社の検索結果が同時に表示されることが望まれる。
また、出張の手配などに際しては、ユーザー個人の情報だけではなく、社内情報の登録や、会社が保有する交通機関等の優待証の取り扱い、管理者による管理、その他詳細なユーザーインターフェースなどがあれば便利である。
【０００９】
そこで本発明においては、上記の様々な課題を解決し、複数の交通機関や宿泊施設等のシステムを利用して検索・予約等を行う際に、それぞれのシステムに対し順次、認証処理を経てログインし、検索や予約などを行った後にログアウトする処理を繰り返すことなく、共通のＩＤやパスワードなどを用いて検索や予約が行えるシステムを提供することを目的とする。中継するサーバーが接続先のシステムを判定し、判定された各社のシステムへの認証処理を自動的に行うことにより、異なるＷＥＢサイトに対し、共通ＩＤでのログインが可能となる。
さらに、ユーザー自身が予約等を行う各社独自のセルフブッキングツールを、ユーザーとの間を結合するシステムを介在させることにより、交通機関や宿泊施設などが個々に結合開発することを不要にすることを目的とする。
また、実際の旅行や出張に際しての手配には、こうした複数の交通機関はもとより、宿泊施設、レンタカー、その他の旅行商品・サービスなども含めて、同時検索、同時予約が行えるシステムを提供することを目的とする。
さらに本発明においては、実際の旅行や出張に際しての手配をする場合に、複数の交通機関や、宿泊施設、レンタカー、その他の旅行商品・サービスなども含めて、スケジュール順の表示や、ルート別の表示などの様々な表示方法を、複数の会社の検索結果を同時に表示することが可能なシステムを提供することを目的とする。これによりたとえば、異なるシステムでの手配結果を1枚のスケジュール表にまとめて、印刷することなどが可能になる。また社内システムと連携することにより、購買承認、精算画面への連動、請求照合などが可能となり、ペーパーレス、キャッシュレスを推進することができる。
さらに本発明においては、出張の手配などに際して、ユーザー個人の情報だけではなく、社内情報の登録や、会社が保有する交通機関等の優待証の取り扱い、管理者による管理、その他詳細なユーザーインターフェースなどを提供することを目的とする。
また、接続先は航空会社、その他の交通機関などの基幹システムとすることができるため、セルフブッキングのような無人の手配ができ、２４時間いつでも、便名が決定していれば即時手配が可能になり、チケットレスでも搭乗が可能になる。さらに「１２：００頃に大阪に着きたい」、「駅近くで１万円のホテルで手配」等の曖昧な検索と予約を可能にすることができる。
【００１０】
【課題を解決するための手段】
上記課題を解決するため、請求項１に記載の発明においては、
交通機関、宿泊施設などの旅行商品の手配を行う旅行商品検索予約サーバーと、交通機関・宿泊施設などの旅行商品・サービスを提供する旅行機関が備える旅行機関システムと、旅行商品検索予約サーバーおよび提供機関システムとの間のデータ中継を行い両者を結合して機能させる結合サーバーとを含み構成され、ユーザー端末装置からアクセスされデータ処理を行うシステムであって、
前記の旅行商品検索予約サーバーは、
ユーザーに関する情報を記憶するユーザー情報記憶手段と、
ユーザー端末からのアクセスに対し認証を行う認証手段と、
あらかじめ記憶されている所定のユーザー情報に対応付けられて記憶された、複数の旅行機関システムごとに設定された認証データを参照し、旅行機関システムとの間での認証データ送受信の中継を行う認証データ中継手段と、
ユーザー端末からのコンテンツ配信要求に応答してコンテンツ送信・データ検索・その他のデータ処理を行うコンテンツ表示手段と、
ユーザー端末から送信される、交通機関・宿泊施設などの旅行商品の検索条件を受信または抽出する検索条件受信抽出手段と、
ユーザー端末から送信される、交通機関・宿泊施設などの旅行商品の予約指示を受信する予約指示受信手段と、
結合サーバーからデータ処理の結果を受信するデータ受信手段とを少なくとも備え、
前記の結合サーバーは、あらかじめ記憶されている所定のユーザー情報と、受信した検索条件または予約指示を含むデータを、複数の旅行機関システムごとに、所定のデータ項目のそれぞれを中継先の各旅行機関システムのデータに対応付けて送信し、旅行機関システムとの間でのデータ送受信の中継を行うデータ中継手段を少なくとも備え、
ユーザー端末から旅行商品検索予約サーバーに検索条件・予約指示の送信をすることにより、複数の旅行機関システムとの間でデータ中継を行い、検索結果・予約結果をユーザー端末において受信可能な、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１１】
また、上記課題を解決するため、請求項２に記載の発明においては、
請求項１に記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織を識別するユーザー組織情報と、組織に属するユーザー個人を識別するユーザー個人情報とが記憶された、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１２】
また、上記課題を解決するため、請求項３に記載の発明においては、
請求項１または２のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、ユーザー個人または法人などの組織に対応して上限金額データが記憶されており、前記の検索条件受信抽出手段が、ユーザー情報を参照して、ユーザーに対応する検索条件を生成する、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１３】
また、上記課題を解決するため、請求項４に記載の発明においては、
請求項１または２のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、ユーザー個人または法人などの組織に対応して上限金額データが記憶されており、前記のコンテンツ表示手段が、ユーザー情報を参照して、上限金額を超えるか否かを判定してコンテンツを生成し表示する、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１４】
また、上記課題を解決するため、請求項５に記載の発明においては、
請求項１〜４のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織に対応して出張規定データが記憶されており、前記の検索条件受信抽出手段が、ユーザー情報を参照して、ユーザーに対応する検索条件を生成する、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１５】
また、上記課題を解決するため、請求項６に記載の発明においては、
請求項１〜４のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織に対応して出張規定データが記憶されており、前記のコンテンツ表示手段が、ユーザー情報を参照して、出張規定に適合するか否かを判定してコンテンツを生成し表示する、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１６】
また、上記課題を解決するため、請求項７に記載の発明においては、
請求項１〜６のいずれかに記載の発明において、
前記のユーザー情報記憶手段には、法人などの組織に対応して優待証データまたは組織割引データが記憶されており、前記の検索条件受信抽出手段が、ユーザー組織情報およびユーザー個人情報を抽出することにより、検索条件の生成、または検索結果の生成、または予約結果の生成において、ユーザーに対応する優待証データまたは組織割引データを反映する、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１７】
また、上記課題を解決するため、請求項８に記載の発明においては、
請求項１〜７のいずれかに記載の発明において、
前記システムにはさらに、複数の旅行機関システムとの間でデータ中継を行い予約された利用料金情報をユーザー情報に関連付けて記憶する利用料金記憶手段が備えられた、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１８】
また、上記課題を解決するため、請求項９に記載の発明においては、
請求項１〜８のいずれかに記載の発明において、
前記のデータ中継手段は、所定のデータ項目を含む検索結果を複数の旅行機関システムから受信して、コンテンツ表示手段により複数の旅行機関システムの検索結果を同時に表示させるとともに、表示されるコンテンツにはＯＰＥＮ手配指示または予約指示の入力手段が含まれる、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００１９】
また、上記課題を解決するため、請求項１０に記載の発明においては、
請求項９に記載の発明において、
コンテンツ表示手段により表示される、複数の旅行機関システムの所定のデータ項目を含む検索結果には、行程を示すスケジュールデータが含まれる、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００２０】
また、上記課題を解決するため、請求項１１に記載の発明においては、
請求項９または１０のいずれかに記載の発明において、
コンテンツ表示手段により表示される、複数の旅行機関システムの所定のデータ項目を含む検索結果には、行程を示す路線データが含まれる、結合サーバーを用いた旅行商品検索・予約システムであることを特徴としている。
【００２１】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。
図１は、本発明のシステムの基本的な構成の一例を示すシステム構成図である。
交通機関、宿泊施設などの旅行商品の手配を行う検索予約サーバーと、交通機関・宿泊施設などの旅行商品・サービスを提供する旅行機関が備える旅行機関システムと、検索予約サーバーおよび旅行機関システムとの間のデータ中継を行い両者を結合して機能させる結合サーバーとを含み構成される、ユーザー端末装置からアクセスされデータ処理を行うシステムである。
【００２２】
旅行機関システムは、交通機関・宿泊施設などの旅行商品・サービスを提供する旅行機関が備えるシステムであり、検索・予約・請求などを行うために必要なデータベースやプログラム等を備えるサーバー装置などである。
旅行機関は、具体的には、航空会社、鉄道会社、船会社、バス会社、レンタカー会社などの輸送機関・交通機関や、ホテルなどの宿泊施設その他の旅行サービスに関連する各種サービスを提供する機関である。これらの旅行サービスの予約をユーザーから、また旅行会社、旅行代理店などから受け付けて、手配から請求・決済処理までを行う、あるいはこれらに類似する予約・仲介・手配・請求等を行う機関である。
【００２３】
なお、本発明において、旅行商品・サービスというときには狭義の交通・宿泊以外にも、旅行会社に依頼することの可能な商品・サービスを広くいい、たとえば出張や会社業務に伴う食事や宴会などの手配、お土産の手配、会議やイベントなどの各種の会場の手配、その他の手配や精算が必要となるものを含む。
【００２４】
従来、これらの旅行機関システムに対して検索や予約などを行う場合には、ユーザーまたは旅行会社などから、それぞれの旅行機関システムに対して、別々にユーザーＩＤやパスワードなどを用いてログインし、検索や予約などの必要なデータ処理を行った後にログアウトをするという処理が必要であった。
また、複数の航空会社や、複数の鉄道会社などのデータを同時に検索・予約したり、宿泊その他の旅行商品・サービスを含めて検索・予約を同時にすることができなかったため、それぞれの旅行機関システムにログインし、データ検索などをした後にログアウトして、予約する座席や宿泊などを確認・決定し、再度ログインすることにより予約などをしなければならなかった。
本発明のシステムにおいては、後述するように旅行会社などが検索予約サーバーを設け、複数の旅行機関システムに対し統一されたインターフェースで検索や予約を行うようにするとともに、複数の異なる旅行機関システムに対してのデータ送受信、データ処理において、データ形式やデータ項目の照合や変換を行うための結合サーバーを設けている。
各旅行機関システムのデータベースの構成や、データ項目、データ形式、その他が異なるためであり、また各旅行機関システムにログインするためのユーザーＩＤなどの認証データをそれぞれ入力しなくても済むように変換を行い同時にログインするためである。
【００２５】
（旅行機関システム）
航空会社などの交通機関や宿泊施設など、それぞれの旅行機関システムのシステムは、前記の通り異なるが、検索・予約・請求などを行う基本的な機能が類似しているため、概略、下記の構成を備えている。
出張や旅行などのように、交通機関や宿泊施設の日時や人数等を指定して手配する必要がある場合には、旅行機関システムは、交通機関、宿泊施設などの旅行商品に関する提供可能なサービスの在庫データを記憶する在庫情報データベースを備えている。なお、通勤定期の手配などのように、日時や人数等を指定して手配しなくてもよい場合には、在庫情報データベースはなくても可能である。区間および期間などが指定できれば購入できるからである。
在庫情報は、交通機関の空席や、宿泊施設の空室などの在庫データである。
在庫データは、交通機関の在庫データであれば、日時、区間、席の種類、便名や列車名など、運賃、その他のデータと共に、空席の有無が記憶されている。また宿泊施設のデータであれば、日時、部屋の種類、食事、宿泊施設名、部屋名や部屋番号、宿泊可能人数、宿泊料金、付帯料金、その他のデータと共に、空室の有無が記憶されている。
【００２６】
また旅行機関システムは、出張や旅行などのように、交通機関や宿泊施設の日時や人数等を指定して手配する必要がある場合には、前記の組織が備える端末装置から送信された、交通機関、宿泊施設などの旅行商品の予約データを記憶する予約情報データベースを備えている。
なお、通勤定期の手配などのように、日時や人数等を指定して手配しなくてもよい場合には、予約情報データベースはなくても可能である。区間および期間などが指定できれば、予約をしなくても購入できるからである。
予約情報データベースには、旅行機関システムに照会をして在庫情報データベースに予約があった場合に、予約された情報を記憶する。予約情報は、交通機関の在庫データであれば、日時、区間、席の種類、便名や列車名など、運賃、その他のデータが、予約を行ったユーザーである出張者の個人ＩＤに関連付けられて記憶される。宿泊施設のデータであれば、日時、部屋の種類、食事、宿泊施設名、部屋名や部屋番号、宿泊人数、宿泊料金、付帯料金、その他のデータが、予約を行ったユーザー情報に関連付けられて記憶される。
【００２７】
また旅行機関システムは、予約に基づき行われる旅行機関システムとユーザーまたはユーザーとの取引を仲介する旅行会社等との取引データを記憶する取引情報データベースを備えている。
取引情報は、予約を行った結果をユーザーの端末装置に回答する回答や、サービスの提供を受けるユーザーから受信した確認や変更、履歴などのデータである。
【００２８】
また旅行機関システムは、取引データに基づき発生する請求データを記憶する請求データベースを備えている。
請求データベースは、ユーザーまたはユーザーとの取引を仲介する旅行会社等とに対し、毎月などの所定期間ごとに請求が行われる請求金額とその明細などのデータを記憶する。請求データベースに記憶されるデータに基づき、請求書などを出力することが可能にされている。
なお、前記の各データベースは、関係データベース、分散型データベース、その他の様々な構成を採用することができるので、必ずしも前記の各構成に限定されない。同様・類似のデータが記憶管理できればよいためである。
【００２９】
また、旅行機関システムは、ユーザーに関する情報を記憶するユーザー情報記憶手段を備えている。
個人のユーザー情報や、ユーザーが組織（法人等）に属する場合の組織のユーザー情報を記憶することにより、個人ＩＤ・パスワードや、組織（法人）ＩＤ・パスワードなどを発行し、認証サーバーによる認証処理に利用する。
ユーザー情報記憶手段には、ユーザーＩＤに関連付けられて、氏名、部署、連絡先住所、連絡先電話番号、電子メールアドレスなどの情報を記憶する。ユーザーが組織（法人等）に属する場合には、ユーザー情報記憶手段には、法人などの組織を識別するユーザー組織情報と、組織に属するユーザー個人を識別するユーザー個人情報とが記憶される。
また、航空会社の株主優待その他の優待証情報や、ユーザーである企業（法人）等ごとに割引などが設定されている場合など、ユーザーに関連するデータを記憶することができる。
【００３０】
旅行機関システムは、ユーザー端末との間のデータ処理を中継する旅行会社などが備えるシステム（結合サーバー）との間でデータ送受信を行い、送受信されるデータに基づきデータ処理を行うことにより、ユーザー端末からユーザーまたはその管理者が必要なデータを登録してユーザー登録を行い、旅行機関システムに対し在庫データの照会を行い、予約可能であれば予約を行い、手配を完了させる処理、取引情報を記録する処理、その他の処理などを行うことが可能にされている。
【００３１】
次に、検索予約サーバー、結合サーバー、予約旅行機関システムなどは通常はサーバー装置であり、これらサーバー装置の基本的なシステムの構成について説明する。
サーバー装置は、インターネットに代表されるネットワークに接続されて備えられ、ネットワークに接続する端末装置からアクセスされる。ネットワークには、インターネットをはじめとして、専用線により接続されたネットワーク形態や、企業間ＬＡＮ、ＷＡＮなどの形態を広く含む。またここで用いられる通信回線の形態には、有線通信、無線通信の形態を広く含み、衛星通信や、Ｂｌｕｅｔｏｏｔｈなどを用いた形態を含む。結合サーバーと各旅行機関システムとの間には、望ましい形態の一例としては専用線による接続を採用することができるが、これには限定されない。
サーバー装置は、通常は、アプリケーションサーバー、データベースサーバー、認証サーバー、ＷＥＢサーバー、その他必要に応じメールサーバー、その他の各種装置により構成することができる。これらの各サーバーは、物理的に同一の装置に設けられる形態や、物理的に複数の装置からなる形態、あるいはネットワークを介して接続される物理的に複数の装置からなる形態などを含み、機能的に同様の機能が実現されるならば、様々な形態を含む。
【００３２】
（検索予約サーバーおよび結合サーバー）
次に、検索予約サーバーおよび結合サーバーについて説明する。
前記したように、本発明のシステムにおいては、旅行会社などが検索予約サーバーを設け、複数の旅行機関システムに対し統一されたインターフェースで検索や予約を行うようにするとともに、複数の異なる旅行機関システムに対してのデータ送受信、データ処理において、データ形式やデータ項目の照合や変換を行うための結合サーバーを設けている。
検索予約サーバーは、主として検索・予約処理を行うためのコンテンツ、プログラム、および必要なデータベース等を備えるものである。サーバーの構成は、ユーザー端末からアクセスするためのコンテンツデータ及びプログラムを記憶するＷＥＢサーバーを備え、さらに必要に応じアプリケーションサーバー、データベースサーバー、認証サーバー、ＷＥＢサーバー、その他必要に応じメールサーバー、その他の各種装置により構成することができる。コンテンツデータには、ＨＴＭＬファイル、ＸＭＬファイルなどのＷＥＢ上に表示されるデータファイルや、Ｃ−ＨＴＭＬファイルなどのＷＥＢサイトにアクセス可能な携帯電話等に表示されるデータファイルなどが含まれる。
【００３３】
図１を再度参照すると、検索予約サーバーと結合サーバーとは、ユーザー端末と旅行機関システムとを中継する旅行会社などが備え、組織（企業等）Ｂや、あるいは組織に属さないユーザー個人からアクセス可能に設置してもよい。
組織（企業等）Ｂの組織内においては、たとえば社内の出張申請・管理システムなどを設け、社内システムにおいて検索予約サーバーへアクセスしデータ処理を行うメニューなどを連携して備えることにより、検索予約サーバーへの検索・予約等の処理を行えるようにすることもできる。
また、前記のように、各サーバーは、物理的に同一の装置に設けられる形態や、物理的に複数の装置からなる形態、あるいはネットワークを介して接続される物理的に複数の装置からなる形態などを含むので、検索予約サーバーと結合サーバーとは物理的に別々の装置であってもよい。
一方、検索予約サーバーと結合サーバーとは物理的に同一の装置であってもよい。
図１を再度参照すると、結合サーバーはユーザー端末と旅行機関システムとを中継する旅行会社などが備え、検索予約サーバーは旅行会社などと契約した組織（企業等）Ａが組織内に設置されるようにしてもよい。
組織（企業等）Ａの組織内においては、たとえば社内の出張申請・管理システムなどを設け、社内システムと検索予約サーバーと連携して備えることにより、検索予約サーバーへの検索・予約等の処理を行えるようにすることもできる。
【００３４】
法人などの組織が備える端末装置からアクセスされデータ処理を行う際の、サーバーシステムに接続するためのユーザー装置としては、通常、パーソナルコンピュータやワークステーションなどのコンピュータ端末が用いられる。この他、ユーザー端末には、インターネット等に接続可能なブラウザ機能を搭載した携帯電話をはじめとする無線通信端末、携帯情報端末や、インターネットＴＶ、ゲーム機器、テレビ会議システム、その他のネットワーク接続機能を備えた家電製品などの機器を広く含むことができる。
なお、法人などの組織が備えるユーザー装置としては、特に代表的な形態では、組織内に設置されたコンピュータ装置がＬＡＮ接続などにより備えられ、出張者などのユーザーによる予約処理や、ユーザーの上司・担当部署などの管理者による管理処理等を組織内に設置されたユーザー端末において操作により行うことができる。
コンピュータ端末は、制御手段、記憶手段、入力手段、出力手段、表示手段などを備える。またインターネットに代表されるコンピュータネットワークに接続し、データの送受信を行う機能を備え、ブラウザや電子メールソフトウェア、ワードプロセッサなどのアプリケーションプログラムや、オペレーティングシステム（ＯＳ）を備えることが通常の形態である。
【００３５】
（検索予約サーバー）
次に、検索予約サーバーの基本的な構成について説明する。
検索予約サーバーは、ユーザーに関する情報を記憶するユーザー情報記憶手段を備えている。
個人のユーザー情報や、ユーザーが組織（法人等）に属する場合の組織のユーザー情報を記憶することにより、ユーザー認証データ（個人ＩＤ・パスワードや、組織（法人）ＩＤ・パスワードなど）を発行し、認証サーバーによる認証処理に利用する。
【００３６】
ユーザー情報記憶手段には、ユーザーＩＤに関連付けられて、氏名、部署、連絡先住所、連絡先電話番号、電子メールアドレスなどの情報を記憶する。ユーザーが組織（法人等）に属する場合には、ユーザー情報記憶手段には、法人などの組織を識別するユーザー組織情報と、組織に属するユーザー個人を識別するユーザー個人情報とが記憶される。
ここで、検索予約サーバーのユーザー情報記憶手段には、検索予約サーバーにアクセスするためのユーザーＩＤ（共通ＩＤ）などの認証データと、これに対応して、複数の旅行機関システムごとにユーザー登録により設定された各旅行機関システムのユーザーＩＤなどの認証データとが関連付けられて記憶されている。これにより、ユーザーは少なくともユーザーＩＤ（共通ＩＤ）を入力すれば、検索予約サーバーにおいてユーザー情報記憶手段を参照することにより、各旅行機関システムごとのユーザーＩＤなどの認証データをそれぞれ入力しなくても済むように、同時にログインするために変換を行うことができる。
【００３７】
また、個人別・あるいは組織（企業等）に、様々な設定の有無を判定可能なように、個人情報データベースに個人ＩＤと関連付けて各種のデータを記憶することができる。
たとえば、ユーザー情報記憶手段には、ユーザー個人または法人などの組織に対応して上限金額データが記憶されており、ユーザーが検索または予約を行う際に参照して利用することができる。上限金額データは、たとえば企業等の組織の管理者や承認者、あるいはシステム管理者などが設定して記憶させておくことができる。
上限金額データの一例としては、交通機関や宿泊機関ごとの金額や、出張などのトータル金額、１日あたりの上限金額、１泊の宿泊料金などの個々の金額などの条件である。
【００３８】
上限金額データにより、検索条件を入力した際に、前記の検索条件受信抽出手段が、ユーザー情報を参照して、ユーザーに対応する検索条件を生成することができ、この場合には旅行機関システムに対し検索要求をする前に、検索条件として上限金額を設定することができる。上限金額を超えるデータは検索結果として抽出されない、あるいは表示方法を変えて検索結果が表示されるようにすることができる。
一方、上限金額データの参照は、検索を行った結果、検索結果を受信した際に、コンテンツ表示手段がユーザー情報を参照して、上限金額を超えるか否かを判定してコンテンツを生成し表示するようにすることができる。この場合にも、上限金額を超えるデータは検索結果として抽出されない、あるいは表示方法を変えて検索結果が表示されるようにすることができる。
【００３９】
たとえば、ユーザー情報記憶手段には、法人などの組織に対応して出張規定データが記憶されており、ユーザーが検索または予約を行う際に参照して利用することができる。出張規定データは、たとえば企業等の組織の管理者や承認者、あるいはシステム管理者などが設定して記憶させておくことができる。
【００４０】
上限金額データや出張規定データは、会社などの組織全体の出張規定・旅費規程などのほか、個人ごとに一人一人につきあらかじめ記憶させておいてもよく、あるいは所属支店ごと、所属部署ごと、役職ごとなどのランクごと、プロジェクトごとなどの単位であらかじめ記憶させておいてもよい。あるいは１回の出張などの一連の取引ごと、あるいは月・年などの期間ごとに上限金額や予算をあらかじめ記憶させておいてもよい。
出張規定データの一例としては、交通機関や宿泊施設の予約をしたりする際の、旅費区分（交通機関・宿泊等）ごとの利用等級・金額、交通機関ごとの期間や日時、季節や曜日、あるいは地域、交通機関の路線や会社名、宿泊施設の種類や名称・会社名などである。
【００４１】
また、上限金額データや、出張規定データなど、ユーザーが検索または予約を行う際に参照する、前述した各種のデータは、企業など組織の上司や管理者、担当部署などが、定期的に、あるいは逐次更新するなどして管理できるようにしてもよい。
たとえば、交通機関の料金や宿泊料金、その他の旅行や出張に掛かる費用は、季節や曜日、あるいは混雑率などによって変動することがあり、さらに企業等の組織における利用率や利用金額、個人ユーザーの利用率や利用金額などの利用実績に応じて、割引率が変更することがある。また、割引率の変動などにより直接料金が変更する以外にも、優待券や割引券などが与えられたり、取引実績に応じて取引条件が変動することがある。
こうした場合において、企業など組織の上司や管理者、担当部署などが、上限金額や社内規定などを変更したり、変更はしないまでも特定の交通機関や宿泊施設を推奨したり、検索結果において表示・非表示や色替え表示、注意喚起表示などにより優先的に表示されるような検索条件をあらかじめ設定したりすることができる。
また、上限金額データや、出張規定データなど、ユーザーが検索または予約を行う際に参照する、前述した各種のデータは、企業など組織の上司や管理者、担当部署などが更新するなどして管理しなくても、企業内システム等において利用金額や利用実績、割引率などを自動的に演算することにより自動的に更新されるようにすることもできる。また、上限金額データや、出張規定データなど、ユーザーが検索または予約を行う際に参照する、前述した各種のデータは、各旅行機関システムから、利用金額や利用実績、割引率などを自動的にダウンロードされるようにして自動的に更新されるようにすることもできる。
【００４２】
出張データにより、検索条件を入力した際に、前記の検索条件受信抽出手段が、ユーザー情報を参照して、ユーザーに対応する検索条件を生成することができ、この場合には旅行機関システムに対し検索要求をする前に、検索条件として出張規定を設定することができる。出張規定に適合しないデータは検索結果として抽出されない、あるいは表示方法を変えて検索結果が表示されるようにすることができる。
一方、出張規定データの参照は、検索を行った結果、検索結果を受信した際に、コンテンツ表示手段がユーザー情報を参照して、出張規定に適合するか否かを判定してコンテンツを生成し表示するようにすることができる。この場合にも、出張規定に適合しないデータは検索結果として抽出されない、あるいは表示方法を変えて検索結果が表示されるようにすることができる。
【００４３】
次に、ユーザー情報記憶手段には、法人などの組織に対応して優待証データまたは組織割引データが記憶されており、前記の検索条件受信抽出手段が、ユーザー組織情報およびユーザー個人情報を抽出して、ユーザーに対応する検索条件を生成するようにすることができる。
優待証データまたは組織割引データは、航空会社の株主優待その他の、交通機関や宿泊施設その他の優待証情報や、ユーザーである企業（法人）等ごとに割引などが設定されている場合などである。
なお、これらのデータは検索予約サーバーに記憶しなくても、各旅行機関システムに記憶されているデータを参照するようにすることができる。
【００４４】
次に検索予約サーバーは、ユーザー端末からのアクセスに対し認証を行う認証手段を備えている。
認証手段は、ユーザーＩＤなどのユーザー認証データ（法人などの組織を識別する認証データや、組織に属する個人を識別する認証データ）を用いて、ユーザー端末からのアクセスに対し、検索予約サーバーへのアクセス権限の認証を行う。
ユーザー認証には様々な認証方法を利用することができるが、代表的な方式としては、端末装置からユーザー登録を行い、ユーザーＩＤやパスワードなどが発行される形態が一般的には用いられる。
本発明においては、検索予約サーバーにアクセスするためのユーザーＩＤ（共通ＩＤ）などの認証データを少なくとも用いればよい。
ユーザー個人のＩＤとは別に、組織（企業）別にＩＤ・パスワードを付与することにより、企業等ごとの予約情報の管理や、請求・精算の管理を行うため、あらかじめ契約企業等の組織ごとのＩＤ・パスワード等を併用することもできる。
【００４５】
認証サーバーによる認証に用いるためのデータは、ユーザー端末の画面に表示される入力フォーム等にキーボード等の入力手段を用いて入力する以外にも、様々な入力手段による入力により、認証サーバーに送信することができる。好ましい形態の一例としては、個人ごとの磁気カード、ＩＣカード、携帯電話その他の端末装置が備える情報記憶媒体、その他の個人別情報記録媒体に記憶されており、個人別情報記録媒体に記憶されたデータを読み取り、サーバーに送信可能にされているような形態である。
【００４６】
次に、検索予約サーバーは、あらかじめ記憶されている所定のユーザー情報に対応付けられて記憶された、複数の旅行機関システムごとに設定された認証データを参照し、旅行機関システムとの間での認証データ送受信の中継を行う認証データ中継手段を備えている。
検索予約サーバーにアクセスするためのユーザーＩＤ（共通ＩＤ）などの認証データに基づき、ユーザー情報記憶手段を参照し、あらかじめユーザーＩＤ（共通ＩＤ）に対応付けられて記憶されている、複数の旅行機関システムごとにユーザー登録により設定された各旅行機関システムのユーザーＩＤなどの認証データを抽出し、各旅行機関システムに送信することによりそれぞれの認証処理を受けるものである。
これにより、ユーザーは少なくともユーザーＩＤ（共通ＩＤ）を入力すれば、検索予約サーバーにおいてユーザー情報記憶手段を参照することにより、各旅行機関システムごとのユーザーＩＤなどの認証データをそれぞれ入力しなくても済むように、同時にログインするために変換を行うことができる。
なお、認証データ中継手段は、検索予約サーバーに設けなくても、後述する結合サーバーに設けることでもよい。その場合の処理や機能、作用などは共通する。
【００４７】
次に、検索予約サーバーは、ユーザー端末からのコンテンツ配信要求に応答してコンテンツ送信・データ検索・その他のデータ処理を行うコンテンツ表示手段を備えている。
ユーザー端末からのアクセスにより、コンテンツ送信要求に応答してコンテンツを送信し、あるいはコンテンツを生成して送信するものである。通常のＷＥＢサーバーの機能である。
コンテンツには、あらかじめ検索予約サーバーに記憶されているコンテンツ（たとえばメニュー画面など）や、各旅行機関システムから受信したデータに基づき生成されるコンテンツ（たとえば検索結果、予約結果など）などが含まれる。
【００４８】
次に、検索予約サーバーは、ユーザー端末から送信される、交通機関・宿泊施設などの旅行商品の検索条件を受信または抽出する検索条件受信抽出手段を備えている。
検索条件受信手段は、ユーザー端末の画面に表示される検索条件等の入力フォーム等に入力され送信されたデータを受信して、各旅行機関システムに対する検索要求を送信するために必要な所定のデータ項目を抽出し、結合サーバーに送信する。検索条件には、予約結果や予約記録、履歴、請求データなどの、あらかじめ各旅行機関システムに記憶されているデータの送信要求指示を広く含み、予約記録一覧の照会などの処理を行うこともできる。
【００４９】
次に、検索予約サーバーは、ユーザー端末から送信される、交通機関・宿泊施設などの旅行商品の予約指示を受信する予約指示受信手段を備えている。
予約指示受信手段は、ユーザー端末の画面に表示される予約指示等の入力フォーム等に入力され送信されたデータを受信して、各旅行機関システムに対する予約要求を送信するために必要な所定のデータ項目を抽出し、結合サーバーに送信する。予約指示には、ＯＰＥＮ手配指示、予約指示、発券指示、取消指示、変更指示などの、旅行商品・サービスの予約・手配・取消・変更に関するデータ処理要求指示を広く含む。
【００５０】
次に、検索予約サーバーは、結合サーバーからデータ処理の結果を受信するデータ受信手段を備えている。
データ受信手段が受信したデータは、コンテンツ表示手段が参照してコンテンツ生成可能なように記憶される。
検索結果、予約結果、各種の履歴や記録、請求データなどを、各データベースを設けてユーザー情報と関連付けることにより、検索予約サーバーに記憶してもよい。
各旅行機関システムと同様に、検索予約サーバーに、取引情報データベース、予約情報データベース、利用料金記憶手段（請求データベース）等を設けてもよい。これらを設けた場合の構成は、各旅行機関システムの構成と同様または類似するものであるため省略する。
【００５１】
なお、利用料金記憶手段に記憶される金額には、中継する旅行会社からの請求金額を含めて記憶することにより、旅行会社の手数料を含めるなどの請求ができる。
また、複数の旅行機関システムとの間でデータ中継を行い予約された利用料金情報をユーザー情報に関連付けて記憶する利用料金記憶手段を備えた場合には、複数の旅行機関システムの利用料金を一括することができる。
旅行会社は一定期間ごとに、組織・企業に対して請求を行う。たとえば１か月ごとなどである。請求は組織・企業ごとに行われるため、旅行会社システムにおいては企業ＩＤに基づき取引情報データベースに記憶されている、あらかじめ決められた日時までの取引情報デ−タを抽出して、請求データを組織ごと、企業ごと等に作成し、利用料金記憶手段データベースに記憶する。
【００５２】
企業との精算方法としては、現金振込、クレジットカード決済、その他の通常知られている様々な決済方法を採用することができる。望ましい形態の一例によれば、旅行会社システムにおいて、たとえばクレジットカード会社等の金融機関、決済機関と連携することなどにより、企業等との契約および個人の登録に従い、個人決済のための個人コーポレートカード、企業決済のための企業コーポレートカード等を発行し、企業が一括精算する形態などを採用することができる。企業の特定のカードＮｏで精算を行うことができ、予約時に与信のみを取り、月締めの後に一括決済する方法などが好ましい。
【００５３】
（結合サーバー）
次に、結合サーバーは、あらかじめ記憶されている所定のユーザー情報と、受信した検索条件または予約指示を含むデータを、複数の旅行機関システムごとに、所定のデータ項目のそれぞれを中継先の各旅行機関システムのデータに対応付けて送信し、旅行機関システムとの間でのデータ送受信の中継を行うデータ中継手段を少なくとも備えている。
検索予約サーバーにおいては、複数の旅行機関システムに送信するための検索条件・検索指示データや、予約指示データは、共通するデータ項目やデータ形式を用いることにより、一つの入力画面で入力を行うことが可能にされている。
これら所定のデータ項目を、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式に対応させて、結合サーバーに記憶されている。対応付けられたデータ項目・データ形式を参照して、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式に変換を行い、送信する。
逆に、各旅行機関システムから検索結果や予約結果などのデータを受信した際に、対応付けられたデータ項目・データ形式を参照して、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式を共通のデータ項目・データ形式に変換を行い、検索予約サーバーを介してユーザー端末に送信する。
これにより、ユーザー端末から旅行商品検索予約サーバーに検索条件・予約指示の送信をすることにより、複数の旅行機関システムとの間でデータ中継を行い、検索結果・予約結果をユーザー端末において受信可能にされている。
【００５４】
以下、本発明の基本的な処理の流れについて説明する。
図２、及び図５から図１８は、本発明の基本的な処理の流れの一例を示すフローチャートである。なお、ここに示す処理の流れは代表的な一例であって、これに限定されるものではなく様々な応用が可能である。
【００５５】
図２は、ユーザー端末からシステムへのログイン処理を経て、本発明のシステムを利用する処理の概要を示すフローチャートである。
また図３は、本発明のシステムを利用する一連の処理において、ユーザー端末から入力を行うデータ形式、データ項目の基本的な一例を示す図である。
また図４は、本発明のシステムを利用する一連の処理において、ユーザー端末に出力され表示されるデータ形式、データ項目の基本的な一例を示す図である。すべての検索結果、予約結果などのデータ処理結果を、各ユーザー端末へログアウト時に共通インタフェースで送信する。
また、図１９から図３５は、本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【００５６】
初めに、図２を参照してユーザー端末からシステムへのログイン処理を経て、本発明のシステムを利用する処理について説明する。
ユーザー端末からインターネットに接続し（Ｓ１００）、検索予約サーバーにアクセスする（Ｓ１０１）。検索予約サーバーから認証画面をユーザー端末に送信して表示させる（Ｓ１０２）。
ユーザー端末においては、あらかじめ検索予約サーバーにアクセスするためのユーザー登録を行いユーザーＩＤなどの認証情報（企業ＩＤ、共通ＩＤ等）が発行されており、認証情報の入力により認証処理が行われる（Ｓ１０３）。
【００５７】
検索処理、予約処理、その他の各処理を行うために、検索予約サーバーから交通機関や宿泊施設などの各旅行機関システムにアクセスをするが、この際には、認証データ中継手段が、あらかじめ記憶されている所定のユーザー情報に対応付けられて記憶された、複数の旅行機関システムごとに設定された認証データを参照する。認証情報に基づき、ユーザーＩＤ（共通ＩＤ）に対応付けられて記憶されている旅行機関システムごとのユーザーＩＤを抽出し（Ｓ１０４）、結合先を判定する。
結合サーバーから各旅行機関システムに対し各旅行機関システムのユーザーＩＤなどの認証データを抽出し、各旅行機関システムに送信し、認証処理により接続する（Ｓ１０５）。各旅行機関システムの認証ＯＫであれば（Ｓ１０６）、検索予約サーバーからユーザー端末にメニュー画面を送信し表示する（Ｓ１０７）。ユーザーは、ユーザー端末においてメニューの中から各旅行機関システムに対する処理を選択する（Ｓ１０８）。
図１９は、メニュー画面の一例を示す。
選択可能な代表的な処理は、検索処理（直接検索、ルート検索等）、予約処理、取消処理、予約記録一覧照会処理、優待証登録処理などである。
各旅行機関システムの認証処理によりアクセスが認められない場合には（Ｓ１０６）、該当する旅行機関システムに対しユーザー登録を行い利用登録をする必要がある。
【００５８】
次に図５を参照して、各旅行機関システムに対する利用登録処理について説明する。
利用登録は、各旅行機関システムを利用するにあたり、接続先の各旅行機関システムへ事前に必須の事項を登録するものである。
登録に際しては、ユーザーが契約した企業などである場合には、事前に社員登録をするようにして、社員データ、所属データなどの必要事項をフレキシブルディスクやＣＤ−ＲＯＭなどの情報記憶媒体等により提出し、旅行機関システム管理者側で登録を行うこともできる。
利用登録の際の必要な事項の登録データを、最初に予約時に、自動送信で利用登録を可能にすることもでき、以下ではその処理について説明する。
利用登録が必要な各旅行機関システムのユーザー登録画面を表示させ（Ｓ１５０）、必要な登録事項をユーザー端末において入力し、検索予約サーバーに送信する（Ｓ１５１）。ユーザー情報は検索予約サーバーのユーザー情報記憶手段に記憶され（Ｓ１５２）、結合サーバーにおいて必要に応じ各旅行機関システムのデータ形式に変換される（Ｓ１５３）。データの変換はＰＯＳＴ、ＸＭＬ（ＳＯＡＰ）等を用いることができる。
【００５９】
ユーザー情報などの必要事項データは各旅行機関システムに送信し記憶され（Ｓ１５４）、該当する旅行機関システムに対するユーザー登録処理が行われる。ユーザー登録が認められれば（Ｓ１５５）、各旅行機関システムのユーザーＩＤなどの認証情報が発行され、認証情報を含むユーザー登録結果を結合サーバーに送信し（Ｓ１５６）、認証情報を含むユーザー登録結果を検索予約サーバーにおいてユーザー情報記憶手段に記憶する（Ｓ１５７）。これにより、各旅行機関システムの認証情報と、検索予約サーバーの認証情報（共通ＩＤなど）とが対応付けられて記憶される。ユーザー登録結果をユーザー端末に送信し表示する（Ｓ１５８）。
【００６０】
次に、図６から図８を参照して、検索処理について説明する。
図２０は、検索条件の入力を行う画面の一例を示す。
ユーザーが検索条件の入力をユーザー端末において行うが、あらかじめ交通機関名、便名、宿泊施設名などがわかっている場合にはこれらを入力、あるいはリスト等の中から選択する。また日程や希望時間帯などを入力または選択等により指定する。これらの情報があらかじめわかっていない場合には、だいたいの日時、場所、その他の条件により検索等を行って抽出し、選択・指定することもできる。
検索方法として、あらかじめルートや、出発地・到着地の指定などを行い、それに合致する検索結果を一覧表示、リスト表示などにより出力・表示する直接検索（ダイレクト検索）の方法や、出発地・到着地・経由地の指定などを行い、その途中のルートを検索し、それに合致する検索結果をルート表示や、ルート表示とリスト表示の組み合わせなどにより出力・表示するルート検索の方法、あらかじめ出発日時や到着日時、宿泊日数、ルートや、出発地・到着地・経由地の指定などを行い、それに合致する検索結果をスケジュール表示や、スケジュール表示とリスト表示の組み合わせなどにより出力・表示するスケジュール検索の方法、その他の様々な検索方法を利用可能にすることができる。
【００６１】
検索処理を行う前に認証処理を経て、各旅行機関システムに接続する処理は、図２に一例を示した通りであり、この処理は後述する他の処理においても共通する。
次にユーザー端末において検索方法を選択し（Ｓ２００）、検索条件（日時、搭乗日、区間、利用クラス、他）を入力する（Ｓ２０１）。
検索条件入力は、様々な検索条件を複数組み合わせて入力し、送信を行うため、あらかじめ入力された複数の検索条件をソート処理等により、優先順位付けを行うことが望ましい。たとえば、日時がまったく異なるのに、料金が安いという条件が優先されて検索結果が出力されても無意味だからであり、検索・予約に際して必須の条件ほど優先されることが望ましい。また、検索条件の優先順位付けをユーザーが行えるようにすることも望ましい。料金の条件を優先するユーザーや、早く到着することを優先するユーザーなど、ユーザーにより優先度が様々だからである。
【００６２】
好ましい一例としては、下記の単位でソートする。
１  出発時刻善準（出発時刻の1便前から昇順に表示）
２  到着時刻基準（到着時刻に近い順に、降順に表示）
３  時間範囲指定
４  特別席（スーパーシート、グリーン、普通席）
５  搭乗日
６  利用会社指定（航空会社のみ、鉄道のみ、各会社単位）
７  各企業等の出張規定
各企業等の出張規定はあらかじめユーザー情報に関連付けられて記憶されているが、たとえば同じ社内で重役が課長以下の一般社員等と同じ場所に出張する場合等において、重役はグリーン車の手配となり、航空チケット等はビジネスまたはファーストクラスで手配しなければならない等の社内規定があらかじめ登録されていた場合には、その登録内容によって予約が行われ一覧が表示される。
アクセス権限によってはすべての社員の一覧を表示する事も出来、また必要最小限の一覧を表示する。検索・予約の際に、重役のユーザー情報と一般社員のユーザー情報とが入力・指定されるなどして識別されればよい。
【００６３】
次に、検索対象とする旅行機関システムをユーザーが指定するなどして確認することができ（Ｓ２０２）、空席・運賃等の検索要求をユーザー端末から送信し（Ｓ２０３）、検索予約サーバーにおいて受信する（Ｓ２０４）。
ルート検索の検索要求である場合には（Ｓ２０５）、後述するＳ３００に進む。
ルート検索の検索要求ではなく、直接検索による一覧表示その他の検索方法である場合には（Ｓ２０５）、検索条件受信手段は、ユーザー端末の画面に表示される検索条件等の入力フォーム等に入力され送信されたデータを受信して、各旅行機関システムに対する検索要求を送信するために必要な所定のデータ項目を抽出し、結合サーバーに送信する。結合サーバーにおいて検索対象となる結合先の旅行会社システムを判定する（Ｓ２０６）。結合サーバーにおいて、検索条件などのデータ項目を、必要に応じ各旅行機関システムのデータ形式に変換する（Ｓ２０７）。所定のデータ項目を、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式に対応させて、結合サーバーに記憶されている。対応付けられたデータ項目・データ形式を参照して、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式に変換を行い、各旅行機関システムに送信する（Ｓ２０８）。
送信されたデータは、各旅行機関システムにおいて受信され（Ｓ２０９）、これに基づき各旅行機関システムにおいて在庫情報データベース等を検索し（Ｓ２１０）、交通機関の空席や時刻、料金、宿泊施設の空室、料金、その他のデータを抽出する。
【００６４】
一方、ルート検索の検索要求である場合には（Ｓ２０５）、検索予約サーバーにおいて、ルートを検索し抽出する（Ｓ３００）。検索条件受信手段は、ユーザー端末の画面に表示される検索条件等の入力フォーム等に入力され送信されたデータを受信して、各旅行機関システムに対する検索要求を送信するために必要な所定のデータ項目を抽出し、結合サーバーに送信する。結合サーバーにおいて検索対象となる結合先を判定し（Ｓ３０１）、結合サーバーにおいて必要に応じ各旅行機関システムのデータ形式に変換する（Ｓ３０２）。所定のデータ項目を、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式に対応させて、結合サーバーに記憶されている。対応付けられたデータ項目・データ形式を参照して、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式に変換を行い、各旅行機関システムに空席・運賃等の検索要求を送信する（Ｓ３０３）。
送信されたデータは、各旅行機関システムにおいて受信され（Ｓ３０４）、各旅行機関システムにおいて在庫情報データベース等を検索し（Ｓ３０５）、目的地までのルートと交通機関の空席や時刻、料金、宿泊施設の空室、料金、その他のデータを抽出する（Ｓ３０６）。ルートの途中において、乗り継ぎが必要である場合には（Ｓ３０７）、乗り継ぎを行う中継地点までのルートについて検索を行い、さらに中継地点から目的地（あるいは次の中継地点）までのルートについて検索を行う（Ｓ３０６）。
さらに他のルートを検索する場合には（Ｓ３０８）、同様の処理を繰り返し、想定されるルートごとの検索を行う。検索を行うルートの組み合わせは、組み合わせが多数ある場合において、すべてのルートの組み合わせを行ってもよく、あるいは５ルートまでのようにあらかじめ設定し、またはユーザーが設定することができる。また、料金の上限や時間の制限などの他の条件により絞り込むこともできる。
【００６５】
直接検索やルート検索のいずれの場合にも、検索結果は、各旅行機関システムから送信され、結合サーバーにおいて受信する（Ｓ４００）。各旅行機関システムから検索結果や予約結果などのデータを受信した際に、対応付けられたデータ項目・データ形式を参照して、各旅行期間システムごとに、各旅行機関システムのデータ項目・データ形式を共通のデータ項目・データ形式に変換を行い（Ｓ４０１）、検索予約サーバーに送信する。
検索予約サーバーにおいては、検索結果に基づき、上限金額チェック処理、出張規定チェック処理、優待証利用可否チェック処理、企業ＩＤごとの割引チェック処理、等の処理をすることもでき、好ましい処理の形態の一例である。これらの各処理について次に説明する。
【００６６】
図９は、上限金額チェック処理の一例を示すフローチャートである。
検索予約サーバーにおいて、ユーザー認証情報に基づき、ユーザー情報記憶手段を参照して上限金額を抽出する（Ｓ４２０）。
検索結果が上限金額以内かを判定し（Ｓ４２１）、上限金額を超える場合には、上限金額を超えることを示すデータを検索結果データに付加する（Ｓ４２２）。上限金額超過フラグなどであり、フラグが付加された検索結果データはユーザー端末において非表示にされたり、あるいは検索結果やルート、スケジュール表などの色替え表示や点滅表示、上限金額超過や予約不可、要社内稟議などを警告する文字やマークなどが付与されてコンテンツが生成されるなどの処理をすることができる。
上限金額の判定は、交通費全体や、あるいはここのルートごとの交通費、１泊ごとの宿泊費、出張などの行程全体の費用などについて判定することができる。
他の検索結果（交通機関、宿泊など）がある場合には（Ｓ４３３）、同様の処理により判定を行う。
【００６７】
図１０は、出張規定チェック処理の一例を示すフローチャートである。
ユーザー認証情報に基づき、ユーザー情報記憶手段を参照して出張規定を抽出する（Ｓ４４０）。
検索結果ごとに、旅費区分（交通機関、宿泊等）ごとの利用等級・金額等を参照し（Ｓ４４１）、検索結果が出張規定に抵触するかを判定する（Ｓ４４２）。判定は、交通機関全体や、あるいはここのルートごと、１泊ごとの宿泊、出張などの行程全体などについて判定することができる。出張規定に抵触する場合には、出張規定に抵触することを示すデータを検索結果データに付加する（Ｓ４４３）。出張規定抵触フラグなどであり、フラグが付加された検索結果データはユーザー端末において非表示にされたり、あるいは検索結果やルート、スケジュール表などの色替え表示や点滅表示、出張規定抵触や予約不可、要社内稟議などを警告する文字やマークなどが付与されてコンテンツが生成されるなどの処理をすることができる。企業ＩＤごとに、利用可能な会社・運賃（割引）などをスケジュール画面等に表示することができる。
また、上限金額データや、出張規定データなど、ユーザーが検索または予約を行う際に参照する、前述した各種のデータは、企業など組織の上司や管理者、担当部署などが更新するなどして管理したり、自動的に更新されるようにされている場合には、これらのデータを参照することにより、特定の交通機関や宿泊施設を推奨したり、検索結果において表示・非表示や色替え表示、注意喚起表示などにより優先的に表示されるような検索条件をあらかじめ設定したりすることができる。
【００６８】
図１１は、優待証利用可否チェック処理の一例を示すフローチャートである。優待証は、必ずしも優待証といった名称ではなくともよく、代表的な一例としては航空会社の株主優待券その他の優待証、鉄道会社などの株主割引その他の優待証、宿泊施設の無料宿泊券や割引券、宿泊チケットなどのようなものである。
優待証を利用することを選択した場合には検索条件にあらかじめそのことを示すデータが含まれることにより、優待証利用可否チェックを行うことを判定する（Ｓ４６０）。検索予約サーバーにおいて、ユーザー認証情報に基づき、ユーザー情報記憶手段を参照して優待証データ（番号・枚数等）を照会し抽出する（Ｓ４６２）。照会対象となる結合先を判定し（Ｓ４６３）、結合サーバーを介して結合先の旅行会社システムに接続し、区間・宿泊先等ごとに、優待証の番号・枚数の存在を照会する（Ｓ４６４）。優待証の利用が可能であれば（Ｓ４６５）、優待証を利用することを検索結果の料金等に反映し、コンテンツが生成・表示されるようにする（Ｓ４６６）。料金等への反映は、優待証利用の場合の料金表示のみをすることでもよく、あるいは利用した場合と利用しない場合とを併記して表示するようにしてもよい。
また、優待証が利用できない場合などにおいても、ユーザー（企業等）ごとの契約や取引量などによる割引適用がある場合には（Ｓ４６７）、割引を検索結果（料金等）に同様に反映することができる（Ｓ４６８）。
優待証による割引は、たとえば航空券の優待証利用において、各航空会社ごとに割引券の割引率等の属性情報が異なるため、検索予約サーバーにおいては各割引券の属性情報を算出してキャリアごとに割引表示を行う。
また、割引ごとの特殊性などの注意表示をすることができ、たとえば割引名称の背景を色わけをするなどして、内容の注意を喚起する。たとえば手数料が発生する割引などである。
優待証に関しても、企業など組織の上司や管理者、担当部署などが更新するなどして管理したり、枚数などのデータを自動的に更新されるようにしておけば、これらのデータを参照することにより、特定の交通機関や宿泊施設での優待証使用を推奨したり、逆に優待証使用を制限したり、検索結果において表示・非表示や色替え表示、注意喚起表示などにより優先的に表示されるような検索条件をあらかじめ設定したりすることができる。
【００６９】
優待証の保有・利用は、各旅行機関システムへの利用登録情報を入力しておけばよい。
あるいは、ユーザー端末から優待証の保有・利用に関するデータを登録しなくても、各旅行機関システムが記憶管理している優待証に関するデータを参照し、あるいはダウンロードすることにより、ユーザー端末から入力・送信をして検索予約サーバーに記憶させなくても、検索結果への反映や、予約時の優待証利用に関するデータの入力を省くことができる。
優待証が紙や、ＩＣカードなどの情報記憶媒体であった場合にも、また優待証が連番か否かに関わりなく、各旅行機関システムごとにチェックしてきた従前の方法に対して、ユーザー（企業等）が保有する優待証の有効枚数の管理ができ、またその優待証を利用した検索・予約等が可能になる。
【００７０】
次に、図８を再度参照し、Ｓ４０１の後に必要に応じ、検索予約サーバーにおいては、検索結果に基づき、上限金額チェック処理、出張規定チェック処理、優待証利用可否チェック処理、企業ＩＤごとの割引チェック処理等の処理を行い、複数の各旅行機関システムから受領したそれぞれの検索結果を記憶する。
ここで、複数の旅行機関システムから受信したデータ項目やデータ形式は、結合サーバーにおける変換処理により、検索予約サーバーにおいて統一された共通のデータ形式・データ項目にされている。
しかしながら、同じ場所（地名・駅名など）であっても、旅行機関システムごとに異なる用語になっている場合がある。たとえば東京の「有楽町」と「日比谷」、「上野」と「京成上野」などが一例である。
また、同じ内容のサービス内容や商品名称などであっても、旅行機関システムごとに異なる用語になっている場合がある。たとえば航空会社ごとの「前売り」と「早割り」、「特定割引」と「便指定予約」などが一例である。
あるいは、同じ区間であっても、旅行機関システムごとに運賃が異なる場合や、あるいは各社の運賃が統一されて設定されている場合などがある。
このような場合において、検索結果をそのまま出力・表示してもよいが、共通運賃・共通名称があればこれを検索して統一したような出力・表示をすることもできる。
図１２は、共通運賃・名称検索処理の一例を示すフローチャートである。
検索予約サーバーにおいて、共通名称・運賃等データベースを参照し（Ｓ４８０）、検索結果データと照合を行う（Ｓ４８１）。
共通名称・運賃等があるか否かを判定し（Ｓ４８２）、あった場合には共通名称・運賃が表示されるようにデータ処理を行う（Ｓ４８３）。たとえば「日比谷」を「有楽町」あるいは「日比谷（有楽町）」、「有楽町（日比谷）」のように変換したり、運賃などが各社共通か、専用運賃かを表示されるようにしたりするような例である（Ｓ４８４）。運賃・名称を各社で共通の名前のセットにしたり、並び順を設定したりすることが可能になる。
他の検索結果（交通機関、宿泊など）がある場合には（Ｓ４８５）、同様にそれぞれについて処理を行う。
【００７１】
次に、再度図８を参照し、変換された各旅行機関システムのデータに基づき表示されるコンテンツを生成する（Ｓ４０２）。
検索結果データの表示条件等を参照し（Ｓ４０３）、検索結果の一覧表示生成処理、スケジュール表示生成処理、ルート表示生成処理等を行う。
図１４は、コンテンツ生成処理の処理の一例を示すフローチャートである。
コンテンツ表示条件の一例としては、在庫（残席・残室等）が少ない場合などには所定数以下の場合には非表示にしたり色替え表示、点滅表示などをする例であり、所定数以下の場合に表示する否かをコンテンツ表示条件から判定し（Ｓ５００）、所定数以下であった場合には、所定数以下であることを示して表示されるようにデータ処理を行う（検索結果非表示、色替え表示等）（Ｓ５０２）。この他にも様々なコンテンツ表示条件を設定することができる。
前述した上限金額チェック処理、出張規定チェック処理、優待証利用可否チェック処理、企業ＩＤごとの割引チェック処理等の処理結果がある場合には、所定の条件（料金規定、出張規定等）に従いデータ処理を行う（Ｓ５０３）。
【００７２】
ユーザー端末に表示する検索結果が一覧表示である場合には（Ｓ５０４）、所定の条件（価格順、会社別、区間順等）に従いソート処理等を行い（Ｓ５０５）、検索結果のリストを生成する（Ｓ５０６）。図２１は、検索結果の表示を行う画面の一例を示す。
ユーザー端末に表示する検索結果がスケジュール表示である場合には（Ｓ５０７）、所定の条件（日時順、区間順等）に従いソート処理等を行い（Ｓ５０８）、スケジュール表を生成する（Ｓ５０９）。コンテンツ表示手段により表示される、複数の旅行機関システムの所定のデータ項目を含む検索結果には、行程を示すスケジュールデータが含まれる。
ユーザー端末に表示する検索結果がルート表示である場合には（Ｓ５１０）、所定の条件（価格順、会社別等）に従いソート処理等を行い（Ｓ５１１）、ルート表を生成する（Ｓ５１２）。
【００７３】
図２１に一例を示した検索結果の表示画面においては、各旅行機関システムの検索結果（運賃・スケジュール・ルート等）を一つのの画面で表示することができる。たとえば東京−大阪の検索では、航空会社と新幹線とを表示し、運賃、所要時間を比較して、予約等することが可能となる。
表示方法の好ましい一例は、空席を記号（○  ：十分空席あり  △：残席わずか：１から１０は実数、×：残席なし）で表示したり、運賃と空席を図２１に示すようなマトリックスで表示したりするものである。
【００７４】
以上の例のようにして、再度図８に戻り、変換された各旅行機関システムのデータに基づき表示されるコンテンツを生成し（Ｓ４０４）、コンテンツをユーザー端末に送信する（Ｓ４０５）。検索結果は、表示条件等に従いユーザー端末において表示され（Ｓ４０６）、一覧表示、スケジュール表示、ルート表示等が行われる。コンテンツ表示手段により表示される、複数の旅行機関システムの所定のデータ項目を含む検索結果には、行程を示す路線データが含まれる。複数の旅行機関システムの同時検索結果を、リストやスケジュール表、ルート表示などにして表示、印刷などの出力をすることが可能になる。また、社内の出張稟議システムなどと連携して、稟議書に添付あるいは挿入等を可能にすることもできる。あるいは、表示画面は「スケジュール表示印刷」ボタンや、「携帯端末へ送信」ボタンにより出張担当者に直接送信したり、携帯端末装置において携帯したりすることもできる。
【００７５】
次に、検索のみを行ってもよいが、続いて予約処理に進むこともできる。
予約処理においては、列車名、便名などを指定して日時の決定した予約を行うこともできるが、たとえば航空券のように日時や利用便・座席などは指定しないで発券を受けるＯＰＥＮ手配（本明細書および図面においてＯＰＥＮ手配という）を行う形態などをとることもできる。
ＯＰＥＮ手配を行うことが可能な検索結果については、好ましくは、結合サーバーが複数の旅行機関システムから受信した検索結果に基づき、検索予約サーバーにおいて、表示されるコンテンツにはＯＰＥＮ手配指示の入力手段（ＯＰＥＮ手配ボタンなど）が設けられて生成される。
同様に、検索結果には、好ましくは、結合サーバーが複数の旅行機関システムから受信した検索結果に基づき、検索予約サーバーにおいて、表示されるコンテンツには予約指示の入力手段（予約ボタンなど）が設けられて生成される。
これにより、便ごとに空席を確認しながら、ＯＰＥＮか予約かを選択することが可能にされる。たとえば、航空会社等によってはＯＰＥＮ選択時には希望搭乗便の混雑状況がわからないために、実際に搭乗できない危険性があるが、予約検討便が混雑している場合には予約を行い、空席が多い場合にはＯＰＥＮで予約を行うことが可能になる。
【００７６】
図１４は、ＯＰＥＮ手配処理の一例を示すフローチャートである。
検索結果のスケジュール等ごとにＯＰＥＮマーク等が表示され（Ｓ６００）、ＯＰＥＮ手配か予約かを選択・指定する（Ｓ６０１）。
ＯＰＥＮ手配を行う場合には、検索結果（スケジュール）を指定し、ＯＰＥＮを選択する（Ｓ６０２）。ＯＰＥＮ手配指示はユーザー端末から検索予約サーバーに送信され、どのスケジュール等が選択されたかを判定することにより、結合サーバーにおいて照会対象となる結合先を判定する（Ｓ６０３）。結合先の旅行機関システムに接続し、検索結果（スケジュール）のＯＰＥＮ手配要求を送信し（Ｓ６０４）、各旅行機関システムにおいて受信される（Ｓ６０５）。
旅行機関システムにおいて予約情報データベース等に記憶されることにより（Ｓ６０６）、手配が完了し、手配結果を結合サーバーを介して返信し、検索予約サーバーにおいてコンテンツ生成を行い（Ｓ６０７）、ユーザー端末に手配結果が表示される（Ｓ６０８）。
【００７７】
次に、図１５および図１６を参照して、予約処理について説明する。
ユーザー端末において検索結果（スケジュール）を指定し、予約処理を選択することにより（Ｓ７００）、検索予約サーバーに対し予約要求が送信される。どのスケジュール等が選択されたかを判定することにより、結合サーバーにおいて照会対象となる結合先を判定する（Ｓ７０２）。結合先の旅行機関システムに接続し、検索結果（スケジュール）の予約要求を送信する（Ｓ７０３）。
各旅行機関システムにおいて予約要求を受信し（Ｓ７０４）、好ましくは予約の確定・完了前に空席や運賃等のデータをユーザー端末に返信し確認のために表示をし（Ｓ７０５）、予約の確定指示を再度ユーザー端末から送信する（Ｓ７０６）。
図２２は、予約確定前の確認ための画面表示の一例であり、また図２３は予約確定指示を送信するための画面表示の一例である。
次に、優待証を利用するかを選択可能な場合において、利用しないことを指定していた場合には（Ｓ７０７）、各旅行機関システムにおいて予約データを予約情報データベース等に記憶することにより（Ｓ８００）、予約が行われる。図２４は、予約完了画面の一例を示す。
【００７８】
一方、図２５に一例を示すように、スケジュール検索時に優待証利用識別をチェックするなどして、優待証を利用することを選択していた場合には（Ｓ７０７）、予約・発券をする際に、図２６に示すように優待券情報入力メニューを選択するなどして、図２７のような専用の番号登録画面を表示する。
優待証は、航空約款上、割引としての扱いがないため、専用の割引クラスがなく、普通運賃（Ｙクラス）の席数を予約後、発券前に、優待証の番号を登録することにより、番号が認証されると、所定の割引額で発券回答されるものである。従来の航空会社の専用予約サイトでは、スケジュール照会時に、全割引（全クラス）が表示され、普通運賃予約後、発券時に、番号をセットしてはじめて、優待証と認識されるため、ユーザーの操作性において誤解を招きやすかった。
優待証の番号が連番である場合には（Ｓ７０８）、図２８に示すような画面において、最初の優待証番号と枚数を入力する（Ｓ７０９）。優待証利用時に、必要な番号をすべて登録する際に、優待証が連番の場合、最初の番号と必要枚数を入力する事により、1枚1枚の番号登録を不要とする機能である。
以上により、優待証番号の入力が行われ（Ｓ７１０）、予約要求データに優待証条件フラグが付加される。
【００７９】
また、優待証番号の入力は、予約・発券時に行う以外にも、あらかじめ企業などのユーザーが保有する優待証番号を事前に登録することにより、あらかじめ登録された優待証在庫データを参照し、自動優待証セット機能を設けることができる。これにより、予約・発券時に優待証番号の入力を行うことなく、自動的に優待証条件フラグが付加される。
あるいは、ユーザー端末から優待証の保有・利用に関するデータを登録しなくても、各旅行機関システムが記憶管理している優待証に関するデータを参照し、あるいはダウンロードすることにより、ユーザー端末から入力・送信をして検索予約サーバーに記憶させなくても、あらかじめ登録された優待証在庫データを参照し、自動優待証セット機能を設けることができる。これにより、予約・発券時に優待証番号の入力を行うことなく、自動的に優待証条件フラグが付加される。
【００８０】
各旅行機関システムにおいて予約データを予約情報データベース等に記憶することにより（Ｓ８００）、予約が行われる。予約が完了しないエラー時には即座に予約取り消しの処理を実行するのではなく、条件変更等のリトライなどの猶予が与えられるようにすることが望ましい。
発注・予約を行う際には、前記のようにユーザー個人が特定されているので、予約データと個人ＩＤ及び個人情報が関連付けられて、旅行会社システムが備える予約情報データベースに記憶される。これにより予約情報がどのユーザーのものであるのかが判別できると共に、組織・企業の管理者がユーザーごとの情報などを確認することも可能にすることができる。
【００８１】
予約が完了すれば（Ｓ８０１）、予約結果を返信し各旅行機関システムからのデータを結合サーバーにおいて受信する（Ｓ８０２）。結合サーバーにおいては、結果解析により、各旅行機関システムのデータを共通データに変換し（Ｓ８０３）、検索予約サーバーにおいて予約結果を示すコンテンツを生成する（Ｓ８０４）。予約結果を含むコンテンツがユーザー端末に送信されて表示される（Ｓ８０５）。
ここで、ユーザーがユーザー端末において予約された内容の確認等を行い、発券処理に進むようにすることができる。発券とは予約確定のことであり、予約が確定するまでは予約取り消し等が可能である。
予約の後に発券処理を行う場合には、ユーザー端末から発券要求を送信し（Ｓ８０６）、検索予約サーバー、結合サーバーを中継して、旅行機関システムにおいて発券処理を行う（Ｓ８０７）。
発券結果（金額、券番等）を返信し、各旅行機関システムからのデータを結合サーバーにおいて受信し（Ｓ８０８）、結果解析により、各旅行機関システムのデータを共通データに変換する（Ｓ８０９）。検索予約サーバーにおいて発券結果を含むコンテンツを生成し（Ｓ８１０）、ユーザー端末に送信して表示する（Ｓ８１１）。
【００８２】
一方、Ｓ８００に示した予約処理と、Ｓ８０７に示した発券処理とを同時に行うことにより、チケットレス予約と発券を同時に行う即売処理を行えるようにしてもよい。
予約エラー時には、自動で予約記録の取消を行うことが好ましい一例である。
図３０は、発券結果を表示する画面の一例を示す。
また図３１は、複数の確定した予約内容を表示する画面の一例を示す。予約内容の確認ができる予約確認書面を出力可能にすることが望ましい。
複数の旅行機関システムの同時予約結果を、リストやスケジュール表、ルート表示などにして表示、印刷などの出力をすることが可能になる。また、社内の出張管理システムなどと連携して、出張申請書や報告書・精算書などに添付あるいは挿入等を可能にすることもできる。あるいは、表示画面は「スケジュール表示印刷」ボタンや、「携帯端末へ送信」ボタンにより出張担当者に直接送信したり、携帯端末装置において携帯したりすることもできる。
さらに、出張者のスケジュールや居場所、行程などを管理者や担当部署などの第三者が確認をすることができ、緊急時や事故発生時における確認や連絡などをすることもでき、リスク管理の面からも有益である。各旅行機関システムにアクセスすることにより、最新のデータに基づきスケジュール表や行程などのデータを同時検索、確認、出力等することができるので、各旅行機関システムのデータを一つの印刷にすることもできる。また、出張者などが出張先で予約の変更をしたり、便の欠航、時間変更、乗り遅れ、その他の変更などがあった場合にも確認をすることが可能になる。
【００８３】
次に、図１７を参照して、予約記録一覧照会処理について説明する。
過去の予約、発券記録の一覧照会、詳細の照会を行う機能である。また、社内システム等と連携している場合において、各企業のシステムへ取り込み済みの記録と、各予約会社上の記録が不一致になった際の情報更新の機能などを設けることもできる。
ユーザー端末から予約記録一覧照会要求を送信し（Ｓ９００）、検索予約サーバーにおいて受信する（Ｓ９０１）。検索対象となる結合先を判定し（Ｓ９０２）、各旅行機関システムに予約記録一覧照会要求を送信し（Ｓ９０３）、各旅行機関システムにおいて受信される（Ｓ９０４）。
各旅行機関システムにおいて予約情報データベース（取引情報データベース）等を検索し（Ｓ９０５）、各旅行機関システムにおいて予約記録を抽出して結合サーバーに送信する（Ｓ９０６）。
結合サーバーにおいて受信し、必要に応じ各旅行機関システムのデータ形式に変換し（Ｓ９０７）、予約済、発券済み、取消済等のステータスを判定する（Ｓ９０８）。検索予約サーバーにおいて、予約記録一覧のコンテンツを生成し（Ｓ９０９）、ユーザー端末に送信して表示する（Ｓ９１０）。予約記録一覧表示が行われるが、一覧表示のほかにも、スケジュール表示やルート表示等を行うこともでき、さらに個々のスケジュールや宿泊等の詳細表示、明細表示等を可能にすることもできる。
図３２は、表示された予約履歴一覧の画面を示す。また図３３は詳細表示、図３４はステータスが判定され取消可能な予約のみを一覧表示した一例を示す。
【００８４】
次に、図１８を参照して取消処理について説明する。
予約の取消と払戻しとを１操作で行うことが好ましい。従来、チケットレスで予約の取消後の再発券はなく、すべて払戻しが必要な仕組みであるために、航空会社サイトでは、取消、払戻しの２操作が必要であったためである。なお、取消の場合の料金払戻し方法には、ユーザーの金融機関口座へ自動的に現金振込み、または次回利用までクレジットされるなどの様々な方法を採用することができる。
取消処理を行う場合には、図３４はステータスが判定され取消可能な予約のみを一覧表示させることが好ましい。ユーザー端末において、検索結果（予約記録）を指定し、取消処理を選択することにより（Ｓ１０００）、検索予約サーバーに取消要求が送信される。照会対象となる結合先を判定し（Ｓ１００１）、結合先の旅行機関システムに接続し、検索結果（予約記録）の取消要求を送信する（Ｓ１００２）。
取消要求は各旅行機関システムにおいて受信され（Ｓ１００３）図３５に一例を示すように取消内容や払戻し料金等を確認表示する（Ｓ１００４）。
確認を経るなどして取消要求（および払戻し要求）を送信することにより（Ｓ１００５）、各旅行機関システムにおいて取消データを取引情報データベース等に記憶して（Ｓ１００６）、取消が完了すれば（Ｓ１００７）、取消結果を返信し、各旅行機関システムからのデータを結合サーバーにおいて受信する（Ｓ１００８）。結果解析により、各旅行機関システムのデータを共通データに変換し（Ｓ１００９）、検索予約サーバーにおいて取消・払戻し結果（払戻し料金・取消手数料等）のコンテンツを生成し（Ｓ１０１０）、ユーザー端末に送信されて表示される（Ｓ１０１１）。
図３６は、取消結果を表示する画面の一例である。
【００８５】
次に、予約、取消の処理と同様の処理により、予約の変更や追加、取り消しなどをユーザー端末から操作により行うことができる。
予約の変更には、日時の変更や、人数の増員、減員のほか、様々な予約内容の変更を、端末装置からデータを入力、送信することにより行うことができる。
送信されたデータ内容に基づき、旅行機関システムに照会を行い、変更等が可能であれば予約の変更などを行い、予約情報データベースに記憶されている予約情報を更新する。また変更結果等をユーザー端末に回答すると共に、取引情報データベースに記憶する。
【００８６】
【発明の効果】
以上詳細に説明したように、本発明によれば、複数の交通機関や宿泊施設等のシステムを利用して検索・予約等を行う際に、それぞれのシステムに対し順次、認証処理を経てログインし、検索や予約などを行った後にログアウトする処理を繰り返すことなく、共通のＩＤやパスワードなどを用いて検索や予約が行えるシステムを提供することができる。中継するサーバーが接続先のシステムを判定し、判定された各社のシステムへの認証処理を自動的に行うことにより、異なるＷＥＢサイトに対し、共通ＩＤでのログインが可能となる。
さらに、ユーザー自身が予約等を行う各社独自のセルフブッキングツールを、ユーザーとの間を結合するシステムを介在させることにより、交通機関や宿泊施設などが個々に結合開発することを不要にすることができる。
実際の旅行や出張に際しての手配には、こうした複数の交通機関はもとより、宿泊施設、レンタカー、その他の旅行商品・サービスなども含めて、同時検索、同時予約が行うことができる。
さらに本発明によれば、実際の旅行や出張に際しての手配をする場合に、複数の交通機関や、宿泊施設、レンタカー、その他の旅行商品・サービスなども含めて、スケジュール順の表示や、ルート別の表示などの様々な表示方法を、複数の会社の検索結果を同時に表示することが可能なシステムを提供することができる。これによりたとえば、異なるシステムでの手配結果を1枚のスケジュール表にまとめて、印刷することなどが可能になる。また社内システムと連携することにより、購買承認、精算画面への連動、請求照合などが可能となり、ペーパーレス、キャッシュレスを推進することができる。
さらに本発明によれば、出張の手配などに際して、ユーザー個人の情報だけではなく、社内情報の登録や、会社が保有する交通機関等の優待証の取り扱い、管理者による管理、その他詳細なユーザーインターフェースなどを提供することができる。
また、接続先は航空会社、その他の交通機関などの基幹システムとすることができるため、セルフブッキングのような無人の手配ができ、２４時間いつでも、便名が決定していれば即時手配が可能になり、チケットレスでも搭乗が可能になる。さらに「１２：００頃に大阪に着きたい」、「駅近くで１万円のホテルで手配」等の曖昧な検索と予約を可能にすることができる。
【図面の簡単な説明】
【図１】本発明のシステムの基本的な構成の一例を示すシステム構成図である。
【図２】ユーザー端末からシステムへのログイン処理を経て、本発明のシステムを利用する処理の概要を示すフローチャートである。
【図３】本発明のシステムを利用する一連の処理において、ユーザー端末から入力を行うデータ形式、データ項目の基本的な一例を示す図である。
【図４】本発明のシステムを利用する一連の処理において、ユーザー端末に出力され表示されるデータ形式、データ項目の基本的な一例を示す図である。
【図５】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図６】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図７】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図８】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図９】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１０】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１１】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１２】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１３】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１４】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１５】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１６】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１７】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１８】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１９】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２０】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２１】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２２】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２３】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２４】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２５】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２６】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２７】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２８】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図２９】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図３０】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図３１】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図３２】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図３３】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図３４】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図３５】本発明のシステムを利用した際にユーザー端末に表示されるコンテンツの一例を示す画面イメージ図である。
【図１】
2004192357.tif 000003
【図２】
2004192357.tif 000004
【図３】
2004192357.tif 000005
【図４】
2004192357.tif 000006
【図５】
2004192357.tif 000007
【図６】
2004192357.tif 000008
【図７】
2004192357.tif 000009
【図８】
2004192357.tif 000010
【図９】
2004192357.tif 000011
【図１０】
2004192357.tif 000012
【図１１】
2004192357.tif 000013
【図１２】
2004192357.tif 000014
【図１３】
2004192357.tif 000015
【図１４】
2004192357.tif 000016
【図１５】
2004192357.tif 000017
【図１６】
2004192357.tif 000018
【図１７】
2004192357.tif 000019
【図１８】
2004192357.tif 000020
【図１９】
2004192357.tif 000021
【図２０】
2004192357.tif 000022
【図２１】
2004192357.tif 000023
【図２２】
2004192357.tif 000024
【図２３】
2004192357.tif 000025
【図２４】
2004192357.tif 000026
【図２５】
2004192357.tif 000027
【図２６】
2004192357.tif 000028
【図２７】
2004192357.tif 000029
【図２８】
2004192357.tif 000030
【図２９】
2004192357.tif 000031
【図３０】
2004192357.tif 000032
【図３１】
2004192357.tif 000033
【図３２】
2004192357.tif 000034
【図３３】
2004192357.tif 000035
【図３４】
2004192357.tif 000036
【図３５】
2004192357.tif 000037