データ通信システム、端末、カタログサーバ、データ通信方法、および通信プログラム
【課題】端末における処理量を増大させずに、メッセージのデータ量の削減を実現するデータ通信システムを提供する。
【解決手段】本発明に係るデータ通信システム１は、複数の端末２がネットワーク４を通じて相互に通信するデータ通信システムであって、端末は、ネットワークを通じて他の端末と通信する送受信部１１と、カタログ識別子３１と関連づけた共通パラメータ３２を記憶するカタログ格納部１６と、通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信する１４メッセージ生成部とを有することを特徴とする。
【解決手段】本発明に係るデータ通信システム１は、複数の端末２がネットワーク４を通じて相互に通信するデータ通信システムであって、端末は、ネットワークを通じて他の端末と通信する送受信部１１と、カタログ識別子３１と関連づけた共通パラメータ３２を記憶するカタログ格納部１６と、通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信する１４メッセージ生成部とを有することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを用いたデータ通信システムに関し、特に通信開始時に端末間でやり取りするメッセージデータ量を削減する方法に関する。
【背景技術】
【０００２】
ユビキタス技術における大きな研究テーマの一つに、いわゆるセンサネットワークがある。センサネットワークとは、センサ（たとえば温度、湿度、振動、加速度、位置、音声など）を備える複数の端末（以下センサ端末という）を無線ネットワーク化して、各々のセンサからの情報をもとに特定範囲の状況を総合的に判断しようという技術である。様々な分野で、センサネットワークの応用が期待されている。
【０００３】
センサ端末は、無線ネットワークに参加できるよう、センサと共にプロセッサ、メモリ、無線モジュールなどのような、ごく簡単なコンピュータ資源（以後リソースという）を備える。センサネットワークを導入するには、膨大な数のセンサ端末を設置してネットワーク化する必要があるため、業務及び生活支援システムを構築する上ではセンサ端末のコストが全体のコストに対し大きな割合を占めることとなる。したがってセンサ端末は、コストを低減するために、搭載されるリソースを可能な限り削減する必要がある。
【０００４】
一方、センサ端末がデータ通信を行うためには、センサ端末間、もしくはセンサ端末とホストコンピュータなどとの間でシグナリングを実施し、特定の通信プロトコルにおいて要求される通信パラメータを交換する必要がある。しかしながら、ＳＩＰ（Session Initiation Protocol）などのような既存の通信プロトコルは、リソースを潤沢に備える高性能な端末、たとえばパーソナルコンピュータやワークステーションなどを前提として開発されている。
【０００５】
このため、従来のセンサ端末においては、既存の通信プロトコルによって通信を行うことに堪えられるリソースを確保する必要があったので、リソースを削減してコストを削減することには限界があった。センサ端末のコストを削減するには、リソースを削減された端末においても処理できるように、シグナリングにおいてデータ量および処理量を削減する必要がある。
【０００６】
一方、シグナリングにおいて端末が交換するメッセージのデータ量を削減する技術が、以下に示す非特許文献１および２、特許文献1および２で開示されている。
【０００７】
非特許文献１では、メッセージのヘッダ圧縮技術であるＲＯＨＣ(Robust Header Compression)アルゴリズムについて記載されている。ＲＯＨＣアルゴリズムでは、メッセージ内のデータを、通常変化しない部分（静的部分）、変化する部分（動的部分）、さらには動的部分の中でも前後のメッセージでシーケンシャルに増加するといった規則性を持って変化する部分に分け、送信メッセージにはひとつ前のメッセージとの差分情報をデータとして持たせる。次に受信側では前記受信したメッセージとひとつ前のメッセージを参照し、メッセージの伸長処理を実施する。上記を基本アプローチとしてヘッダサイズを圧縮することによりメッセージのデータ量を削減する。
【０００８】
非特許文献２では、ＳＩＰ（Session Initiation Protocol）等のテキストベースのシグナリングプロトコルによって生成されたヘッダ及びペイロードを含むメッセージ全体を圧縮するSigComp（Signaling Compression）アルゴリズムについて記載されている。SigCompアルゴリズムでは、テキスト形式のプロトコルを、送信側がバイナリ形式に圧縮する。次に受信側で、圧縮されたバイナリ形式のメッセージをテキスト形式に復元する。このようにメッセージサイズを圧縮することによってメッセージのデータ量を削減する。
【０００９】
特許文献１では、センサネットワークにおけるセンサ端末から業務サーバに対して送信するデータ量を削減する方法について記載されている。センサ端末が複数の数値データを送信する場合、該複数の数値データから基本データを抽出する。次に、抽出した基本データとそれぞれの数値データとの差分値を計算する。そして、計算した差分値を業務サーバに送信する。これによって、業務サーバが受信するデータ量を削減する。
【００１０】
特許文献２では、トラフィック全体におけるヘッダ領域の占める割合を低減しメッセージデータ量を削減する方法について記載されている。送信側は複数データをまとめて送信できる場合には、ヘッダを共通化して送信することにより、ヘッダ付与回数が減って、トラフィック内のオーバヘッドサイズを低減する。
【００１１】
【非特許文献１】Lars-Erik Jonsson、「RFC 4163: RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression」、［online］、平成１７年８月、IETF、［平成１９年９月１１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc4163.txt＞
【非特許文献２】M. Garcia-Martin他、「RFC 3485: The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)」、［online］、平成１５年２月、IETF、［平成１９年９月１１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc3485.txt＞
【特許文献１】特開２００４−３２１７６号公報
【特許文献２】特開平１１−１８７０６８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
非特許文献１および２、特許文献1および２で示される方法では、いずれもメッセージのデータを圧縮することによって、シグナリングにおいて端末が交換するメッセージのデータ量を削減している。しかし、シグナリングを行う端末においては、通常のシグナリング処理に加えて、メッセージの圧縮および解凍の処理が必要となるので、処理量はかえって増大する。前述のセンサ端末にこれらの技術を適用しても、データ量は削減しても処理量が増大しているので、リソースを削減することができない。
【００１３】
そこで本発明の目的は、端末における処理量をほとんど増大させずに、メッセージのデータ量の削減を実現する、データ通信システム、端末、カタログサーバ、データ通信方法、および通信プログラムを提供することにある。
【課題を解決するための手段】
【００１４】
上記目的を達成するため、本発明に係るデータ通信システムは、複数の端末がネットワークを通じて相互に通信するデータ通信システムであって、端末は、ネットワークを通じて他の端末と通信する第１の送受信部と、カタログ識別子と関連づけた共通パラメータを記憶する第１のカタログ格納部と、通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信する第１のメッセージ生成部とを有することを特徴とする。
【００１５】
上記目的を達成するため、本発明に係る端末は、他の端末とネットワークを通じて相互に通信可能な端末であって、ネットワークを通じて他の端末と通信する送受信部と、カタログ識別子と関連づけた共通パラメータを記憶するカタログ格納部と、通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信するメッセージ生成部とを有することを特徴とする。
【００１６】
上記目的を達成するため、本発明に係るカタログサーバは、複数の端末および単数もしくは複数のカタログサーバがネットワークを通じて相互に通信するデータ通信システムにあって使用されるカタログサーバであって、ネットワークを通じて他の端末と通信し、端末が共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを受信する送受信部と、共通パラメータリストに対してカタログ識別子を発行するメッセージ処理部と、共通パラメータリストに記載された共通パラメータをカタログ識別子に対応づけて格納するカタログ格納部と、カタログ識別子を端末に返信するメッセージ生成部とを有することを特徴とする。
【００１７】
上記目的を達成するため、本発明に係るデータ通信方法は、第１のカタログ格納部を有する複数の端末がネットワークを通じて相互に通信するデータ通信システムにあってデータ通信を行う方法であって、端末が他の端末に送信する通信データを生成するデータ生成工程と、端末がカタログ識別子と関連づけた共通パラメータを第１のカタログ格納部から検索するカタログ検索工程と、端末が通信データに含まれる共通パラメータをカタログ識別子によって置換する第１の置換工程と、端末が置換された通信データを他の端末に送信する送信工程とを有することを特徴とする。
【００１８】
上記目的を達成するため、本発明に係る通信プログラムは、他の端末とネットワークを通じて相互に通信可能で第１のカタログ格納部を有する端末にあって、端末が備えるコンピュータに、他の端末に送信する通信データを生成する機能と、カタログ識別子と関連づけた共通パラメータを第１のカタログ格納部から検索する機能と、通信データに含まれる共通パラメータをカタログ識別子によって置換する機能と、置換された通信データを他の端末に送信する機能とを実行させることを特徴とする。
【００１９】
上記目的を達成するため、本発明に係る他の通信プログラムは、複数の端末および単数もしくは複数のカタログサーバとネットワークを通じて相互に通信可能で第２のカタログ格納部を有するカタログサーバにあって、カタログサーバが備えるコンピュータに、端末から共通パラメータリストを受信する機能と、共通パラメータリストに対してカタログ識別子を発行する機能と、共通パラメータリストに記載された共通パラメータをカタログ識別子に対応づけて第２のカタログ格納部に格納する機能と、カタログ識別子を端末に返信する機能とを実行させることを特徴とする。
【発明の効果】
【００２０】
本発明は、上記したように通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信するように構成したので、単純な置換処理によってデータ量を削減することができる。これによって、端末における処理量を増大させずに、メッセージのデータ量の削減を実現する、従来にない優れたデータ通信システム、端末、カタログサーバ、データ通信方法、および通信プログラムを提供することができる。
【発明を実施するための最良の形態】
【００２１】
図１は、本発明の実施の形態に係るデータ通信システム１のネットワーク構成を示す概念図である。データ通信システム１は、端末２ａとカタログサーバ３ａ、端末２ｂとカタログサーバ３ｂとがそれぞれ接続され、カタログサーバ３ａとカタログサーバ３ｂとがネットワーク４を介して接続されている。ここで、端末２ａと端末２ｂは同一の構成を有するので、これらを総称して端末２という。同様に、カタログサーバ３ａとカタログサーバ３ｂも同一の構成を有するので、これらを総称してカタログサーバ３という。
【００２２】
図１は、本発明の概念をわかりやすくするために、２台ずつの端末２とカタログサーバ３とを記載したに過ぎない。端末２とカタログサーバ３は１対１で接続される必要はなく、たとえば複数の端末２に１台のカタログサーバ３が接続されていてもよい。また一つのネットワーク４の中にカタログサーバ３は２台に限定されることはなく、１台以上であれば何台あってもよい。端末２とカタログサーバ３との間の接続は、無線であっても有線であってもよい。
【００２３】
図２は、図１で開示した端末２の構成を示すブロック図である。端末２は、ごく簡単なリソースを備えた低コストなものとすることができる。また、端末２が交換する対象となる情報を検知するセンサなどのハードウェアについては、それ自体が本発明の対象には含まれず、またセンサ端末に用途が限定されるものでもないので、記載を省略している。
【００２４】
端末２は、主制御部１０と、共通パラメータリスト格納部１５と、カタログ格納部１６と、通信モジュール１７とを有する。主制御部１０はＣＰＵ、ＲＡＭ、およびＯＳなどで構成されたコンピュータの主要部であり、その上で動作するプログラムとして構成された送受信部１１、メッセージ解析部１２、メッセージ処理部１３、およびメッセージ生成部１４を実行することができる。
【００２５】
送受信部１１は、通信モジュール１７を制御して、ネットワーク４を介してメッセージを送受信する。送受信部１１は、ネットワーク４から到着した自端末宛のメッセージを受信しメッセージ解析部１２へ転送し、またメッセージ生成部１４において生成したメッセージをネットワーク４へ送信する。通信モジュール１７は、無線通信であっても有線通信であってもよい。
【００２６】
メッセージ解析部１２は、送受信部１１が受信したメッセージを構文解析して、メッセージ種別を識別し、通信パラメータを取得する。受信したメッセージに後述するカタログ識別子が含まれている場合は、カタログ格納部１６から該カタログ識別子に対応する通信パラメータを取得する。次に取得したメッセージ種別と通信パラメータとをメッセージ処理部１３へ通知する。
【００２７】
メッセージ処理部１３は、メッセージ解析部１２が取得したメッセージ種別と通信パラメータに基づいてシグナリング処理を行う。シグナリング処理の結果、応答メッセージあるいは新たなメッセージを送信する必要がある場合、メッセージ生成部１４へ送信メッセージのメッセージ種別と通信パラメータとを通知する。その際、通信パラメータについては、共通パラメータリスト格納部１５とカタログ格納部１６を参照して、後述するようにカタログ化できる通信パラメータを対応するカタログ識別子に置き換えて通知する。
【００２８】
メッセージ生成部１４は、メッセージ処理部１３から通知されたメッセージ種別と通信パラメータに従ってメッセージを生成し、生成されたメッセージを送受信部１１へ通知して送信させる。
【００２９】
共通パラメータリスト格納部１５は、共通パラメータとして扱う通信パラメータのリストを格納する。カタログ格納部１６は、カタログ識別子と該カタログ識別子に対応する通信パラメータとを格納する。共通パラメータリスト格納部１５およびカタログ格納部１６が格納する情報の内容については後述する。
【００３０】
図３は、図１で開示したカタログサーバ３の構成を示すブロック図である。カタログサーバ３は、端末２と違って、潤沢なリソースを備えた高性能のものとすることができる。ただし、カタログサーバ３の内部構成は、端末２のそれと同一であり、ただ各部分の性能に違いがあるというだけである。従って、同一の部分には同一の参照番号を付して、説明を省略する。
【００３１】
図４は、図２〜３で開示した端末２およびカタログサーバ３内部の共通パラメータリスト格納部１５が格納するデータの構成を示す概念図である。共通パラメータリスト格納部１５は、異なる端末に対しても常に同じ値を使用できる通信パラメータのリストである共通パラメータリスト２１と、特定のセッションあるいはダイアログなどのような限られた期間内でのみ同じ値を使用できる通信パラメータのリストである一時共通パラメータリスト２２とを格納する。
【００３２】
図５は、図２〜３で開示した端末２およびカタログサーバ３内部のカタログ格納部１６が格納するデータの構成を示す概念図である。カタログ格納部１６は、カタログ識別子３１と、カタログ識別子３１が示すカタログにおいて使用される共通パラメータ３２と一時共通パラメータ３３とを格納する。これらの内容および動作については後述する。
【００３３】
図６は、図１で開示したデータ通信システム１における通信の手順を示すシーケンス図である。図７は図２で開示した端末２における処理の内容を示すフローチャートである。図８は図３で開示したカタログサーバ３における処理の内容を示すフローチャートである。
【００３４】
図６で、端末２ａはカタログサーバ３ａに接続されると、まずカタログサーバ３ａに共通パラメータを登録するためのカタログ登録要求１０１ａを送信する。これを受けたカタログサーバ３ａは、端末２ａにカタログ登録要求応答１０２ａを返信する。同様に端末２ｂとカタログサーバ３ｂの間でも、端末２ｂがカタログサーバ３ｂにカタログ登録要求１０１ｂを送信し、これを受けたカタログサーバ３ｂは端末２ｂにカタログ登録要求応答１０２ｂを返信する。
【００３５】
図７（ａ）は、図６にＳ１として示される、端末２内部におけるカタログ登録要求１０１ａおよびカタログ登録要求応答１０２ａにまつわる処理を示す。起動すると（Ｓ２０１）、メッセージ生成部１４が共通パラメータリスト格納部１５に保持される共通パラメータリスト２１を参照して、カタログ登録要求１０１ａを作成し（Ｓ２０２）、送受信部１１がカタログ登録要求１０１ａをカタログサーバ３に送信する（Ｓ２０３）。
【００３６】
続いて送受信部１１がカタログサーバ３からのカタログ登録要求応答１０２ａを待ち（Ｓ２０４）、カタログ登録要求応答１０２ａを受信すれば、メッセージ解析部１２がカタログ登録要求応答１０２ａに記述されたカタログ識別子３１と共通パラメータ３２を抽出し、メッセージ処理部１３が抽出されたカタログ識別子３１と共通パラメータ３２をカタログ格納部１６に格納して（Ｓ２０５）、処理を終了する（Ｓ２０６）。
【００３７】
図８（ａ）は、図６にＳ２として示される、カタログサーバ３内部におけるカタログ登録要求１０１ａおよびカタログ登録要求応答１０２ａにまつわる処理を示す。起動すると（Ｓ３０１）、送受信部１１がカタログ登録要求１０１ａを受信し（Ｓ３０２）、メッセージ処理部１３がシステム内で一意となるカタログ識別子３１を発行し（Ｓ３０３）、発行されたカタログ識別子３１と、メッセージ解析部１２によって抽出されたカタログ登録要求１０１ａに記述される共通パラメータ３２を、カタログ格納部１６に格納する（Ｓ３０４）。
【００３８】
続いてメッセージ生成部１４が、カタログ識別子３１と共通パラメータ３２を含むカタログ登録要求応答１０２ａを生成して、送受信部１１を介して端末２に送信させ（Ｓ３０５）、処理を終了する（Ｓ３０６）。
【００３９】
なお、Ｓ３０３で新規にカタログ識別子３１を発行したカタログサーバ３は、カタログ識別子３１とそれに対応する共通パラメータ３２および一時共通パラメータ３３を含んだ新規カタログ情報１０３を他のカタログサーバ３へ通知する。これによって、カタログサーバ間の情報の同期を取ることができ、端末２ａがカタログ登録要求１０１ａに含めた共通パラメータ３２がすべてのカタログサーバ３に登録されたことになる。これを、カタログ登録が完了したという。これ以降のメッセージのやり取りでは、すべての端末２は共通パラメータ３２をカタログ識別子３１に置き換えて通信することができる。
【００４０】
続いて、端末２ａが端末２ｂに対してセッションの確立を要求し、これによって端末２ａと端末２ｂとの間でセッションを確立してデータ通信が可能な状態になるまでの処理について説明する。図６で、端末２ａは端末２ｂに向けてのセッション確立要求１０４を発行する。端末２ａから送信されたセッション確立要求１０４は、まずカタログサーバ３ａが受ける。
【００４１】
図８（ｂ）は、図６にＳ４として示される、カタログサーバ３ａ内部におけるセッション確立要求１０４にまつわる処理を示す。起動すると（Ｓ３１１）、送受信部１１がセッション確立要求１０４を受信し（Ｓ３１２）、セッション確立要求１０４がカタログ識別子３１を使ったメッセージであるか否かをメッセージ解析部１２が判断する（Ｓ３１３）。カタログ識別子３１を使ったメッセージであれば、メッセージ解析部１２は、共通パラメータリスト格納部１５に保持された一時共通パラメータリスト２２に一致する一時共通パラメータ３３をカタログ格納部１６に格納して（Ｓ３１４）、Ｓ３１５に進む。この一時共通パラメータ３３は、カタログ識別子３１に対応した一時共通パラメータ３３として格納される。
【００４２】
Ｓ３１３でセッション確立要求１０４がカタログ識別子を使ったメッセージでなければ、そのままＳ３１５に進む。そしてメッセージ生成部１４は、受け取ったセッション確立要求１０４を、そのまま送受信部１１を介して端末２ｂに転送し（Ｓ３１５）、処理を終了する（Ｓ３１６）。転送されたセッション確立要求１０４は、カタログサーバ３ｂにおいて特に何もされず、そのまま端末２ｂに送られる。
【００４３】
図７（ｂ）は、図６にＳ３として示される、端末２ｂ内部におけるセッション確立要求１０４にまつわる処理を示す。起動すると（Ｓ２１１）、送受信部１１がセッション確立要求１０４を受信し（Ｓ２１２）、セッション確立要求１０４がカタログ識別子３１を使ったメッセージであるか否かをメッセージ解析部１２が判断する（Ｓ２１３）。カタログ識別子３１を使ったメッセージでなければ、後述のＳ２１９に進む。
【００４４】
Ｓ２１３で、セッション確立要求１０４がカタログ識別子３１を使ったメッセージであれば、カタログ識別子３１に対応する共通パラメータ３２および一時共通パラメータ３３の情報（以後カタログ情報という）がカタログ格納部１６に存在するか否かをメッセージ解析部１２が判断する（Ｓ２１４）。カタログ識別子３１に該当するカタログ情報が存在していれば、後述のＳ２１８に進む。
【００４５】
Ｓ２１４で、カタログ識別子３１に該当するカタログ情報が存在していなければ、メッセージ生成部１４がカタログ問合わせ要求１０５を生成し、送受信部１１を介してカタログサーバ３ｂに送信する（Ｓ２１５）。送受信部１１はカタログサーバ３ｂからのカタログ問合わせ要求応答１０６を待つ（Ｓ２１６）。カタログ問合わせ要求応答１０６があれば、メッセージ解析部１２によって抽出されたカタログ問合わせ要求応答１０６に記述されるカタログ情報を、カタログ格納部１６に格納して（Ｓ２１７）、Ｓ２１８に進む。
【００４６】
Ｓ２１８で、メッセージ処理部１３は、カタログ格納部１６でカタログ識別子３１に対応するカタログ情報に含まれる通信パラメータを取得する。そして、取得した通信パラメータによって、シグナリング処理を実施する（Ｓ２１９）。なおＳ２１９で、前述のＳ２１３でカタログ識別子３１を使ったメッセージでなければ、カタログ格納部１６から通信パラメータを取得しなくてもよいので、そのままシグナリング処理を実施する。
【００４７】
続いてメッセージ生成部１４がセッション確立要求応答１０７を生成して送受信部１１を介して端末２ａに送信し（Ｓ２２０）、生成したセッション確立要求応答１０７から、共通パラメータリスト格納部１５に保持された一時共通パラメータリスト２２に一致する一時共通パラメータ３３を、メッセージ解析部１２はカタログ識別子３１に対応した一時共通パラメータ３３としてカタログ格納部１６に格納して（Ｓ２２１）、処理を終了する（Ｓ２２１）。
【００４８】
図８（ｃ）は、図６にＳ５として示される、カタログサーバ３ｂ内部におけるカタログ問合わせ要求１０５にまつわる処理を示す。起動すると（Ｓ３２１）、送受信部１１がカタログ問合わせ要求１０５を受信し（Ｓ３２２）、メッセージ解析部１２がカタログ問合わせ要求１０５からカタログ識別子３１を抽出し、メッセージ処理部１３が抽出されたカタログ識別子３１に対応するカタログ情報をカタログ格納手段２６から取得する（Ｓ３２３）。そしてメッセージ生成部１４が、取得されたカタログ情報を含んだカタログ問合わせ要求応答１０６を作成して送受信部１１を介して端末２ｂに送信し（Ｓ３２４）、処理を終了する（Ｓ３２５）。
【００４９】
端末２ｂがセッション確立要求１０４に対するシグナリング処理を完了すると、セッション確立要求応答１０７を端末２ａ宛に返信する。このセッション確立要求応答１０７は、カタログサーバ３ｂを介してカタログサーバ３ａに送られる。カタログサーバ３ａでは、このセッション確立要求応答１０７に対しても、図８の（ｂ）として示したものと同一の処理を行い、一時共通パラメータ３３を取得してカタログ格納部１６へ登録する。ここでは、端末２ｂによって新たに追加された通信パラメータに対して一時共通パラメータ３３の登録処理を行う。この処理は図６にＳ６として示されているが、処理の内容は図８の（ｂ）と同一であるので説明を省略する。この処理が終了したら、カタログサーバ３ａはセッション確立要求応答１０７をそのまま端末２ａに転送する。
【００５０】
図７（ｃ）は、図６にＳ７として示される、端末２ａにおけるセッション確立要求応答１０７にまつわる処理を示す。起動すると（Ｓ２３１）、送受信部１１がセッション確立要求応答１０７を受信し（Ｓ２３２）、メッセージ解析部１２がセッション確立要求応答１０７から抽出した通信パラメータの中で、共通パラメータリスト格納部１５において保持される一時共通パラメータリスト２２に記載された通信パラメータを、メッセージ処理部１３が一時共通パラメータ３３としてカタログ格納部１６に格納する（Ｓ２３３）。そしてセッション確立要求応答１０７に対して通常のシグナリング処理を行い、確認応答メッセージ１０８を端末２ｂに返信し（Ｓ２３４）、処理を終了する（Ｓ２３５）。
【００５１】
確認応答メッセージ１０８は、カタログサーバ３ａおよびカタログサーバ３ｂを介して、そのまま端末２ｂに送られる。以上で端末２ａと端末２ｂとの間でのセッション確立が完了する。セッション確立の完了により、一時共通パラメータはカタログ情報としてカタログサーバ３ａおよびカタログサーバ３ｂに登録される。同一セッションあるいはダイアログ内における以降のメッセージのやり取りでは、共通パラメータに加えて一時共通パラメータについてもカタログ識別子に置き換えて通信できる。
【００５２】
図９は、図６で開示した通信の手順を、具体的なプロトコルにおいて実施する例を示すシーケンス図である。ここでは、ＳＩＰ（Session Initiation Protocol）に本発明を適用した場合について説明する。ＳＩＰはＩＥＴＦ（Internet Engineering Task Force）において標準化されている（RFC3261）シグナリングプロトコルの1つであり、主なアプリケーションの１つとしてＶｏＩＰ（Voice over Internet Protocol）がある。システムの構成および処理手順は、ここまでで説明したものと同一である。カタログサーバ３は、ＳＩＰにおけるプロキシサーバと同一装置に実装してもよい。
【００５３】
図１０は、図９において端末２ａがカタログサーバ３ａに送信するカタログ登録要求１０１ａおよびカタログサーバ３ａが端末２ａに返信するカタログ登録要求応答１０２ａの例である。端末２ａは、カタログ登録要求１０１ａとして、図１０（ａ）に示すREGISTERメッセージ４００をカタログサーバ３ａに送信する。
【００５４】
REGISTERメッセージ４００は、ＳＩＰにおける通常のリクエストと同様に、リクエスト４０１とヘッダ４０２の後に、１行の空行をおいてボディ４０３という形式で構成される。リクエスト４０１は、リクエストの種類（メソッド）を示す「REGISTER」と、リクエストの宛先となるカタログサーバ３ａを示す「sip:LS1.aaa.net」、そしてＳＩＰのバージョンを示す「SIP/x.0」とからなる。ヘッダ４０２は、ＳＩＰにおける通常のリクエストと同様に、Via、Max-Forwards、From、To、Call-ID、CSeq、Contact、Content-Type、Content-Lengthといった各行が示されている。これらについての詳しい説明は、当業者には公知であるので省略する。
【００５５】
ボディ４０３には、端末２ａがカタログ登録しようとしている共通パラメータ３２が記述される。ここで記述されるのは、ヘッダの中で共通して使われる情報、およびＳＤＰ（Session Description Protocol）を用いてＳＩＰボディ部分に記述されるセッション情報の一部である。ここで記載された各々のパラメータを共通パラメータ３２として扱うかどうかは、カタログサーバ３ａ側の共通パラメータリスト格納部１５に格納される共通パラメータリスト２１を参照して決定する。
【００５６】
また、1行に複数通信パラメータが含まれ、該当行に含まれる通信パラメータの一部が共通パラメータでない場合には、「＊」などの略記号に置き換え非共通パラメータ部分であることを明示する。図１０（ａ）の例では、セッションを識別するための情報を示すタイプであるｏ＝行４０４に、非共通パラメータ部分を示す「＊」が含まれる。略記号に置き換えられた通信パラメータについては、メッセージ送信の度に値が記述される。
【００５７】
ヘッダの中で使われるVia行４０６、From行４０７、およびContact行４０８も、非共通パラメータ部分を示す「＊」を含むが、共通パラメータリスト２１に含まれるので、ここでは共通パラメータ３２として登録される。
【００５８】
セッションの開始および終了の時刻を示すタイプであるｔ＝行４０５は、共通パラメータリスト２１に含まれないので、共通パラメータ３２として登録されない。その他のパラメータを示すｖ＝行、ｓ＝行、ｃ＝行、ｍ＝行、ａ＝行は、共通パラメータリスト２１に含まれるので、共通パラメータ３２として登録される。
【００５９】
REGISTERメッセージ４００を受信したカタログサーバ３ａは、メッセージ処理部１３において、ボディ４０３に記述された共通パラメータ３２に対してカタログ識別子３１を発行し、図８の（ａ）（図６および図９のＳ２）として示した処理を実行する。ここでは「xxx@aaa.net」というカタログ識別子３１が発行されている。次にカタログサーバ３ａは、端末２ａに対して、カタログ登録要求応答１０２ａとして、図１０（ｂ）に示す２００ ＯＫレスポンス（以後、単にＯＫレスポンスという）４１０を返信する。ＯＫレスポンス４１０は、ＳＩＰにおける通常のレスポンスと同様に、ステータス４１１とヘッダ４１２という形式で構成される。ここではボディは無い。
【００６０】
ステータス４１１は、ＳＩＰのバージョンを示す「SIP/x.0」と、ステータスを表す「200 OK」とからなる。ヘッダ４１２は、ＳＩＰにおける通常のリクエストと同様のVia、From、To、Call-ID、CSeq、Contact、Expires、Content-Lengthといった各行に加えて（やはりこれらも、当業者には公知であるので詳しい説明は省略する）に加えて、発行されたカタログ識別子３１を示すCatalog-ID行４１３が含まれる。
【００６１】
ＯＫレスポンス４１０を受信した端末２ａは、図７の（ａ）（図６および図９のＳ１）として示した処理によって、カタログ識別子３１とそれに対応するカタログ情報をカタログ格納部１６へ格納する。以上で、カタログ登録が完了する。
【００６２】
図１１は、図９において端末２ａが端末２ｂに送信するセッション確立要求１０４および端末２ｂが端末２ａに返信するセッション確立要求応答１０７の例である。端末２ａは、セッション確立要求１０４として、図１１（ａ）に示すINVITEメッセージ４２０を端末２ｂに送信する。
【００６３】
INVITEメッセージ４２０は、ＳＩＰにおける通常のリクエストと同様に、リクエスト４２１とヘッダ４２２の後に、１行の空行をおいてボディ４２３という形式で構成される。リクエスト４２１は、リクエストの種類（メソッド）を示す「INVITE」と、リクエストの宛先となるＵＲＩを示す「sip:UserB@bbb.net」、そしてＳＩＰのバージョンを示す「SIP/x.0」とからなる。ヘッダ４２２は、REGISTERメッセージ４００のヘッダ４０２と同様の各行に加えて、前述のカタログ識別子３１を示すCatalog-ID行４２４が含まれる。
【００６４】
ここで、端末２ａがメッセージを生成する際、メッセージ生成部１４は共通パラメータリスト格納部１５に保持される共通パラメータリスト２１を参照し、共通パラメータ３２に関して行ごと省略するか、もしくは「＆」などのような略記号に置き換えて、ボディ４２３に記述する。
【００６５】
特に「＊」などの略記号に置き換えられた非共通パラメータ部分を含む共通パラメータ３２については、「＊」に該当する部分について数値などを記述し、それ以外の部分は「＆」などのような略記号に置き換える。
【００６６】
図１１（ａ）の例では、ボディ４２３のｏ＝行４２５に、非共通パラメータ部分を示す「＊」が２個含まれて共通パラメータ３２として登録されているので、ここでは＊に該当する数値２つと、それ以外の部分を示す略記号「＆」を記述する。ｔ＝行４２６は、共通パラメータリスト２１に含まれないので、そのまま記述する。ボディ４２３において、これ以外のパラメータ（ｖ＝行、ｓ＝行、ｃ＝行、ｍ＝行、ａ＝行）は、すべて共通パラメータリスト２１に含まれ、かつ非共通パラメータ部分もないので、行ごと省略する。
【００６７】
また、ヘッダ４２２においても、Via行４０６およびFrom行４０７が非共通パラメータ部分を示す「＊」を含む共通パラメータ３２として既に登録されているので、ここではVia行４２７およびFrom行４２８は、共通パラメータ３２の＊に該当する部分のみを記述し、それ以外の部分は略記号「＆」で記述するようにする。Contact行４０８は丸ごと共通パラメータ３２として既に登録されているので、ヘッダ４２２においては省略する。ちなみにMax-Forward行４２９は、そのまま記載する（共通パラメータ３２にはMax-Forwards行４０９が登録されているが、Max-Forward行４２９は共通パラメータ３２に該当しないので）。
【００６８】
INVITEメッセージ４２０を受信したカタログサーバ３ａは、図８（ｂ）（図６および図９のＳ４）に示した処理によって、INVITEメッセージ４２０に含まれる一時共通パラメータ３３を抽出してカタログ格納部１６に格納し、受信したINVITEメッセージ４２０自体には特に何もせずに端末２ｂに転送する。一時共通パラメータ３３の例としては、ヘッダ４２２のFrom行４２８内部のtag、およびCall-ID行のように同一ダイアログ内で同じ値が複数メッセージにおいて使用される通信パラメータが挙げられる。
【００６９】
カタログサーバ３ｂを経由してINVITEメッセージ４２０を受信した端末２ｂは、図７（ｂ）（図６および図９のＳ３）に示した処理を行い、端末２ａにセッション確立要求応答１０７として図１１（ｂ）に示すＯＫレスポンス４３０を返信する。ＯＫレスポンス４３０は、図１０（ｂ）に示したＯＫレスポンス４１０と同様のステータス４３１とヘッダ４３２に加えて、１行の空行をおいてボディ４３３という形式で構成される。ヘッダにはCatalog-ID行４３４が、ＯＫレスポンス４１０と同様に含まれる。ボディ４３３は、端末２ａと端末２ｂとの間で確立された通信条件を示すＳＤＰによって記述されるセッション情報である。これらも、当業者には公知であるので詳しい説明は省略する。
【００７０】
図１２は、図９において端末２ｂがカタログサーバ３ｂに送信するカタログ問合わせ要求１０５およびカタログサーバ３ｂが端末２ｂに返信するカタログ問合わせ要求応答１０６の例である。端末２ｂは、カタログ問合わせ要求１０５として、図１２（ａ）に示すOPTIONSメッセージ４４０をカタログサーバ３ｂに送信する。
【００７１】
OPTIONSメッセージ４４０は、ＳＩＰにおける通常のリクエストと同様に、リクエスト４４１とヘッダ４４２とで構成されるが、ここではボディは無い。リクエスト４４１は、リクエストの種類（メソッド）を示す「OPTIONS」と、リクエストの宛先となるＵＲＩを示す「sip:ls1@bbb.net」、そしてＳＩＰのバージョンを示す「SIP/x.0」とからなる。ヘッダ４４２は、INVITEメッセージ４２０のヘッダ４２２と同様の各行で構成される。ヘッダ４４２には、カタログ情報問い合わせの対象となるカタログ識別子３１を含むRequest-Catalog-ID行４４４が含まれる。
【００７２】
なお、端末２ｂはカタログサーバ３ｂに対して、あらかじめ図１０（ａ）で示したものと同様のREGISTERコマンドを送信して自らのカタログ情報を登録している。そのため、OPTIONSメッセージ４４０のヘッダ４４２には、端末２ｂが登録したカタログ情報に対応するカタログ識別子を含むCatalog-ID行４４３が含まれ、また前述のINVITEメッセージ４２０と同様に、自らの登録したカタログ情報に基づいてヘッダ４４２の一部を省略している。
【００７３】
OPTIONSメッセージ４４０を受信したカタログサーバ３ｂは、図８（ｃ）（図６および図９のＳ５）に示した処理を行い、端末２ｂにカタログ問合わせ要求応答１０６として図１２（ｂ）に示すＯＫレスポンス４５０を返信する。ＯＫレスポンス４５０は、図１０（ｂ）に示したＯＫレスポンス４１０と同様のステータス４５１とヘッダ４５２に加えて、１行の空行をおいてボディ４５３という形式で構成される。ヘッダにはCatalog-ID行４５４とRequest-Catalog-ID行４５５とが、ＯＫレスポンス４１０と同様に含まれる。ボディ４５３は、OPTIONSメッセージ４４０のRequest-Catalog-ID行４４４に含まれるカタログ識別子３１に対応するカタログ情報が、REGISTERメッセージ４００のボディ４０３と同様の形で記述されている。
【００７４】
端末２ｂは、カタログサーバ３ｂにOPTIONSメッセージ４４０を送信してカタログ情報を得ることにより、Request-Catalog-ID行４５５に含まれるカタログ識別子３１に対応するカタログ情報を取得して、カタログ格納部１６に格納することができる。これにより、端末２ａの共通パラメータ３２についての情報を得ることができるので、データ量が大幅に削減されたINVITEメッセージ４２０に対しても通信パラメータを解釈して、通常のINVITEメッセージと同様にシグナリング処理を行うことができる。
【００７５】
ＯＫレスポンス４３０（セッション確立要求応答１０７）を受けた端末２ａは、図７（ｃ）（図６および図９のＳ７）に示した処理を行い、確認応答メッセージ１０８としてＡＣＫリクエスト４６０を端末２ｂ宛に送信する。ＡＣＫリクエスト４６０、およびＳ７以後の処理は当業者には公知であるので、詳しい説明は省略する。
【００７６】
図１３は、本実施の形態によらない従来の通信システムにおいて、端末が発信する従来のINVITEメッセージ５２０の例である。従来のINVITEメッセージ５２０は、リクエスト５２１とヘッダ５２２の後に、１行の空行をおいてボディ５２３という形式で構成される。
【００７７】
従来のINVITEメッセージ５２０と、図１１（ａ）に示した本実施の形態のINVITEメッセージ４２０とを比較すると、従来のINVITEメッセージ５２０ではボディ５２３に少なくとも７行（図１３では１１行）のパラメータを記述するのに対して、本実施の形態のボディ４２３では２行を記述するだけで済み、１行あたりの記述も少なくなっていることがわかる。また、本実施の形態のヘッダ４２２は、従来のヘッダ５２２と比べてCatalog-ID行４２４が１行加わるが、Via行４２７およびFrom行４２８の一部、さらにContact行の全部が省略されている。従って、従来のINVITEメッセージ５２０と比べて、本実施の形態のINVITEメッセージ４２０のデータ量が大幅に削減されていることは一目瞭然である。
【００７８】
本実施の形態によって、カタログ情報として登録された共通パラメータ３２を適用することにより、ヘッダおよびボディにおいて共通して使われるパラメータを、データサイズの小さなカタログ識別子に置き換えて通信を行うことができる。このため、INVITEメッセージ以外においても、図６〜１２で示したセッション確立の処理が完了すれば、端末が送受信するすべてのメッセージにおいて、これと同じ方法によってデータ量を削減することができる。
【００７９】
また、端末がメッセージを送受信する際の処理は、単純な置換処理によって行うことができるので、複雑なデータの圧縮／伸長処理を必要とはしない。従って、本実施の形態を適用することによる端末における処理量の増大は、ごく僅かである。
【００８０】
以上のように、本実施の形態によって、端末における処理量をほとんど増大させずに、メッセージのデータ量の削減を実現することが可能である。従って、リソースを削減された安価な端末であっても、本実施の形態を容易に実施することができるので、そのような端末のコストダウンに好適な構成を備えていると言える。
【００８１】
なお、図９以降で示したＳＩＰは、一般的によく使用されるプロトコルの一つとして例示したに過ぎない。本発明はこれ以外のプロトコルにおいても利用可能である。また、本発明はリソースを削減された安価な端末での利用に適しているが、端末の種類はセンサネットワークにおけるセンサ端末などに限定されるものではない。たとえば、いわゆるＩＰ電話など、ＳＩＰのアプリケーションの１つであるＶｏＩＰによって音声通信を行う端末においても利用できる。
【００８２】
これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることは言うまでもないことである。
【産業上の利用可能性】
【００８３】
データ通信を行う端末によって構成されるネットワークにおいて利用可能である。プロトコルの種類、および端末やデータの種類は特に限定されない。
【図面の簡単な説明】
【００８４】
【図１】本発明の実施の形態に係るデータ通信システムのネットワーク構成を示す概念図である。
【図２】図１で開示した端末の構成を示すブロック図である。
【図３】図１で開示したカタログサーバの構成を示すブロック図である。
【図４】図２〜３で開示した端末およびカタログサーバ内部の共通パラメータリスト格納部が格納するデータの構成を示す概念図である。
【図５】図２〜３で開示した端末およびカタログサーバ内部のカタログ格納部が格納するデータの構成を示す概念図である。
【図６】図１で開示したデータ通信システムにおける通信の手順を示すシーケンス図である。
【図７】図２で開示した端末における処理の内容を示すフローチャートである。
【図８】図３で開示したカタログサーバにおける処理の内容を示すフローチャートである。
【図９】図６で開示した通信の手順を、具体的なプロトコルにおいて実施する例を示すシーケンス図である。
【図１０】図９において端末がカタログサーバに送信するカタログ登録要求およびカタログサーバが端末に返信するカタログ登録要求応答の例である。
【図１１】図９において端末が他の端末に送信するセッション確立要求およびセッション確立要求応答の例である。
【図１２】図９において端末がカタログサーバに送信するカタログ問合わせ要求およびカタログサーバが端末に返信するカタログ問合わせ要求応答の例である。
【図１３】従来の通信システムにおいて、端末が発信する従来のINVITEメッセージの例である。
【符号の説明】
【００８５】
１ データ通信システム
２、２ａ、２ｂ 端末
３、３ａ、３ｂ カタログサーバ
４ ネットワーク
１０ 主制御部
１２ メッセージ解析部
１３ メッセージ処理部
１４ メッセージ生成部
１５ 共通パラメータリスト格納部
１６ カタログ格納部
２１ 共通パラメータリスト
２２ 一時共通パラメータリスト
３１ カタログ識別子
３２ 共通パラメータ
３３ 一時共通パラメータ
１０１ａ、１０１ｂ カタログ登録要求
１０２ａ、１０２ｂ カタログ登録要求応答
１０３ 新規カタログ情報
１０４ セッション確立要求
１０５ カタログ問合わせ要求
１０６ カタログ問合わせ要求応答
１０７ セッション確立要求応答
１０８ 確認応答メッセージ
【技術分野】
【０００１】
本発明は、ネットワークを用いたデータ通信システムに関し、特に通信開始時に端末間でやり取りするメッセージデータ量を削減する方法に関する。
【背景技術】
【０００２】
ユビキタス技術における大きな研究テーマの一つに、いわゆるセンサネットワークがある。センサネットワークとは、センサ（たとえば温度、湿度、振動、加速度、位置、音声など）を備える複数の端末（以下センサ端末という）を無線ネットワーク化して、各々のセンサからの情報をもとに特定範囲の状況を総合的に判断しようという技術である。様々な分野で、センサネットワークの応用が期待されている。
【０００３】
センサ端末は、無線ネットワークに参加できるよう、センサと共にプロセッサ、メモリ、無線モジュールなどのような、ごく簡単なコンピュータ資源（以後リソースという）を備える。センサネットワークを導入するには、膨大な数のセンサ端末を設置してネットワーク化する必要があるため、業務及び生活支援システムを構築する上ではセンサ端末のコストが全体のコストに対し大きな割合を占めることとなる。したがってセンサ端末は、コストを低減するために、搭載されるリソースを可能な限り削減する必要がある。
【０００４】
一方、センサ端末がデータ通信を行うためには、センサ端末間、もしくはセンサ端末とホストコンピュータなどとの間でシグナリングを実施し、特定の通信プロトコルにおいて要求される通信パラメータを交換する必要がある。しかしながら、ＳＩＰ（Session Initiation Protocol）などのような既存の通信プロトコルは、リソースを潤沢に備える高性能な端末、たとえばパーソナルコンピュータやワークステーションなどを前提として開発されている。
【０００５】
このため、従来のセンサ端末においては、既存の通信プロトコルによって通信を行うことに堪えられるリソースを確保する必要があったので、リソースを削減してコストを削減することには限界があった。センサ端末のコストを削減するには、リソースを削減された端末においても処理できるように、シグナリングにおいてデータ量および処理量を削減する必要がある。
【０００６】
一方、シグナリングにおいて端末が交換するメッセージのデータ量を削減する技術が、以下に示す非特許文献１および２、特許文献1および２で開示されている。
【０００７】
非特許文献１では、メッセージのヘッダ圧縮技術であるＲＯＨＣ(Robust Header Compression)アルゴリズムについて記載されている。ＲＯＨＣアルゴリズムでは、メッセージ内のデータを、通常変化しない部分（静的部分）、変化する部分（動的部分）、さらには動的部分の中でも前後のメッセージでシーケンシャルに増加するといった規則性を持って変化する部分に分け、送信メッセージにはひとつ前のメッセージとの差分情報をデータとして持たせる。次に受信側では前記受信したメッセージとひとつ前のメッセージを参照し、メッセージの伸長処理を実施する。上記を基本アプローチとしてヘッダサイズを圧縮することによりメッセージのデータ量を削減する。
【０００８】
非特許文献２では、ＳＩＰ（Session Initiation Protocol）等のテキストベースのシグナリングプロトコルによって生成されたヘッダ及びペイロードを含むメッセージ全体を圧縮するSigComp（Signaling Compression）アルゴリズムについて記載されている。SigCompアルゴリズムでは、テキスト形式のプロトコルを、送信側がバイナリ形式に圧縮する。次に受信側で、圧縮されたバイナリ形式のメッセージをテキスト形式に復元する。このようにメッセージサイズを圧縮することによってメッセージのデータ量を削減する。
【０００９】
特許文献１では、センサネットワークにおけるセンサ端末から業務サーバに対して送信するデータ量を削減する方法について記載されている。センサ端末が複数の数値データを送信する場合、該複数の数値データから基本データを抽出する。次に、抽出した基本データとそれぞれの数値データとの差分値を計算する。そして、計算した差分値を業務サーバに送信する。これによって、業務サーバが受信するデータ量を削減する。
【００１０】
特許文献２では、トラフィック全体におけるヘッダ領域の占める割合を低減しメッセージデータ量を削減する方法について記載されている。送信側は複数データをまとめて送信できる場合には、ヘッダを共通化して送信することにより、ヘッダ付与回数が減って、トラフィック内のオーバヘッドサイズを低減する。
【００１１】
【非特許文献１】Lars-Erik Jonsson、「RFC 4163: RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression」、［online］、平成１７年８月、IETF、［平成１９年９月１１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc4163.txt＞
【非特許文献２】M. Garcia-Martin他、「RFC 3485: The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)」、［online］、平成１５年２月、IETF、［平成１９年９月１１日検索］、インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc3485.txt＞
【特許文献１】特開２００４−３２１７６号公報
【特許文献２】特開平１１−１８７０６８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
非特許文献１および２、特許文献1および２で示される方法では、いずれもメッセージのデータを圧縮することによって、シグナリングにおいて端末が交換するメッセージのデータ量を削減している。しかし、シグナリングを行う端末においては、通常のシグナリング処理に加えて、メッセージの圧縮および解凍の処理が必要となるので、処理量はかえって増大する。前述のセンサ端末にこれらの技術を適用しても、データ量は削減しても処理量が増大しているので、リソースを削減することができない。
【００１３】
そこで本発明の目的は、端末における処理量をほとんど増大させずに、メッセージのデータ量の削減を実現する、データ通信システム、端末、カタログサーバ、データ通信方法、および通信プログラムを提供することにある。
【課題を解決するための手段】
【００１４】
上記目的を達成するため、本発明に係るデータ通信システムは、複数の端末がネットワークを通じて相互に通信するデータ通信システムであって、端末は、ネットワークを通じて他の端末と通信する第１の送受信部と、カタログ識別子と関連づけた共通パラメータを記憶する第１のカタログ格納部と、通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信する第１のメッセージ生成部とを有することを特徴とする。
【００１５】
上記目的を達成するため、本発明に係る端末は、他の端末とネットワークを通じて相互に通信可能な端末であって、ネットワークを通じて他の端末と通信する送受信部と、カタログ識別子と関連づけた共通パラメータを記憶するカタログ格納部と、通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信するメッセージ生成部とを有することを特徴とする。
【００１６】
上記目的を達成するため、本発明に係るカタログサーバは、複数の端末および単数もしくは複数のカタログサーバがネットワークを通じて相互に通信するデータ通信システムにあって使用されるカタログサーバであって、ネットワークを通じて他の端末と通信し、端末が共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを受信する送受信部と、共通パラメータリストに対してカタログ識別子を発行するメッセージ処理部と、共通パラメータリストに記載された共通パラメータをカタログ識別子に対応づけて格納するカタログ格納部と、カタログ識別子を端末に返信するメッセージ生成部とを有することを特徴とする。
【００１７】
上記目的を達成するため、本発明に係るデータ通信方法は、第１のカタログ格納部を有する複数の端末がネットワークを通じて相互に通信するデータ通信システムにあってデータ通信を行う方法であって、端末が他の端末に送信する通信データを生成するデータ生成工程と、端末がカタログ識別子と関連づけた共通パラメータを第１のカタログ格納部から検索するカタログ検索工程と、端末が通信データに含まれる共通パラメータをカタログ識別子によって置換する第１の置換工程と、端末が置換された通信データを他の端末に送信する送信工程とを有することを特徴とする。
【００１８】
上記目的を達成するため、本発明に係る通信プログラムは、他の端末とネットワークを通じて相互に通信可能で第１のカタログ格納部を有する端末にあって、端末が備えるコンピュータに、他の端末に送信する通信データを生成する機能と、カタログ識別子と関連づけた共通パラメータを第１のカタログ格納部から検索する機能と、通信データに含まれる共通パラメータをカタログ識別子によって置換する機能と、置換された通信データを他の端末に送信する機能とを実行させることを特徴とする。
【００１９】
上記目的を達成するため、本発明に係る他の通信プログラムは、複数の端末および単数もしくは複数のカタログサーバとネットワークを通じて相互に通信可能で第２のカタログ格納部を有するカタログサーバにあって、カタログサーバが備えるコンピュータに、端末から共通パラメータリストを受信する機能と、共通パラメータリストに対してカタログ識別子を発行する機能と、共通パラメータリストに記載された共通パラメータをカタログ識別子に対応づけて第２のカタログ格納部に格納する機能と、カタログ識別子を端末に返信する機能とを実行させることを特徴とする。
【発明の効果】
【００２０】
本発明は、上記したように通信データに含まれる共通パラメータをカタログ識別子によって置換して他の端末に送信するように構成したので、単純な置換処理によってデータ量を削減することができる。これによって、端末における処理量を増大させずに、メッセージのデータ量の削減を実現する、従来にない優れたデータ通信システム、端末、カタログサーバ、データ通信方法、および通信プログラムを提供することができる。
【発明を実施するための最良の形態】
【００２１】
図１は、本発明の実施の形態に係るデータ通信システム１のネットワーク構成を示す概念図である。データ通信システム１は、端末２ａとカタログサーバ３ａ、端末２ｂとカタログサーバ３ｂとがそれぞれ接続され、カタログサーバ３ａとカタログサーバ３ｂとがネットワーク４を介して接続されている。ここで、端末２ａと端末２ｂは同一の構成を有するので、これらを総称して端末２という。同様に、カタログサーバ３ａとカタログサーバ３ｂも同一の構成を有するので、これらを総称してカタログサーバ３という。
【００２２】
図１は、本発明の概念をわかりやすくするために、２台ずつの端末２とカタログサーバ３とを記載したに過ぎない。端末２とカタログサーバ３は１対１で接続される必要はなく、たとえば複数の端末２に１台のカタログサーバ３が接続されていてもよい。また一つのネットワーク４の中にカタログサーバ３は２台に限定されることはなく、１台以上であれば何台あってもよい。端末２とカタログサーバ３との間の接続は、無線であっても有線であってもよい。
【００２３】
図２は、図１で開示した端末２の構成を示すブロック図である。端末２は、ごく簡単なリソースを備えた低コストなものとすることができる。また、端末２が交換する対象となる情報を検知するセンサなどのハードウェアについては、それ自体が本発明の対象には含まれず、またセンサ端末に用途が限定されるものでもないので、記載を省略している。
【００２４】
端末２は、主制御部１０と、共通パラメータリスト格納部１５と、カタログ格納部１６と、通信モジュール１７とを有する。主制御部１０はＣＰＵ、ＲＡＭ、およびＯＳなどで構成されたコンピュータの主要部であり、その上で動作するプログラムとして構成された送受信部１１、メッセージ解析部１２、メッセージ処理部１３、およびメッセージ生成部１４を実行することができる。
【００２５】
送受信部１１は、通信モジュール１７を制御して、ネットワーク４を介してメッセージを送受信する。送受信部１１は、ネットワーク４から到着した自端末宛のメッセージを受信しメッセージ解析部１２へ転送し、またメッセージ生成部１４において生成したメッセージをネットワーク４へ送信する。通信モジュール１７は、無線通信であっても有線通信であってもよい。
【００２６】
メッセージ解析部１２は、送受信部１１が受信したメッセージを構文解析して、メッセージ種別を識別し、通信パラメータを取得する。受信したメッセージに後述するカタログ識別子が含まれている場合は、カタログ格納部１６から該カタログ識別子に対応する通信パラメータを取得する。次に取得したメッセージ種別と通信パラメータとをメッセージ処理部１３へ通知する。
【００２７】
メッセージ処理部１３は、メッセージ解析部１２が取得したメッセージ種別と通信パラメータに基づいてシグナリング処理を行う。シグナリング処理の結果、応答メッセージあるいは新たなメッセージを送信する必要がある場合、メッセージ生成部１４へ送信メッセージのメッセージ種別と通信パラメータとを通知する。その際、通信パラメータについては、共通パラメータリスト格納部１５とカタログ格納部１６を参照して、後述するようにカタログ化できる通信パラメータを対応するカタログ識別子に置き換えて通知する。
【００２８】
メッセージ生成部１４は、メッセージ処理部１３から通知されたメッセージ種別と通信パラメータに従ってメッセージを生成し、生成されたメッセージを送受信部１１へ通知して送信させる。
【００２９】
共通パラメータリスト格納部１５は、共通パラメータとして扱う通信パラメータのリストを格納する。カタログ格納部１６は、カタログ識別子と該カタログ識別子に対応する通信パラメータとを格納する。共通パラメータリスト格納部１５およびカタログ格納部１６が格納する情報の内容については後述する。
【００３０】
図３は、図１で開示したカタログサーバ３の構成を示すブロック図である。カタログサーバ３は、端末２と違って、潤沢なリソースを備えた高性能のものとすることができる。ただし、カタログサーバ３の内部構成は、端末２のそれと同一であり、ただ各部分の性能に違いがあるというだけである。従って、同一の部分には同一の参照番号を付して、説明を省略する。
【００３１】
図４は、図２〜３で開示した端末２およびカタログサーバ３内部の共通パラメータリスト格納部１５が格納するデータの構成を示す概念図である。共通パラメータリスト格納部１５は、異なる端末に対しても常に同じ値を使用できる通信パラメータのリストである共通パラメータリスト２１と、特定のセッションあるいはダイアログなどのような限られた期間内でのみ同じ値を使用できる通信パラメータのリストである一時共通パラメータリスト２２とを格納する。
【００３２】
図５は、図２〜３で開示した端末２およびカタログサーバ３内部のカタログ格納部１６が格納するデータの構成を示す概念図である。カタログ格納部１６は、カタログ識別子３１と、カタログ識別子３１が示すカタログにおいて使用される共通パラメータ３２と一時共通パラメータ３３とを格納する。これらの内容および動作については後述する。
【００３３】
図６は、図１で開示したデータ通信システム１における通信の手順を示すシーケンス図である。図７は図２で開示した端末２における処理の内容を示すフローチャートである。図８は図３で開示したカタログサーバ３における処理の内容を示すフローチャートである。
【００３４】
図６で、端末２ａはカタログサーバ３ａに接続されると、まずカタログサーバ３ａに共通パラメータを登録するためのカタログ登録要求１０１ａを送信する。これを受けたカタログサーバ３ａは、端末２ａにカタログ登録要求応答１０２ａを返信する。同様に端末２ｂとカタログサーバ３ｂの間でも、端末２ｂがカタログサーバ３ｂにカタログ登録要求１０１ｂを送信し、これを受けたカタログサーバ３ｂは端末２ｂにカタログ登録要求応答１０２ｂを返信する。
【００３５】
図７（ａ）は、図６にＳ１として示される、端末２内部におけるカタログ登録要求１０１ａおよびカタログ登録要求応答１０２ａにまつわる処理を示す。起動すると（Ｓ２０１）、メッセージ生成部１４が共通パラメータリスト格納部１５に保持される共通パラメータリスト２１を参照して、カタログ登録要求１０１ａを作成し（Ｓ２０２）、送受信部１１がカタログ登録要求１０１ａをカタログサーバ３に送信する（Ｓ２０３）。
【００３６】
続いて送受信部１１がカタログサーバ３からのカタログ登録要求応答１０２ａを待ち（Ｓ２０４）、カタログ登録要求応答１０２ａを受信すれば、メッセージ解析部１２がカタログ登録要求応答１０２ａに記述されたカタログ識別子３１と共通パラメータ３２を抽出し、メッセージ処理部１３が抽出されたカタログ識別子３１と共通パラメータ３２をカタログ格納部１６に格納して（Ｓ２０５）、処理を終了する（Ｓ２０６）。
【００３７】
図８（ａ）は、図６にＳ２として示される、カタログサーバ３内部におけるカタログ登録要求１０１ａおよびカタログ登録要求応答１０２ａにまつわる処理を示す。起動すると（Ｓ３０１）、送受信部１１がカタログ登録要求１０１ａを受信し（Ｓ３０２）、メッセージ処理部１３がシステム内で一意となるカタログ識別子３１を発行し（Ｓ３０３）、発行されたカタログ識別子３１と、メッセージ解析部１２によって抽出されたカタログ登録要求１０１ａに記述される共通パラメータ３２を、カタログ格納部１６に格納する（Ｓ３０４）。
【００３８】
続いてメッセージ生成部１４が、カタログ識別子３１と共通パラメータ３２を含むカタログ登録要求応答１０２ａを生成して、送受信部１１を介して端末２に送信させ（Ｓ３０５）、処理を終了する（Ｓ３０６）。
【００３９】
なお、Ｓ３０３で新規にカタログ識別子３１を発行したカタログサーバ３は、カタログ識別子３１とそれに対応する共通パラメータ３２および一時共通パラメータ３３を含んだ新規カタログ情報１０３を他のカタログサーバ３へ通知する。これによって、カタログサーバ間の情報の同期を取ることができ、端末２ａがカタログ登録要求１０１ａに含めた共通パラメータ３２がすべてのカタログサーバ３に登録されたことになる。これを、カタログ登録が完了したという。これ以降のメッセージのやり取りでは、すべての端末２は共通パラメータ３２をカタログ識別子３１に置き換えて通信することができる。
【００４０】
続いて、端末２ａが端末２ｂに対してセッションの確立を要求し、これによって端末２ａと端末２ｂとの間でセッションを確立してデータ通信が可能な状態になるまでの処理について説明する。図６で、端末２ａは端末２ｂに向けてのセッション確立要求１０４を発行する。端末２ａから送信されたセッション確立要求１０４は、まずカタログサーバ３ａが受ける。
【００４１】
図８（ｂ）は、図６にＳ４として示される、カタログサーバ３ａ内部におけるセッション確立要求１０４にまつわる処理を示す。起動すると（Ｓ３１１）、送受信部１１がセッション確立要求１０４を受信し（Ｓ３１２）、セッション確立要求１０４がカタログ識別子３１を使ったメッセージであるか否かをメッセージ解析部１２が判断する（Ｓ３１３）。カタログ識別子３１を使ったメッセージであれば、メッセージ解析部１２は、共通パラメータリスト格納部１５に保持された一時共通パラメータリスト２２に一致する一時共通パラメータ３３をカタログ格納部１６に格納して（Ｓ３１４）、Ｓ３１５に進む。この一時共通パラメータ３３は、カタログ識別子３１に対応した一時共通パラメータ３３として格納される。
【００４２】
Ｓ３１３でセッション確立要求１０４がカタログ識別子を使ったメッセージでなければ、そのままＳ３１５に進む。そしてメッセージ生成部１４は、受け取ったセッション確立要求１０４を、そのまま送受信部１１を介して端末２ｂに転送し（Ｓ３１５）、処理を終了する（Ｓ３１６）。転送されたセッション確立要求１０４は、カタログサーバ３ｂにおいて特に何もされず、そのまま端末２ｂに送られる。
【００４３】
図７（ｂ）は、図６にＳ３として示される、端末２ｂ内部におけるセッション確立要求１０４にまつわる処理を示す。起動すると（Ｓ２１１）、送受信部１１がセッション確立要求１０４を受信し（Ｓ２１２）、セッション確立要求１０４がカタログ識別子３１を使ったメッセージであるか否かをメッセージ解析部１２が判断する（Ｓ２１３）。カタログ識別子３１を使ったメッセージでなければ、後述のＳ２１９に進む。
【００４４】
Ｓ２１３で、セッション確立要求１０４がカタログ識別子３１を使ったメッセージであれば、カタログ識別子３１に対応する共通パラメータ３２および一時共通パラメータ３３の情報（以後カタログ情報という）がカタログ格納部１６に存在するか否かをメッセージ解析部１２が判断する（Ｓ２１４）。カタログ識別子３１に該当するカタログ情報が存在していれば、後述のＳ２１８に進む。
【００４５】
Ｓ２１４で、カタログ識別子３１に該当するカタログ情報が存在していなければ、メッセージ生成部１４がカタログ問合わせ要求１０５を生成し、送受信部１１を介してカタログサーバ３ｂに送信する（Ｓ２１５）。送受信部１１はカタログサーバ３ｂからのカタログ問合わせ要求応答１０６を待つ（Ｓ２１６）。カタログ問合わせ要求応答１０６があれば、メッセージ解析部１２によって抽出されたカタログ問合わせ要求応答１０６に記述されるカタログ情報を、カタログ格納部１６に格納して（Ｓ２１７）、Ｓ２１８に進む。
【００４６】
Ｓ２１８で、メッセージ処理部１３は、カタログ格納部１６でカタログ識別子３１に対応するカタログ情報に含まれる通信パラメータを取得する。そして、取得した通信パラメータによって、シグナリング処理を実施する（Ｓ２１９）。なおＳ２１９で、前述のＳ２１３でカタログ識別子３１を使ったメッセージでなければ、カタログ格納部１６から通信パラメータを取得しなくてもよいので、そのままシグナリング処理を実施する。
【００４７】
続いてメッセージ生成部１４がセッション確立要求応答１０７を生成して送受信部１１を介して端末２ａに送信し（Ｓ２２０）、生成したセッション確立要求応答１０７から、共通パラメータリスト格納部１５に保持された一時共通パラメータリスト２２に一致する一時共通パラメータ３３を、メッセージ解析部１２はカタログ識別子３１に対応した一時共通パラメータ３３としてカタログ格納部１６に格納して（Ｓ２２１）、処理を終了する（Ｓ２２１）。
【００４８】
図８（ｃ）は、図６にＳ５として示される、カタログサーバ３ｂ内部におけるカタログ問合わせ要求１０５にまつわる処理を示す。起動すると（Ｓ３２１）、送受信部１１がカタログ問合わせ要求１０５を受信し（Ｓ３２２）、メッセージ解析部１２がカタログ問合わせ要求１０５からカタログ識別子３１を抽出し、メッセージ処理部１３が抽出されたカタログ識別子３１に対応するカタログ情報をカタログ格納手段２６から取得する（Ｓ３２３）。そしてメッセージ生成部１４が、取得されたカタログ情報を含んだカタログ問合わせ要求応答１０６を作成して送受信部１１を介して端末２ｂに送信し（Ｓ３２４）、処理を終了する（Ｓ３２５）。
【００４９】
端末２ｂがセッション確立要求１０４に対するシグナリング処理を完了すると、セッション確立要求応答１０７を端末２ａ宛に返信する。このセッション確立要求応答１０７は、カタログサーバ３ｂを介してカタログサーバ３ａに送られる。カタログサーバ３ａでは、このセッション確立要求応答１０７に対しても、図８の（ｂ）として示したものと同一の処理を行い、一時共通パラメータ３３を取得してカタログ格納部１６へ登録する。ここでは、端末２ｂによって新たに追加された通信パラメータに対して一時共通パラメータ３３の登録処理を行う。この処理は図６にＳ６として示されているが、処理の内容は図８の（ｂ）と同一であるので説明を省略する。この処理が終了したら、カタログサーバ３ａはセッション確立要求応答１０７をそのまま端末２ａに転送する。
【００５０】
図７（ｃ）は、図６にＳ７として示される、端末２ａにおけるセッション確立要求応答１０７にまつわる処理を示す。起動すると（Ｓ２３１）、送受信部１１がセッション確立要求応答１０７を受信し（Ｓ２３２）、メッセージ解析部１２がセッション確立要求応答１０７から抽出した通信パラメータの中で、共通パラメータリスト格納部１５において保持される一時共通パラメータリスト２２に記載された通信パラメータを、メッセージ処理部１３が一時共通パラメータ３３としてカタログ格納部１６に格納する（Ｓ２３３）。そしてセッション確立要求応答１０７に対して通常のシグナリング処理を行い、確認応答メッセージ１０８を端末２ｂに返信し（Ｓ２３４）、処理を終了する（Ｓ２３５）。
【００５１】
確認応答メッセージ１０８は、カタログサーバ３ａおよびカタログサーバ３ｂを介して、そのまま端末２ｂに送られる。以上で端末２ａと端末２ｂとの間でのセッション確立が完了する。セッション確立の完了により、一時共通パラメータはカタログ情報としてカタログサーバ３ａおよびカタログサーバ３ｂに登録される。同一セッションあるいはダイアログ内における以降のメッセージのやり取りでは、共通パラメータに加えて一時共通パラメータについてもカタログ識別子に置き換えて通信できる。
【００５２】
図９は、図６で開示した通信の手順を、具体的なプロトコルにおいて実施する例を示すシーケンス図である。ここでは、ＳＩＰ（Session Initiation Protocol）に本発明を適用した場合について説明する。ＳＩＰはＩＥＴＦ（Internet Engineering Task Force）において標準化されている（RFC3261）シグナリングプロトコルの1つであり、主なアプリケーションの１つとしてＶｏＩＰ（Voice over Internet Protocol）がある。システムの構成および処理手順は、ここまでで説明したものと同一である。カタログサーバ３は、ＳＩＰにおけるプロキシサーバと同一装置に実装してもよい。
【００５３】
図１０は、図９において端末２ａがカタログサーバ３ａに送信するカタログ登録要求１０１ａおよびカタログサーバ３ａが端末２ａに返信するカタログ登録要求応答１０２ａの例である。端末２ａは、カタログ登録要求１０１ａとして、図１０（ａ）に示すREGISTERメッセージ４００をカタログサーバ３ａに送信する。
【００５４】
REGISTERメッセージ４００は、ＳＩＰにおける通常のリクエストと同様に、リクエスト４０１とヘッダ４０２の後に、１行の空行をおいてボディ４０３という形式で構成される。リクエスト４０１は、リクエストの種類（メソッド）を示す「REGISTER」と、リクエストの宛先となるカタログサーバ３ａを示す「sip:LS1.aaa.net」、そしてＳＩＰのバージョンを示す「SIP/x.0」とからなる。ヘッダ４０２は、ＳＩＰにおける通常のリクエストと同様に、Via、Max-Forwards、From、To、Call-ID、CSeq、Contact、Content-Type、Content-Lengthといった各行が示されている。これらについての詳しい説明は、当業者には公知であるので省略する。
【００５５】
ボディ４０３には、端末２ａがカタログ登録しようとしている共通パラメータ３２が記述される。ここで記述されるのは、ヘッダの中で共通して使われる情報、およびＳＤＰ（Session Description Protocol）を用いてＳＩＰボディ部分に記述されるセッション情報の一部である。ここで記載された各々のパラメータを共通パラメータ３２として扱うかどうかは、カタログサーバ３ａ側の共通パラメータリスト格納部１５に格納される共通パラメータリスト２１を参照して決定する。
【００５６】
また、1行に複数通信パラメータが含まれ、該当行に含まれる通信パラメータの一部が共通パラメータでない場合には、「＊」などの略記号に置き換え非共通パラメータ部分であることを明示する。図１０（ａ）の例では、セッションを識別するための情報を示すタイプであるｏ＝行４０４に、非共通パラメータ部分を示す「＊」が含まれる。略記号に置き換えられた通信パラメータについては、メッセージ送信の度に値が記述される。
【００５７】
ヘッダの中で使われるVia行４０６、From行４０７、およびContact行４０８も、非共通パラメータ部分を示す「＊」を含むが、共通パラメータリスト２１に含まれるので、ここでは共通パラメータ３２として登録される。
【００５８】
セッションの開始および終了の時刻を示すタイプであるｔ＝行４０５は、共通パラメータリスト２１に含まれないので、共通パラメータ３２として登録されない。その他のパラメータを示すｖ＝行、ｓ＝行、ｃ＝行、ｍ＝行、ａ＝行は、共通パラメータリスト２１に含まれるので、共通パラメータ３２として登録される。
【００５９】
REGISTERメッセージ４００を受信したカタログサーバ３ａは、メッセージ処理部１３において、ボディ４０３に記述された共通パラメータ３２に対してカタログ識別子３１を発行し、図８の（ａ）（図６および図９のＳ２）として示した処理を実行する。ここでは「xxx@aaa.net」というカタログ識別子３１が発行されている。次にカタログサーバ３ａは、端末２ａに対して、カタログ登録要求応答１０２ａとして、図１０（ｂ）に示す２００ ＯＫレスポンス（以後、単にＯＫレスポンスという）４１０を返信する。ＯＫレスポンス４１０は、ＳＩＰにおける通常のレスポンスと同様に、ステータス４１１とヘッダ４１２という形式で構成される。ここではボディは無い。
【００６０】
ステータス４１１は、ＳＩＰのバージョンを示す「SIP/x.0」と、ステータスを表す「200 OK」とからなる。ヘッダ４１２は、ＳＩＰにおける通常のリクエストと同様のVia、From、To、Call-ID、CSeq、Contact、Expires、Content-Lengthといった各行に加えて（やはりこれらも、当業者には公知であるので詳しい説明は省略する）に加えて、発行されたカタログ識別子３１を示すCatalog-ID行４１３が含まれる。
【００６１】
ＯＫレスポンス４１０を受信した端末２ａは、図７の（ａ）（図６および図９のＳ１）として示した処理によって、カタログ識別子３１とそれに対応するカタログ情報をカタログ格納部１６へ格納する。以上で、カタログ登録が完了する。
【００６２】
図１１は、図９において端末２ａが端末２ｂに送信するセッション確立要求１０４および端末２ｂが端末２ａに返信するセッション確立要求応答１０７の例である。端末２ａは、セッション確立要求１０４として、図１１（ａ）に示すINVITEメッセージ４２０を端末２ｂに送信する。
【００６３】
INVITEメッセージ４２０は、ＳＩＰにおける通常のリクエストと同様に、リクエスト４２１とヘッダ４２２の後に、１行の空行をおいてボディ４２３という形式で構成される。リクエスト４２１は、リクエストの種類（メソッド）を示す「INVITE」と、リクエストの宛先となるＵＲＩを示す「sip:UserB@bbb.net」、そしてＳＩＰのバージョンを示す「SIP/x.0」とからなる。ヘッダ４２２は、REGISTERメッセージ４００のヘッダ４０２と同様の各行に加えて、前述のカタログ識別子３１を示すCatalog-ID行４２４が含まれる。
【００６４】
ここで、端末２ａがメッセージを生成する際、メッセージ生成部１４は共通パラメータリスト格納部１５に保持される共通パラメータリスト２１を参照し、共通パラメータ３２に関して行ごと省略するか、もしくは「＆」などのような略記号に置き換えて、ボディ４２３に記述する。
【００６５】
特に「＊」などの略記号に置き換えられた非共通パラメータ部分を含む共通パラメータ３２については、「＊」に該当する部分について数値などを記述し、それ以外の部分は「＆」などのような略記号に置き換える。
【００６６】
図１１（ａ）の例では、ボディ４２３のｏ＝行４２５に、非共通パラメータ部分を示す「＊」が２個含まれて共通パラメータ３２として登録されているので、ここでは＊に該当する数値２つと、それ以外の部分を示す略記号「＆」を記述する。ｔ＝行４２６は、共通パラメータリスト２１に含まれないので、そのまま記述する。ボディ４２３において、これ以外のパラメータ（ｖ＝行、ｓ＝行、ｃ＝行、ｍ＝行、ａ＝行）は、すべて共通パラメータリスト２１に含まれ、かつ非共通パラメータ部分もないので、行ごと省略する。
【００６７】
また、ヘッダ４２２においても、Via行４０６およびFrom行４０７が非共通パラメータ部分を示す「＊」を含む共通パラメータ３２として既に登録されているので、ここではVia行４２７およびFrom行４２８は、共通パラメータ３２の＊に該当する部分のみを記述し、それ以外の部分は略記号「＆」で記述するようにする。Contact行４０８は丸ごと共通パラメータ３２として既に登録されているので、ヘッダ４２２においては省略する。ちなみにMax-Forward行４２９は、そのまま記載する（共通パラメータ３２にはMax-Forwards行４０９が登録されているが、Max-Forward行４２９は共通パラメータ３２に該当しないので）。
【００６８】
INVITEメッセージ４２０を受信したカタログサーバ３ａは、図８（ｂ）（図６および図９のＳ４）に示した処理によって、INVITEメッセージ４２０に含まれる一時共通パラメータ３３を抽出してカタログ格納部１６に格納し、受信したINVITEメッセージ４２０自体には特に何もせずに端末２ｂに転送する。一時共通パラメータ３３の例としては、ヘッダ４２２のFrom行４２８内部のtag、およびCall-ID行のように同一ダイアログ内で同じ値が複数メッセージにおいて使用される通信パラメータが挙げられる。
【００６９】
カタログサーバ３ｂを経由してINVITEメッセージ４２０を受信した端末２ｂは、図７（ｂ）（図６および図９のＳ３）に示した処理を行い、端末２ａにセッション確立要求応答１０７として図１１（ｂ）に示すＯＫレスポンス４３０を返信する。ＯＫレスポンス４３０は、図１０（ｂ）に示したＯＫレスポンス４１０と同様のステータス４３１とヘッダ４３２に加えて、１行の空行をおいてボディ４３３という形式で構成される。ヘッダにはCatalog-ID行４３４が、ＯＫレスポンス４１０と同様に含まれる。ボディ４３３は、端末２ａと端末２ｂとの間で確立された通信条件を示すＳＤＰによって記述されるセッション情報である。これらも、当業者には公知であるので詳しい説明は省略する。
【００７０】
図１２は、図９において端末２ｂがカタログサーバ３ｂに送信するカタログ問合わせ要求１０５およびカタログサーバ３ｂが端末２ｂに返信するカタログ問合わせ要求応答１０６の例である。端末２ｂは、カタログ問合わせ要求１０５として、図１２（ａ）に示すOPTIONSメッセージ４４０をカタログサーバ３ｂに送信する。
【００７１】
OPTIONSメッセージ４４０は、ＳＩＰにおける通常のリクエストと同様に、リクエスト４４１とヘッダ４４２とで構成されるが、ここではボディは無い。リクエスト４４１は、リクエストの種類（メソッド）を示す「OPTIONS」と、リクエストの宛先となるＵＲＩを示す「sip:ls1@bbb.net」、そしてＳＩＰのバージョンを示す「SIP/x.0」とからなる。ヘッダ４４２は、INVITEメッセージ４２０のヘッダ４２２と同様の各行で構成される。ヘッダ４４２には、カタログ情報問い合わせの対象となるカタログ識別子３１を含むRequest-Catalog-ID行４４４が含まれる。
【００７２】
なお、端末２ｂはカタログサーバ３ｂに対して、あらかじめ図１０（ａ）で示したものと同様のREGISTERコマンドを送信して自らのカタログ情報を登録している。そのため、OPTIONSメッセージ４４０のヘッダ４４２には、端末２ｂが登録したカタログ情報に対応するカタログ識別子を含むCatalog-ID行４４３が含まれ、また前述のINVITEメッセージ４２０と同様に、自らの登録したカタログ情報に基づいてヘッダ４４２の一部を省略している。
【００７３】
OPTIONSメッセージ４４０を受信したカタログサーバ３ｂは、図８（ｃ）（図６および図９のＳ５）に示した処理を行い、端末２ｂにカタログ問合わせ要求応答１０６として図１２（ｂ）に示すＯＫレスポンス４５０を返信する。ＯＫレスポンス４５０は、図１０（ｂ）に示したＯＫレスポンス４１０と同様のステータス４５１とヘッダ４５２に加えて、１行の空行をおいてボディ４５３という形式で構成される。ヘッダにはCatalog-ID行４５４とRequest-Catalog-ID行４５５とが、ＯＫレスポンス４１０と同様に含まれる。ボディ４５３は、OPTIONSメッセージ４４０のRequest-Catalog-ID行４４４に含まれるカタログ識別子３１に対応するカタログ情報が、REGISTERメッセージ４００のボディ４０３と同様の形で記述されている。
【００７４】
端末２ｂは、カタログサーバ３ｂにOPTIONSメッセージ４４０を送信してカタログ情報を得ることにより、Request-Catalog-ID行４５５に含まれるカタログ識別子３１に対応するカタログ情報を取得して、カタログ格納部１６に格納することができる。これにより、端末２ａの共通パラメータ３２についての情報を得ることができるので、データ量が大幅に削減されたINVITEメッセージ４２０に対しても通信パラメータを解釈して、通常のINVITEメッセージと同様にシグナリング処理を行うことができる。
【００７５】
ＯＫレスポンス４３０（セッション確立要求応答１０７）を受けた端末２ａは、図７（ｃ）（図６および図９のＳ７）に示した処理を行い、確認応答メッセージ１０８としてＡＣＫリクエスト４６０を端末２ｂ宛に送信する。ＡＣＫリクエスト４６０、およびＳ７以後の処理は当業者には公知であるので、詳しい説明は省略する。
【００７６】
図１３は、本実施の形態によらない従来の通信システムにおいて、端末が発信する従来のINVITEメッセージ５２０の例である。従来のINVITEメッセージ５２０は、リクエスト５２１とヘッダ５２２の後に、１行の空行をおいてボディ５２３という形式で構成される。
【００７７】
従来のINVITEメッセージ５２０と、図１１（ａ）に示した本実施の形態のINVITEメッセージ４２０とを比較すると、従来のINVITEメッセージ５２０ではボディ５２３に少なくとも７行（図１３では１１行）のパラメータを記述するのに対して、本実施の形態のボディ４２３では２行を記述するだけで済み、１行あたりの記述も少なくなっていることがわかる。また、本実施の形態のヘッダ４２２は、従来のヘッダ５２２と比べてCatalog-ID行４２４が１行加わるが、Via行４２７およびFrom行４２８の一部、さらにContact行の全部が省略されている。従って、従来のINVITEメッセージ５２０と比べて、本実施の形態のINVITEメッセージ４２０のデータ量が大幅に削減されていることは一目瞭然である。
【００７８】
本実施の形態によって、カタログ情報として登録された共通パラメータ３２を適用することにより、ヘッダおよびボディにおいて共通して使われるパラメータを、データサイズの小さなカタログ識別子に置き換えて通信を行うことができる。このため、INVITEメッセージ以外においても、図６〜１２で示したセッション確立の処理が完了すれば、端末が送受信するすべてのメッセージにおいて、これと同じ方法によってデータ量を削減することができる。
【００７９】
また、端末がメッセージを送受信する際の処理は、単純な置換処理によって行うことができるので、複雑なデータの圧縮／伸長処理を必要とはしない。従って、本実施の形態を適用することによる端末における処理量の増大は、ごく僅かである。
【００８０】
以上のように、本実施の形態によって、端末における処理量をほとんど増大させずに、メッセージのデータ量の削減を実現することが可能である。従って、リソースを削減された安価な端末であっても、本実施の形態を容易に実施することができるので、そのような端末のコストダウンに好適な構成を備えていると言える。
【００８１】
なお、図９以降で示したＳＩＰは、一般的によく使用されるプロトコルの一つとして例示したに過ぎない。本発明はこれ以外のプロトコルにおいても利用可能である。また、本発明はリソースを削減された安価な端末での利用に適しているが、端末の種類はセンサネットワークにおけるセンサ端末などに限定されるものではない。たとえば、いわゆるＩＰ電話など、ＳＩＰのアプリケーションの１つであるＶｏＩＰによって音声通信を行う端末においても利用できる。
【００８２】
これまで本発明について図面に示した特定の実施の形態をもって説明してきたが、本発明は図面に示した実施の形態に限定されるものではなく、本発明の効果を奏する限り、これまで知られたいかなる構成であっても採用することができることは言うまでもないことである。
【産業上の利用可能性】
【００８３】
データ通信を行う端末によって構成されるネットワークにおいて利用可能である。プロトコルの種類、および端末やデータの種類は特に限定されない。
【図面の簡単な説明】
【００８４】
【図１】本発明の実施の形態に係るデータ通信システムのネットワーク構成を示す概念図である。
【図２】図１で開示した端末の構成を示すブロック図である。
【図３】図１で開示したカタログサーバの構成を示すブロック図である。
【図４】図２〜３で開示した端末およびカタログサーバ内部の共通パラメータリスト格納部が格納するデータの構成を示す概念図である。
【図５】図２〜３で開示した端末およびカタログサーバ内部のカタログ格納部が格納するデータの構成を示す概念図である。
【図６】図１で開示したデータ通信システムにおける通信の手順を示すシーケンス図である。
【図７】図２で開示した端末における処理の内容を示すフローチャートである。
【図８】図３で開示したカタログサーバにおける処理の内容を示すフローチャートである。
【図９】図６で開示した通信の手順を、具体的なプロトコルにおいて実施する例を示すシーケンス図である。
【図１０】図９において端末がカタログサーバに送信するカタログ登録要求およびカタログサーバが端末に返信するカタログ登録要求応答の例である。
【図１１】図９において端末が他の端末に送信するセッション確立要求およびセッション確立要求応答の例である。
【図１２】図９において端末がカタログサーバに送信するカタログ問合わせ要求およびカタログサーバが端末に返信するカタログ問合わせ要求応答の例である。
【図１３】従来の通信システムにおいて、端末が発信する従来のINVITEメッセージの例である。
【符号の説明】
【００８５】
１ データ通信システム
２、２ａ、２ｂ 端末
３、３ａ、３ｂ カタログサーバ
４ ネットワーク
１０ 主制御部
１２ メッセージ解析部
１３ メッセージ処理部
１４ メッセージ生成部
１５ 共通パラメータリスト格納部
１６ カタログ格納部
２１ 共通パラメータリスト
２２ 一時共通パラメータリスト
３１ カタログ識別子
３２ 共通パラメータ
３３ 一時共通パラメータ
１０１ａ、１０１ｂ カタログ登録要求
１０２ａ、１０２ｂ カタログ登録要求応答
１０３ 新規カタログ情報
１０４ セッション確立要求
１０５ カタログ問合わせ要求
１０６ カタログ問合わせ要求応答
１０７ セッション確立要求応答
１０８ 確認応答メッセージ
【特許請求の範囲】
【請求項１】
複数の端末がネットワークを通じて相互に通信するデータ通信システムであって、
前記端末は、
前記ネットワークを通じて他の端末と通信する第１の送受信部と、
カタログ識別子と関連づけた共通パラメータを記憶する第１のカタログ格納部と、
通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換して前記他の端末に送信する第１のメッセージ生成部と
を有することを特徴とするデータ通信システム。
【請求項２】
前記端末は、
他の端末から受信した通信データにカタログ識別子が含まれるか否かを解析する第１のメッセージ解析部と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記カタログ識別子を前記共通パラメータに置換する第１のメッセージ処理部と
を有することを特徴とする、請求項１に記載のデータ通信システム。
【請求項３】
前記ネットワークは前記端末と通信が可能なカタログサーバを有し、
前記端末は、
前記第１のメッセージ生成部が前記共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを前記カタログサーバに送信し、
前記カタログサーバは、
前記ネットワークを通じて他の端末およびカタログサーバと通信する第２の送受信部と、
前記共通パラメータリストに対して前記カタログ識別子を発行する第２のメッセージ処理部と、
前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて格納する第２のカタログ格納部と、
前記カタログ識別子を前記端末に返信する第２のメッセージ生成部と
を有することを特徴とする、請求項２に記載のデータ通信システム。
【請求項４】
前記端末において、
前記第１のメッセージ解析部は、前記他の端末から受信した通信データにカタログ識別子が含まれており、かつ前記カタログ識別子が前記第１のカタログ格納部に含まれているか否かを解析し、
前記第１のメッセージ処理部は、前記カタログ識別子が前記第１のカタログ格納部に含まれていなければ、前記カタログサーバに前記カタログ識別子に対応する前記共通パラメータを照会する
ことを特徴とする、請求項３に記載のデータ通信システム。
【請求項５】
前記カタログサーバにおいて、
前記端末から前記共通パラメータの照会を受けたことに反応して、前記第２のメッセージ処理部は、前記カタログ識別子に対応する前記共通パラメータを前記第２のカタログ格納部から検索し、
前記第２のメッセージ生成部は、前記検索された共通パラメータを前記端末に送信する
ことを特徴とする、請求項４に記載のデータ通信システム。
【請求項６】
前記共通パラメータは、特定の期間においてのみ使用できる一時共通パラメータを含むことを特徴とする、請求項１ないし５のうちいずれか１項に記載のデータ通信システム。
【請求項７】
他の端末とネットワークを通じて相互に通信可能な端末であって、
前記ネットワークを通じて他の端末と通信する送受信部と、
カタログ識別子と関連づけた共通パラメータを記憶するカタログ格納部と、
通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換して前記他の端末に送信するメッセージ生成部と
を有することを特徴とする端末。
【請求項８】
他の端末から受信した通信データにカタログ識別子が含まれるか否かを解析するメッセージ解析部と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記カタログ識別子を前記共通パラメータに置換するメッセージ処理部と
を有することを特徴とする、請求項７に記載の端末。
【請求項９】
前記メッセージ生成部が前記共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを前記ネットワークに接続されたカタログサーバに送信し、
前記カタログ格納部が前記カタログサーバから受信したカタログ識別子を前記共通パラメータリストと関連づけて記憶することを特徴とする、請求項８に記載の端末。
【請求項１０】
前記メッセージ解析部は、前記他の端末から受信した通信データにカタログ識別子が含まれており、かつ前記カタログ識別子が前記カタログ格納部に含まれているか否かを解析し、
前記メッセージ処理部は、前記カタログ識別子が前記カタログ格納部に含まれていなければ、前記カタログサーバに前記カタログ識別子に対応する前記共通パラメータを照会する
ことを特徴とする、請求項９に記載の端末。
【請求項１１】
前記照会に対応して前記カタログサーバから返送されてきた前記カタログ識別子に対応する前記共通パラメータを、前記カタログ格納部が前記カタログ識別子と関連づけて記憶することを特徴とする、請求項１０に記載の端末。
【請求項１２】
前記共通パラメータは、特定の期間においてのみ使用できる一時共通パラメータを含むことを特徴とする、請求項７ないし１１のうちいずれか１項に記載の端末。
【請求項１３】
複数の端末および単数もしくは複数のカタログサーバがネットワークを通じて相互に通信するデータ通信システムにおいて使用されるカタログサーバであって、
前記ネットワークを通じて他の端末と通信し、前記端末が共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを受信する送受信部と、
前記共通パラメータリストに対してカタログ識別子を発行するメッセージ処理部と、
前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて格納するカタログ格納部と、
前記カタログ識別子を前記端末に返信するメッセージ生成部と
を有することを特徴とするカタログサーバ。
【請求項１４】
前記端末から前記共通パラメータの照会を受けたことに反応して、前記メッセージ処理部は、前記カタログ識別子に対応する前記共通パラメータを前記カタログ格納部から検索し、
前記メッセージ生成部は、前記検索された共通パラメータを前記端末に送信する
ことを特徴とする、請求項１３に記載のカタログサーバ。
【請求項１５】
第１のカタログ格納部を有する複数の端末がネットワークを通じて相互に通信するデータ通信システムにおいてデータ通信を行う方法であって、
前記端末が他の端末に送信する通信データを生成するデータ生成工程と、
前記端末がカタログ識別子と関連づけた共通パラメータを前記第１のカタログ格納部から検索するカタログ検索工程と、
前記端末が前記通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換する第１の置換工程と、
前記端末が前記置換された通信データを前記他の端末に送信する送信工程と
を有することを特徴とするデータ通信方法。
【請求項１６】
前記端末が他の端末から通信データを受信する受信工程と、
前記端末が前記受信工程で受信された通信データにカタログ識別子が含まれるか否かを解析するメッセージ解析工程と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記端末が前記カタログ識別子を前記共通パラメータに置換する第２の置換工程と
を有することを特徴とする、請求項１５に記載のデータ通信方法。
【請求項１７】
前記ネットワークは前記端末と通信が可能で第２のカタログ格納部を有するカタログサーバを有し、
前記端末が前記共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを前記カタログサーバに送信するカタログ送信工程と、
前記カタログサーバが前記共通パラメータリストを受信するカタログ受信工程と、
前記カタログサーバが前記共通パラメータリストに対して前記カタログ識別子を発行する識別子発行工程と、
前記カタログサーバが前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて前記第２のカタログ格納部に格納するカタログ格納工程と、
前記カタログサーバが前記カタログ識別子を前記端末に返信する識別子送信工程と
を有することを特徴とする、請求項１６に記載のデータ通信方法。
【請求項１８】
他の端末とネットワークを通じて相互に通信可能で第１のカタログ格納部を有する端末において、前記端末が備えるコンピュータに、
他の端末に送信する通信データを生成する機能と、
カタログ識別子と関連づけた共通パラメータを前記第１のカタログ格納部から検索する機能と、
前記通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換する機能と、
前記置換された通信データを前記他の端末に送信する機能と
を実行させることを特徴とする通信プログラム。
【請求項１９】
前記端末が備えるコンピュータに、
他の端末から通信データを受信する機能と、
前記受信工程で受信された通信データにカタログ識別子が含まれるか否かを解析する機能と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記カタログ識別子を前記共通パラメータに置換する機能と
を実行させることを特徴とする、請求項１８に記載の通信プログラム。
【請求項２０】
複数の端末および単数もしくは複数のカタログサーバとネットワークを通じて相互に通信可能で第２のカタログ格納部を有するカタログサーバにおいて、前記カタログサーバが備えるコンピュータに、
前記端末から前記共通パラメータリストを受信する機能と、
前記共通パラメータリストに対して前記カタログ識別子を発行する機能と、
前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて前記第２のカタログ格納部に格納する機能と、
前記カタログ識別子を前記端末に返信する機能と
を実行させることを特徴とする通信プログラム。
【請求項１】
複数の端末がネットワークを通じて相互に通信するデータ通信システムであって、
前記端末は、
前記ネットワークを通じて他の端末と通信する第１の送受信部と、
カタログ識別子と関連づけた共通パラメータを記憶する第１のカタログ格納部と、
通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換して前記他の端末に送信する第１のメッセージ生成部と
を有することを特徴とするデータ通信システム。
【請求項２】
前記端末は、
他の端末から受信した通信データにカタログ識別子が含まれるか否かを解析する第１のメッセージ解析部と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記カタログ識別子を前記共通パラメータに置換する第１のメッセージ処理部と
を有することを特徴とする、請求項１に記載のデータ通信システム。
【請求項３】
前記ネットワークは前記端末と通信が可能なカタログサーバを有し、
前記端末は、
前記第１のメッセージ生成部が前記共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを前記カタログサーバに送信し、
前記カタログサーバは、
前記ネットワークを通じて他の端末およびカタログサーバと通信する第２の送受信部と、
前記共通パラメータリストに対して前記カタログ識別子を発行する第２のメッセージ処理部と、
前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて格納する第２のカタログ格納部と、
前記カタログ識別子を前記端末に返信する第２のメッセージ生成部と
を有することを特徴とする、請求項２に記載のデータ通信システム。
【請求項４】
前記端末において、
前記第１のメッセージ解析部は、前記他の端末から受信した通信データにカタログ識別子が含まれており、かつ前記カタログ識別子が前記第１のカタログ格納部に含まれているか否かを解析し、
前記第１のメッセージ処理部は、前記カタログ識別子が前記第１のカタログ格納部に含まれていなければ、前記カタログサーバに前記カタログ識別子に対応する前記共通パラメータを照会する
ことを特徴とする、請求項３に記載のデータ通信システム。
【請求項５】
前記カタログサーバにおいて、
前記端末から前記共通パラメータの照会を受けたことに反応して、前記第２のメッセージ処理部は、前記カタログ識別子に対応する前記共通パラメータを前記第２のカタログ格納部から検索し、
前記第２のメッセージ生成部は、前記検索された共通パラメータを前記端末に送信する
ことを特徴とする、請求項４に記載のデータ通信システム。
【請求項６】
前記共通パラメータは、特定の期間においてのみ使用できる一時共通パラメータを含むことを特徴とする、請求項１ないし５のうちいずれか１項に記載のデータ通信システム。
【請求項７】
他の端末とネットワークを通じて相互に通信可能な端末であって、
前記ネットワークを通じて他の端末と通信する送受信部と、
カタログ識別子と関連づけた共通パラメータを記憶するカタログ格納部と、
通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換して前記他の端末に送信するメッセージ生成部と
を有することを特徴とする端末。
【請求項８】
他の端末から受信した通信データにカタログ識別子が含まれるか否かを解析するメッセージ解析部と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記カタログ識別子を前記共通パラメータに置換するメッセージ処理部と
を有することを特徴とする、請求項７に記載の端末。
【請求項９】
前記メッセージ生成部が前記共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを前記ネットワークに接続されたカタログサーバに送信し、
前記カタログ格納部が前記カタログサーバから受信したカタログ識別子を前記共通パラメータリストと関連づけて記憶することを特徴とする、請求項８に記載の端末。
【請求項１０】
前記メッセージ解析部は、前記他の端末から受信した通信データにカタログ識別子が含まれており、かつ前記カタログ識別子が前記カタログ格納部に含まれているか否かを解析し、
前記メッセージ処理部は、前記カタログ識別子が前記カタログ格納部に含まれていなければ、前記カタログサーバに前記カタログ識別子に対応する前記共通パラメータを照会する
ことを特徴とする、請求項９に記載の端末。
【請求項１１】
前記照会に対応して前記カタログサーバから返送されてきた前記カタログ識別子に対応する前記共通パラメータを、前記カタログ格納部が前記カタログ識別子と関連づけて記憶することを特徴とする、請求項１０に記載の端末。
【請求項１２】
前記共通パラメータは、特定の期間においてのみ使用できる一時共通パラメータを含むことを特徴とする、請求項７ないし１１のうちいずれか１項に記載の端末。
【請求項１３】
複数の端末および単数もしくは複数のカタログサーバがネットワークを通じて相互に通信するデータ通信システムにおいて使用されるカタログサーバであって、
前記ネットワークを通じて他の端末と通信し、前記端末が共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを受信する送受信部と、
前記共通パラメータリストに対してカタログ識別子を発行するメッセージ処理部と、
前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて格納するカタログ格納部と、
前記カタログ識別子を前記端末に返信するメッセージ生成部と
を有することを特徴とするカタログサーバ。
【請求項１４】
前記端末から前記共通パラメータの照会を受けたことに反応して、前記メッセージ処理部は、前記カタログ識別子に対応する前記共通パラメータを前記カタログ格納部から検索し、
前記メッセージ生成部は、前記検索された共通パラメータを前記端末に送信する
ことを特徴とする、請求項１３に記載のカタログサーバ。
【請求項１５】
第１のカタログ格納部を有する複数の端末がネットワークを通じて相互に通信するデータ通信システムにおいてデータ通信を行う方法であって、
前記端末が他の端末に送信する通信データを生成するデータ生成工程と、
前記端末がカタログ識別子と関連づけた共通パラメータを前記第１のカタログ格納部から検索するカタログ検索工程と、
前記端末が前記通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換する第１の置換工程と、
前記端末が前記置換された通信データを前記他の端末に送信する送信工程と
を有することを特徴とするデータ通信方法。
【請求項１６】
前記端末が他の端末から通信データを受信する受信工程と、
前記端末が前記受信工程で受信された通信データにカタログ識別子が含まれるか否かを解析するメッセージ解析工程と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記端末が前記カタログ識別子を前記共通パラメータに置換する第２の置換工程と
を有することを特徴とする、請求項１５に記載のデータ通信方法。
【請求項１７】
前記ネットワークは前記端末と通信が可能で第２のカタログ格納部を有するカタログサーバを有し、
前記端末が前記共通パラメータとして扱う通信パラメータのリストである共通パラメータリストを前記カタログサーバに送信するカタログ送信工程と、
前記カタログサーバが前記共通パラメータリストを受信するカタログ受信工程と、
前記カタログサーバが前記共通パラメータリストに対して前記カタログ識別子を発行する識別子発行工程と、
前記カタログサーバが前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて前記第２のカタログ格納部に格納するカタログ格納工程と、
前記カタログサーバが前記カタログ識別子を前記端末に返信する識別子送信工程と
を有することを特徴とする、請求項１６に記載のデータ通信方法。
【請求項１８】
他の端末とネットワークを通じて相互に通信可能で第１のカタログ格納部を有する端末において、前記端末が備えるコンピュータに、
他の端末に送信する通信データを生成する機能と、
カタログ識別子と関連づけた共通パラメータを前記第１のカタログ格納部から検索する機能と、
前記通信データに含まれる前記共通パラメータを前記カタログ識別子によって置換する機能と、
前記置換された通信データを前記他の端末に送信する機能と
を実行させることを特徴とする通信プログラム。
【請求項１９】
前記端末が備えるコンピュータに、
他の端末から通信データを受信する機能と、
前記受信工程で受信された通信データにカタログ識別子が含まれるか否かを解析する機能と、
前記受信した通信データに前記カタログ識別子が含まれていれば、前記カタログ識別子を前記共通パラメータに置換する機能と
を実行させることを特徴とする、請求項１８に記載の通信プログラム。
【請求項２０】
複数の端末および単数もしくは複数のカタログサーバとネットワークを通じて相互に通信可能で第２のカタログ格納部を有するカタログサーバにおいて、前記カタログサーバが備えるコンピュータに、
前記端末から前記共通パラメータリストを受信する機能と、
前記共通パラメータリストに対して前記カタログ識別子を発行する機能と、
前記共通パラメータリストに記載された共通パラメータを前記カタログ識別子に対応づけて前記第２のカタログ格納部に格納する機能と、
前記カタログ識別子を前記端末に返信する機能と
を実行させることを特徴とする通信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００９−７７１４１（Ｐ２００９−７７１４１Ａ）
【公開日】平成２１年４月９日（２００９．４．９）
【国際特許分類】
【出願番号】特願２００７−２４４０３３（Ｐ２００７−２４４０３３）
【出願日】平成１９年９月２０日（２００７．９．２０）
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成１８年度、独立行政法人情報通信研究機構、高度通信・放送研究開発における委託研究）は産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２１年４月９日（２００９．４．９）
【国際特許分類】
【出願日】平成１９年９月２０日（２００７．９．２０）
【国等の委託研究の成果に係る記載事項】（出願人による申告）国等の委託研究の成果に係る特許出願（平成１８年度、独立行政法人情報通信研究機構、高度通信・放送研究開発における委託研究）は産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]