JP4458041B2

JP4458041B2 - プログラム、情報処理方法および装置、並びにデータ構造

Info

Publication number: JP4458041B2
Application number: JP2005505581A
Authority: JP
Inventors: 隆野村; 浩之富永; 治彦坂田; 誠之高橋
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2002-07-30
Filing date: 2003-07-30
Publication date: 2010-04-28
Anticipated expiration: 2023-07-30
Also published as: EP1526461A1; WO2004012088A1; EP1526461A4; US7840593B2; US20040243629A1; EP1526461B1; JPWO2004012088A1; EP3447999A1

Description

本発明は、プログラム、情報処理方法および装置、並びにデータ構造に関し、特に、能力が異なる装置間で確実に接続ができるようにしたプログラム、情報処理方法および装置、並びにデータ構造に関する。

最近、インターネットが普及し、インターネットを利用して各種のデータを相手側と授受するユーザが増えてきた。

しかしながら、従来、例えば、相手側の装置に対して所定の画像を伝送しようとした場合、相手側の装置の能力が自分自身の能力と異なるため、実質的には、相互に接続することができず、結局、画像データを伝送することができなくなるといった事態が発生することがあった。

これを防ぐには、ユーザは、相手側の装置の能力を事前に確認する必要がある。

例えば、ストリーミングを行う場合に、RTSP(Real Time Streaming Protocol)（Real Time Streaming Protocol,IETF RFC 2326,April 1998，<http://www.ietf.org/rfc/rfc/2326.txt>）では、サーバとクライアント間でストリームのパラメータを交換する方法として、SDP(Session Description Protocol)（SDP:Session Description Protocol,IETF RFC 2327,April 1998，<http://www.ietf.org/rfc/rfc/2327.txt>）を用いることが規定されている。

しかしながら、RTSPには、具体的にどのようにしてパラメータを交換するのかが規定されておらず、結局、サーバとクライアント間でデータを確実に授受することができない課題があった。

本発明は、このような状況に鑑みてなされたものであり、相手側の装置と確実に接続し、データを授受することができるようにするものである。

本発明のプログラムは、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信先に送信する詳細情報送信ステップと、前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち前記送信先が利用可能な範囲を示す第２の詳細情報を、前記送信先から受信する詳細情報受信ステップと、前記第２の詳細情報に基づいて、前記送信先と通信する通信ステップとを含む処理をコンピュータに実行させる。

Ｍ次元の前記パラメータのそれぞれは、整数値と論理記号の組み合わせで表現されるようにすることができる。

前記論理記号として、複数の前記整数値のいずれか１つの選択を表現する第１の記号と、前記整数値の集合を表す第２の記号が用いられるようにすることができる。

前記第２の記号として、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップが用いられるようにすることができる。

前記サービスを識別する識別子を、前記送信先に送信する識別子送信ステップと、前記識別子に対応する前記第１の詳細情報の送信の要求を、前記送信先から受信する要求受信ステップとをさらに含み、前記詳細情報送信ステップの処理により、前記送信先の要求に基づいて、前記識別子に対応する前記第１の詳細情報を、前記送信先に送信する処理をコンピュータに実行させるようにすることができる。

前記パラメータは、基本単位により正規化されているようにすることができる。

本発明の情報処理方法は、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信先に送信する詳細情報送信ステップと、前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち前記送信先が利用可能な範囲を示す第２の詳細情報を、前記送信先から受信する詳細情報受信ステップと、前記第２の詳細情報に基づいて、前記送信先と通信する通信ステップとを含む。

本発明の情報処理装置は、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信先に送信する詳細情報送信手段と、前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち前記送信先が利用可能な範囲を示す第２の詳細情報を、前記送信先から受信する詳細情報受信手段と、前記第２の詳細情報に基づいて、前記送信先と通信する通信手段とを備える。
本発明のプログラムは、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信者から受信する詳細情報受信ステップと、受信した前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち利用可能な範囲を示す第２の詳細情報を生成する生成ステップと、生成した前記第２の詳細情報を、前記送信者に送信する詳細情報送信ステップとを含む処理をコンピュータに実行させる。
前記生成ステップは、前記各領域について前記主要因パラメータが利用可能な範囲を含むか否かを判定してから、利用可能な範囲を含む前記主要因パラメータを含む前記領域内の他の前記パラメータが利用可能な範囲を含むか否かを判定するようにすることができる。
前記サービスを識別する識別子を、前記送信者から受信する識別子受信ステップと、前記識別子に対応する前記第１の詳細情報の送信の要求を、前記送信者に送信する要求送信ステップとをさらに含み、前記詳細情報受信ステップは、前記識別子に対応する前記第１の詳細情報を、前記送信者から受信する処理をコンピュータに実行させるようにすることができる。
本発明の情報処理方法は、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信者から受信する詳細情報受信ステップと、受信した前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち利用可能な範囲を示す第２の詳細情報を生成する生成ステップと、生成した前記第２の詳細情報を、前記送信者に送信する詳細情報送信ステップとを含む。
本発明の情報処理装置は、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信者から受信する詳細情報受信手段と、受信した前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち利用可能な範囲を示す第２の詳細情報を生成する生成手段と、生成した前記第２の詳細情報を、前記送信者に送信する詳細情報送信手段とを備える。

本発明の第１のプログラム、第１の情報処理方法および第１の情報処理装置においては、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報が、前記ネットワークに接続されている送信先に送信され、前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち前記送信先が利用可能な範囲を示す第２の詳細情報が、前記送信先から受信され、前記第２の詳細情報に基づいて、前記送信先と通信される。
本発明の第２のプログラム、第２の情報処理方法および第２の情報処理装置においては、ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報が、前記ネットワークに接続されている送信者から受信され、受信された前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち利用可能な範囲を示す第２の詳細情報が生成され、生成された前記第２の詳細情報が、前記送信者に送信される。

本発明によれば、サービスの内容を表す情報を生成することができる。特に、サービスの内容を容易に確認することが可能な詳細情報を生成することができる。それにより、サービスの内容を確実に相手側に知らしめることが可能となり、相手側の装置と迅速且つ確実に接続し、データを授受することができる。

本発明によれば、サービスの内容を表現することができる。特に、サービスの内容を容易に確認することが可能な状態で表現することができる。それにより、サービスの内容を確実に確認することが可能となり、相手側の装置と迅速且つ確実に接続し、データを授受することができる。

図１は、本発明を適用したネットワークシステムの構成例を表している。このネットワークシステムにおいては、インターネット１を介して、メディアインスタントメッセージサーバ(Media IM Server)１４に対して、ユーザ端末として、パーソナルコンピュータ１１，１２，並びにPDA(Personal Digital Assistants)１３が接続されている。メディアIMサーバ１４にはまた、アプリケーションサーバ１５もインターネット１を介して接続されている。

パーソナルコンピュータ１１には、ミドルウェアとしてメディアIMクライアント＃１が実装されており、パーソナルコンピュータ１２には、ミドルウェアとしてメディアIMクライアント＃２が実装されている。同様に、PDA１３には、ミドルウェアとしてメディアIMクライアント＃３が実装されている。

アプリケーションサーバ１５には、ミドルウェアとしてメディアIMクライアント＃４が実装されている。アプリケーションサーバ１５は、プリントサービス＃１乃至プリントサービス＃７を、アクセスしてきたユーザに対して提供する。

メディアIMサーバ１４は、これらのメディアIMクライアント＃１乃至メディアIMクライアント＃４の相互のインスタントメッセージ処理を制御する。

図２は、ソフトウェアの構成を表している。上述したメディアIMクライアント＃１乃至メディアIMクライアント＃４は、図２において、メディアIMクライアントミドルウェア３２として示されている。このメディアIMクライアントミドルウェア３２は、IPネットワークトランスポート層３１とAPI(Application Program Interface)３３との間に配置されている。API３３は、アプリケーション＃１乃至アプリケーション＃Ｎと、メディアIMクライアントミドルウェア３２との間のインタフェース処理を実行する。メディアIMクライアントミドルウェア３２は、API３３とIPネットワークトランスポート層３１とのインタフェース処理を実行する。

アプリケーション(Application)＃１乃至アプリケーション＃Ｎは、それぞれサービスエンティティを構成する。

このネットワークシステムにおいては、図３に示されるように、サービスを提供する側のアプリケーション（図３の例では、Application＃１）がサービスプロバイダ(Service Provider)５１とされ、そのサービスの提供を受ける側のアプリケーション（図３の例では、Application＃ｎ）が（サービスを消費する側が）サービスコンシューマ(Service Consumers)５２とされる。

サービスプロバイダ５１とサービスコンシューマ５２は、対応するメディアIMクライアント＃Ｐ１またはメディアIMクライアント＃Ｃ１を介して、インスタントメッセージのプレゼンス機能、メッセージング機能、またはInfo/Query機能を用いて、接続のためのネゴシエーション処理を実行する。ネゴシエーションにより、相手側と接続が可能であることが確認された後、サービスプロバイダ５１とサービスコンシューマ５２は、ピアツーピア（Ｐ２Ｐ）で、接続処理を実行する。

サービスプロバイダ５１とサービスコンシューマ５２は、それぞれサービスエンティティを構成する。サービスエンティティは、そのものが１つのアプリケーションである場合もあれば、複数のサービスエンティティの集合が１つのアプリケーションを形成する場合もある。以下においては、簡単のため、１つのサービスエンティティが１つのアプリケーションに対応しているものとする。

次に、接続処理の詳細を図４乃至図７のフローチャートを参照して説明する。

ステップＳ１において、サービスプロバイダ５１としてのアプリケーション＃１は、名簿(Roster)に登録されている各メンバー(Buddy)に対して、自分自身が提供可能なサービスの種別を表すプロファイルスペースID(Profile Space ID)をアナウンスすることを、メディアIMクライアント＃Ｐ１に指令する。メディアIMクライアント＃Ｐ１は、ステップＳ２において、この指示を受け取ると、ステップＳ３において名簿に予め登録されているメンバーに対して、プロファイルスペースIDをプレゼンスによって通知する。

ここで、メンバー（Buddy）は、メディアIMサーバ１４が提供するインスタントメッセージサービスにおいて、あるユーザ（または、メディアIMクライアント）に対するメッセージ通信の相手のことであり、メディアIMサーバ１４に予め登録されているユーザIDや、ユーザIDに対応付けられたニックネーム等で表される情報である。

また、名簿(Roster)は、そのメンバー（Buddy）のリストであり、すなわち、ユーザ（またはメディアIMクライアント）が、メッセージ通信の相手として設定した他のユーザ（または、他のメディアIMクライアント）のユーザID（またはニックネーム）のリストである。この、ユーザ毎の名簿(Roster)は、メディアIMサーバ１４において一元管理される。

例えば、メディアIMクライアント＃Ｐ１のユーザがメディアIMクライアント＃Ｃ１のユーザをメッセージ通信の相手として設定している場合、メディアIMクライアント＃Ｐ１に対応する名簿には、メディアIMクライアント＃Ｃ１のユーザ（ユーザID等）がメンバーとして登録されている。逆に、メディアIMクライアント＃Ｃ１のユーザがメディアIMクライアント＃Ｐ１のユーザをメッセージ通信の相手として設定している場合、メディアIMクライアント＃Ｃ１に対応する名簿には、メディアIMクライアント＃Ｐ１のユーザがメンバーとして登録されている。

このように、インスタントメッセージによるメッセージ通信を行う場合、互いをメンバーとして予め名簿に登録しておかなければならない。例えば、第１のユーザが、他のメディアIMクライアントの第２のユーザをメンバーとして名簿に登録しているが、第２のユーザが第１のユーザをメンバーとしてそのクライアントに登録してない場合、メッセージ通信を行うためには、第１のユーザは、メッセージ通信の前に第２のユーザにメンバーとして名簿に登録させる必要がある。

この名簿は、メディアIMクライアントよりユーザがメディアIMサーバ１４にログイン（接続）すると、必要に応じてメディアIMサーバ１４よりそのメディアIMクライアントに提供され、ディスプレイ等にGUI（Graphical User Interface）として表示される。その際、メディアIMサーバ１４は、上述した名簿とともに、ユーザが目的のメンバーを容易に識別することができるようにするためのアイコンや、そのメンバーに関する情報（例えば、通信可能か否かを示す情報）であるプレゼンス等の情報をメディアIMクライアントに供給する。名簿等を供給されたメディアIMクライアントは、その名簿の各メンバーにアイコンやプレゼンスを関連付けて表示する。

なお、以上のような名簿を一元管理する専用のサーバを設けるようにしてももちろんよい。

なお、プロファイルスペースID並びにアプリケーションIDは、図１のネットワークシステムに示されるような、インスタントメッセージのプレゼンス機能、メッセージング機能、およびInfo/Query機能をベースとして、アプリケーションレベルでのプロファイルのネゴシエーションを実現するアプリケーションプラットフォームの運用者によって、予め登録され、管理されている。従って、サービスコンシューマ５２は、そのIDに基づいて、その内容を特定することが可能となる。

図８は、パーソナルコンピュータ１１において動作するMPEG４ストリーミングサーバアプリケーションを定義するためのプロファイルスペースの例を表している。同図に示されるように、プロファイルスペースは、そのパーソナルコンピュータにおいて提供されるサービスを表現するＭ次元の空間（スペース）であり、各プロファイルスペースを識別するためのIDであるプロファイルスペースIDとＭ次元のパラメータにより構成される。この例においては、プロファイルスペースIDは、「１００００００１」とされている。また、パラメータは、access method, bit rate(link speed), X scale, Y scale, audio codecにより構成されている。この例の場合、通信に用いられるプロトコルを表すaccess methodの値は、１(RTSP/TCP+RTP/UDP)または２(HTTP tunnelling)とされる。接続されている通信回線の速度を表すbit rateは、６k乃至５１２kbpsとされる。画面の横方向の大きさを表すX scaleは１２８pixel乃至３５２pixelとされ、また画面の縦方向の大きさを表すY scaleは９６pixel乃至２８８pixelとされている。

ここで、プロファイルのaccess methodは、通信に用いられるプロトコルを表しており、例えば、番号１で表されるRTSP(Real Time Streaming Protocol)/TCP(Transmission Control Protocol)+RTP(Real Time Transport Protocol)/UDP(User Datagram Protocol)、または番号２で表されるHTTP(Hyper Text Transfer Protocol)tunnellingのいずれかとされる。また、bit rateは、使用されている通信回線のデータ転送速度を表す。すなわち、bit rateは、アプリケーション＃１がMPEG４ストリーミングサービスを行う際のMPEG４データ転送速度を決定するための情報である。

さらに、ビデオの圧縮伸長方式を表すVideo Codecは、MPEG４とされている。オーディオの圧縮伸長方式を表すaudio codecは、なし(none)、CELP(Code Excited Linear Predictive) ８k，CELP １６k，AAC(Advanced Audio Coding) １６k， AAC ３２k， AAC ４４．１k，AAC ４８kのいずれかとされる。

このように、パラメータは全て数値によって表現されている。これにより、サービスを提供するサービスプロバイダと、サービスの提供を受ける（サービスを利用する）サービスコンシューマとの間で、迅速且つ簡単に、サービスの利用の可否を判定することができる。

図４に戻って、メディアIMサーバ１４は、ステップＳ４において、メディアIMクライアント＃Ｐ１からの通知を受け取ると、ステップＳ５において、これを名簿内の各メンバーにアナウンスする。

アナウンスを受けたメンバー（サービスコンシューマ５２）の１人であるメディアIMクライアント＃Ｃ１は、ステップＳ６において、この通知を受け取ると、ステップＳ７において、プロファイルスペースIDとサービスプロバイダ５１側のアプリケーションID（いまの場合、アプリケーション＃１のID）に基づいて、自分自身がこのプロファイルを受け入れ可能であるか否かを判定する（検証する）。上述したように、このシステムの参加者は、これらのIDに基づいて、その内容（図８に示されているような、相手側装置の機能）を特定することができるので、この判定が可能である。

例えば、各メディアIMクライアント（すなわち、パーソナルコンピュータ１１，１２等）は、図８に示されるような、プロファイルに含まれるパラメータの種類や、そのパラメータが取り得る値の集合に、アプリケーションIDおよびプロファイルIDを関連付けたテーブルと、サービスコンシューマとなるアプリケーションに関する情報を予め保持しており、ステップＳ７において、保持しているテーブルを参照し、ステップＳ６において取得したアプリケーションIDやプロファイルIDに対応するプロファイルに含まれるパラメータの種類やそのパラメータが取り得る値の集合を特定し、さらに、保持しているアプリケーションに関する情報に基づいて、その特定されたパラメータ（パラメータに対応するプロファイル）が、サービスコンシューマとなるアプリケーションの有する機能に対応しているか否か（すなわち、受け入れ可能であるか否か）を判定する。

なお、この、IDと内容の対応関係を記述したテーブルを各装置（パーソナルコンピュータ１１，１２等）に記憶させておくこともできるが、所定のサーバ（例えば、メディアIMサーバ１４）に記憶させておくこともできる。この場合、ユーザが検証のために、このテーブルを利用する度に、ユーザに対して課金するようにすることもできる。これにより、メディアIMサーバ１４の運用者は、利益を得ることができる。

メディアIMクライアント＃Ｃ１は、サービスプロバイダ５１からプレゼンスを受けたプロファイルの内容が、サービスコンシューマが受け入れ可能であると判断した場合、ステップＳ８において、その受け入れ可能なサービスコンシューマ５２となるアプリケーション＃ｎに対して、プレゼンスの内容（図８に示されるような、プロファイルスペースIDに対応するプロファイル）を通知する。ステップＳ９において、アプリケーション＃ｎは、メディアIMクライアント＃Ｃ１からの通知を受信する。

なお、サービスプロバイダからのアナウンス（ステップＳ４乃至Ｓ６）を受け取った各メディアIMクライアントは、ステップＳ７における検証の結果、サービスコンシューマとなる適切なアプリケーションが存在しないと判断した場合、受信したアナウンスを無視する。

サービスコンシューマ５２としてのアプリケーション＃ｎは、サービスプロバイダ５１のプレゼンスの内容を受信すると、ステップＳ１０において、サービスプロバイダ５１から提供されたサービスの詳細情報を取得するように、メディアIMクライアント＃Ｃ１に指示する。ステップＳ１１において、メディアIMクライアント＃Ｃ１は、この指示を受け取ると、ステップＳ１２において、サービスプロバイダ５１が提供するサービスの、上述したプロファイルスペースのパラメータ群の一部または全部のパラメータにより構成されるプロバイダプロファイルの送信を、メッセージング機能またはInfo/Query機能を用いて要求する。この要求には、サービスプロバイダ５１を指定するための宛先情報が含められている。

なお、Info/Query機能を用いて通知や要求を行った場合、メッセージング機能を用いた場合と異なり、受け手側より受信確認の応答が送り手側に供給される。例えば、メディアIMクライアント＃Ｐ１のアプリケーション＃１がメディアIMサーバ１４より名簿(Roster)を取得する場合、メディアIMクライアント＃Ｐ１は、Info/Query機能により、GETコマンド等をメディアIMサーバ１４に供給する。メディアIMサーバ１４は、このGETコマンドを取得すると、取得したことを示す応答を送信元のメディアIMクライアント＃Ｐ１を介してアプリケーション＃１に供給する。アプリケーション＃１は、この応答により、GETコマンドがメディアIMサーバ１４に供給されたことを確認することができる。

このようにアプリケーションレベルにおいて確認応答が送信先より送信元に対して供給されるので、アプリケーションは、Info/Query機能を用いて通知や要求を行うことにより、確実にその通知や要求を送信先に供給することができる。

これに対してメッセージング機能を用いて通知や要求を行う場合、その通知や要求を取得した送信先のアプリケーションは、送信元に上述した確認応答を供給しない。従って、送信元のアプリケーションは、メッセージング機能を用いて供給した通知や要求を、その送信先が取得したか否かを把握することができないので、Info/Query機能を用いた場合と比較して、目的の送信先に確実に供給することができない。しかしながら、メッセージング機能を用いた通知や要求の場合、Info/Query機能を用いた場合と比較して、通信処理が簡潔になるので、処理の負荷を減らすことができる。このメッセージング機能は、例えば、メディアIMクライアント間におけるテキスト文書からなるインスタントメッセージ（INSTANT MESSAGING）の授受に用いられる。

なお、以上のようなInfo/Query機能を用いた通知や要求、またはメッセージング機能を用いた通知や要求は、メディアIMクライアントだけでなくメディアIMサーバも使用可能であり、メディアIMクライアントとメディアIMサーバ間における通知や要求だけでなくメディアIMクライアント間における通知や要求等にも使用可能である。

さらに、これらのInfo/Query機能やメッセージング機能を用いた通知や要求は、コマンドだけでなく、メッセージやパラメータ等、どのようなデータを含んでいても良く、どのような内容であっても良い。

以上のように、メディアIMクライアント＃Ｐ１、メディアIMクライアント＃Ｃ１、およびメディアIMサーバ１４は、メッセージング機能またはInfo/Query機能を用いてデータ（通知や要求等も含む）の授受を行う。

上述したように、プロバイダプロファイルを送信する場合、メディアIMクライアント＃Ｐ１等は、メッセージング機能またはInfo/Query機能のいずれを用いて送信してもよい。ただし、Info/Query機能を用いてプロバイダプロファイルを送信する場合、そのプロバイダプロファイルの送信に対する応答が、送信先より送信元に供給される。

メディアIMサーバ１４は、ステップＳ１３において、メディアIMクライアント＃Ｃ１からの要求を受信すると、ステップＳ１４において、これをメディアIMクライアント＃Ｐ１に送信する。メディアIMクライアント＃Ｐ１は、ステップＳ１５において、メディアIMサーバ１４からの要求を受信すると、ステップＳ１６において、これをサービスプロバイダ５１としてのアプリケーション＃１に供給する。

アプリケーション＃１は、ステップＳ１７において、メディアIMクライアント＃Ｐ１からの要求を受信すると、ステップＳ１８において、サービスコンシューマ５２に対して提供するプロバイダプロファイルを組み立て、メディアIMクライアント＃Ｐ１に送信する。このプロバイダプロファイルの組み立ての詳細は、図１６と図１７のフローチャートを参照して後述する。

アプリケーション＃１により生成されるプロバイダプロファイルの内容は、プロファイルスペース（図８）で定義されているパラメータ群のうち、サービスプロバイダ５１がネットワークのリンクスピードやCPUの負荷状況などのランタイム環境を考慮した上で、サービスコンシューマ５２に対して実際に提供できるパラメータの値の範囲を具体的に設定したものとされる。

図９は、このようにして、生成されるプロバイダプロファイルの例を表している。図９では、このプロバイダプロファイルが、プロファイルディスクリプション(Profile Description)として表されている。

図９は、サービスプロバイダ５１としてのアプリケーション＃１がVGA(Video Graphics Array)系の画角（１６０pixel×１２０pixelまたは３２０pixel×２４０pixel）のみをサポートし、かつPHS(Personal Handyphone System)相当のネットワーク（リンクスピードの最大値が１２８kbpsのネットワーク）に接続されている場合の例を表している。従って、図９の例においては、ネットワークのリンクスピードとの兼ね合いから、画角が図８のプロファイルスペースで規定されている範囲のうち、１６０pixel×１２０pixel(X scale×Y scale)のみに限定されている。

また、図９の例においては、プロファイルスペースIDは、「１００００００１」とされており、図８に示されるプロファイルスペースに対応するプロファイルディスクリプションであることが示されている。すなわち、上述したように、メディアIMクライアント＃Ｃ１がステップＳ１２においてプロバイダプロファイルを要求すると、その要求に応じて、図９に示されるような、ステップＳ３においてメディアIMクライアント＃Ｐ１が供給したプロファイルスペースIDに対応するプロファイルディスクリプション（プロバイダプロファイル）が生成される。

図９のaccess methodは、RTSP/TCP+RTP/UDPまたはHTTP tunnellingのいずれかとされる。bit rateは、６k乃至１２８kbpsとされている。さらに、audio codecは、なし(none)またはCELP ８kとされている。

メディアIMクライアント＃Ｐ１は、ステップＳ１９において、アプリケーション＃１からのプロバイダプロファイルの応答を受信すると、ステップＳ２０において、これをアプリケーション＃ｎに向けてメッセージング機能またはInfo/Query機能を用いて返信する。

メディアIMサーバ１４は、ステップＳ２１において、メディアIMクライアント＃Ｐ１からの返信を受信すると、ステップＳ２２において、これをメディアIMクライアント＃Ｃ１に送信する。ステップＳ２３において、メディアIMクライアント＃Ｃ１は、この返信を受信すると、それをステップＳ２４において、アプリケーション＃ｎに送信する。アプリケーション＃ｎは、ステップＳ２５において、このサービスプロバイダ５１からの返信（図９に示されるプロバイダプロファイルが含まれている）を受信する。

アプリケーション＃ｎは、ステップＳ２５の処理で受信したサービスプロバイダ５１のプロバイダプロファイルと、自分自身が形成するコンシューマプロファイルとのマッチング（比較）を行う。上述したプロバイダプロファイルとコンシューマプロファイルは、後述する図１６と図１７のフローチャートで示される処理で生成される。

ここで、プロバイダプロファイルは、上述したように、メディアIMクライアント＃Ｃ１によりサービスコンシューマが受け入れ可能であると判断された内容のプロファイルスペースに基づいて、アプリケーション＃１が作成したプロファイルである。すなわち、このプロバイダプロファイルに対応するプロファイルスペースは、サービスコンシューマとしてのアプリケーション＃ｎにも対応している。従って、アプリケーション＃ｎは、アプリケーション＃１がプロバイダプロファイルを作成する場合と同様の処理を行い、サービスコンシューマに対応する、このプロファイルスペースのパラメータ群の一部または全部のパラメータにより構成されるプロファイル（すなわち、コンシューマプロファイル）を作成することができる。アプリケーション＃ｎは、受信したサービスプロバイダ５１のプロバイダプロファイルと、このように作成されたコンシューマプロファイルとのマッチングを行う。

上述したように、サービスプロバイダが提示するプロバイダプロファイル（プロファイルディスクリプション）は、数値だけで表現されているため、サービスコンシューマ５２は、自分自身のプロファイルを構成する各パラメータの値の範囲と単純に１次元での比較を行うだけで、整合性を簡単に検証することができる。

ここで、次元とは、パラメータの実質的な数を意味する。すなわち、サービスコンシューマ５２は、コンシューマプロファイルの各パラメータの値の範囲を、そのパラメータに対応するプロバイダプロファイルのパラメータの値の範囲とを１対１で、１つずつ比較する。

そして、コンシューマプロファイルの各パラメータの値の範囲の一部または全部が、そのパラメータに対応するプロバイダプロファイルのパラメータの値の範囲に重なる場合、すなわち、サービスコンシューマ５２が、サービスプロバイダ５１より提供されたサービスを取得することができる（アプリケーション＃１が送信したデータを、アプリケーション＃ｎが受け入れることができる）範囲が存在すると判定した場合、サービスコンシューマ５２は、整合性が確認できたと判定する。

アプリケーション＃ｎは、整合性が確認できた場合、ステップＳ２６において、サービスプロバイダ５１に対して、提供されたサービスへの自分自身（サービスコンシューマ５２）の登録を要求する。メディアIMクライアント＃Ｃ１は、ステップＳ２７において、アプリケーション＃ｎからこの指示を受け取ると、ステップＳ２８において、サービスプロバイダ５１に対して、プロファイルスペースIDに対応させて、サービスコンシューマ５２のアプリケーション＃ｎのアプリケーションIDを登録することにより、サービスの提供先としてサービスコンシューマ５２を登録する、サービスへの登録を、メッセージング機能またはInfo/Query機能を用いて要求する。このとき、プロファイルスペースIDとアプリケーションID（アプリケーション＃ｎのID）がその要求に含められる。

メディアIMサーバ１４は、ステップＳ２９において、メディアIMクライアント＃Ｃ１からの要求を受け取ると、ステップＳ３０において、これをメディアIMクライアント＃Ｐ１に送信する。メディアIMクライアント＃Ｐ１は、ステップＳ３１において、メディアIMサーバ１４からの要求を受信すると、ステップＳ３２において、これをアプリケーション＃１に送信する。アプリケーション＃１は、ステップＳ３３において、サービスコンシューマ５２からの登録要求を受信する。

サービスプロバイダ５１としてのアプリケーション＃１は、ステップＳ１８の処理でサービスコンシューマ５２に対して提供したサービスに対応してサービスコンシューマ５２を登録する。具体的には、プロファイルスペースIDに対応して、サービスコンシューマ５２のアプリケーション＃ｎのアプリケーションIDが対応して登録される。

このように登録されたサービスコンシューマ５２に関する情報は、アプリケーション＃１によりサービスが提供される際に利用される。すなわち、アプリケーション＃１は、この登録された情報を参照し、その情報に基づいてサービスコンシューマ５２のアプリケーション（アプリケーションIDに対応するアプリケーション）に対して、サービスを提供する。

ステップＳ３４において、アプリケーション＃１は、サービスコンシューマ５２より供給された要求であり、アプリケーション＃１がプロファイルスペースIDに対応させてサービスコンシューマ５２のアプリケーション＃ｎのアプリケーションIDを登録することにより、サービスの提供先としてサービスコンシューマ５２を登録させる要求である、サービスへの登録要求に対応する応答（すなわち、アプリケーション＃ｎの登録が完了したか否かを示す情報の供給）をメディアIMクライアント＃Ｐ１に指示し、ステップＳ３５において、この指示を受け取ったメディアIMクライアント＃Ｐ１は、ステップＳ３６において、供給された登録要求に対応する応答である登録結果を、メッセージング機能またはInfo/Query機能を用いて通知する。ステップＳ３７において、この登録結果の通知を受信したメディアIMサーバ１４は、ステップＳ３８において、それをメディアIMクライアント＃Ｃ１に送信する。メディアIMクライアント＃Ｃ１は、ステップＳ３９において、これを受信すると、ステップＳ４０において、アプリケーション＃ｎに送信する。アプリケーション＃ｎは、ステップＳ４１において、登録結果の通知を受信する。

アプリケーション＃ｎは、ステップＳ４２において、サービスプロバイダ５１からのプロファイルディスクリプション（ステップＳ２５の処理で受信したプロバイダプロファイル）に基づく接続性を保証するためのパラメータを、プロファイルアトム(Profile Atom)として決定する。すなわち、アプリケーション＃１が送信したデータを、アプリケーション＃ｎがそのまま利用することが可能な（アプリケーション＃ｎが受け入れることが可能な）パラメータが決定される。このプロファイルアトムの決定処理の詳細は、図２１と図２２のフローチャートを参照して後述する。

図１０は、このプロファイルアトムのディスクリプションの例を表している。この例においては、プロファイルスペースIDが「１００００００１」とされており、図８に示されるプロファイルスペースに対応するプロファイルアトムであることが示されている。すなわち、上述したように、メディアIMクライアント＃Ｃ１の要求に応じてプロファイルスペースIDに対応するプロファイルディスクリプション（プロバイダプロファイル）がメディアIMクライアント＃Ｐ１により作成され、供給されると、メディアIMクライアント＃Ｃ１は、プロファイルスペースIDに対応するコンシューマプロファイルを作成し、それを供給されたプロバイダプロファイルと比較し、整合すると判定した場合、提供されたサービスへの登録処理を行うとともに、それらのプロファイルに対応するプロファイルスペースの各パラメータの範囲から、接続性を保証するための範囲を特定し、図１０に示されるような、それらの範囲のパラメータにより構成されるプロファイルアトムを生成する。

access methodは、HTTP tunnellingとされている。すなわち、図９のプロバイダプロファイルにおけるaccess methodのうち、番号２に対応する方が選択されている。

また、bit rateは４８kbps、 X scaleは１６０、Y scaleは１２０とされている。さらに、audio codecは、CELP ８kとされている。

アプリケーション＃ｎは、ステップＳ４２において、このようにして決定したプロファイルアトムを伴ったコネクト要求を発行する。ステップＳ４３において、メディアIMクライアント＃Ｃ１は、この要求を受信すると、ステップＳ４４において、この要求を、メッセージング機能またはInfo/Query機能を利用して、サービスプロバイダ５１に送信する。メディアIMサーバ１４は、ステップＳ４５において、この要求を受信すると、ステップＳ４６において、その要求をメディアIMクライアント＃Ｐ１に送信する。メディアIMクライアント＃Ｐ１は、ステップＳ４７において、メディアIMサーバ１４からの要求を受信すると、これをステップＳ４８において、アプリケーション＃１に送信する。アプリケーション＃１は、ステップＳ４９において、この要求を受信する。

アプリケーション＃１は、この要求を受信すると、ステップＳ５０において、サービスコンシューマ５２（アプリケーション＃ｎ）がサービスプロバイダ５１（アプリケーション＃１）に対して接続するために必要な接続情報を含む応答を、サービスコンシューマ５２に送信する。この接続情報は、例えば、サービスコンシューマ５２がサービスプロバイダ５１に接続する際にアクセスするアドレスである、サービスプロバイダ５１のアドレスを示すURI(Uniform Resource Identifier)（サービスURI）とすることができる。

アプリケーション＃１からステップＳ５０の処理で送信された応答は、ステップＳ５１において、メディアIMクライアント＃Ｐ１で受信され、メディアIMクライアント＃Ｐ１は、ステップＳ５２において、その応答を、メッセージング機能またはInfo/Query機能を利用して、サービスコンシューマ５２に向けて送信する。メディアIMサーバ１４は、ステップＳ５３において、メディアIMクライアント＃Ｐ１からの応答を受信すると、ステップＳ５４において、これをメディアIMクライアント＃Ｃ１に送信する。メディアIMクライアント＃Ｃ１は、ステップＳ５５において、メディアIMサーバ１４からの応答を受信すると、ステップＳ５６において、これをアプリケーション＃ｎに送信する。アプリケーション＃ｎは、ステップＳ５７において、この応答を受信する。

アプリケーション＃１は、ステップＳ５０において、応答の送信を指示した後、アプリケーション＃ｎからの直接の（メディアIMサーバ１４を介さない）アクセスを待機している。そこで、ステップＳ５８において、アプリケーション＃ｎは、メディアIMサーバ１４を介さずに、ピアツーピアで、アプリケーション＃１のサービスURL(Uniform Resource Locator)にアクセスする。ステップＳ５９において、アプリケーション＃１は、アプリケーション＃ｎからのピアツーピアのURLへのアクセスを受け付ける。

以後、アプリケーション＃１とアプリケーション＃ｎは、ピアツーピアで情報を授受することが可能となる。

以上に説明した手順を行うことにより、最終的に、プロファイルアトムというアプリケーション＃１とアプリケーション＃ｎは、実行可能な機能を事前に交換しているため、アプリケーション＃１とアプリケーション＃ｎとの間の接続性が保証され、情報が授受できないといった事態が発生することが防止される。

以上のように、本発明のアプリケーションプラットフォームは、インスタントメッセージのプレゼンス機能、メッセージング機能、およびInfo/Query機能をベースとして、アプリケーションレベルでのプロファイルのネゴシエーションを実現する新たなプロトコルアーキテクチャを構築している。その結果、このアプリケーションプラットフォームにおけるマッチングメーキングの仕組みを用いることによって、パーソナルコンピュータ、モバイル機器などの能力が異なる（勿論、同一でもよいが）様々なデバイスに実装されたアプリケーション同志が、簡単かつ確実に接続可能となる。これにより、文字、音声、音楽、動画、静止画といった様々な情報からなるリッチメディア情報を、ピアツーピアコミュニケーションで伝送することが可能なシステムを実現することができる。この場合において、最終的に接続性が保証されたアプリケーション（サービスエンティティ同志）がピアツーピアでコミュニケーションを図ることができる。従って、ユーザは、特別の操作を行わずとも、簡単かつ確実に、情報を授受することが可能となる。

上述したアプリケーション（サービスエンティティ）は、パーソナルコンピュータやネットワーク対応のCE(Consumer Electronics)機器のみならず、インターネット１上の商用アプリケーションサーバにも適用することが可能となる。

例えば、図１のアプリケーションサーバ１５においては、商用プリントサービスのアプリケーションが、サービスプロバイダとして、メディアIMクライアント＃４上で実行される。従って、図１におけるパーソナルコンピュータ１１，１２あるいはPDA１３は、アプリケーションサーバ１５との間で上述した手順を実行することで、アプリケーションサーバ１５が提供するプリントサービスを、インターネット１を介して利用することができる。

従って、本発明においては、インターネット１に接続されている各サーバが提供しているサービスを検索することで、サービスプロバイダの一覧をBuddyリストとして、例えば、図１１に示されるように、表示することができる。

図１１の例においては、PDA１３に実装されたメディアIMクライアント＃３上で、サービスコンシューマとして動作しているプリントサービスのアプリケーションが利用できるサービスプロバイダの一覧が表示されている。この場合において、プレゼンス機能を用いることによって、サービスコンシューマに応じてきめ細かく、かつ自由に、商用サービスのステータスを表現することができる。例えば、図１１の例において、商用サービスを運用中であるか否かを、ランプアイコン１３Ａで表示するようにすることができる。この場合、例えば、運用中の商用サービスは、緑色で表示し、休止中の商用サービスは、赤色で表示するようにすることができる。また、図１１の例においては、依頼したプリントが仕上がる時刻、価格などの細かい状況も、ステータス情報として表示されている。

なお、当然のことながら、ユーザ端末上のサービスプロバイダとサービスコンシューマのアプリケーション間においても、ユーザインタフェースおよびプレゼンス機能により、相手先に応じたきめ細かいステータス表示をアプリケーション毎に行うことが可能である。

図１２は、パーソナルコンピュータ１１の構成例を表している。なお、図示は省略するが、他のパーソナルコンピュータ１２も同様に構成される。従って、この図１２には、パーソナルコンピュータ１２の構成としても、適宜、引用される。

図１２において、CPU（Central Processing Unit）１２１は、ROM（Read Only Memory）１２２に記憶されているプログラム、または記憶部１２８からRAM（Random Access Memory）１２３にロードされたプログラムに従って各種の処理を実行する。RAM１２３にはまた、CPU１２１が各種の処理を実行する上において必要なデータなども適宜記憶される。

CPU１２１、ROM１２２、およびRAM１２３は、バス１２４を介して相互に接続されている。このバス１２４にはまた、入出力インタフェース１２５も接続されている。

入出力インタフェース１２５には、キーボード、マウスなどよりなる入力部１２６、CRT(Cathode Ray Tube)、LCD(Liquid Crystal display)などよりなるディスプレイ、並びにスピーカなどよりなる出力部１２７、ハードディスクなどより構成される記憶部１２８、モデム、ターミナルアダプタなどより構成される通信部１２９が接続されている。通信部１２９は、インターネットを含むネットワークを介しての通信処理を行う。

入出力インタフェース１２５にはまた、必要に応じてドライブ１３０が接続され、磁気ディスク１４１、光ディスク１４２、光磁気ディスク１４３、或いは半導体メモリ１４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１２８にインストールされる。

上述したアプリケーション＃１（サービスプロバイダ５１）及びメディアIMクライアント＃Ｐ１またはアプリケーション＃ｎ（サービスコンシューマ５２）及びメディアIMクライアント＃Ｃ１は、CPU１２１により、RAM１２３によりロードされ、実行される。

本発明においては、以上に説明したように、プロファイルにより、サービス内容を記述して、サービスコンシューマに提供される。このプロファイル（プロファイルディスクリプション）は、Ｍ次元のパラメータで表記される。ここで次元とは、パラメータの実質的な数を意味する。図１３に示される例では、プロファイルが５次元のパラメータにより構成されている（Ｍ＝５とされている）。

図１３は、図８の例におけるプロファイルスペースとは異なる、MPEG(Moving Picture Experts Group)４のストリーミングサーバのプロファイルスペースを表している。図１３の例の場合、パラメータは、主に、全体に関連するパラメータ、ビデオに関するパラメータ、並びにオーディオに関するパラメータの３つにより構成される。そのうちの全体に関連するパラメータは、アクセスメソッド(access method)とリンクスピード(Link Speed)とにより構成され、ビデオに関するパラメータは、X scaleとY scaleとにより構成される。すなわち、access method, Link Speed, X scale, Y scale, audio codecの５次元の（５個の）パラメータにより構成される。そして、この５次元のパラメータは、「１００００００２」のプロファイルスペースIDにより識別される。

このプロファイルのaccess methodは、通信に用いられるプロトコルを表し、番号１で表されるRTSP(Real Time Streaming Protocol)/TCP(Transmission Control Protocol)+RTP(Real Time Transport Protocol)/UDP(User Datagram Protocol)、または番号２で表されるHTTP(Hyper Text Transfer Protocol) tunnellingのいずれかとされる。

使用されている通信回線のデータ転送速度を表すLink Speedは、図８の例におけるbit rateに対応し、６kbps乃至１０００００kbpsの範囲のいずれかの値とされる。

画面のＸ軸方向の大きさを表すX scaleは、１２８pixel乃至３５２pixelの範囲とされ、Ｙ軸の方向の大きさを表すY scaleは、９６pixel乃至２８８pixelの範囲とされる。

オーディオの圧縮伸長方式を表すaudio codecは、番号０で表されるなし(none)、番号１で表されるCELP ８ｋ、番号２で表されるCELP(Code Excited Linear Predictive) １６ｋ、番号３で表されるAAC(Advanced Audio Coding) １６ｋ、番号４で表されるAAC ３２ｋ、番号５で表されるAAC ４４．１ｋ、または番号６で表されるAAC ４８ｋのいずれかとされる。

このように、パラメータは、全て整数値で表現される。また、１つの次元を構成する１つのパラメータが、複数の整数値の組み合わせとして表現される場合、次のような論理記号が用いられる。

１つのパラメータが、複数の整数値のいずれか１つとして表現される場合、「OR」（または）の論理記号が用いられる。「OR」は、［ｋ］｜［ｍ］｜［ｎ］のように、［｜］で区切って表される。これは、そのパラメータが、ｋ，ｍ，ｎのいずれか１つとされることを意味する。この場合、ｋ，ｍ，ｎは整数とされ、小さい順番に（ｋ＜ｍ＜ｎのように）、配置される。

例えば、後述する図１５において、access methodが、「１｜２」とされているが、これは、access methodが、１(RTSP/TCP+RTP/UDP)または２(HTTP tunnelling)のいずれかであることを意味する。

１つのパラメータが、所定の範囲の中の整数値で表される場合、その範囲を表す論理記号「：」が用いられる。範囲は、［ｍ］：［ｎ］＃［ｋ］のように表される。［ｍ］は、始値を表し、［ｎ］は、終値を表す。［ｍ］と［ｎ］は、省略することができない。また、当然のことながら、始値［ｍ］は、終値［ｎ］と等しいか、それより小さい値とされる。＃［ｋ］は、始値［ｍ］と終値［ｎ］の間の変化幅を規定するステップを表し、［ｋ］は、自然数かつ正規化のための基本単位を１とする倍数値とされる。［ｋ］は、省略することができる。

例えば、ビデオＸ軸が、「８：２２＃２」と表される場合、これは、ビデオＸ軸が、（８，１０，１２，１４，１６，１８，２０，２２）のいずれかであることを表す。すなわち、正規化のための基本単位が１６ピクセルであるとすると（１６ピクセルがｋ＝１に対応するものとすると）、この表現は、１２８ピクセル乃至３５２ピクセルを、３２ピクセル（ｋ＝２に対応する）おきにサンプリングした値の集合を表す。

サービスを受けることが可能であるのか否の容易な判定が困難になるため、範囲（レンジ）と「OR」の複合記述は禁止される。適用できない（Ｎ／Ａ（not-applicable）のパラメータは、空（,,）(null)で表される。

さらに、プロファイルを具体的に記述する場合には、各パラメータは、正規化のための単位として予め定められた基本単位で正規化される。図１４に示されるように、Link Speedの基本単位は、kbpsとされ、X scaleとY scaleの基本単位は、それぞれ１６pixelとされる。従って、図１３に示されるX scaleの１２８pixel乃至３５２pixelは、１６pixelで正規化すると、８乃至２２と表記され、Y scaleの９６pixel乃至２８８pixelは、６乃至１８と表記される。

以上がパラメータのスタンダードの表記方法とされるが、XML(eXtensible Markup Lunguage) Documentでカスタムな表記を追加することが可能とされる。

また、各次元を構成する要素は、適宜追加することが可能である。例えば、audio codecは、図１３の例の場合、番号０から番号６で表される７個のいずれかとされるが、それ以外の番号７あるいは番号８で表される要素を追加、拡張することができる。

ただし、追加した場合には、下位互換性が確保されることが要求される。すなわち、番号７または番号８で表される追加したaudio codecの要素を有しない装置も、このプロファイルスペースIDが「１００００００２」であるプロファイルスペースを利用することができることが要求される。各装置が、プロファイルスペースIDによりその内容を判定することができることを保証するためである。従って、各次元を構成する要素の数が増加されても、各装置が、プロファイルスペースIDによりその内容を判定することができるので（互換性が確保されるので）、プロファイルスペースIDは、変更されない。逆に、次元が増加された場合には、各装置が、プロファイルスペースIDによりその内容を判定することができないので（互換性が確保できないので）、プロファイルスペースIDは変更される。

また、本発明においては、プロファイルは、他のパラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域(region)に区分して、作成することが可能とされる。

他のパラメータとの共存が制限されるとは、そのパラメータの値が所定の値を取ると、他のパラメータとの組み合わせが困難になるようなパラメータをいう。本発明においては、リンクスピードが主要因パラメータとされる。

例えば、ユーザに、Link Speedとして任意の値を選択させ、audio codecとして任意の値を選択させると、実際には実現できないか、実現が困難となる環境が規定されてしまうことがある。例えば、リンクスピードが５０kbps未満であるアナログの電話回線に接続されているパーソナルコンピュータが、audio codecとして番号５で示されるAAC ４４．１ｋや、番号６で示されるAAC ４８ｋといったaudio codecを選択したとしても、そのような関係は、実際には、実現することが困難となる。

そこで、本発明においては、図１５に示されるように、アナログ電話回線などにおける場合のように、リンクスピードが５０kbps未満（４９kbps以下）の第１の領域（（１）のregion）、ISDN(Integrated Service Digital Network)やPHSなどにおける場合のような、５０kbps以上２００kbps未満（１９９kbps以下）の第２の領域（（２）のregion）、さらにADSL(Asymmetric Digital Subscriber Line)における１．５Mbpsまたは８Mbpsなどにおける場合のような、２００kbps以上の第３の領域（（３）のregion）に区分される。さらに、リンクスピードが２００kbps以上であって、その装置が使用しているCPU(Central Processing Unit)の能力が高い場合の領域として、第４の領域（（４）のregion）が規定される。

図１５の例の場合、第１の領域においては、アクセスメソッドは１または２とされ、リンクスピードは３５kbps乃至４９kbpsとされる。X scaleは１０とされ、Y scaleは７とされる。audio codecは、０または１のいずれかとされる。

第２の領域においては、アクセスメソッドは１または２とされ、リンクスピードは５０kbps乃至１９９kbpsとされる。X scaleとY scaleは、第１の領域における場合と同様に、それぞれ、１０または７とされる。audio codecは、１または２とされる。

第３の領域においては、アクセスメソッドは１または２とされ、リンクスピードは２００kbps乃至１０００００kbpsとされる。X scaleは１０とされ、Y scaleは７とされる。audio codecは１乃至６のいずれかとされる。

第４の領域においては、アクセスメソッドは１または２とされ、リンクスピードは第３の領域における場合と同様に、２００kbps乃至１０００００kbpsとされる。X scaleは２０とされ、Y scaleは１５とされる。audio codecは、１乃至６のいずれかとされる。

各領域においては、５次元の各パラメータは、１次元の整数値として規定される。すなわち、１個の数値として規定される。

プロファイルの分割の数（領域の数）は、各サービスプロバイダが任意に行うことができる。また、プロファイルディスクリプションの値（各領域における各次元の構成要素の値）をいずれの値にするかも、サービスプロバイダが任意に設定することができる。

なお、領域の数が変更されても、プロファイルスペースＩＤは変更されない。

このように、主要因パラメータに基づいて、複数の領域に分割しておくと、１つの領域内においては、サービスコンシューマが５次元のパラメータの値をいずれの値に設定したとしても、実現困難あるいは実現不可能な環境が設定されることがない。従って、サービスコンシューマが複数の領域の中から１つの領域を選択し、その領域の５次元のパラメータの中から任意の値を適宜選択することが可能となる。

具体的には、上述した図５のステップＳ２５の処理で、サービスプロバイダ５１のプロバイダプロファイル（プロファイルディスクリプション）を受信したとき、サービスコンシューマ５２（アプリケーション＃ｎ）は、プロバイダプロファイルの各領域に記述されている主要因パラメータ（リンクスピード）の値を、自分自身のコンシューマプロファイルの主要因パラメータと比較し、整合する部分が存在する領域を抽出する。主要因パラメータは、上述したように、整数で表されているため、単純な整数値演算によって、整合する範囲があるか否かを容易に算出することが可能となる。

パラメータをこのように、領域に区分しない場合には、複雑な場合分けを伴ったプログラムを駆使しなければ、サービスコンシューマ５２は、適用可能なサービスを選択することができなくなる。

以上のように、サービスは、Ｍ次元のパラメータで構成される空間（スペース）により表現される。個々の空間は、プロファイルスペースＩＤにより識別される。個々の空間を構成するパラメータは、整数値と論理記号の組み合わせで表現される。論理記号としては、複数の整数値のいずれか１つの選択を表現する「OR」と、整数値の集合を表す「範囲」が用いられる。サービスをこのようなデータ構造で表現することで、サービスを提供するサービスプロバイダと、サービスの提供を受ける（サービスを利用する）サービスコンシューマとの間で、迅速且つ簡単に、サービスの利用の可否を判定することが可能になる。

次に、サービスプロバイダ５１（アプリケーション＃１）が、サービスコンシューマ５２（アプリケーション＃ｎ）に提供するプロファイル（プロファイルディスクリプション）を作成する処理について、図１６と図１７のフローチャートを参照して説明する。この処理は、図５のステップＳ１８におけるプロバイダファイルの組立処理に対応する処理である。

いま、アプリケーション＃１が、図１３に示されたプロファイルスペースIDが「１００００００２」のプロバイダプロファイル（自分自身の機能に関するプロファイル）を生成するものとする。そして、アプリケーション＃１は、８MbpsのADSL回線に接続されており、その実際の回線のスループットの値（CurrentLinkSpeed（カレントリンクスピード））から、主要因パラメータであるリンクスピードは４８００kbpsであり、ビデオの表示系はVGA(Video Graphics Array)系であり、CPUの処理能力は、比較的低いものであるとする。

以下の各ステップにおいて、アプリケーション＃１は、各領域に対応する自分自身の能力（機能）を調べ、各パラメータに、各領域に対応する自分自身の能力に対応する値を設定する。従って、以下に述べる各ステップにおいて各パラメータに設定される具体的数値は、各領域に対応する自分自身の能力に対応する値である。アプリケーション＃１は、自分自身の能力を、各ステップにおいて、その都度調べてもよいし、予め、調べて記憶しておいたものを読み出して使用するようにしてもよい。

ステップＳ７１において、アプリケーション＃１は、パラメータを設定する変数PSIdに、いま対象とされているプロファイルスペースIDの値「１００００００２」を設定する。

以下、ステップＳ７２乃至ステップＳ７８において、第１の領域に関するパラメータの設定処理が行われ、ステップＳ７９乃至ステップＳ８５において、第２の領域に関するパラメータの設定が行われ、ステップＳ８６乃至ステップＳ９２において、第３の領域に関するパラメータの設定が行われ、そして、ステップＳ９３乃至ステップＳ９８において、第４の領域に関するパラメータの設定が行われる。

ステップＳ７２において、アプリケーション＃１は、領域が第１の領域であることを表す変数PSId.regionに値「１」を設定する。

すなわち、図１８に示されるように、プロファイルスペースIDが１００００００２のプロファイルは、PSId（プロファイルスペースID）をルートとして、region(Region)毎に、access(Access Method), linkSpeed(Link Speed), xScale(X scale), yScale(Y scale), audio(Audio Codec)の各パラメータで構成される。以下、上記ツリーの構造は、各階層を（．）で区切り、例えば、PSId.region.accessという記述方法で記述する。

従って、PSId.regionには、具体的には、「１００００００２．１」が設定されることになる。ただし、図１６と図１７においては、記述が長くなるので、新たに設定されたパラメータだけが示されている。

ステップＳ７３において、アプリケーション＃１は、Access Methodとして、１：RTSP/TCP+RTP/UDP、または２：HTTP tunnellingを示す｛１｜２｝をPSId.region.accessに設定する。これは、上述したように、アプリケーション＃１が、「RTSP/TCP+RTP/UDP」を用いた通信を行う機能を有するとともに、「HTTP tunnelling」を用いた通信を行う機能をも有するからである。仮に、アプリケーション＃１が、「RTSP/TCP+RTP/UDP」を用いた通信を行う機能しか有していないのであれば（「HTTP tunnelling」を用いた通信を行う機能を有していないのであれば）、アプリケーション＃１は、Access Methodとして、１：RTSP/TCP+RTP/UDPを示す｛１｝をPSId.region.accessに設定することになる。

ステップＳ７４において、アプリケーション＃１は、Link Speedとして、３０kbpsから４９kbpsを表す｛３９：４９｝を、PSId.region.linkSpeedに設定する。これは、いま処理対象としている領域が第１の領域であり、第１の領域のデフォルトのLink Speedが、３０kbpsから４９kbpsであるからである（従って、後述するように、対応する第２乃至第４の領域のステップＳ８１，Ｓ８８，Ｓ９５の処理では、各領域におけるデフォルトのLink Speedである、５０kbpsから１９９kbps，２００kbpsから１０００００kbps，または２００kbpsから１０００００kbpsが、それぞれ設定される）。

ステップＳ７５において、アプリケーション＃１は、Xscaleとして、１６０pixelを示す｛１０｝を、PSId.region.xScaleに設定し、Y scaleとして、１１４pixelを示す｛７｝を、PSId.region.yScaleに設定する。これらの値も、アプリケーション＃１が有する画像表示の画角に関する機能に基づくものである。

ステップＳ７６において、アプリケーション＃１は、audio Codecとして０：none、または１：CELP ８ｋを表す｛０｜１｝を、PSId.region.audioに設定する。これも、アプリケーション＃１が、audio Codecとして０：none、または１：CELP ８ｋの両方の機能に対応しているからである。

次に、ステップＳ７７において、アプリケーション＃１は、自分自身が実際に接続されている回線の実効スループットを示すカレントスピード(Current Link Speed)の値が、次の第２の領域の下限値である５０kbpsと比較して、それより小さいか否かを判定する。カレントリンクスピードが５０kbpsより小さい場合には、第２の領域以上の領域を規定することができないので、ステップＳ７８に進み、アプリケーション＃１は、Link Speedとして３０kbpsからカレントリンクスピード(CurrentLinkSpeed)までの値を示す｛３０：CurrentLinkSpeed｝をPSId.region.linkSpeedに再度設定する。すなわち、ステップＳ７４の処理で設定された値｛３０：４９｝の値が更新される。これにより、使用可能な最大の値がパラメータとして設定される。

いまの場合、アプリケーション＃１のCurrentLinkSpeedは、４８００kbpsであるため、５０kbpsより大きいのでステップＳ７９に進み、第２の領域のパラメータ設定処理が実行される。

ステップＳ７９において、アプリケーション＃１は、PSId.regionに第２の領域である値「２」を設定する。具体的には、PSId.regionに「１００００００２．２」が設定されることになる。

ステップＳ８０において、ステップＳ７３における場合と同様に、アプリケーション＃１は、Access Methodとして｛１｜２｝を、PSId.region.accessに設定する。

ステップＳ８１において、アプリケーション＃１は、Link Speedとして、５０kbpsから１９９kbpsを示す｛５０：１９９｝を、PSId.region.linkSpeedに設定する。

ステップＳ８２において、アプリケーション＃１は、ステップＳ７５における場合と同様に、X Scaleとして｛１０｝を、PSId.region.xScaleに設定し、Y Scaleとして｛７｝を、PSId.region.yScaleに設定する。

ステップＳ８３において、アプリケーション＃１は、Audio Codecとして１：CELP ８ｋ、または２：CELP １６ｋを示す｛１｜２｝を、PSId.region.audioに設定する。

ステップＳ８４において、アプリケーション＃１は、CurrentLinkSpeedの値が、次の第３の領域の下限値である２００kbpsと比較して、それより小さいか否かを判定する。CurrentLinkSpeedの値が２００kbpsより小さい場合には、第３の領域のパラメータを設定することができないので、ステップＳ８５に進み、アプリケーション＃１は、Link Speedとして｛５０：CurrentLinkSpeed｝を、PSId:region:linkSpeedに再度設定する。すなわち、ステップＳ８１で設定された｛５０：１９９｝の値が更新される。

ステップＳ８４において、CurrentLinkSpeedの値が、２００kbpsより大きいと判定された場合、ステップＳ８６に進み、第３の領域のパラメータ設定処理が実行される。いまの場合、アプリケーション＃１は、そのCurrentLinkSpeedの値は、４８００kbpsであるため、ステップＳ８４において、NOの判定が行われ、ステップＳ８６以降の処理が実行される。

ステップＳ８６において、アプリケーション＃１は、第３の領域の値「３」をPSId.regionに設定する。具体的には、PSId.regionに「１００００００２．３」の値が設定される。

ステップＳ８７において、アプリケーション＃１は、ステップＳ８０における場合と同様に、Access Methodとして｛１｜２｝を、PSId.region.accessに設定する。

ステップＳ８８において、アプリケーション＃１は、Link Speedとして、２００kbpsから１０００００kbpsを示す｛２００：１０００００｝を、PSId.region.linkSpeedに設定する。

ステップＳ８９において、アプリケーション＃１は、ステップＳ８２における場合と同様に、X Scaleとして｛１０｝を、PSId.region.xScaleに設定し、Y Scaleとして｛７｝を、PSId.region.yScaleに設定する。

ステップＳ９０において、アプリケーション＃１は、Audio Codecとして、１：CELP８ｋ，２：CELP１６ｋ，３：AAC１６ｋ，４：AAC３２ｋ，５：AAC４４．１ｋ、または６：AAC ４８ｋを示す｛１｜２｜３｜４｜５｜６｝を、PSId.region.audioに設定する。

ステップＳ９１において、アプリケーション＃１は、次の第４の領域のパラメータを設定する条件として、CPUの性能が低いか否かを判定する。CPUは、そのクロックの周波数が予め設定されている所定の基準の周波数（例えば、８００MHz）より低い場合、あるいは所定の種類（例えば、Pentium（登録商標）４）より低い機能のCPUである場合には、CPUの性能が低いと判定される。

いまの場合、アプリケーション＃１のCPUは性能が低いため、ステップＳ９１でYESと判定され、ステップＳ９２において、アプリケーション＃１は、第３の領域のLink Speedの更新処理を行う。これにより、Link Speedとして｛２００：CurrentLinkSpeed｝と設定されていたものが、PSId.region.linkSpeedに再度設定される。すなわち、ステップＳ８８の処理で設定された｛２００：１００００００｝の値が、使用可能な最大値に更新される。

ステップＳ９１において、CPUの性能が低くない（高い）と判定された場合（クロック周波数が８００MHz以上であるか、またはPentium（登録商標）４と同等か、それ以上の機能のCPUである場合）には、ステップＳ９３に進み、第４の領域のパラメータ設定処理が実行される。

ステップＳ９３において、アプリケーション＃１は、第４の領域であることを表す値「４」を、PSId.redionに設定する。具体的には、「１００００００２．４」が設定される。

ステップＳ９４において、アプリケーション＃１は、ステップＳ８７における場合と同様に、Access Methodとして｛１｜２｝を、PSId.region.accessに設定する。

ステップＳ９５において、アプリケーション＃１は、ステップＳ８８における場合と同様に、Link Speedとして｛２００：１０００００｝を、PSId.region.linkSpeedに設定する。

ステップＳ９６において、アプリケーション＃１は、X scaleとして３２０pixelを示す｛２０｝を、PSId.region.xScaleに設定し、Y scaleとして２４０pixelを示す｛１５｝を、PSId.region.yScaleに設定する。

ステップＳ９７において、アプリケーション＃１は、ステップＳ９０における場合と同様に、Audio Codecとして｛１｜２｜３｜４｜５｜６｝を、PSId.region.audioに設定する。

最後に、ステップＳ９８において、アプリケーション＃１は、Link Speedとして｛２００：CurrentLinkSpeed｝を、PSId.region.linkSpeedに再度設定する。すなわち、ステップＳ９５の処理で設定された｛２００：１０００００｝の値が更新される。

以上のようにして、設定されたサービスプロバイダ５１としてのアプリケーション＃１のプロバイダプロファイル（プロバイダプロファイルディスクリプション）が図１９に示されている。同図に示されるように、この場合、上述したステップＳ７１乃至ステップＳ９２の処理により、３つの領域のパラメータが設定されている。設定されているパラメータは、図１６と図１７を参照して説明した値の通りである。

図１６と図１７に示されるプロファイルディスクリプション作成処理は、サービスコンシューマ５２としてのアプリケーション＃ｎにおいても実行され、それによりコンシューマプロファイルが作成される。但し、図１６と図１７の各ステップに記載されているパラメータの具体的な値は、アプリケーション＃１のものであり、アプリケーション＃ｎのものではないので、各ステップで設定される値は異なるものとなる。

例えば、サービスコンシューマ５２としてのアプリケーション＃ｎが比較的低速なISDN６４kbpsの回線に接続され、実効スループットであるCurrentLinkSpeedが４８kbpsであるとする。この場合、図１６と図１７に示されるプロファイルディスクリプション作成処理が実行されると、ステップＳ７１乃至ステップＳ７８の第１の領域の処理のみが実行される。すなわち、CurrentLinkSpeedの値（４８kbps）が５０kbpsより小さいため、ステップＳ７７において、YESと判定され、ステップＳ７９以降の処理は実行されない。

すなわち、この場合、アプリケーション＃ｎは、ステップＳ７１において、PSIdに、「１００００００２」を設定し、ステップＳ７２において、PSId.regionとして第１の領域であることを示す値「１」を設定する。具体的には、PSId.regionに「１００００００２．１」が設定される。

ステップＳ７３において、アプリケーション＃ｎは、Access Methodとして｛１｜２｝を、PSId.region.accessに設定する。

ステップＳ７４において、アプリケーション＃ｎは、Link Speedとして｛３０：４８｝を、PSId.region.linkSpeedに設定する。

ステップＳ７５において、アプリケーション＃ｎは、X Scaleとして｛１０｝を、PSId.region.xScaleに設定し、Y Scaleとして｛７｝を、PSId.region.yScaleに設定する。

ステップＳ７７において、CurrentLinkSpeedの値は、４８kbpsであるため、５０kbpsより小さいと判定され、ステップＳ７８において、アプリケーション＃ｎは、Link Speedとして｛３０：CurrentLinkSpeed｝を、PSId.region.linkSpeedに再度設定する。すなわち、ステップＳ７４で設定された｛３０：４９｝の値が更新される。

以上のようにして、アプリケーション＃ｎにより生成されたコンシューマプロファイル（コンシューマプロファイルディスクリプション）は、図２０に示されるようになる。同図に示されるように、領域は、第１の領域だけとされる。この領域に設定される各パラメータは、上述したステップＳ７１乃至ステップＳ７８の処理で設定された値である。

アプリケーション＃ｎが図２０に示されるコンシューマプロファイルを有する場合、アプリケーション＃１から図１９に示されるようなプロバイダプロファイルが送信されてくると、図６のステップＳ２６において、アプリケーション＃ｎは、コンシューマプロファイルの主要因パラメータとしてのリンクスピード３０：４８（図２０）が、プロバイダプロファイルの主要因パラメータの値に整合する部分があるか否かを判定することになる。図１９のプロバイダプロファイルは、第１の領域のリンクスピードが３０：４９であり、第２の領域のリンクスピードが５０：１９９であり、第３の領域のリンクスピードが２００：４８００であるため、少なくとも１つの領域（第１の領域）において、整合する部分（重なる部分）がある（３０乃至４９の範囲は、３０乃至４８の値で、３０乃至４８の範囲と重なっている）と判定されることになる。その結果、上述したように、図６のステップＳ２６で、アプリケーション＃ｎは、提供されたサービスへの登録要求処理を実行し、その後、ステップＳ４２で、プロファイルアトムを作成することになる。

次に、図２１と図２２のフローチャートを参照して、このプロファイルアトム生成処理について説明する。この処理は、図７のステップＳ４２において実行される処理に対応する。

この処理では、最初に、ステップＳ１１１乃至ステップＳ１１５の処理で、サービスプロバイダが提示した各領域毎のパラメータ群から、サービスコンシューマが接続されているネットワークのLink Speed（主要因パラメータ）を考慮して、領域(Region)が選択される。

すなわち、ステップＳ１１１において、アプリケーション＃ｎは、アプリケーション＃１から送信されてきたプロバイダプロファイルディスクリプション（図１９）を受信する。この処理は、図６のステップＳ４１の処理に対応する。

次に、ステップＳ１１２において、アプリケーション＃ｎは、内部の変数Ｎの値を０に初期化する。ステップＳ１１３において、アプリケーション＃ｎは、ステップＳ１１１の処理で受信したプロバイダプロファイルと、自分自身が図１６と図１７の処理を実行することで作成したコンシューマプロファイル（図２０）の中から、Ｎ＋１の領域の（いまの場合、Ｎ＝０であるので、第１の領域の）パラメータを抽出する。

ステップＳ１１４において、アプリケーション＃ｎは、ステップＳ１１３の処理で抽出した領域のLink Speedが重なるか否かを判定する。いまの場合、第１の領域のLink Speedが重なるか否かが判定される。両者のLink Speedが重ならない場合には、ステップＳ１１６に進み、値Ｎが０以外の値であるか否かを判定する。いまの場合、値Ｎは０であるため、NOと判定される。すなわち、この場合には、Link Speedが重なる領域が１個も存在しないことになるので、アプリケーション＃ｎは、アプリケーション＃１と通信することができないことになる。そこで、処理は終了される。

図１９と図２０に示される例の場合、図２０の第１の領域のLink Speedの３０：４８は、図１９の第１の領域のLink Speedの３０：４９と重なるので、ステップＳ１１５に進み、アプリケーション＃ｎは、変数Ｎの値を１だけインクリメントする（いまの場合、Ｎ＝１とする）。

その後、ステップＳ１１３に戻り、アプリケーション＃ｎは、Ｎ＋１の領域（いまの場合、Ｎ＝１なので、第２の領域）のプロバイダプロファイルとコンシューマプロファイルのパラメータをアプリケーション＃ｎは取り出す。

ステップＳ１１４において、アプリケーション＃ｎは、ステップＳ１１３の処理で取り出されたパラメータのうちの、Link Speedが重なるか否かを判定する。第２の領域のLink Speedが重なる場合には、ステップＳ１１５に進み、変数Ｎの値がさらに１だけインクリメントされる（いまの場合、Ｎ＝２とされる）。

そして、ステップＳ１１３において、Ｎ＋１の領域（いまの場合、Ｎ＝２なので、第３の領域）のプロバイダプロファイルとコンシューマプロファイルが読み出される。ステップＳ１１４において、ステップＳ１１３で取り出されたパラメータのLink Speedが重なるか否かが判定され、重なる場合には、再び、ステップＳ１１５に進み、変数Ｎの値が１だけインクリメントされる（いまの場合、Ｎ＝３とされる）。

以上のようにして、ステップＳ１１３乃至ステップＳ１１５の処理が繰り返し実行されることで、Link Speedが重なる全ての領域が抽出される。プロバイダプロファイルとコンシューマプロファイルのうち、対応する領域がもはや存在しない場合、あるいは存在したとしても、Link Speedが重ならないと判定された場合には、処理はステップＳ１１４からステップＳ１１６に進められ、値Ｎが０以外の値であるか否かが判定される。この場合における値Ｎは、ステップＳ１１３乃至ステップＳ１１５の処理により、Link Speedが重なる領域のうちの、最も番号が大きい領域（最も高機能の領域）のその番号に対応している。従って、Link Speedが１個でも重なる領域が存在する場合には、値Ｎは、０以外の値ということになる。

この場合、ステップＳ１１７に進み、アプリケーション＃ｎは、第Ｎ番目の領域のプロバイダプロファイルとコンシューマプロファイルのパラメータを取り出す。ステップＳ１１８において、アプリケーション＃ｎは、ステップＳ１１７の処理で取り出したプロバイダプロファイルのAccess MethodとコンシューマプロファイルのAccess Methodが重なるか否かを判定する。

図１９と図２０に示される例の場合、第１の領域のAccess Methodは、いずれも｛１｜２｝であるから、Access Methodが重なると判定される。もし、Access Methodが重ならないと判定された場合には、ステップＳ１１９に進み、変数Ｎの値が１だけデクリメントされる。すなわち、処理対象とされる領域が、１つだけ番号の値が小さい領域に変更される。そして、ステップＳ１１６において、値Ｎが０以外の値であるか否かが判定され、０以外の値ではない、すなわち、０であると判定された場合には、結局、プロファイルアトムが見つからなかったことになるため、処理は終了される。

このように、５次元のパラメータのうちの、１つでも重ならないパラメータが存在する場合には、１つ下の番号の領域に処理対象が移される。同様に、後述するステップＳ１２６において、X scaleとY scaleが重ならないと判定された場合、並びにステップＳ１２９において、Audioが重ならないと判定された場合にも、１つ下の番号の領域に処理対象が移されることになる。

図１９と図２０の例の場合、第１の領域のAccess Methodは、いずれも｛１｜２｝であるため、両者が重なることになるので、ステップＳ１２０に進み、アプリケーション＃ｎは、HTTP Tunnellingを優先することが選択されているか否かが判定される。ファイアウォールがインターネット１との間に存在する場合には、HTTP Tunnellingを優先することが選択されている。

この場合、ステップＳ１２１に進み、アプリケーション＃ｎは、プロファイルアトム(Profile Atom)のAccess MethodであるAtomAccessに｛２｝（図１３）を設定する。これに対して、ステップＳ１２０において、HTTP Tunnellingが優先されていないと判定された場合には、ステップＳ１２２において、アプリケーション＃ｎは、AtomAccessに｛１｝（図１３）を設定する。

ステップＳ１２１、またはステップＳ１２２の処理の後、ステップＳ１２３に進み、アプリケーション＃ｎは、CurrentLinkSpeedの値が、プロバイダプロファイルのLinkSpeedの最大値と等しいか、それより小さいか否かを判定する。アプリケーション＃ｎが接続されている回線の実効スループットを示すCurrentLinkSpeedの値が、プロバイダプロファイルのLink Speedのパラメータの最大値以下である場合には、ステップＳ１２４において、アプリケーション＃ｎは、AtomLinkSpeedにCurrentLinkSpeedの値を設定する。

これに対して、ステップＳ１２３において、CurrentLinkSpeedの値が、プロバイダプロファイルのLink Speedの最大値より大きいと判定された場合には、ステップＳ１２５において、アプリケーション＃ｎは、AtomLinkSpeedにプロバイダプロファイルのLinkSpeedの最大値を設定する。

例えば、CurrentLinkSpeedが４８kbpsであり、プロバイダプロファイルのLinkSpeedのパラメータの最大値が４９kbpsであれば、ステップＳ１２５において、プロファイルアトムのAtomLinkSpeedに｛４８｝が設定される。

次に、ステップＳ１２６において、アプリケーション＃ｎは、プロバイダプロファイルとコンシューマプロファイルのX scaleとY scaleが重なるか否かを判定する。両者が重ならない場合には、上述したように、ステップＳ１１９に進み、値Ｎを１だけデクリメントして、番号が１だけ小さい領域の処理に移行する。

ステップＳ１２６において、X scaleとY scaleが重なると判定された場合、ステップＳ１２７において、アプリケーション＃ｎは、プロファイルアトムのX scaleであるAtomXscaleに、重なったX scaleの最大値を設定する。さらに、ステップＳ１２８において、アプリケーション＃ｎは、プロファイルアトムのY scaleであるAtomYscaleに、重なったY scaleの最大値を設定する。

例えば、プロバイダプロファイルとコンシューマプロファイルのいずれもX scaleの最大値が１６０pixel（１０×１６pixel）であり、Y scaleの最大値が１１２pixel(７×１６pixel)となっている場合、プロファイルアトムのAtomXscaleに｛１０｝が設定され、AtomYscaleに｛７｝が設定される。

ステップＳ１２９において、プロバイダプロファイルとコンシューマプロファイルのAudio Codecの重なりが判定される。両者が重ならない場合には、上述したように、ステップＳ１１９に進み、値Ｎが１だけデクリメントされ、１つだけ小さい番号の領域の処理に移行する。

ステップＳ１２９において、プロバイダプロファイルとコンシューマプロファイルのAudio Codecが重なると判定された場合、ステップＳ１３０に進み、アプリケーション＃ｎは、プロファイルアトムのAudio CodecであるAtomAudioに、重なったAudio Codecの中で最も音質の良いものを選択し、設定する。本例においては、プロファイル内に記述される各Audio Codecに対して、音質の低いものから高いものの順番に値が大きくなるようにパラメータの番号付けが行われており、重なったAudio Codecの中で最も大きい番号のものを選択することによって、音質の高いものが選択される。例えば、プロバイダプロファイルとコンシューマプロファイルのいずれも、Audio Codecが０：None、または１：CELP ８ｋとなっている場合、プロファイルアトムのAtomAudioには｛１｝が設定される。

ステップＳ１３１において、アプリケーション＃ｎは、以上の各ステップの処理で決定されたプロファイルアトムのパラメータの値を基に、プロファイルアトムを作成する（組み立てる）。

以上のようにして生成されたプロファイルアトムは、図７のステップＳ４２の処理により、アプリケーション＃１に通知される。

以上のようにして、本発明によれば、サービスに関するパラメータであって、数値化されたＭ次元のパラメータによりサービスの内容を表す詳細情報を生成するようにしたので、サービスの内容を、容易に識別することができ、ネットワークを介して、２つの装置が迅速且つ確実に情報を授受することが可能となる。

パラメータを基本単位により、正規化するようにすることで、より小さい数字で詳細情報を表現することが可能となる。従って、比較処理が容易となる。

パラメータを複数の領域に区分することで、複雑なアルゴリズムを用いることなく、簡単に、実際に情報を転送することが可能なパラメータを選択することが可能となる。

パラメータを１次元の整数値として表現することで、パラメータを容易に比較することが可能となる。

詳細情報を、整数値と論理記号の組み合わせで表現するようにすることで、パラメータを容易に比較することが可能な形式で表現することができる。

論理記号として、複数の前記整数値のいずれか１つの選択を表現する第１の記号と、前記整数値の集合を表す第２の記号を用いるようにすることで、パラメータを容易に比較することが可能な形式で表現することができる。

第２の記号として、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップを用いるようにすることで、範囲を容易に比較することが可能な形式で表現することができる。

サービスは、ネットワークを介してデータを送信または受信するサービスとすることで、ネットワークを介して、２つの装置が迅速且つ確実に情報を授受するのに必要な情報を交換することが可能となる。

識別子を詳細情報に付加することで、詳細情報の特定が容易となる。

識別子をネットワークを介して送信先に送信することで、送信先に詳細情報を簡単に識別させることが可能となる。

送信先に識別子に対応する詳細情報を送信し、送信先から送信されてきたＭ次元のパラメータを受信するようにすることで、始めから詳細情報を送信する必要がなくなり、伝送路を効率的に利用しながら、確実に情報を授受することが可能となる。

ネットワークを介して送信されてきた識別子を受信することで、詳細情報を簡単に識別することが可能となる。

受信された識別子に対応する詳細情報の送信を要求するようにすることで、通信不能な相手側と無駄に詳細情報を交換するようなことが防止される。

データ構造を、Ｍ次元のパラメータで構成し、前記パラメータを、整数値と論理記号の組み合わせで構成することで、内容を容易に識別可能な形式でデータを記述することが可能となる。

以上においては、Ｍ：５としたが、それより大きい次元または小さい次元とすることも可能である。

また、以上においては、AVデータを提供するサービスを例として説明したが、AVデータを授受するサービスの他、各種のサービスを提供し、利用する場合に、本発明は適用することができる。

なお、上述した処理は、ネットワーク対応のCE機器等の場合、ハードウェアにより実行することもできる。勿論、ソフトウェアにより実行することもできる。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。

この記録媒体は、図１２に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク１４１（フロッピディスクを含む）、光ディスク１４２（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク１４３（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリ１４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているROM１２２や、記憶部１２８に含まれるハードディスクなどで構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。

本発明は、例えばパーソナルコンピュータに適用できる。

本発明を適用したネットワークシステムの構成例を示す図である。ソフトウェアの階層を説明する図である。本発明を適用したネットワークシステムの動作の概要を説明する図である。図１のネットワークシステムの動作を説明するフローチャートである。図１のネットワークシステムの動作を説明するフローチャートである。図１のネットワークシステムの動作を説明するフローチャートである。図１のネットワークシステムの動作を説明するフローチャートである。プロファイルスペースの例を示す図である。プロファイルディスクリプションの例を示す図である。プロファイルアトムの例を示す図である。サービスプロバイダの一覧の表示例を示す図である。パーソナルコンピュータの構成例を示すブロック図である。プロファイルの構成を示す図である。プロファイルの基本単位を説明する図である。プロファイルの領域を説明する図である。プロファイルディスクリプション作成処理を説明するフローチャートである。プロファイルディスクリプション作成処理を説明するフローチャートである。プロファイルの階層構造を説明する図である。プロバイダプロファイルの例を示す図である。コンシューマプロファイルの例を示す図である。プロファイルアトム生成処理を説明するフローチャートである。プロファイルアトム生成処理を説明するフローチャートである。

符号の説明

１インターネット，１１，１２パーソナルコンピュータ，１３ PDA，１４メディアIMサーバ，３１ IPネットワークトランスポート層，３２メディアIMクライアントミドルウェア，３３ API

Claims

ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信先に送信する詳細情報送信ステップと、
前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち前記送信先が利用可能な範囲を示す第２の詳細情報を、前記送信先から受信する詳細情報受信ステップと、
前記第２の詳細情報に基づいて、前記送信先と通信する通信ステップと
を含む処理をコンピュータに実行させるためのプログラム。
Ｍ次元の前記パラメータのそれぞれは、整数値と論理記号の組み合わせで表現される
請求項１に記載のプログラム。
前記論理記号として、複数の前記整数値のいずれか１つの選択を表現する第１の記号と、前記整数値の集合を表す第２の記号が用いられる
請求項２に記載のプログラム。
前記第２の記号として、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップが用いられる
請求項３に記載のプログラム。
前記サービスを識別する識別子を、前記送信先に送信する識別子送信ステップと、
前記識別子に対応する前記第１の詳細情報の送信の要求を、前記送信先から受信する要求受信ステップと
をさらに含み、
前記詳細情報送信ステップは、前記送信先の要求に基づいて、前記識別子に対応する前記第１の詳細情報を、前記送信先に送信する
処理をコンピュータに実行させるための請求項１に記載のプログラム。
前記パラメータは、基本単位により正規化されている
請求項１に記載のプログラム。
情報処理装置の情報処理方法において、
ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信先に送信する詳細情報送信ステップと、
前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち前記送信先が利用可能な範囲を示す第２の詳細情報を、前記送信先から受信する詳細情報受信ステップと、
前記第２の詳細情報に基づいて、前記送信先と通信する通信ステップと
を含む情報処理方法。
ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信先に送信する詳細情報送信手段と、
前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち前記送信先が利用可能な範囲を示す第２の詳細情報を、前記送信先から受信する詳細情報受信手段と、
前記第２の詳細情報に基づいて、前記送信先と通信する通信手段と
を備える情報処理装置。
ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信者から受信する詳細情報受信ステップと、
受信した前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち利用可能な範囲を示す第２の詳細情報を生成する生成ステップと、
生成した前記第２の詳細情報を、前記送信者に送信する詳細情報送信ステップと
を含む処理をコンピュータに実行させるためのプログラム。
前記生成ステップは、前記各領域について前記主要因パラメータが利用可能な範囲を含むか否かを判定してから、利用可能な範囲を含む前記主要因パラメータを含む前記領域内の他の前記パラメータが利用可能な範囲を含むか否かを判定する
請求項９に記載のプログラム。
前記サービスを識別する識別子を、前記送信者から受信する識別子受信ステップと、
前記識別子に対応する前記第１の詳細情報の送信の要求を、前記送信者に送信する要求送信ステップと
をさらに含み、
前記詳細情報受信ステップは、前記識別子に対応する前記第１の詳細情報を、前記送信者から受信する
処理をコンピュータに実行させるための請求項９に記載のプログラム。
情報処理装置の情報処理方法において、
ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信者から受信する詳細情報受信ステップと、
受信した前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち利用可能な範囲を示す第２の詳細情報を生成する生成ステップと、
生成した前記第２の詳細情報を、前記送信者に送信する詳細情報送信ステップと
を含む情報処理方法。
ネットワークを介してデータを送信または受信するサービスに関する数値化されたＭ次元のパラメータのうち、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域に区分し、前記領域ごとにＭ次元の前記パラメータにより前記サービスの内容を表す第１の詳細情報を、前記ネットワークに接続されている送信者から受信する詳細情報受信手段と、
受信した前記第１の詳細情報に示されるＭ次元の前記パラメータの範囲のうち利用可能な範囲を示す第２の詳細情報を生成する生成手段と、
生成した前記第２の詳細情報を、前記送信者に送信する詳細情報送信手段と
を備える情報処理装置。