JP5693638B2 - Ｘｍｌタグ等の分割・結合機能を備える通信中継システム - Google Patents

Description

本発明は，クライアント端末と複数のサービスサーバとの通信を中継するシステム等に関する。本発明の内容を簡単に説明すると，本発明に係る中継システムは，クライアント端末からの要求に応じて，複数のサービスサーバから回答情報を収集し，収集した回答情報を，クライアント端末に送信する機能を持つ。このとき，本発明の中継システムは，クライアント端末との通信は統一された共通のインターフェイス形式で行い，複数のサービスサーバとの通信は各サービスサーバに応じた個別のインターフェイス形式で行うことができる。このため，本発明の中継システムがクライアント端末と複数のサービスサーバの通信を中継することで，インターフェイス形式がそれぞれ異なるサービスサーバから情報を収集する場合であっても，クライアント端末は，共通のインターフェイス形式で中継システムと通信を行えば足りるようになり，サービスサーバそれぞれのインターフェイス形式の違いを意識せずに，必要な情報を簡単に収集することが可能となる。

従来から，パーソナルコンピュータやインターネットを利用して，電子商取引や企業間取引などが活発に行われており，また，企業内におけるシステムも様々なものが開発されている。このような中で，現在では，例えば，旅行や出張などに際して利用する交通機関，宿泊施設，及びその他の旅行商品等の検索や予約を，インターネットを利用して簡単に行うことができるようになっている。例えば，消費者は，旅行代理店のＷＥＢサイト，又は交通機関・宿泊施設のＷＥＢサイトを利用して，旅行商品や，適切な交通手段，宿泊先のデータを検索したり，予約を行ったりすることができる。このように，取引対象がサービス（交通手段や宿泊施設の提供等）である場合は，そのサービスを一括して扱うことが効率的であるため，航空会社や旅行会社において，そのサービスの一括管理を実現するためのシステムが開発され実用化されてきた。

例えば，従来から，航空券の取扱いに関し，航空券の予約や，発券，決済，予約のキャンセルを一括管理するシステムが知られている。このようなシステムは，一般的に，ＣＲＳ（Computer Reservation System）と呼ばれる。ＣＲＳは，アメリカにおいて開発され，現在では世界の殆どの主要航空会社が，国際線の取り扱いにおいて導入しているシステムである。ＣＲＳは，複数の国際線航空会社それぞれの航空券や航空座席等の航空情報を一手に集めて集中管理する。ＣＲＳは，基本的には，ＣＲＳサービスを提供するＣＲＳ運営会社が管理するＣＲＳサーバと，利用航空会社のホストサーバとを通信回線によって接続し，ＩＡＴＡ（International Air Transport Association）で定められたＡＩＲＩＭＰ（ATA/IATA
Reservations Interline Message Procedures）ルールに基づいてメッセージを交換することにより，在庫管理，予約，発券等の処理をする。例えば，ＣＲＳ運営会社としては，ＡＸＥＳＳ（登録商標）や，ＩＮＦＩＮＩ（登録商標），ＧＡＬＩＬＥＯ（登録商標）等が知られている。

このように，現在，ＣＲＳサービスを提供するＣＲＳ運営会社は，多数存在している。このため，旅行代理店等は，複数のＣＲＳサーバ（サービスサーバ）のそれぞれに専用線を介して専用端末（クライアント端末）を接続しておき，この専用端末を利用して，各ＣＲＳサーバへとアクセスして，予約取得及び発券処理を行うこととしている。

また，上記ＣＲＳに関する技術として，例えば，特許文献１に開示されたものが知られている。特許文献１では，ＷＥＢサイトにおいて直接，交通機関の検索や予約までをユーザが行えるように，国際航空会社における航空券の空き状況を，複雑な操作や特定のシステムを利用しないで簡単にアクセスして把握できるようにした航空券予約販売システムが提案されている。この特許文献１のシステムは，各航空会社が発行している航空券を主体とした航空券情報が蓄積されているデータベースを備えた航空券情報サーバと，航空座席予約及び照会を行う航空座席予約・照会サーバとから構成される。このシステムは，航空座席予約・照会サーバと航空券情報サーバを専用回線で接続して航空券情報を受信できるようにすると共に，所定のネットワーク上において航空券を専門に扱う旅行代理店を含むエンドユーザが，航空券情報に基づいて航空券料金の閲覧及び航空座席予約ができるようにしている。

特開２００２−１１７２６６号公報

しかしながら，現在では，上述したように，ＣＲＳサービスを提供するＣＲＳ運営会社は多数存在しているため，旅行代理店等は，複数のＣＲＳサーバ（サービスサーバ）のそれぞれに専用線を介して専用端末（クライアント端末）を接続しておき，専用端末からＣＲＳサーバにアクセスする際には，各ＣＲＳサーバに応じたインターフェイスを利用する必要があった。例えば，ある旅行代理店が，自己の専用端末を通じて，ＣＲＳ運営会社であるＡ社のＣＲＳサーバとＢ社のＣＲＳサーバのアクセスし，それぞれのサーバから航空機の空席情報を取得しようとした場合，旅行代理店の専用端末は，Ａ社のＣＲＳサーバにアクセスするときには，ある決まったインターフェイス形式を利用し，Ｂ社のＣＲＳサーバにアクセスするときには，Ａ社のものとは異なるインターフェイス形式を利用する必要がある。

一般的に，旅行代理店等の専用端末とＣＲＳ運営会社のＣＲＳサーバのデータのやり取りは，ＸＭＬ等のインターフェイス形式によって記述されたデータで行われる。ＸＭＬは，文書やデータの意味や構造を記述するためのマークアップ言語の一であり，「タグ」と呼ばれる特定の文字列を基本単位として情報の意味や構造，装飾などを構造的に記述したものであり，ＸＭＬは，特に，ユーザが独自の「タグ」を自由に指定できることを特徴としている。ＸＭＬは，統一的な記法を用いながら独自の意味や構造を持ったタグを指定することができるため，汎用性が高いとされているものの，ＸＭＬ形式のインターフェイスを提供するサーバとデータ通信を行う際には，そのサーバにより提供される独自のインターフェイスのタグ構造を常に把握しておく必要がある。従って，Ａ社のＣＲＳサーバと通信を行うためのインターフェイスのタグ構造と，Ｂ社のＣＲＳサーバと通信を行うためのインターフェイスのタグ構造が異なる場合，旅行代理店の専用端末は，航空機の空席情報という一つの回答情報が欲しい場合であっても，それを求めるための指令情報を，Ａ社固有のインターフェイス形式とＢ社固有のインターフェイス形式の両方を用いて，各社のＣＲＳサーバに送信しなければならならず，処理が煩雑なものとなっていた。

例えば，ある旅行代理店の専用端末が，Ａ社のＣＲＳサーバを介して航空座席を予約するためには，予約者の氏名，住所，人数，連絡先，航空会社名，及び航空機の便名のデータを，それぞれ計６回ずつ送受信する必要がある。他方，同じ旅行代理店の専用端末が，Ｂ社のＣＲＳサーバを介して航空座席を予約する際には，予約者の氏名・住所・人数のデータについては一度にまとめて送受信することができるものの，その他の連絡先，航空会社名，及び航空機の便名のデータは別々に送受信する必要があり，計４回の送受信が求められることがある。このように，Ａ社のＣＲＳサーバとＢ社のＣＲＳサーバとで送受信を行う回数が異なるのは，各ＣＲＳサーバとデータの送受信を行う際のインターフェイス形式がそれぞれ異なる結果，一つのＸＭＬデータにまとめて送信可能な情報の種類や数が異なるからである。

このように，従来技術においては，例えば，ＣＲＳ等を扱う複数のサービスサーバごとに，個別の形式でデータが記憶されているため，旅行代理店の端末から，各サービスサーバが保持するデータを横断的に利用しようとする場合，各サービスサーバごとの固有のデータ構造やテーブル構造を考慮したインターフェイスが必要となる。このため，旅行代理店の端末から，複数のサービスサーバに対して特定の回答情報を求める指令情報を送信するときには，その指令情報を，各サービスサーバに応じたインターフェイス形式に変更する必要があり，旅行代理店にとっては，複数のＣＲＳサーバとの連携するシステムを導入する際に多大なコストが掛かったり，ＣＲＳサーバとの連携するシステムの管理が面倒なものとなっていた。

そこで，現在では，異なるインターフェイス形式でのデータ通信が必要となる複数のサービスサーバに対し，クライアント端末から指令情報を送信して，それに応じた回答情報を得るときにも，クライアント端末の利用者が，各サービスサーバのインターフェイス形式の違いを意識せずに，指令情報の送信や回答情報の受信を効率的に行うことのできるシステムが求められている。

そこで，本発明の発明者は，上記の従来発明の問題点を解決する手段について鋭意検討した結果，クライアント端末と複数のサービスサーバとの間に中継システムを介在させ，この中継システムが，クライアント端末との間では共通のインターフェイス形式でデータ通信を行い，複数のサービスサーバとの間では各サーバに応じた個別のインターフェイス形式でデータ通信を行うことができるようにすることで，クライアント端末の利用者が，各サービスサーバのインターフェイス形式の違いを意識せずに，クライアント端末と複数のサービスサーバとの間で情報の送受信を行うことできるようになるという知見を得た。
そして，本発明者は，上記知見に基づけば，従来技術の課題を解決できることに想到し，本発明を完成させた。
具体的に説明すると，本発明は以下の構成を有する。

本発明の第１の側面は，中継システムに関する。中継システム３は，回答を求める命令情報を送信する一又は複数のクライアント端末１と，命令情報を受信したときに当該命令情報に応じた回答情報を送信する複数のサービスサーバ２とに対して情報通信回線を通じて接続されている。このため，中継システム３は，クライアント端末１と複数のサービスサーバ２の間において，命令情報と回答情報の送受信を中継する。
中継システム３は，基本的に，受信部３１と，インターフェイスデータベース（以下，ＩＦＤＢともいう）３２と，第１変換部３３と，通信部３４と，第２変換部３５と，送信部３６と，を有している。
受信部３１は，クライアント端末１から送信された命令情報を，共通インターフェイス形式により，受信する。
ＩＦＤＢ３２は，複数のサービスサーバ２のそれぞれと通信可能な複数の個別インターフェイス形式と共に，当該複数の個別インターフェイス形式のそれぞれについて，共通インターフェイス形式との対応関係を記憶している。
第１変換部３３は，ＩＦＤＢ３２を参照し，受信部３１が受信した共通インターフェイス形式の命令情報を，当該命令情報を伝達するサービスサーバ２と通信可能な個別インターフェイス形式の命令情報に変換する。
通信部３４は，第１変換部３３が変換した個別インターフェイス形式に基づいて，命令情報を前記サービスサーバ２に送信すると共に，当該命令情報に応じた回答情報を，当該サービスサーバ２から受信する。
第２変換部３５は，ＩＦＤＢ３２を参照し，通信部３４が受信した個別インターフェイス形式の回答情報を，共通インターフェイス形式の回答情報に変換する。
送信部３６は，第２変換部３５により得られた共通インターフェイス形式の回答情報を，クライアント端末１へ送信する。

本発明では，上記構成のように，中継システムにおいて，クライアント端末１との通信を行う際に利用する共通インターフェイス形式と，各サービスサーバ２との通信を行う際に利用する個別インターフェイス形式との対応関係を関連付けてテーブル等に記憶しておくことで，この中継システムが，クライアント端末１の代理として各サービスサーバ２との通信を行うことが可能となる。このため，クライアント端末１は，各サービスサーバ２が保持するデータの収集を行う場合であっても，直接的に，各サービスサーバ２と通信を行う必要がなくなり，中継システム３に対して，共通インターフェイス形式で通信を行えば済むため，従来技術のような処理の煩雑さの問題を解消できる。

本発明の中継システムにおいて，共通インターフェイス形式及び個別インターフェイス形式は，共にＸＭＬ形式であって，タグ構造が異なるものであることが好ましい。この場合，第１変換部３３は，共通インターフェイス形式の共通タグを，命令情報を伝達するサービスサーバ２と通信可能な個別インターフェイス形式の個別タグに変換する処理を行う。また，第２変換部３５は，個別インターフェイス形式の個別タグを，共通インターフェイス形式の共通タグに変換する処理を行う。

本発明の中継システムにおいて，第１変換部３３は，ＩＦＤＢ３２を参照し，共通インターフェイス形式の共通タグにより記述された命令情報を，当該命令情報をサービスサーバ２にすべて伝達するのに必要な，個別インターフェイス形式の個別タグに記述された複数の命令情報に変換するものであってもよい。
この場合，通信部３４は，第１変換部３３により得られた個別タグにより記述された複数の命令情報を，サービスサーバ２に順次送信すると共に，当該複数の命令情報のそれぞれに対する複数の回答情報を，個別インターフェイス形式の個別タグにより記述された情報として，当該サービスサーバ２から順次受信する。
また，中継システム３は，通信部３４を介して順次受信される複数の回答情報を，一時的に記憶するメモリ３７を，さらに有することが好ましい。
この場合，中継システム３の第２変換部３５は，共通タグに記述された命令情報に対する複数の回答情報がメモリ３７に蓄積された後に，複数の回答情報に関する個別タグをまとめて，共通インターフェイス形式の共通タグへと変換する処理を行うことが好ましい。

本発明の中継システム３では，個別インターフェイス形式によっては，クライアント端末１から送信され共通タグで記述された命令情報が，個別タグで記述された複数の命令情報に変換されることが考えられる。この場合，サービスサーバ２は，中継システム３から，個別タグで記述された複数の命令情報を受信したときに，それぞれの命令情報に対して，個別タグで記述された複数の回答情報を返信する。このとき，中継システムは３が，サービスサーバ２から回答情報を受信した都度，回答情報をクライアント端末１に伝達すると，クライアント端末１としては，一の命令情報に対しする回答情報を複数回得ることとなり，情報の整理や管理が複雑化する。そこで，サービスサーバ２からの送信された複数の回答情報を，中継システム３のメモリ３７に一時的に記憶し，すべての回答情報が揃った段階で，まとめてフォーマットを共通フォーマットへと変換してクライアント端末１に送信することで，クライアント端末１としては，一の命令情報に対して一の回答情報を得ることとができるようになるため，情報を一括管理し易くなる。

本発明の第２の側面は，コンピュータを，上記第１の側面に係る中継システムとして機能させるためのコンピュータプログラムに関する。

本発明の第３の側面は，上記第１の側面に係る中継システムを用いて行う通信中継方法である。
すなわち，本発明の中継方法では，
中継システム３が，
クライアント端末１から送信された命令情報を，共通インターフェイス形式により，受信する受信工程と，
複数のサービスサーバ２のそれぞれと通信可能な複数の個別インターフェイス形式と共に，当該個別インターフェイス形式のそれぞれについて，共通インターフェイス形式との対応関係を記憶しているインターフェイスデータベース（ＩＦＤＢ）３２を参照し，受信工程で受信した共通インターフェイス形式の命令情報を，当該命令情報を伝達するサービスサーバ２と通信可能な個別インターフェイス形式の命令情報に変換する第１変換工程と，
第１変換工程で変換した個別インターフェイス形式により，命令情報をサービスサーバ２に送信すると共に，当該命令情報に応じた回答情報を，当該サービスサーバ２から受信する通信工程と，
ＩＦＤＢ３２を参照し，通信工程で受信した個別インターフェイス形式の回答情報を，共通インターフェイス形式の回答情報に変換する第２変換工程と，
第２変換工程で得られた共通インターフェイス形式の回答情報を，クライアント端末１へ送信する送信工程と，を行う。

本発明によれば，異なるインターフェイス形式でのデータ通信が必要となる複数のサービスサーバに対し，クライアント端末から指令情報を送信して，それに応じた回答情報を得るときであっても，クライアント端末の利用者が，各サービスサーバのインターフェイス形式の違いを意識せずに，指令情報の送信や回答情報の受信を効率的に行うことができるようになる。

図１は，本発明に係る中継システムの構成を示したブロック図である。 図２は，本発明に係る中継システムの処理の流れを示したフロー図である。 図３は，Ａ社のサービスサーバを利用して航空券の予約をする場合の例を示している。 図４は，Ｂ社のサービスサーバを利用して航空券の予約をする場合の例を示している。

以下，図面を用いて本発明を実施するための形態について説明する。本発明は，以下に説明する形態に限定されるものではなく，以下の形態から当業者が自明な範囲で適宜修正したものも含む。

図１は，本発明に係る中継システム３の構成の一例を示したブロック図である。図１に示されるように，本発明の中継システム３は，クライアント端末１と複数のサービスサーバ２の間において情報の通信の中継を行うシステムである。すなわち，中継システム３は，クライアント端末１，及び複数のサービスサーバ２のそれぞれと，インターネット等の情報通信回線を介して相互に情報の授受が可能なように接続されている。中継システム３は，クライアント端末１から命令情報を受信すると，その命令情報を，クライアント端末１により指定された一又は複数のサービスサーバ２に対し伝達する。各サービスサーバ２は，中継システム３から命令情報を受信すると，その受信した命令情報に応じた回答情報を，中継システム３へと送信する。そして，中継システム３は，各サービスサーバ３から回答情報を受信すると，その回答情報を，上記命令情報を発信したクライアント端末１に対し，送信する。このように，本発明に係る中継システム３は，クライアント端末１と複数のサービスサーバ２の間において情報の通信の中継を行う。

クライアント端末１としては，公知のコンピュータや携帯端末等を利用することができる。例えば，サービスサーバ２が，ＣＲＳ（Computer
Reservation System）サービスを提供するものである場合，クライアント端末１は，旅行代理店等において使用されるものであり，ＣＲＳサービスサーバにアクセスすることで，交通機関，宿泊施設，又はその他の旅行商品等の検索や，予約，キャンセル等の手続を行う。クライアント端末１は，情報の入出力を行うための入出力部，情報を記憶する記憶部，制御を行う制御部（ＣＰＵ），各種演算を行う演算部，及びそれぞれの要素を接続するバスなどの伝送路を含むハードウェア構成を有している。そして，例えば，記憶部のメインメモリには，制御用のアプリケーションプログラムが格納され，所定の情報が入力されると，制御部（ＣＰＵ）はメインメモリからアプリケーションプログラムを読み出すと共に，記憶部に記憶された各種情報を読み出して，演算部にて所定の演算を行い，適宜記憶部に記憶しながら，演算処理した情報を出力部から出力する。例えば，クライアント端末１は，ＣＰＵと，ＲＡＭやＲＯＭ等からなるメモリと，マウスやキーボード等の操作入力部と，ディスプレイやスピーカ等の出力部と，インターネット等の情報通信回線を通じてデータ信号の送受信を行うデータ送受信部と，を備えていればよい。

複数のサービスサーバ２としては，公知のサーバ装置を利用すればよい。例えば，サービスサーバ２は，ＣＲＳサービスを提供するＣＲＳ運営会社によって管理されるサーバである。ＣＲＳサーバとして機能するサービスサーバ２は，利用航空会社等のホストサーバ（図示省略）とを情報通信回線によって接続されており，ＩＡＴＡで定められたＡＩＲＩＭＰルールに基づいてメッセージを交換することにより，在庫管理，予約，発券等の処理をすることができる。このように，各サービスサーバ２は，交通機関・宿泊施設などの旅行商品やサービスを提供するＣＲＳに用いられる場合，各サービスサーバ２は，さらに複数の旅行機関が管理するホストサーバに接続される。各サービスサーバ２は，複数のホストサーバにアクセスし，旅行商品やサービスの検索，予約，及び費用請求などを行うために必要なデータベースやプログラム等を備えるサーバ装置であればよい。なお，旅行機関としては，上記航空会社に限られず，その他鉄道会社や，船会社，バス会社，レンタカー会社などの輸送機関・交通機関や，ホテルなどの宿泊施設その他の旅行サービスに関連する各種サービスを提供する機関が挙げられる。各サービスサーバ２は，基本的に，情報の入出力を行うための入出力部，情報を記憶する記憶部，制御を行う制御部（ＣＰＵ），各種演算を行う演算部，及びそれぞれの要素を接続するバスなどの伝送路を含むハードウェア構成を有している。例えば，各サービスサーバ２は，ＣＰＵと，ＲＡＭやＲＯＭ等からなるメモリと，各種データをテーブルで関連付けて記憶したデータベースと，マウスやキーボード等の操作入力部と，ディスプレイやスピーカ等の出力部と，インターネット等の情報通信回線を通じてデータ信号の送受信を行うデータ送受信部と，を備えていることが好ましい。

また，複数のサービスサーバ２において，各種のデータは，ＸＭＬ形式により記述されたものであることが好ましい。ＸＭＬは，文書やデータの意味や構造を記述するためのマークアップ言語の一つであり，「タグ」と呼ばれる特定の文字列で地の文に情報の意味や構造，装飾などを埋め込むことで構築された言語である。ＸＭＬでは，ユーザーが独自のタグを自由に指定できる点を特徴としている。ＸＭＬは，統一的な記法を用いながら独自の意味や構造を持ったマークアップ言語を作成することができるため，情報通信回線を通じた通信及び情報交換に用いるデータ形式や，様々な種類のデータを保存するためのファイルフォーマットなどの定義に用いることができる。本発明において，複数のサービスサーバ２のデータベースに記憶されているデータの構造は異なるものであってもよい。すなわち，複数のサービスサーバ２のデータベースに記憶されているＸＭＬ形式のデータは，そのタグ構造が異なるものであってもよい。このように，各サービスサーバ２において，記憶されているＸＭＬデータのタグ構造が異なる場合，他の端末等がサービスサーバ２との間でＸＭＬデータの送受信を行うためには，複数のサービスサーバ２ごとにインターフェイス形式を一致させて通信を行う必要がある。このように，各サービスサーバ２ごとに独自に設定されたタグ構造を持つＸＭＬデータの送受信を行う際に用いられるインターフェイス形式を，本願明細書では，個別インターフェイス形式と呼ぶ。

続いて，本発明に係る中継システム３について詳しく説明する。
図１に示されるように，本実施形態において，中継システム３は，受信部３１と，インターフェイスデータベース（ＩＦＤＢ）３２と，第１変換部３３と，通信部３４と，第２変換部３５と，送信部３６と，メモリ３７と，これらの要素を制御する制御部（ＣＰＵ）３０とを，備えている。例えば，メモリ３７には制御用のアプリケーションプログラムが格納されており，受信部３１や通信部３４を介して所定の情報が入力されると，ＣＰＵ３０は，メモリ３７からアプリケーションプログラムを読み出すと共に，ＩＦＤＢ３２に記憶された各種情報を読み出して，第１変換部３３や第２変換部３５にて所定の演算処理を行わせ，適宜各種情報をＲＡＭ等のメモリ３７等に記憶しながら，演算処理した情報を通信部３４や送信部３６を介して出力する。中継システム３は，一のコンピュータ（サーバ装置）によりその機能を全て実現したものであってもよいし，複数のコンピュータ（サーバ装置）にその機能を分担して構築されたものであってもよい。

中継システム３の受信部３１は，クライアント端末１から送信された命令情報を，共通インターフェイス形式により受信する。本願明細書において，共通インターフェイス形式とは，中継システム３とクライアント端末１とが，情報通信回線を通じて通信及び情報交換を行うことが可能な統一されたデータの形式である。例えば，中継システム３に複数のクライアント端末１が接続されている場合，この中継システム３と複数のクライアント端末１は，一つに統一された共通インターフェイス形式によりデータ通信を行う。本発明において，共通インターフェイス形式としては，ＸＭＬ形式を好適に利用することができる。クライアント端末１と中継システム３とで送受信されるデータがＸＭＬのようなマークアップ言語で記述されたものである場合，そのタグ構造が共通のものとされる。例えば，共通インターフェイス形式におけるタグ構造は，中継システム３の運営者が指定すればよい。この場合，各クライアント端末１には，この中継システム３の運営者が指定したタグ構造を持つ共通インターフェイスが提供される。このため，各クライアント端末１は，中継システム３の運営者により提供されたインターフェイス形式に従ってデータを記述することで，容易に，共通インターフェイスを利用できる。

また，クライアント端末１から中継システム３に送信される命令情報とは，基本的に，一又は複数のサービスサーバ２からの回答を求めるための情報（データ）である。例えば，命令情報には，回答を求めるサービスサーバ２を特定するための情報（ＩＰアドレス等）や，各サービスサーバ２が回答可能な情報を要求するための情報が含まれる。例えば，サービスサーバ２が，ＣＲＳサービスを提供するＣＲＳ運営会社によって管理されるサーバである場合，クライアント端末１から発信される命令情報には，例えば，航空座席の検索を求める命令や，航空座席の空席状況の確認を求める命令，航空座席を予約するための命令等，種々の情報が含まれる。また，一の命令情報（コマンド）が，複数の情報を組み合わせて形成される場合もある。例えば，航空座席を予約するための命令情報には，予約者の氏名，住所，人数，連絡先，航空会社名，航空機の便名，運行区間，出発予定日時，その他航空座席を予約するのに必要な情報が含まれる。このため，中継システム３とクライアント端末１との間でデータ通信を行うための共通インターフェイス形式は，一つの命令情報に複数の情報が含まれる場合に，これらの複数の情報を一括して扱えるように，タグ構造等が調整されたものを用いることが好ましい。例えば，共通インターフェイス形式では，航空座席を予約するための命令情報と回答情報を送受信する際に，予約者の氏名，住所，人数，連絡先，航空会社名，航空機の便名，運行区間，及び出発予定日時等を，一つの共通タグ（データ）にまとめて送受信可能なタグ構造を採用することが好ましい。このように，共通インターフェイスでは，複数の情報によって形成される命令情報と回答情報を一つの共通タグにまとめて送受信可能なように設計することで，クライアント端末１は，ある命令情報と回答情報（例えば航空座席を予約等）に関するやりとりを，１回の送受信で完結させることができるようになる。

インターフェイスデータベース（ＩＦＤＢ）３２は，複数のサービスサーバ２のそれぞれと通信可能な複数の個別インターフェイス形式と共に，当該複数の個別インターフェイス形式のそれぞれについて，共通インターフェイス形式との対応関係を記憶するテーブルによって構築されたデータベースである。上述したように，本発明において，中継システム３が複数のサービスサーバ２と通信する際の個別インターフェイス形式は，各サービスサーバ２ごとに，それぞれ異なっていてもよい。また，クライアント端末１と中継システム３とが通信するための共通インターフェイス形式と，各サービスサーバ２と中継システム３とが通信するための個別インターフェイス形式は，それぞれ異なっていてもよい。なお，インターフェイス形式が異なるとは，例えば，データを記述するタグ構造が異なることを意味する。本願明細書では，共通インターフェイス形式に対応するデータを記述するタグを共通タグと称し，個別インターフェイス形式に対応するデータを記述するタグを個別タグと称している。本発明の中継システム３は，クライアント端末１から共通インターフェイス形式により受信した命令情報を，各サービスサーバ２に送信するために，個別インターフェイス形式の命令情報へと変換する処理を行う。また，中継システム３は，各サービスサーバ２から個別インターフェイス形式により受信した回答情報を，クライアント端末１に送信するために共通インターフェイス形式の回答情報へと変換する処理を行う。このため，中継システム３は，共通インターフェイス形式と，各個別インターフェイスの対応関係を記憶しておくためのＩＦＤＢ３２が必要となる。

具体的には，命令情報や回答情報がＸＭＬ形式のデータとして送受信されるものである場合，ＩＦＤＢ３２には，共通インターフェイス形式に対応した共通タグと，各個別インターフェイス形式に対応した個別タグを相互に変換するためのルールを記憶すればよい。例えば，ＩＦＤＢ３２には，ある命令情報を記述するための共通タグを，Ａ社のサービスサーバ用の個別タグに変換するためのルールや，Ｂ社のサービスサーバ用の個別タグに変換するためのルールや，その他の会社のサービスサーバ用の個別タグに変換するためのルールと関連付けて記憶する。例えば，命令情報に，名前と，航空会社名と，連絡先が含まれている場合に，共通インターフェイスに対応した共通タグでは，これらの名前，航空会社名，及び連絡先を一括した命令情報として記述可能となっているのに対し，Ａ社のサービスサーバ用の個別インターフェイスに対応した個別タグでは，名前が記述された命令情報，航空会社名が記述された命令情報，連絡先が記述された命令情報に分割する必要がある場合などに，ＩＦＤＢ３２には，共通タグにより記述された命令情報を，個別タグにより記述された複数の命令情報へと分割する際のルールを記憶する。このように，ＩＦＤＢ３２は，共通インターフェイスにおける共通タグと，他の複数の個別インターフェイスにおける個別タグの対応関係を記憶するものであればよい。

第１変換部３３は，上記のＩＦＤＢ３２を参照し，受信部３１が受信した共通インターフェイス形式の共通タグを，当該命令情報を伝達するサービスサーバ２と通信可能な個別インターフェイス形式の個別タグに変換する処理を行う。上述のように，ＩＦＤＢ３２には，複数の個別インターフェイスのそれぞれについて，共通インターフェイスの共通タグを個別タグに変換するためのルールが記憶されている。このため，第１変換部３３は，命令情報を伝達するサービスサーバ２に応じて，ＩＦＤＢ３２から共通タグを個別タグに変換するためのルールを読み出し，そのルールに従った変換処理を行う。例えば，サービスサーバ２が個別タグによって記述された複数の命令情報を要求している場合に，第１変換部３３は，ＩＦＤＢ３２に記憶されているルールに従って，共通タグによって記述された一の命令情報を，個別タグによって記述された複数の命令情報へと書き換える。

通信部３４は，第１変換部３３が変換した個別インターフェイス形式に基づいて，命令情報をサービスサーバ２に送信すると共に，当該命令情報に応じた回答情報を，当該サービスサーバ２から受信する送受信処理を行う。なお，通信部３４は，個別インターフェイス形式の命令情報をサービスサーバ２に送信する送信手段と，個別インターフェイス形式の回答情報をサービスサーバ２から受信する受信手段とを有するものであると言い換えることもできる。このように，通信部３４は，複数のサービスサーバ２のそれぞれと，個別インターフェイス形式でデータの送受信を行う。また，本発明では，第１変換部３３において，共通インターフェイス形式に対応した共通タグにより記述された命令情報を，個別インターフェイス形式に対応した個別タグにより記述された複数の命令情報へと変換する場合が多いと考えられる。この場合，通信部３４は，個別タグにより記述された複数の命令情報を，サービスサーバ２に順次送信すると共に，この複数の命令情報のそれぞれに対する複数の回答情報を，個別インターフェイス形式の個別タグによって記述された情報として，当該サービスサーバ２から順次受信すればよい。

メモリ３７には，通信部３４を介してサービスサーバ２から順次受信した回答情報のそれぞれが，一時的に記憶される。例えば，第１変換部３３によって，共通タグで記述された一の命令情報が，個別タグで記述された複数の命令情報に変換されて，あるサービスサーバ２に順次送信されると，命令情報を受信したサービスサーバ２は，個別タグによって記述されている複数の命令情報のそれぞれに対し，個別タグで記述された複数の回答情報で順次送信する。このように，クライアント端末１から送信された命令情報が一つであっても，サービスサーバ２からは，複数の回答情報が得られる場合がある。このような場合，複数の回答情報を，一の命令情報への回答に必要なものであるとして，メモリ３７に蓄積して一時的に保持しておくことが好ましい。

第２変換部３５は，ＩＦＤＢ３２を参照して，通信部３４がサービスサーバ２から受信した個別インターフェイス形式の回答情報を，共通インターフェイス形式の回答情報に変換する処理を行う。具体的に説明すると，第２変換部３５は，個別インターフェイス形式の個別タグによって記述されている回答情報を，共通インターフェイス形式の共通タグによって記述される回答情報に書き換えればよい。上述のように，ＩＦＤＢ３２には，複数の個別インターフェイスに対応した個別タグのそれぞれを，共通インターフェイスの共通タグに変換するためのルールが記憶されている。このため，第２変換部３５は，回答情報が得られたサービスサーバ２に応じて，ＩＦＤＢ３２から個別タグを共通タグに変換するためのルールを読み出し，そのルールに従った変換処理を行う。例えば，サービスサーバ２が個別タグによって記述された回答情報を送信してきたときに，第２変換部３５は，ＩＦＤＢ３２に記憶されているルールに従って，個別タグを共通タグへと変換し，共通タグによって記述された回答情報へと書き換える。また，サービスサーバ２が個別タグによって記述された複数の回答情報を順次送信してきたときには，その回答情報を，一旦メモリ３７に蓄積し，すべての回答情報が揃った段階で，第２変換部３５は，個別タグにより記述された複数の回答情報をまとめて，共通タグにより記述された一の回答情報へと変換することが好ましい。

送信部３６は，第２変換部３５により得られた共通インターフェイス形式の回答情報を，クライアント端末１へ送信する処理を行う。すなわち，中継システム３は，送信部３６を介して，クライアント端末１に対し，共通インターフェイス形式によって回答情報を送信する。このようにして，クライアント端末１は，自身から発信した命令情報に対応する回答情報を，中継システム３を介して，共通インターフェイス形式で受信することが可能になる。このため，クライアント端末１は，どのサービスサーバ２から回答情報を得ようとする場合であっても，統一された共通インターフェイス形式で，中継システム３に対し命令情報を送信し，統一された共通インターフェイス形式で，中継システムから回答情報を受信することができるため，サービスサーバ２との通信を行うためのインターフェイス形式がそれぞれ異なる場合であっても，そのインターフェイス形式の違いを意識する必要がなくなる。従って，本発明によれば，クライアント端末１を，複数のサービスサーバ２のそれぞれと専用回線で接続する必要がなくなり，両者を連携させることが容易になるため，多大な開発費用を抑えることができる。また，従来は，接続することが必要なサービスサーバ２が増える度に，クライアント端末１と新しいサービスサーバ２を連携させるための専用回線を増設する費用があったが，本発明によれば，中継システム３と新しいサービスサーバ２を接続すればよく，クライアント端末１と新しいサービスサーバ２を接続する必要がないため，クライアント端末１を管理する旅行代理店等の負担を軽減できる。

中継システム３のＣＰＵ３０は，上記した各要素を制御する。図２は，中継システム３のＣＰＵ３０による情報処理を一般化したフロー図である。図２に示した情報処理は，ＣＰＵ３０が，メインメモリに記憶されているアプリケーションプログラに従って，中継システム３の各要素を制御することにより実行される。
なお，図２のフロー図では，クライアント端末１が，中継システム３を介して，Ａ社のサービスサーバから回答情報を得る場合を想定したものとなっている。

図２に示されるように，中継システム３は，クライアント端末１から送信された命令情報（命令文）を，受信部３１によって受信する（受信工程）。この命令情報には，回答を求めるサービスサーバ２を特定するための情報（ＩＰアドレス等）や，サービスサーバ２が回答可能な情報を要求するための情報が含まれる。このとき，中継システム３の受信部３１は，クライアント端末１から送信された命令情報を，共通インターフェイス形式によって受信する。例えば，共通インターフェイス形式は，中継システム３の運営者によってクライアント端末１に提供されるものであればよく，クライアント端末１は，中継システム３の運営者が指定したタグ構造（共通タグ）に従って，命令情報を生成すればよい。すなわち，クライアント端末１から中継システム３に送信される命令情報は，共通タグによって記述されたデータとなっている。このように，各クライアント端末１は，中継システム３の運営者により提供されたインターフェイス形式に従って命令情報を記述することで，容易に，共通インターフェイスを利用できる。

受信部３１が共通タグにより記述された命令情報を受信すると，ＣＰＵ３０は，当該命令情報を解析し，当該命令情報を送信するサービスサーバ２を特定する。また，ＣＰＵ３０は，命令情報を送信するサービスサーバ２を特定した後，命令情報を記述している共通タグをそのサービスサーバ２固有の個別タグに変換するためのルールを，ＩＦＤＢ３２から読み出す。そして，ＣＰＵ３０は，第１変換部３３を制御して，ＩＦＤＢ３２から読み出した変換ルールに従って，命令情報を記述している共通タグを個別タグに変換させる（第１変換工程）。このとき，個別タグで記述された命令情報が一つであっても，個別インターフェイス形式の個別タグによっては，その一つの命令情報を複数の命令情報に分割し，その複数の命令情報によってサービスサーバ２と通信を行う必要がある場合もある。その場合，第１変換部３３は，共通タグで記述された一つの命令情報を，個別タグで記述された複数の命令情報（Ｎ個の命令情報：Ｎは２以上の整数）に変換する処理を行う。

第１変換部３３が個別タグで記述された複数の命令情報を生成した後，ＣＰＵ３０は，通信部３４を介して，複数の命令情報のそれぞれをサービスサーバ２（Ａ社）に送信すると共に，当該複数の命令情報に応答する複数の回答情報をサービスサーバ２（Ａ社）から受信する（通信工程）。例えば，第１変換部３３が，個別タグで記述された第１の命令情報，第２の命令情報，…第Ｎの命令情報を生成したとする。この場合，中継システム３は，まず，第１の命令情報をサービスサーバ２（Ａ社）に送信し，その第１の命令情報に対応した第１の回答情報を，サービスサーバ２（Ａ社）から受信する。サービスサーバ２（Ａ社）から受信した第１の回答情報は，メモリ３７に記憶される。その後，中継システム３は，第２の命令情報をサービスサーバ２（Ａ社）に送信し，その第２の命令情報に対応した第２の回答情報を，サービスサーバ２（Ａ社）から受信する。サービスサーバ２（Ａ社）から受信した第２の回答情報も，メモリ３７に記憶される。そして，中継システム３は，第Ｎの命令情報をサービスサーバ２（Ａ社）に送信し，その第Ｎの命令情報に対応した第Ｎの回答情報を，サービスサーバ２（Ａ社）から受信するまで，命令情報及び回答情報の送受信を繰り返し行う。第Ｎの回答情報を得るまでに得られた回答情報は，適宜，メモリ３７に記憶されている。このように，第１変換部３３が，共通タグで記述された一つの命令情報を，個別タグで記述されたＮ個の命令情報に変換した場合には，Ｎ個の命令情報のすべてに応答するＮ個の回答情報がメモリ３７に蓄積された段階で，ＣＰＵ３０は，共通タグで記述された一つの命令情報に対する十分な回答が得られたものと判断し，サービスサーバ２との通信を終了する。

サービスサーバ２との通信が終了すると，ＣＰＵ３０は，回答情報を記述しているサービスサーバ２固有の個別タグを共通タグに変換するためのルールを，ＩＦＤＢ３２から読み出す。そして，ＣＰＵ３０は，第２変換部３５を制御して，ＩＦＤＢ３２から読み出した変換ルールに従って，回答情報を記述している個別タグを共通タグに変換させる（第２変換工程）。このとき，第２変換部３５は，メモリ３７に個別タグで記述されたＮ個の回答情報が記憶されている場合には，このＮ個の回答情報を全て読み出し，Ｎ個の回答情報に関する個別タグをまとめて，共通インターフェイス形式の共通タグへと変換する。これにより，個別タグで記述されたＮ個の回答情報から，共通タグで記述された一つの回答情報が得られる。

第２変換部３５によるタグ構造の変換処理が終了すると，ＣＰＵ３０は，送信部３６を介して，第２変換部３５が生成した共通タグで記述された一つの回答情報を，クライアント端末１に対して送信する（送信工程）。このとき，中継システム３の送信部３６は，一つの命令情報を，クライアント端末１に対し共通インターフェイス形式によって送信する。このように，クライアント端末１は，中継システム３との間の命令情報と回答情報の送受信を，すべて共通インターフェイス形式により行うことができる。また，クライアント端末１は，命令情報を中継システム１に送信する処理を一度の送受信で済ませることができると共に，回答情報を中継システムから受信する処理も一度の送受信で済ませることができる。すなわち，従来の技術では，サービスサーバ２の個別インターフェイス形式によっては，クライアント端末１は，サービスサーバ２との間で命令情報の送受信を何度も繰り返し行う必要がある場合もあったが，本発明によれば，クライアント端末１は，統一された共通インターフェイス形式により，中継システム２との間での命令情報と回答情報の送受信を一度で済ませることができるようになる。

図３及び図４は，クライアント端末１が，中継システム３を介して，Ａ社のサービスサーバ２ＡとＢ社のサービスサーバ２Ｂとにアクセスし，航空券の予約をする際の命令情報と回答情報の内容の一例を模式的に示したものである。図３は，Ａ社のサービスサーバ２Ａを利用して航空券の予約をする場合の例を示しており，図４は，Ｂ社のサービスサーバ２Ｂを利用して航空券の予約をする場合の例を示している。

例えば，図３及び図４に示されるように，航空券の予約を行う際には，クライアント端末１に，名前（ＮＡＭＥ），航空会社，便名，クラス，日付，区間，人数，及び連絡先の入力が必要であるとする。これらの名前〜連絡先までの情報は，航空券の予約を行うための命令となる。クライアント端末１に入力された命令情報は，共通タグで記述されたデータとなる。このため，共通タグで記述された命令情報は，共通インターフェイス形式によって，中継システム３へと送信される。

中継システム３は，共通タグで記述された命令情報を受信すると，その命令情報を送信するサービスサーバ２を特定する。図３に示した例では，命令情報を送信するサービスサーバは，Ａ社のサービスサーバ２Ａとなっている。そこで，図３に示した例において，中継システム３は，Ａ社のサービスサーバ２Ａ固有の個別インターフェイス形式に合わせるために，共通タグで記述された命令情報を，Ａ社のサービスサーバ２Ａ固有の個別タグへと変換する。このとき，サービスサーバ２Ａ用の個別タグでは，共通タグでは一つにまとめで記述可能であった命令情報を，３つの命令情報に分けて記述する必要があるとする。サービスサーバ２Ａ用の個別タグによると，第１の命令情報には名前（ＮＡＭＥ）のみを記述可能であり，第２の命令情報には便名，クラス，日付，区間，及び人数を記述可能であり，第３の命令情報には連絡先が記述可能である。このような場合，中継システム３は，まず，個別タグによる第１の命令情報を，Ａ社のサービスサーバ２Ａに送信し，その回答情報（第１の回答情報）を得る。また，中継システム３は，個別タグによる第２の命令情報を，Ａ社のサービスサーバ２Ａに送信し，その回答情報（第２の回答情報）を得る。同様に，中継システム３は，個別タグによる第３の命令情報を，Ａ社のサービスサーバ２Ａに送信し，その回答情報（第３の回答情報）を得る。そしてその後，中継システム３は，Ａ社のサービスサーバ２Ａから得られた第１の回答情報，第２の回答情報，及び第３の回答情報を記述する個別タグを，まとめて共通タグへと変換し，一の回答情報を予約結果として生成する。共通タグによって記述された一の回答情報（予約結果）は，共通インターフェイス形式により，中継システム３からクライアント端末１へと送信される。

他方，図４に示した例では，命令情報を送信するサービスサーバは，Ｂ社のサービスサーバ２Ｂとなっている。このため，図４に示した例において，中継システム３は，Ｂ社のサービスサーバ２Ｂ固有の個別インターフェイス形式に合わせるために，共通タグで記述された命令情報を，Ｂ社のサービスサーバ２Ｂ固有の個別タグへと変換する。このとき，サービスサーバ２Ｂ用の個別タグでは，共通タグでは一つにまとめで記述可能であった命令情報を，２つの命令情報に分けて記述する必要があるとする。サービスサーバ２Ｂ用の個別タグによると，第１の命令情報には名前（ＮＡＭＥ），クラス，日付，区間，及び人数を記述可能であり，第２の命令情報には連絡先が記述可能である。このような場合，中継システム３は，まず，個別タグによる第１の命令情報を，Ｂ社のサービスサーバ２Ｂに送信し，その回答情報（第１の回答情報）を得る。また，中継システム３は，個別タグによる第２の命令情報を，Ｂ社のサービスサーバ２Ｂに送信し，その回答情報（第２の回答情報）を得る。そしてその後，中継システム３は，Ｂ社のサービスサーバ２Ｂから得られた第１の回答情報，及び第２の回答情報を記述する個別タグを，まとめて共通タグへと変換し，一の回答情報を予約結果として生成する。共通タグによって記述された一の回答情報（予約結果）は，共通インターフェイス形式により，中継システム３からクライアント端末１へと送信される。

上記のように，航空券の予約に利用するサービスサーバが，Ａ社のサービスサーバ２Ａであるか，Ｂ社のサービスサーバ２Ｂであるかによって，個別インターフェイス形式のタグ構造が異なっている。すなわち，Ａ社のサービスサーバ２Ａとの通信に必要なインターフェイス形式と，Ｂ社のサービスサーバ２Ｂとの通信に必要なインターフェイス形式が異なるため，Ａ社のサービスサーバ２Ａを利用して航空券を予約するためには，命令情報と回答情報を３回に分けて送受信する必要があり，Ｂ社のサービスサーバ２Ｂを利用して航空券を予約するためには，命令情報と回答情報を２回に分けて送受信する必要がある。ただし，本発明では，クライアント端末１と各サービスサーバ２Ａ，２Ｂの通信を中継システム３が中継しているため，クライアント端末１は，中継システム３と，共通インターフェイス形式によって，命令情報と回答情報を一回送受信すれば，航空券の予約を完了させることができる。従って，本発明の中継システム２がクライアント端末１と複数のサービスサーバ２の通信を中継することで，インターフェイス形式がそれぞれ異なるサービスサーバ２から情報を収集する場合であっても，クライアント端末１は，共通のインターフェイス形式で中継システム３と通信を行えば足りるようになり，サービスサーバ２それぞれのインターフェイス形式の違いを意識せず，必要な情報を簡単に収集することが可能となる。

本発明は，例えば，旅行代理店のクライアント端末と，ＣＲＳ運営会社のＣＲＳサーバとの通信を中継するシステム等に関する。従って，本発明は，旅行商品，交通手段，及び宿泊施設等の手配や検索を行うサービス産業等において好適に利用し得る。

１…クライアント端末 ２…サービスサーバ ３…中継システム
３０…制御部（ＣＰＵ） ３１…受信部 ３２…インターフェイスデータベース
３３…第１変換部 ３４…通信部 ３５…第２変換部
３６…送信部 ３７…メモリ

Claims (2)

1. 回答を求める命令情報を共通インターフェイス形式で送受信する一又は複数のクライアント端末（１）と，前記命令情報を受信したときに当該命令情報に応じた回答情報を個別インターフェイス形式で送受信する複数のサービスサーバ（２）とに情報通信回線を通じて接続され，前記クライアント端末（１）と前記複数のサービスサーバ（２）の間において，前記命令情報と前記回答情報の送受信を中継する中継システム（３）であって，
   前記共通インターフェイス形式及び前記個別インターフェイス形式は，共にＸＭＬ形式であって，タグ構造が異なるものであり，
   前記中継システム（３）は，
   前記クライアント端末（１）から送信された前記共通インターフェイス形式の１つの共通タグにより記述された複数の命令情報を，受信可能な受信部（３１）と，
   前記複数のサービスサーバ（２）のそれぞれと通信可能な複数の個別インターフェイス形式と共に，当該複数の個別インターフェイス形式のそれぞれについて，前記共通インターフェイス形式の共通タグにより記述された情報を，前記個別インターフェイスの個別タグにより記述された命令情報へと分割するためのルールを記憶しているインターフェイスデータベース（以下，ＩＦＤＢ）（３２）と，
   前記ＩＦＤＢ（３２）を参照し，前記受信部（３１）が受信した前記共通インターフェイス形式の１つの共通タグにより記述された複数の命令情報を，当該複数の命令情報を前記サービスサーバ（２）にすべて伝達するのに必要な，前記個別インターフェイス形式の複数の個別タグにより記述された複数の命令情報に分解する第１変換部（３３）と，
   前記第１変換部（３３）により得られた前記個別タグにより記述された複数の命令情報を，前記サービスサーバ（２）に順次送信すると共に，当該個別タグにより記述された複数の命令情報のそれぞれに対する複数の回答情報を，前記個別インターフェイス形式の複数の個別タグにより記述された複数の情報として，当該サービスサーバ（２）から受信する通信部（３４）と，
   前記通信部（３４）を介して順次受信される前記複数の回答情報を，一時的に記憶するメモリ（３７）と，
   前記ＩＦＤＢ（３２）を参照し，前記１つの共通タグにより記述された複数の命令情報のそれぞれに対する複数の回答情報のすべてが前記メモリ（３７）に蓄積された後に，前記複数の回答情報に関する複数の個別タグをまとめて，前記共通インターフェイス形式の１つの共通タグに結合する第２変換部（３５）と，
   前記第２変換部（３５）により得られた前記共通インターフェイス形式の１つの共通タグにより記述された回答情報を，前記クライアント端末（１）へ送信する送信部（３６）と，を有する
   中継システム。
2. 回答を求める命令情報を共通インターフェイス形式で送受信する一又は複数のクライアント端末（１）と，前記命令情報を受信したときに当該命令情報に応じた回答情報を個別インターフェイス形式で送受信する複数のサービスサーバ（２）とに情報通信回線を通じて接続された中継システム（３）により，前記クライアント端末（１）と前記複数のサービスサーバ（２）の間で，前記命令情報と前記回答情報の送受信を中継する方法であって，
   前記共通インターフェイス形式及び前記個別インターフェイス形式は，共にＸＭＬ形式であって，タグ構造が異なるものであり，
   前記中継システム（３）は，
   前記複数のサービスサーバ（２）のそれぞれと通信可能な複数の個別インターフェイス形式と共に，当該複数の個別インターフェイス形式のそれぞれについて，前記共通インターフェイス形式の共通タグにより記述された情報を，前記個別インターフェイスの個別タグにより記述された命令情報へと分割するためのルールを記憶しているインターフェイスデータベース（以下，ＩＦＤＢ）（３２）を有しており，
   前記中継システム（３）が，
   前記クライアント端末（１）から送信された前記共通インターフェイス形式の１つの共通タグにより記述された複数の命令情報を，受信する受信工程と，
   前記ＩＦＤＢ（３２）を参照し，前記受信工程で受信した前記共通インターフェイス形式の１つの共通タグにより記述された複数の命令情報を，当該複数の命令情報を前記サービスサーバ（２）にすべて伝達するのに必要な，前記個別インターフェイス形式の複数の個別タグにより記述された複数の命令情報に分解する第１変換工程と，
   前記第１変工程で得られた前記個別タグにより記述された複数の命令情報を，前記サービスサーバ（２）に順次送信すると共に，当該個別タグにより記述された複数の命令情報のそれぞれに対する複数の回答情報を，前記個別インターフェイス形式の複数の個別タグにより記述された複数の情報として，当該サービスサーバ（２）から受信する通信工程と，
   前記ＩＦＤＢ（３２）を参照し，前記１つの共通タグにより記述された複数の命令情報のそれぞれに対する複数の回答情報のすべてが前記メモリ（３７）に蓄積された後に，前記複数の回答情報に関する複数の個別タグをまとめて，前記共通インターフェイス形式の１つの共通タグに結合する第２変換工程と，
   記第２変換工程で得られた前記共通インターフェイス形式の１つの共通タグにより記述された回答情報を，前記クライアント端末（１）へ送信する送信工程と，を行う
   方法。

Images