JP2010050617A - プロトコル変換装置およびプロトコル変換方法 - Google Patents

Abstract

【課題】既存アプリケーションソフトウェアのプログラムの変更を行うことなく、適切な状況下で異なるプロトコルを用いて通信を行うことができる。
【解決手段】データ取得部３１０は、特定のアプリケーションソフトウェアとＨＴＴＰを用いてデータの送受信を行う。ＨＴＴＰ通信部３３３は、クライアント側端末２００とＨＴＴＰを用いてデータの送受信を行う。また、ＨＴＴＰ通信部３３３は要求メッセージを受信する。データ判定部３３３は、クライアント側端末２００が使用するプロトコルを、ＨＴＴＰからＳＩＰに変換するか否かを判定する。ＳＩＰ通信部３４４は、データ判定部３３３が、ＳＩＰに変換すると判定した場合、ＳＩＰを用いてクライアント側端末２００とデータの送受信を行う。
【選択図】図１

Description

本発明は、プロトコル変換装置およびプロトコル変換方法に関する。

ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）が基本プロトコルとなるインターネットを対象に、サービスを提供していたアプリケーションソフトウェアがある。このアプリケーションソフトウェアを、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を基本プロトコルとして用いるＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）系次世代ネットワーク（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ、ＮＧＮ）上で提供する技術が知られている。例えば、Ｐａｒｌａｙ Ｘ ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）を利用する技術（例えば、非特許文献１参照）や、ＳＩＰ Ｓｅｒｖｌｅｔを利用する技術（例えば、非特許文献２参照）や、ＩＭＳ Ｓｅｒｖｉｃｅｓ ＡＰＩ（例えば、非特許文献３参照）を利用する技術が知られている。

Ｐａｒｌａｙ Ｘ ＡＰＩは、通信ネットワークの機能をインターネットにおける外部サービス呼び出しの標準であるＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）Ｗｅｂサービス形式のＡＰＩを通じて利用するためのインタフェースを規定している。Ｐａｒｌａｙ Ｘ ＡＰＩを利用してアプリケーションソフトウェアを書き換えることにより、アプリケーションソフトウェアの開発者が、通信ネットワークの特性や通信プロトコルの知識を要することなく、ＡＰＩの呼び出しだけでその通信ネットワークを利用したサービスの提供が可能となる。

ＳＩＰ Ｓｅｒｖｌｅｔは、ＳＩＰによる通信を行うサーバを実装するための開発技術である。ＳＩＰ Ｓｅｒｖｌｅｔはインターネットにおけるサーバ開発技術であるＨＴＴＰ Ｓｅｒｖｌｅｔを踏襲しており、アプリケーションソフトウェア開発者にとってのＳＩＰインタフェースの追加実装コストを低減する。

ＩＭＳ Ｓｅｒｖｉｃｅｓ ＡＰＩは、ＳＩＰ Ｓｅｒｖｌｅｔと同様に、ＳＩＰを利用した通信を行うクライアントを実装するためのＡＰＩを提供している。
"Ｐａｒｌａｙ Ｘ Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ"、[online]、[平成２０年８月１２日検索]、インターネット、http://www.parlay.org/en/specifications/pxws.asp "ＪＳＲ ２８９：ＳＩＰ Ｓｅｒｖｌｅｔ ｖ１．１"、[online]、[平成２０年８月１２日検索]、インターネット、http://jcp.org/en/jsr/detail?id=289 "ＪＳＲ ２８１：ＩＭＳ Ｓｅｒｖｉｃｅｓ ＡＰＩ" 、[online]、[平成２０年８月１２日検索]、インターネット、http://jcp.org/en/jsr/detail?id=281

非特許文献１〜３に記載の背景技術は、ＩＭＳの知識を十分に持たないアプリケーションソフトウェア開発者にとって利用しやすい形でＡＰＩを提供することにより、アプリケーションソフトウェア開発者がＩＭＳ上のアプリケーションソフトウェアを容易に開発するための技術である。

具体的には、非特許文献１にはＳＯＡＰ Ｗｅｂサービスをプログラム中で呼び出すことによりＩＭＳ系の通信機能を利用する技術が示されている。また、非特許文献２，３にはＳｅｒｖｌｅｔモデルのＡＰＩをプログラム中で呼び出すことによりＩＭＳ系の通信機能を利用する技術が示されている。

しかしながら、インターネットを対象にサービスを行っていた既存アプリケーションソフトウェアを、非特許文献１〜３に記載の技術を用いてＩＭＳ上で提供する場合、サービス提供者は、利用したいＩＭＳのサービスとのインタフェースとなるＡＰＩを呼び出すように既存アプリケーションソフトウェアを書き換える必要がある。この書き換えをインターネットで提供されている個々のサービスの既存アプリケーションソフトウェア全てについて行おうとした場合、サービス提供者にとっての負担が大きい。

本発明はこのような事情に鑑みてなされたものであり、既存アプリケーションソフトウェアの変更を行うことなく、適切な状況下で異なるプロトコルを用いて通信を行うことができるプロトコル変換装置およびプロトコル変換方法を提供することを目的とする。

本発明は、特定のアプリケーションソフトウェアを実行するサーバ装置と、前記サーバ装置が実行する前記特定のアプリケーションソフトウェアと第１のプロトコルを用いてデータの送受信を行う情報処理装置と、プロトコル変換装置とを備える通信システムのプロトコル変換装置であって、前記特定のアプリケーションソフトウェアと前記第１のプロトコルを用いて前記データの送受信を行うサーバ側通信部と、前記情報処理装置と前記第１のプロトコルを用いて前記データの送受信を行うクライアント側通信部と、前記特定のアプリケーションソフトウェアと前記情報処理装置との間での前記データの送受信の開始を要求する要求メッセージを受信する受信部と、前記受信部が前記要求メッセージを受信した場合、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる第２のプロトコルに変換するか否かを判定する判定部と、前記判定部が、前記第２のプロトコルに変換すると判定した場合、前記第２のプロトコルを用いて前記情報処理装置と前記データの送受信を行う通信部と、を備え、前記判定部が、前記第２のプロトコルに変換しないと判定した場合、前記サーバ側通信部と前記クライアント側通信部とは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継し、前記判定部が、前記第２のプロトコルに変換すると判定した場合、前記サーバ側通信部と前記通信部とは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継することを特徴とするプロトコル変換装置である。

この構成によれば、サーバ側通信部は特定のアプリケーションソフトウェアと第１のプロトコルを用いてデータの送受信を行う。また、クライアント側通信部は情報処理装置と第１のプロトコルを用いてデータの送受信を行う。また、受信部は、特定のアプリケーションソフトウェアと情報処理装置との間でのデータの送受信の開始を要求する要求メッセージを受信する。また、受信部が要求メッセージを受信した場合、判定部は、データの送受信で情報処理装置が使用するプロトコルを、第１のプロトコルとは異なる第２のプロトコルに変換するか否かを判定する。判定部が、第２のプロトコルに変換すると判定した場合、通信部は第２のプロトコルを用いて情報処理装置とデータの送受信を行う。

ここで、判定部が、第２のプロトコルに変換しないと判定した場合、サーバ側通信部とクライアント側通信部とは、互いに前記データの入出力を行う。これにより、判定部が、第２のプロトコルに変換しないと判定した場合、すなわち第１のプロトコルを用いて通信を行う場合、サーバ側通信部は第１のプロトコルを用いて特定のアプリケーションソフトウェアとデータの送受信を行う。また、クライアント側通信部は第１のプロトコルを用いて情報処理装置とデータの送受信を行う。また、サーバ側通信部とクライアント側通信部とは互いにデータの入出力を行う。よって、プロトコル変換装置全体では、特定のアプリケーションソフトウェアおよび情報処理装置との間では第１のプロトコルを用いた上で、特定のアプリケーションソフトウェアと情報処理装置との間のデータの送受信を中継することができる。

一方、判定部が、第２のプロトコルに変換すると判定した場合、サーバ側通信部と通信部とは、互いにデータの入出力を行う。これにより、判定部が、第２のプロトコルに変換すると判定した場合、サーバ側通信部は第１のプロトコルを用いて特定のアプリケーションソフトウェアとデータの送受信を行う。また、通信部は第２のプロトコルを用いて情報処理装置とデータの送受信を行う。また、サーバ側通信部と通信部とは互いにデータの入出力を行う。よって、プロトコル変換装置全体では、特定のアプリケーションソフトウェアとの間では第１のプロトコルを用い、情報処理装置との間では第２のプロトコルを用いた上で、特定のアプリケーションソフトウェアと情報処理装置との間のデータの送受信を中継することができる。これらより、既存アプリケーションソフトウェアの変更を行うことなく、適切な状況下で異なるプロトコルを用いて通信を行うことができる。

また、本発明は、前記第２のプロトコルで通信を行う通信装置として前記情報処理装置を動作させるプログラムを前記情報処理装置に送信するプログラム提供部を備えたことを特徴とするプロトコル変換装置である。

この構成によれば、プログラム提供部は、変更後のプロトコルで通信を行う通信装置として前記情報処理装置を動作させるプログラムを情報処理装置に送信する。これにより、情報処理装置が変更後のプロトコルで通信を行うことが出来ない場合においても、情報処理装置はプログラム提供部から送信されたプログラムを実行することにより、変更後のプロトコルで通信を行うことができる。

また、本発明は、前記サーバ側通信部が前記特定のアプリケーションソフトウェアから受信した前記データの特性を変換する特性変換部を備え、前記判定部が、前記第２のプロトコルに変換すると判定した場合、前記通信部は、前記特性変換部が特性を変換した前記データを前記情報処理装置に送信することを特徴とするプロトコル変換装置である。

この構成によれば、特性変換部は、サーバ側通信部が特定のアプリケーションソフトウェアから受信したデータの特性を変換する。また、判定部が、第２のプロトコルに変換すると判定した場合、通信部は、特性変換部が特性を変換したデータを情報処理装置に送信する。これにより、特定のアプリケーションが送信するデータが、第２のプロトコルで送信するための要件を満たしていないデータであっても、プロトコル変換装置は、第２のプロトコルを用いて、このデータを情報処理装置に送信することができる。

また、本発明のプロトコル変換装置において、前記要求メッセージは、前記情報処理装置に送信する前記データを指定する情報を含み、前記判定部は、前記要求メッセージに含まれる前記データを指定する情報に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定することを特徴とする。

この構成によれば、要求メッセージは、情報処理装置に送信するデータを指定する情報を含んでいる。また、判定部は、要求メッセージに含まれるデータを指定する情報に基づいて、データの送受信で情報処理装置が使用するプロトコルを、第１のプロトコルとは異なる第２のプロトコルに変換するか否かを判定する。これにより、情報処理装置に送信するデータに応じて、情報処理装置と通信を行う際に使用するプロトコルを変更するか否かを判定することができる。

また、本発明は、前記サーバ装置の負荷を監視する監視部を備え、前記判定部は、前記監視部が監視した前記サーバ装置の負荷に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定することを特徴とするプロトコル変換装置である。

この構成によれば、監視部は、サーバ装置の負荷を監視する。また、判定部は、監視部が監視したサーバ装置の負荷に基づいて、データの送受信で情報処理装置が使用するプロトコルを、第１のプロトコルとは異なる第２のプロトコルに変換するか否かを判定する。これにより、サーバ装置の負荷に応じて、情報処理装置と通信を行う際に使用するプロトコルを変更するか否かを判定することができる。

また、本発明は、特定のアプリケーションソフトウェアを実行するサーバ装置と、前記サーバ装置が実行する前記特定のアプリケーションソフトウェアと第１のプロトコルを用いてデータの送受信を行う情報処理装置と、プロトコル変換装置とを備える通信システムのプロトコル変換方法であって、サーバ側通信部が、前記特定のアプリケーションソフトウェアと前記第１のプロトコルを用いて前記データの送受信を行うサーバ側通信ステップと、クライアント側通信部が、前記情報処理装置と前記第１のプロトコルを用いて前記データの送受信を行うクライアント側通信ステップと、受信部が、前記特定のアプリケーションソフトウェアと前記情報処理装置との間での前記データの送受信の開始を要求する要求メッセージを受信する受信ステップと、前記受信ステップで前記要求メッセージを受信した場合、判定部が、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる第２のプロトコルに変換するか否かを判定する判定ステップと、前記判定ステップで前記第２のプロトコルに変換すると判定した場合、通信部が、前記第２のプロトコルを用いて前記情報処理装置と前記データの送受信を行う通信ステップと、を含み、前記判定ステップで前記第２のプロトコルに変換しないと判定した場合、前記サーバ側通信ステップと前記クライアント側通信ステップとでは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継し、前記判定ステップで前記第２のプロトコルに変換すると判定した場合、前記サーバ側通信ステップと前記通信ステップとでは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継することを特徴とするプロトコル変換方法である。

また、本発明は、プログラム提供部が、前記第２のプロトコルで通信を行う通信装置として前記情報処理装置を動作させるプログラムを前記情報処理装置に送信するプログラム提供ステップを含むことを特徴とするプロトコル変換方法である。

また、本発明は、特性変換部が、前記サーバ側通信ステップで前記特定のアプリケーションソフトウェアから受信した前記データの特性を変換する特性変換ステップを含み、前記判定ステップで前記第２のプロトコルに変換すると判定した場合、前記通信ステップでは、前記特性変換ステップで特性を変換した前記データを前記情報処理装置に送信することを特徴とするプロトコル変換方法である。

また、本発明のプロトコル変換方法において、前記要求メッセージは、前記情報処理装置に送信する前記データを指定する情報を含み、前記判定ステップは、前記要求メッセージに含まれる前記データを指定する情報に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定することを特徴とするプロトコル変換方法である。

また、本発明は、監視部が、前記サーバ装置の負荷を監視する監視ステップを含み、前記判定ステップでは、前記監視ステップで監視した前記サーバ装置の負荷に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定することを特徴とするプロトコル変換方法である。

本発明によれば、既存アプリケーションソフトウェアのプログラムの変更を行うことなく、適切な状況下で異なるプロトコルを用いて通信を行うことができる。

以下、図面を参照し、本発明の一実施形態について説明する。まず、本発明の実施形態の一例として、既存アプリケーションソフトウェアによるインターネットの映像配信サービスを行う通信システムを、アプリケーションソフトウェアの変更を行うことなく次世代ネットワークを用いて提供する通信システムに変更する例について説明する。

既存のアプリケーションソフトウェアによる映像配信サービスを行う例として、映像データや、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等のデータの種類にかかわらず、ＨＴＴＰで通信を行うアプリケーションソフトウェアを備えた通信システムがある。この通信システムの場合、映像データもＨＴＴＰで送信するため、帯域保証を行った上で映像データの配信を行うことができない。

帯域保証を行った上で映像データを送信するためには、例えば、ＳＩＰによりセッションを確立し、次世代ネットワーク上で映像データを送信するように通信システムを変更する必要がある。本実施形態では既存のアプリケーションソフトウェアを変更することなく、映像データを送信する場合は、変更後のプロトコルであるＳＩＰによりセッションを確立し、次世代ネットワーク上で送信し、映像データ以外のデータを送信する場合は、変更前のプロトコルであるＨＴＴＰで送信する例について説明する。なお、変更前のプロトコルであるＨＴＴＰは第１のプロトコルである。また、変更後のプロトコルであるＳＩＰは第２のプロトコルである。また、既存のアプリケーションソフトウェアは、特定のアプリケーションソフトウェアである。

図１は、本実施形態における配信サービス提供システム１の構成を示した構成図である。配信サービス提供システム１は、サーバ装置である映像配信サーバ１００と、情報処理装置であるクライアント側端末２００と、プロトコル変換装置３００と、次世代ネットワーク４００とを備える。

映像配信サーバ１００は、ＨＴＴＰサーバ部１０１と、記憶部１０５とを備える。映像配信サーバ１００が備えるＣＰＵ上で、ＨＴＴＰで通信を行う既存のアプリケーションソフトウェアが実行されることでＨＴＴＰサーバ部１０１は動的に構成される。動的に構成されたＨＴＴＰサーバ部１０１は、クライアント側端末２００からのリクエストに基づいて、リクエストされたデータをＨＴＴＰで送信する。記憶部１０５は、映像データ１０２と、その他データ１０３とを記憶する。映像データ１０２は、配信する映像データである。その他データ１０３は、ＨＴＭＬデータなど、映像データ以外のデータである。この構成により、映像配信サーバ１００は、ＨＴＴＰで映像データやＨＴＭＬデータなどのデータを配信する。

クライアント側端末２００は、ウェブブラウザ部２２０を備える。ウェブブラウザ部２２０は、ＲＩＡ（Ｒｉｃｈ Ｉｎｔｅｒｎｅｔ Ａｐｐｌｉｃａｔｉｏｎ）ランタイム部２２１とＨＴＴＰクライアント部２２２とを備える。

クライアント側端末２００が備えるＣＰＵ上で、ＲＩＡを実行するために必要なランタイムプログラムが実行されることでＲＩＡランタイム部２２１は動的に構成される。動的に構成されたＲＩＡランタイム部２２１はＲＩＡを実行する。ＲＩＡは、単純なＨＴＭＬで記述されたページよりも操作性や表現力に優れたＷｅｂアプリケーションソフトウェアである。ＨＴＴＰクライアント部２２２は、ＨＴＴＰで配信されるデータを再生する。これにより、クライアント側端末２００は、ウェブブラウザ部２２０を用いて、ＲＩＡを実行することができ、また、ＨＴＴＰで配信されるデータを再生することができる。

プロトコル変換装置３００は、サーバ側通信部であるデータ取得部３１０と、対応ＤＢ（Ｄａｔａｂａｓｅ、データベース）３２０と、クライアント側通信部であるＨＴＴＰインタフェース部３３０と、通信部であるＳＩＰ連携インタフェース部３４０とを備える。ＨＴＴＰインタフェース部３３０は、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ、統一資源識別子）生成部３３１と、プログラム提供部であるＳＩＰ−ＵＡ（ＳＩＰ−Ｕｓｅｒ Ａｇｅｎｔ）提供部３３２と、判定部であるデータ判定部３３３と、受信部であるＨＴＴＰ通信部３３４とを備える。ＳＩＰ連携インタフェース部３４０は、特性変換部３４１と、配信部３４２と、ＵＲＩ判定部３４３と、ＳＩＰ通信部３４４とを備える。

データ取得部３１０は映像配信サーバ１００からデータを受信する。対応ＤＢ３２０は、後述するＳＩＰ−ＵＲＩと対応映像データとを関連付けて記憶する記憶部である。図２は、本実施形態における対応ＤＢ３２０が記憶する情報の例を示した図である。属性としてＳＩＰ−ＵＲＩと、対応映像データとがある。ＳＩＰ−ＵＲＩは、ＳＩＰでセッションを確立する通信先を決定する識別子である。対応映像データは、関連付けられているＳＩＰ−ＵＲＩでプロトコル変換装置３００とクライアント側端末２００との間に通信経路が確立された場合に、この通信経路を確立したクライアント側端末２００に送信する映像データを示す情報である。

図示する例では、ＳＩＰ−ＵＲＩが「ｓｉｐ：ｖｉｄｅｏ０１＠ｓｅｒｖｉｃｅ．ｊｐ」であり、対応映像データが「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ．ｊｐ／ｖｉｄｅｏ０１．ｆｌｖ」である行が示されている。これは、ＳＩＰ−ＵＲＩ「ｓｉｐ：ｖｉｄｅｏ０１＠ｓｅｒｖｉｃｅ．ｊｐ」に基づいてプロトコル変換装置３００とクライアント側端末２００との間に通信経路が確立された場合、「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ．ｊｐ／ｖｉｄｅｏ０１．ｆｌｖ」で指定されるｖｉｄｅｏ０１．ｆｌｖ（映像データ１０２）をクライアント側端末２００に送信することを示す。他の行についても図示する通りである。

図３は、図２に示した対応ＤＢ３２０に、新たにＳＩＰ−ＵＲＩと対応映像データとを記憶した例を示した図である。図示する例では、図２に示した対応ＤＢ３２０が記憶するデータに、ＳＩＰ−ＵＲＩが「ｓｉｐ：ｖｉｄｅｏ２６＠ｓｅｒｖｉｃｅ．ｊｐ」であり、対応映像データが「ｈｔｔｐ：／／ｓｅｒｖｉｃｅ．ｊｐ／ｖｉｄｅｏ２６．ｆｌｖ」であるデータを新たに記憶している。

以下、図１の説明に戻る。ＵＲＩ生成部３３１は、後述する条件に基づいてＳＩＰ−ＵＲＩを生成する。ＳＩＰ−ＵＡ提供部３３２は、ＲＩＡランタイム部２２１上でＳＩＰ−ＵＡとして動作するＲＩＡを提供する。データ判定部３３３は、記憶部１０５が記憶する映像データ１０２に対する要求であるか、その他データ１０３に対する要求であるかを判定する。ＨＴＴＰ通信部３３４は、ＨＴＴＰで通信を行う。

特性変換部３４１は、データ取得部３１０が取得した映像データ１０２の特性の変換を行う。具体例については後述する。配信部３４２は、特性変換部３４１が特性を変換した映像データ１０２を配信する。ＵＲＩ判定部３４３は、要求メッセージを受けた対応映像データが対応ＤＢ３２０に記憶されているか否か判定する。ＳＩＰ通信部３４４は、クライアント側端末２００のＲＩＡランタイム部２２１上で動作するＲＩＡであるＳＩＰ−ＵＡと通信を行う。

次世代ネットワーク４００は、IPネットワークの柔軟性・経済性を備えた、次世代の情報通信ネットワークである。

次に、図４を参照して、本実施形態における配信サービス提供システム１の情報配信方法について説明する。図４は、本実施形態における配信サービス提供システム１がデータを配信する手順を示したフローチャートである。

（ステップＳ１０１）クライアント側端末２００は、ウェブブラウザ部２２０が備えるＨＴＴＰクライアント部２２２を用いて、映像配信サーバ１００にＨＴＴＰリクエストを送信する。本実施形態では、次世代ネットワーク４００と映像配信サーバ１００との間にプロトコル変換装置３００を備えている。そのため、クライアント側端末２００から送信されたＨＴＴＰリクエストは、次世代ネットワーク４００を介して、プロトコル変換装置３００のＨＴＴＰ通信部３３４が受信する。その後、ステップＳ１０２に進む。

（ステップＳ１０２）ＨＴＴＰ通信部３３４は、ステップＳ１０１で受信したＨＴＴＰリクエストをデータ判定部３３３に入力する。続いて、データ判定部３３３は、入力されたＨＴＴＰリクエストが、映像配信サーバ１００の記憶部１０５が記憶する映像データ１０２へのアクセス要求であるか、その他データ１０３へのアクセス要求であるかを判定する。データ判定部３３３が、映像データ１０２へのアクセス要求であると判定した場合はステップＳ１０４に進み、データ判定部３３３が、その他データ１０３へのアクセス要求であると判定した場合はステップＳ１０３に進む。

具体的には、データ判定部３３３は、拡張子などにより要求されたデータの種類を判定し、映像配信サーバ１００の記憶部１０５が記憶する映像データ１０２へのアクセス要求であるか、その他データ１０３へのアクセス要求であるかを判定する。

なお、事前に設定されたその他の条件によって、映像配信サーバ１００の記憶部１０５が記憶する映像データ１０２へのアクセス要求であるか、その他データ１０３へのアクセス要求であるかを判定してもよい。

（ステップＳ１０３）プロトコル変換装置３００は、ステップＳ１０１で受信したＨＴＴＰリクエスト通りに、映像配信サーバ１００の記憶部１０５からその他データ１０３を受信し、受信したその他データ１０３をクライアント側端末２００に送信する。その後、処理を終了する。

具体的には、データ判定部３３３は、データ取得部３１０に対して、ＨＴＴＰリクエストで要求された、記憶部１０５が記憶するその他データ１０３の受信を指示する。続いて、データ取得部３１０は、映像配信サーバ１００のＨＴＴＰサーバ部１０１に記憶部１０５が記憶するその他データ１０３の受信要求を行い、該当するその他データ１０３をＨＴＴＰで受信する。続いて、データ取得部３１０は、受信したその他データ１０３をＨＴＴＰ通信部３３４に入力する。なお、入力は、データ取得部３１０が全てのデータを受信した上でＨＴＴＰ通信部３３４に入力する同期的な方式でも、データ取得部３１０が受信したデータを順次ＨＴＴＰ通信部３３４に入力する非同期な方式のどちらかに限るものではない。

続いて、ＨＴＴＰ通信部３３４はステップＳ１０１で受信したＨＴＴＰリクエストに対するレスポンスとして、映像配信サーバ１００から取得したその他データ１０３をＨＴＴＰクライアント部２２２に送信する。続いて、ウェブブラウザ部２２０は、ＨＴＴＰクライアント部２２２が受信したその他データ１０３を表示する。その後、処理を終了する。

（ステップＳ１０４）データ判定部３３３は、記憶部１０５が記憶する映像データ１０２の取得が要求されたという情報をＵＲＩ生成部３３１に入力する。続いて、ＵＲＩ生成部３３１はＳＩＰ−ＵＲＩを発行する。続いて、ＵＲＩ生成部３３１は、発行したＳＩＰ−ＵＲＩと、取得対象である記憶部１０５が記憶する映像データ１０２を一意に示す対応映像データとを関連付けて対応ＤＢ３２０に書き込む。

なお、ＵＲＩ生成部３３１が生成するＳＩＰ−ＵＲＩは任意の文字列で構わないが、下記の二つの条件を満たす必要がある。
（条件１）ＳＩＰ−ＵＲＩに対して発呼することにより、次世代ネットワーク４００によってプロトコル変換装置３００のＳＩＰ連携インタフェース部３４０にルーチングされるようなものでなくてはならない。
（条件２）既に対応ＤＢ３２０に登録されているＳＩＰ−ＵＲＩの値としてはならない。

続いて、ＵＲＩ生成部３３１は、生成したＳＩＰ−ＵＲＩをＳＩＰ−ＵＡ提供部３３２に入力する。続いて、ＳＩＰ−ＵＡ提供部３３２は、入力されたＳＩＰ−ＵＲＩに対してシグナリングを行うＳＩＰ−ＵＡとして動作するＲＩＡを、ＨＴＴＰ通信部３３４経由でＨＴＴＰクライアント部２２２に送信する。その後、ステップＳ１０５に進む。

（ステップＳ１０５）ウェブブラウザ部２２０は、ＨＴＴＰクライアント部２２２が受信したＲＩＡをＲＩＡランタイム部２２１上で実行する。これにより、ＲＩＡランタイム部２２１上でＳＩＰ−ＵＡが動作し、ＵＲＩ生成部３３１が生成したＳＩＰ−ＵＲＩに対してシグナリングを行う。すなわち、ＳＩＰ連携インタフェース部３４０のＳＩＰ通信部３４４にシグナリングメッセージを送信する。その後、ステップＳ１０６に進む。

（ステップＳ１０６）ＳＩＰ通信部３４４は、シグナリングメッセージを受信すると、受信したシグナリングメッセージに対応するＳＩＰ−ＵＲＩをＵＲＩ判定部３４３に入力する。続いて、ＵＲＩ判定部３４３は、ＳＩＰ通信部３４４から入力されたＳＩＰ−ＵＲＩと関連付けて記憶されている対応映像データを、対応ＤＢ３２０から読み出す。

ここで、ＵＲＩ判定部３４３から入力されたＳＩＰ−ＵＲＩと関連付けて記憶されている対応映像データが対応ＤＢ３２０に記憶されていない場合、ＵＲＩ判定部３４３はＳＩＰ通信部３４４にエラーメッセージを送信する。続いて、ＳＩＰ通信部３４４はクライアント側端末２００上で動作するＳＩＰ−ＵＡに対してエラーメッセージを送信する。

一方、ＵＲＩ判定部３４３から入力されたＳＩＰ−ＵＲＩと関連付けて記憶されている対応映像データが対応ＤＢ３２０に記憶されている場合、ＵＲＩ判定部３４３は、データ取得部３１０に対して、対応映像データで指定される映像データ１０２を記憶部１０５から受信するように指示する。続いて、データ取得部３１０は、映像配信サーバ１００のＨＴＴＰサーバ部１０１経由で、記憶部１０５が記憶する映像データ１０２をＨＴＴＰによって受信し、特性変換部３４１に入力する。データ取得部３１０が特性変換部３４１に映像データ１０２を入力するタイミングは、記憶部１０５から映像データ１０２を受信するタイミングと同期していても非同期であってもかまわない。

続いて、特性変換部３４１は、次世代ネットワーク４００のネットワーク特性に応じた変換（特性変換）を入力された映像データ１０２に対して行う。具体的には、バースト性のあるＨＴＴＰ通信を次世代ネットワーク４００の帯域保証路内で通信可能であるように、映像データ１０２のシェイピング等を行う。ただし、特性変換部３４１が映像データ１０２行う特性変換は、対象となる網や状況によって異なっており、シェイピングだけに限ったものではない。

続いて、特性変換部３４１は、特性変換した映像データ１０２を配信部３４２に入力し、さらにＳＩＰ通信部３４４に対して配信準備完了通知を入力する。続いて、配信準備完了通知を受信したＳＩＰ通信部３４４は、クライアント側端末２００上で動作しているＳＩＰ−ＵＡとの間に帯域保証路を確立する。続いて、配信部３４２は、ＳＩＰ通信部３４４が確立した帯域保証路を通じてクライアント側端末２００に対して映像データ１０２を送信する。続いて、クライアント側端末２００は、ＲＩＡランタイム部２２１上で動作するＳＩＰ−ＵＡによって映像データ１０２を受信する。続いて、ウェブブラウザ部２２０は、受信した映像データ１０２を再生する。これにより、クライアント側端末２００で映像を視聴することができる。

図５は、本実施形態において、クライアント側端末２００から記憶部１０５が記憶するその他データ１０３に対してアクセス要求が行われた際（図４におけるステップＳ１０１、ステップＳ１０２、ステップＳ１０３）の、クライアント側端末２００と、プロトコル変換装置３００と、映像配信サーバ１００との間のメッセージのシーケンスを示したシーケンス図である。

図示する例では、初めにクライアント側端末２００からプロトコル変換装置３００に対して、記憶部１０５が記憶するその他データ１０３の送信要求を含んだＨＴＴＰリクエストが送信される（ステップＳ２０１）。続いて、プロトコル変換装置３００から映像配信サーバ１００に対して記憶部１０５が記憶するその他データ１０３の送信要求が送信される（ステップＳ２０２）。続いて、映像配信サーバ１００からプロトコル変換装置３００に対して、記憶部１０５が記憶するその他データ１０３が送信される（ステップＳ２０３）。続いて、プロトコル変換装置３００からクライアント側端末２００に対して、その他データ１０３が送信される（ステップＳ２０４）。

図６は、本実施形態において、クライアント側端末２００から記憶部１０５が記憶する映像データ１０２に対してアクセス要求が行われた際（図４におけるステップＳ１０１、ステップＳ１０２、ステップＳ１０４、ステップＳ１０５、ステップＳ１０６）の、クライアント側端末２００と、プロトコル変換装置３００と、映像配信サーバ１００との間のメッセージのシーケンスを示したシーケンス図である。

図示する例では、初めにクライアント側端末２００からプロトコル変換装置３００に対して、記憶部１０５が記憶する映像データ１０２の送信要求を含んだＨＴＴＰリクエストが送信される（ステップＳ３０１）。続いて、プロトコル変換装置３００からクライアント側端末２００に対してＳＩＰ−ＵＡとして動作するＲＩＡを送信する（ステップＳ３０２）。続いて、クライアント側端末２００は、ＲＩＡランタイム部２２１上でＳＩＰ−ＵＡとして動作するＲＩＡを実行する。ＲＩＡランタイム部２２１上で動作するＳＩＰ−ＵＡはプロトコル変換装置３００に対してＳＩＰリクエストを送信する（ステップＳ３０３）。

続いて、プロトコル変換装置３００から映像配信サーバ１００に対して、記憶部１０５が記憶する映像データ１０２の配信要求が送信される（ステップＳ３０４）。続いて、映像配信サーバ１００からプロトコル変換装置３００に対して、記憶部１０５が記憶する映像データ１０２が送信される（ステップＳ３０５）。続いて、プロトコル変換装置３００からクライアント側端末２００に対して、帯域保証路が確立したことを示すＳＩＰレスポンスを送信する（ステップＳ３０６）。続いて、プロトコル変換装置３００は、確立した帯域保証路を用いて、クライアント側端末２００に対して映像データ１０２を送信する（ステップＳ３０７）。

上述したとおり、本実施形態では、映像配信サーバ１００とクライアント側端末２００との間に、プロトコル変換装置３００を備える。このプロトコル変換装置３００は、クライアント側端末２００からのリクエストが、記憶部１０５が記憶する映像データ１０２に対するものか、その他データ１０３に対するものかを判定する。その他データ１０３に対するリクエストの場合、プロトコル変換装置３００はＨＴＴＰリクエストとしてクライアント側端末２００からのリクエストを処理する。映像データ１０２に対するリクエストの場合、プロトコル変換装置３００は、クライアント側端末２００にＳＩＰ−ＵＡとして動作するＲＩＡを送信し、クライアント側端末２００はこのＲＩＡを実行する。

これにより、プロトコル変換装置３００とクライアント側端末２００との間では、ＳＩＰによりセッションを確立し、次世代ネットワーク上で映像データの送受信を行うことができるようになる。また、プロトコル変換装置３００は、記憶部１０５から映像データ１０２を取得し、次世代ネットワーク４００のネットワーク特性に応じた変換を行う。続いて、プロトコル変換装置３００はクライアント側端末２００に対して、変換した映像データ１０２をＳＩＰでセッションを確立した次世代ネットワーク上で送信する。

以上の処理により、映像配信サーバ１００が備えている既存アプリケーションソフトウェアの変更を行うことなく、クライアント側端末２００に対して、映像データ１０２を送信する場合は、ＳＩＰによりセッションを確立し、次世代ネットワーク上で映像データ１０２を送信し、その他データ１０３を送信する場合はＨＴＴＰで送信するなど、適切な状況下で異なるネットワーク・プロトコルを用いて通信を行うことができる。

なお、配信サービス提供システム１の構成は、図１に示した映像配信サーバ１００と、プロトコル変換装置３００とを別の装置とした構成に限るものではない。例えば、図７に示すように、映像配信サーバ１００内にプロトコル変換装置３００を備える構成としてもよい。図８は図７に示した構成を詳細に示した構成図である。図１に示した構成と異なる点としては、映像配信サーバ１００内にプロトコル変換装置３００が配置され、映像配信サーバ１００からＨＴＴＰサーバ部１０１が削除されている点である。これは、映像配信サーバ１００内にプロトコル変換装置３００を備えた構成であるため、データ取得部３１０は記憶部１０５が記憶している映像データ１０２とその他データ１０３とを取得する際に、ＨＴＴＰサーバを介することなく取得することができるためである。この場合、既存のアプリケーションはプロトコル変換装置が備える図示せぬＣＰＵ上で実行され、動的に構成されている。なお、この場合も、既存のアプリケーションソフトウェアは、クライアント側端末２００とＨＴＴＰで通信を行うアプリケーションソフトウェアである。この構成では、データ取得部３１０が記憶部１０５から映像データ１０２とその他データ１０３を取得する動作以外の動作は前述した動作と同様である。

図７、図８に示した構成とすることで、映像配信サーバ１００とプロトコル変換装置３００とを１つの装置とすることができ、さらに、ＨＴＴＰサーバ部１０１を用いることなく適切な状況下で異なるネットワーク・プロトコルを用いて通信を行うことができる。

また、図９に示すように、配信サービス提供システム１は、複数の映像配信サーバ１００を備え、複数の映像配信サーバ１００に対するプロトコル変更、変換を１台のプロトコル変換装置３００によって行う構成としてもよい。これにより、配信サービス提供システム１が複数の映像配信サーバ１００を備える場合においても、１台のプロトコル変換装置３００を備えるだけで、適切な状況下で異なるネットワーク・プロトコルを用いて通信を行うことができる。

また、図１０に示すように、配信サービス提供システム１は、クライアント側ゲートウェイ装置２１０を備え、ＲＩＡランタイム部２２１をクライアント側端末２００ではなくクライアント側ゲートウェイ装置２１０が備える構成としてもよい。この構成は、クライアント側ゲートウェイ装置２１０のＲＩＡランタイム部２２１上でＳＩＰ−ＵＡとして動作するＲＩＡを実行する構成である。すなわち、クライアント側端末２００のウェブブラウザ部２２０は、ＨＴＴＰの通信を行うＨＴＴＰクライアント部２２２のみを具備しており、ＲＩＡランタイム部２２１はクライアント側ゲートウェイ装置２１０内に配備される。このとき、クライアント側ゲートウェイ装置２１０は、クライアント側端末２００と通信を行うために、ＨＴＴＰ通信部２１２を備える構成とする。

図１０に示した構成でのプロトコル変換装置３００および映像配信サーバ１００の動作については、図１に示した構成での動作と同様である。クライアント側端末２００から次世代ネットワーク４００へのＨＴＴＰリクエストはクライアント側ゲートウェイ装置２１０を経由するが、クライアント側ゲートウェイ装置２１０は特別な処理は行わずに次世代ネットワーク４００ヘリクエストを転送する。データの受信に関しても、クライアント側ゲートウェイ装置２１０を経由するが、記憶部１０５が記憶するその他データ１０３の受信に関しては、クライアント側ゲートウェイ装置２１０は特別な処理を行わずにＨＴＴＰクライアント部２２２へ受信したデータを送信する。

ただし、クライアント側端末２００が、記憶部１０５が記憶する映像データ１０２の受信を試みて、プロトコル変換装置３００からＳＩＰ−ＵＡとして動作するＲＩＡが送信された場合のみ、クライアント側ゲートウェイ装置２１０はＳＩＰ−ＵＡを受信する。続いてクライアント側ゲートウェイ装置２１０は、受信したＳＩＰ−ＵＡをＲＩＡランタイム部２２１上で実行し、プロトコル変換装置３００へのＳＩＰのシグナリングを行う。そして、ＲＩＡランタイム部２２１上のＳＩＰ−ＵＡが前述のシーケンスで映像データ１０２を受信すると、クライアント側ゲートウェイ装置２１０のＨＴＴＰ通信部２１２は、ＨＴＴＰクライアント部２２２に対して映像データ１０２を送信する。

これにより、クライアント側端末２００がＲＩＡランタイム部２２１を備えていない場合においても、配信サービス提供システム１はクライアント側ゲートウェイ装置２１０を備えることで、適切な状況下で異なるネットワーク・プロトコルを用いて通信を行うことができる。

また、図１１に示すように、配信サービス提供システム１は、１台のクライアント側ゲートウェイ装置２１０と複数のクライアント側端末２００を備え、クライアント側ゲートウェイ装置２１０が複数のクライアント側端末２００に対するＳＩＰ−ＵＡとして動作するＲＩＡを実行する構成としてもよい。

これにより、配信サービス提供システム１が、ＲＩＡランタイム部２２１を備えていないクライアント側端末２００を複数台備える場合においても、１台のクライアント側ゲートウェイ装置２１０を備えるだけで、適切な状況下で異なるネットワーク・プロトコルを用いて通信を行うことができる。

また、図１２に示すように、プロトコル変換装置３００のＳＩＰ連携インタフェース部３４０と、クライアント側端末２００のＲＩＡランタイム部２２１とを第２のネットワークである次世代ネットワーク４００に接続し、プロトコル変換装置３００のＨＴＴＰインタフェース部３３０と、クライアント側端末２００のＨＴＴＰクライアント部２２２とを第１のネットワークであるインターネット４０２に接続する構成としてもよい。この構成により、ＳＩＰによりセッションを確立した通信を次世代ネットワーク４００経由で行い、ＨＴＴＰを用いる通信をインターネット４０２で行うことができる。

また、これまでの説明ではクライアント側端末２００から映像配信サーバ１００に対してデータ取得要求を行う場合で説明したが、クライアント側端末２００がデータ取得要求を送信しなくても、映像配信サーバ１００からクライアント側端末２００にデータを送信する場合もある。例えば、映像配信サーバ１００からクライアント側端末２００に定期的に映像データを送信する場合や、予め映像データの送信時刻が予約されており、予約時刻に映像配信サーバ１００からクライアント側端末２００に映像データを送信する場合などがある。このような場合では、映像配信サーバ１００からクライアント側端末２００に対してデータの配信開始の通知メッセージを送信することからデータの送受信の処理が開始される。このような場合においても、データなどの信号の送受信の向きが異なるだけで、基本的な動作は、クライアント側端末２００から映像配信サーバ１００に対してデータ取得要求を行う場合と同様の動作である。また、本実施形態では映像データの送信の例を説明したが、帯域保証を要求するほかのサービス、例えば、音声通話や音楽配信でも同様に行うことができる。

また、本実施形態では、配信データに応じてプロトコルを変更するか否かを判断したが、映像配信サーバ１００の負荷に基づいてプロトコルを変更するか否かを判断してもよい。例えば、プロトコル変換装置３００は、映像配信サーバ１００の負荷を監視する図示せぬ監視部を備える。監視部が映像配信サーバ１００の負荷を監視する方法としては、映像配信サーバ１００から映像配信サーバ１００の負荷情報を受信する、または、映像配信サーバ１００からデータを取得する際に要した時間に基づいて映像配信サーバ１００の負荷情報を算出する。続いて、プロトコル変換装置３００は、映像配信サーバ１００の負荷が予め定められている閾値以下であると判断した場合は、プロトコルを変更せずにデータを送信し、映像配信サーバ１００の負荷が予め定められている閾値より大きいと判断した場合は、プロトコルを変更してデータを送信する。これにより、映像配信サーバ１００の負荷に応じてプロトコル変換装置３００はプロトコルの変更を行うため、映像配信サーバ１００の負荷を均等化することができる。

また、配信対象のデータが必要とするネットワークの帯域に基づいて、プロトコルを変更するか否か判断してもよい。具体的には、プロトコル変換装置３００は、配信対象のデータを送信するために必要なネットワークの帯域の情報を取得する。データを送信するために必要なネットワークの帯域の情報は、データ毎に予め定めていてもよく、データの容量に応じて算出するようにしてもよい。続いて、プロトコル変換装置３００は、配信対象のデータを送信するために必要なネットワークの帯域が予め定められている閾値より大きいと判断した場合は、プロトコルを変更してデータを配信し、それ以外はプロトコルを変更せずにデータを配信する。これにより、配信対象のデータを送信するために大きなネットワーク帯域が必要な場合には、帯域保証が可能なプロトコルで送信することができる。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成、プログラム、およびシステムはこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

また、プロトコル変換装置の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、プロトコルの変換等を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものであってもよい。

また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ））のように、一定時間プログラムを保持しているものも含むものとする。

また、上記プログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことをいう。また、上記プログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。

本発明の一実施形態における配信サービス提供システムの構成を示した構成図である。 本実施形態における対応ＤＢが記憶する情報の例を示した図である。 本実施形態における対応ＤＢが情報を追加記憶する例を示した図である。 本実施形態における配信サービス提供システムがデータを送信する手順を示したフローチャートである。 本実施形態においてその他データにアクセス要求がある場合でのクライアント側端末と、変更機能部と、映像配信サーバとの間のメッセージのシーケンスを示したシーケンス図である。 本実施形態において映像データにアクセス要求がある場合でのクライアント側端末と、変更機能部と、映像配信サーバとの間のメッセージのシーケンスを示したシーケンス図である。 本実施形態において映像配信サーバ内にプロトコル変換装置を備えた配信サービス提供システムの構成を示した構成図である。 本実施形態において映像配信サーバ内にプロトコル変換装置を備えた配信サービス提供システムの構成を示した構成図である。 本実施形態において複数の映像配信サーバを備えた配信サービス提供システムの構成を示した構成図である。 本実施形態においてクライアント側ゲートウェイ装置を備えた配信サービス提供システムの構成を示した構成図である。 本実施形態において複数のクライアント側端末を備えた配信サービス提供システムの構成を示した構成図である。 本実施形態において次世代ネットワークとインターネットとを備えた配信サービス提供システムの構成を示した構成図である。

符号の説明

１・・・配信サービス提供システム、１００・・・映像配信サーバ、１０１・・・ＨＴＴＰサーバ部、１０２・・・映像データ、１０３・・・その他データ、１０５・・・記憶部、２００・・・クライアント側端末、２１０・・・クライアント側ゲートウェイ装置、２１２，３３４・・・ＨＴＴＰ通信部、２２０・・・ウェブブラウザ部、２２１・・・ＲＩＡランタイム部、２２２・・・ＨＴＴＰクライアント部、３００・・・プロトコル変換装置、３１０・・・データ取得部、３２０・・・対応ＤＢ、３３０・・・ＨＴＴＰインタフェース部、３３１・・・ＵＲＩ生成部、３３２・・・ＳＩＰ−ＵＡ提供部、３３３・・・データ判定部、３４０・・・ＳＩＰ連携インタフェース部、３４１・・・特性変換部、３４２・・・配信部、３４３・・・ＵＲＩ判定部、３４４・・・ＳＩＰ通信部、４００・・・次世代ネットワーク、４０２・・・インターネット

Claims (10)

1. 特定のアプリケーションソフトウェアを実行するサーバ装置と、前記サーバ装置が実行する前記特定のアプリケーションソフトウェアと第１のプロトコルを用いてデータの送受信を行う情報処理装置と、プロトコル変換装置とを備える通信システムのプロトコル変換装置であって、
   前記特定のアプリケーションソフトウェアと前記第１のプロトコルを用いて前記データの送受信を行うサーバ側通信部と、
   前記情報処理装置と前記第１のプロトコルを用いて前記データの送受信を行うクライアント側通信部と、
   前記特定のアプリケーションソフトウェアと前記情報処理装置との間での前記データの送受信の開始を要求する要求メッセージを受信する受信部と、
   前記受信部が前記要求メッセージを受信した場合、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる第２のプロトコルに変換するか否かを判定する判定部と、
   前記判定部が、前記第２のプロトコルに変換すると判定した場合、前記第２のプロトコルを用いて前記情報処理装置と前記データの送受信を行う通信部と、
   を備え、
   前記判定部が、前記第２のプロトコルに変換しないと判定した場合、前記サーバ側通信部と前記クライアント側通信部とは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継し、
   前記判定部が、前記第２のプロトコルに変換すると判定した場合、前記サーバ側通信部と前記通信部とは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継する
   ことを特徴とするプロトコル変換装置。
2. 前記第２のプロトコルで通信を行う通信装置として前記情報処理装置を動作させるプログラムを前記情報処理装置に送信するプログラム提供部
   を備えたことを特徴とする請求項１に記載のプロトコル変換装置。
3. 前記サーバ側通信部が前記特定のアプリケーションソフトウェアから受信した前記データの特性を変換する特性変換部
   を備え、
   前記判定部が、前記第２のプロトコルに変換すると判定した場合、前記通信部は、前記特性変換部が特性を変換した前記データを前記情報処理装置に送信する
   ことを特徴とする請求項１または請求項２のいずれか１項に記載のプロトコル変換装置。
4. 前記要求メッセージは、前記情報処理装置に送信する前記データを指定する情報を含み、
   前記判定部は、前記要求メッセージに含まれる前記データを指定する情報に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定する
   ことを特徴とする請求項１から請求項３のいずれか１項に記載のプロトコル変換装置。
5. 前記サーバ装置の負荷を監視する監視部
   を備え、
   前記判定部は、前記監視部が監視した前記サーバ装置の負荷に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定する
   ことを特徴とする請求項１から請求項３のいずれか１項に記載のプロトコル変換装置。
6. 特定のアプリケーションソフトウェアを実行するサーバ装置と、前記サーバ装置が実行する前記特定のアプリケーションソフトウェアと第１のプロトコルを用いてデータの送受信を行う情報処理装置と、プロトコル変換装置とを備える通信システムのプロトコル変換方法であって、
   サーバ側通信部が、前記特定のアプリケーションソフトウェアと前記第１のプロトコルを用いて前記データの送受信を行うサーバ側通信ステップと、
   クライアント側通信部が、前記情報処理装置と前記第１のプロトコルを用いて前記データの送受信を行うクライアント側通信ステップと、
   受信部が、前記特定のアプリケーションソフトウェアと前記情報処理装置との間での前記データの送受信の開始を要求する要求メッセージを受信する受信ステップと、
   前記受信ステップで前記要求メッセージを受信した場合、判定部が、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる第２のプロトコルに変換するか否かを判定する判定ステップと、
   前記判定ステップで前記第２のプロトコルに変換すると判定した場合、通信部が、前記第２のプロトコルを用いて前記情報処理装置と前記データの送受信を行う通信ステップと、
   を含み、
   前記判定ステップで前記第２のプロトコルに変換しないと判定した場合、前記サーバ側通信ステップと前記クライアント側通信ステップとでは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継し、
   前記判定ステップで前記第２のプロトコルに変換すると判定した場合、前記サーバ側通信ステップと前記通信ステップとでは、互いに前記データの入出力を行い、前記特定のアプリケーションソフトウェアと前記情報処理装置との間の前記データの送受信を中継する
   ことを特徴とするプロトコル変換方法。
7. プログラム提供部が、前記第２のプロトコルで通信を行う通信装置として前記情報処理装置を動作させるプログラムを前記情報処理装置に送信するプログラム提供ステップ
   を含むことを特徴とする請求項６に記載のプロトコル変換方法。
8. 特性変換部が、前記サーバ側通信ステップで前記特定のアプリケーションソフトウェアから受信した前記データの特性を変換する特性変換ステップ
   を含み、
   前記判定ステップで前記第２のプロトコルに変換すると判定した場合、前記通信ステップでは、前記特性変換ステップで特性を変換した前記データを前記情報処理装置に送信する
   ことを特徴とする請求項６または請求項７のいずれか１項に記載のプロトコル変換方法。
9. 前記要求メッセージは、前記情報処理装置に送信する前記データを指定する情報を含み、
   前記判定ステップは、前記要求メッセージに含まれる前記データを指定する情報に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定する
   ことを特徴とする請求項６から請求項８のいずれか１項に記載のプロトコル変換方法。
10. 監視部が、前記サーバ装置の負荷を監視する監視ステップ
    を含み、
    前記判定ステップでは、前記監視ステップで監視した前記サーバ装置の負荷に基づいて、前記データの送受信で前記情報処理装置が使用するプロトコルを、前記第１のプロトコルとは異なる前記第２のプロトコルに変換するか否かを判定する
    ことを特徴とする請求項６から請求項８のいずれか１項に記載のプロトコル変換方法。

Images