(57)【要約】本発明は能力が異なる装置間で確実に接続ができるようにしたプログラム、情報処理方法および装置、並びにデータ構造に関する。相手側に提供できるサービスは、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄ，Ｌｉｎｋ  Ｓｐｅｅｄ，Ｘ  ｓｃａｌｅ，Ｙ  ｓｃａｌｅ、およびＡｕｄｉｏ  Ｃｏｄｅｃの５次元のパラメータで表現される。各パラメータの値は、全て整数値で表される。Ａｃｃｅｓｓ  Ｍｅｔｈｏｄは、ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰの場合、番号１で表現され、ＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇの場合、番号２で表現される。Ｌｉｎｋ  Ｓｐｅｅｄは、ｋｂｐｓを基本単位として正規化され、Ｘ  ｓｃａｌｅとＹ  ｓｃａｌｅは１６ｐｉｘｅｌを基本単位として正規化される。Ａｕｄｉｏ  Ｃｏｄｅｃも、番号０乃至６が所定の方式に対応している。本発明は、パーソナルコンピュータに適用できる。
2004012088.tif 000002
【特許請求の範囲】
【請求項１】
サービスに関するパラメータであって、数値化されたＭ次元のパラメータを取得し、取得された前記パラメータにより、前記サービスの内容を表す詳細情報を生成する生成ステップ
をコンピュータに実行させることを特徴とするプログラム。
【請求項２】
前記生成ステップは、基本単位により正規化された前記パラメータを取得する
ことを特徴とする請求の範囲第１項に記載のプログラム。
【請求項３】
前記生成ステップは、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、前記パラメータを複数の領域に区分し、前記領域ごとに前記パラメータを取得する
ことを特徴とする請求の範囲第１項に記載のプログラム。
【請求項４】
前記生成ステップは、前記各領域ごとに、Ｍ次元の前記パラメータのそれぞれを、１次元の整数値として取得する
ことを特徴とする請求の範囲第３項に記載のプログラム。
【請求項５】
前記生成ステップは、前記詳細情報を、前記整数値と論理記号の組み合わせで表現する
ことを特徴とする請求の範囲第４項に記載のプログラム。
【請求項６】
前記生成ステップは、前記論理記号として、複数の前記整数値のいずれか１つの選択を表現する第１の記号と、前記整数値の集合を表す第２の記号を用いる
ことを特徴とする請求の範囲第５項に記載のプログラム。
【請求項７】
前記生成ステップは、前記第２の記号として、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップを用いる
ことを特徴とする請求の範囲第６項に記載のプログラム。
【請求項８】
前記サービスは、ネットワークを介してデータを送信または受信するサービスである
ことを特徴とする請求の範囲第１項に記載のプログラム。
【請求項９】
前記生成ステップは、前記サービスを識別する識別子をさらに取得し、前記詳細情報に付加する
ことを特徴とする請求の範囲第８項に記載のプログラム。
【請求項１０】
前記識別子を、前記ネットワークを介して所定の送信先に送信する第１の送信ステップ
をさらに含むことを特徴とする請求の範囲第９項に記載のプログラム。
【請求項１１】
前記送信先から、前記識別子に対応する前記詳細情報の送信の要求を受信する第１の受信ステップと、
前記第１の受信ステップの処理により受信された要求に基づいて、前記詳細情報を、前記ネットワークを介して前記送信先に送信する第２の送信ステップと、
前記送信先から送信されてきた、前記詳細情報に含まれるＭ次元の前記パラメータを受信する第２の受信ステップと、
前記第２の受信ステップの処理により受信されたＭ次元の前記パラメータに基づいて、前記送信先と通信する通信ステップと
をさらに含むことを特徴とする請求の範囲第１０項に記載のプログラム。
【請求項１２】
前記ネットワークを介して送信されてきた前記識別子を受信する第１の受信ステップ
をさらに含むことを特徴とする請求の範囲第９項に記載のプログラム。
【請求項１３】
前記第１の受信ステップの処理により受信された前記識別子の送信者に、前記識別子に対応する前記詳細情報であって、前記送信者により生成された前記識別情報の送信を要求する要求ステップと、
前記要求ステップの処理による要求に基づいて、前記識別子の送信者から前記ネットワークを介して送信されてきた前記詳細情報を受信する第２の受信ステップと、
前記第２の受信ステップの処理により受信された前記詳細情報を、前記生成ステップの処理により生成した前記詳細情報と比較し、２つの前記詳細情報の両方を満足するＭ次元の前記パラメータを設定する設定ステップと、
前記設定ステップの処理により生成されたＭ次元の前記パラメータを、前記識別子の送信者に送信する送信ステップと、
前記送信ステップの処理により送信されたＭ次元の前記パラメータに基づいて、前記送信者と通信する通信ステップと
をさらに含むことを特徴とする請求の範囲第１２項に記載のプログラム。
【請求項１４】
情報処理装置の情報処理方法において、
サービスに関するパラメータであって、数値化されたＭ次元のパラメータを取得し、取得された前記パラメータにより、前記サービスの内容を表す詳細情報を生成する生成ステップ
を含むことを特徴とする情報処理方法。
【請求項１５】
サービスに関するパラメータであって、数値化されたＭ次元のパラメータを取得し、取得された前記パラメータにより、前記サービスの内容を表す詳細情報を生成する生成手段
を備えることを特徴とする情報処理装置。
【請求項１６】
サービスの内容を表すデータ構造であって、
Ｍ次元のパラメータで構成され、
前記パラメータは、整数値と論理記号の組み合わせで構成される
ことを特徴とするデータ構造。
【請求項１７】
前記論理記号は、複数の整数値のいずれか１つの選択を表現する第１の記号と、整数値の集合を表す第２の記号とで構成される
ことを特徴とする請求の範囲第１６項に記載のデータ構造。
【請求項１８】
前記第２の記号は、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップで構成される
ことを特徴とする請求の範囲第１７項に記載のデータ構造。
【請求項１９】
前記サービスを識別する識別番号をさらに含む
ことを特徴とする請求の範囲第１６項に記載のデータ構造。
【発明の詳細な説明】
【技術分野】  本発明は、プログラム、情報処理方法および装置、並びにデータ構造に関し、特に、能力が異なる装置間で確実に接続ができるようにしたプログラム、情報処理方法および装置、並びにデータ構造に関する。
【背景技術】  最近、インターネットが普及し、インターネットを利用して各種のデータを相手側と授受するユーザが増えてきた。
しかしながら、従来、例えば、相手側の装置に対して所定の画像を伝送しようとした場合、相手側の装置の能力が自分自身の能力と異なるため、実質的には、相互に接続することができず、結局、画像データを伝送することができなくなるといった事態が発生することがあった。
これを防ぐには、ユーザは、相手側の装置の能力を事前に確認する必要がある。
例えば、ストリーミングを行う場合に、ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ，ＩＥＴＦ  ＲＦＣ  ２３２６，Ａｐｒｉｌ  １９９８，〈ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ／２３２６．ｔｘｔ〉）では、サーバとクライアント間でストリームのパラメータを交換する方法として、ＳＤＰ（Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）（ＳＤＰ：Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ，ＩＥＴＦ  ＲＦＣ  ２３２７，Ａｐｒｉｌ  １９９８，〈ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ／２３２７．ｔｘｔ〉）を用いることが規定されている。
しかしながら、ＲＴＳＰには、具体的にどのようにしてパラメータを交換するのかが規定されておらず、結局、サーバとクライアント間でデータを確実に授受することができない課題があった。
【発明の開示】
本発明は、このような状況に鑑みてなされたものであり、相手側の装置と確実に接続し、データを授受することができるようにするものである。
本発明のプログラムは、サービスに関するパラメータであって、数値化されたＭ次元のパラメータを取得し、取得された前記パラメータにより、前記サービスの内容を表す詳細情報を生成する生成ステップをコンピュータに実行させることを特徴とする。
前記生成ステップは、基本単位により正規化された前記パラメータを取得するようにすることができる。
前記生成ステップは、他の前記パラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、前記パラメータを複数の領域に区分し、前記領域ごとに前記パラメータを取得するようにすることができる。
前記生成ステップは、前記各領域ごとに、Ｍ次元の前記パラメータのそれぞれを、１次元の整数値として取得するようにすることができる。
前記生成ステップは、前記詳細情報を、前記整数値と論理記号の組み合わせで表現するようにすることができる。
前記生成ステップは、前記論理記号として、複数の前記整数値のいずれか１つの選択を表現する第１の記号と、前記整数値の集合を表す第２の記号を用いるようにすることができる。
前記生成ステップは、前記第２の記号として、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップを用いるようにすることができる。
前記サービスは、ネットワークを介してデータを送信または受信するサービスであるようにすることができる。
前記生成ステップは、前記サービスを識別する識別子をさらに取得し、前記詳細情報に付加するようにすることができる。
前記識別子を、前記ネットワークを介して所定の送信先に送信する第１の送信ステップようにすることができる。
前記送信先から、前記識別子に対応する前記詳細情報の送信の要求を受信する第１の受信ステップと、前記第１の受信ステップの処理により受信された要求に基づいて、前記詳細情報を、前記ネットワークを介して前記送信先に送信する第２の送信ステップと、前記送信先から送信されてきた、前記詳細情報に含まれるＭ次元の前記パラメータを受信する第２の受信ステップと、前記第２の受信ステップの処理により受信されたＭ次元の前記パラメータに基づいて、前記送信先と通信する通信ステップとをさらに含むようにすることができる。
前記ネットワークを介して送信されてきた前記識別子を受信する第１の受信ステップをさらに含むようにすることができる。
前記第１の受信ステップの処理により受信された前記識別子の送信者に、前記識別子に対応する前記詳細情報であって、前記送信者により生成された前記識別情報の送信を要求する要求ステップと、前記要求ステップの処理による要求に基づいて、前記識別子の送信者から前記ネットワークを介して送信されてきた前記詳細情報を受信する第２の受信ステップと、前記第２の受信ステップの処理により受信された前記詳細情報を、前記生成ステップの処理により生成した前記詳細情報と比較し、２つの前記詳細情報の両方を満足するＭ次元の前記パラメータを設定する設定ステップと、前記設定ステップの処理により生成されたＭ次元の前記パラメータを、前記識別子の送信者に送信する送信ステップと、前記送信ステップの処理により送信されたＭ次元の前記パラメータに基づいて、前記送信者と通信する通信ステップとをさらに含むようにすることができる。
本発明の情報処理方法は、サービスに関するパラメータであって、数値化されたＭ次元のパラメータを取得し、取得された前記パラメータにより、前記サービスの内容を表す詳細情報を生成する生成ステップを含むことを特徴とする。
本発明の情報処理装置は、サービスに関するパラメータであって、数値化されたＭ次元のパラメータを取得し、取得された前記パラメータにより、前記サービスの内容を表す詳細情報を生成する生成手段を備えることを特徴とする。
本発明のデータ構造は、Ｍ次元のパラメータで構成され、前記パラメータは、整数値と論理記号の組み合わせで構成されることを特徴とする。
前記論理記号は、複数の整数値のいずれか１つの選択を表現する第１の記号と、整数値の集合を表す第２の記号とで構成されるようにすることができる。
前記第２の記号は、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップで構成されるようにすることができる。
前記サービスを識別する識別番号をさらに含むようにすることができる。号とが用いられることを特徴とする。
本発明のプログラム、情報処理装置および方法においては、サービスに関する数値化されたＭ次元のパラメータが取得され、そのパラメータにより、サービスの内容を表す詳細情報が生成される。
本発明のデータ構造においては、データ構造が、Ｍ次元のパラメータで構成され、パラメータは、整数値と論理記号の組み合わせで構成される。
【図面の簡単な説明】  図１は、本発明を適用したネットワークシステムの構成例を示す図である。
図２は、ソフトウェアの階層を説明する図である。
図３は、本発明を適用したネットワークシステムの動作の概要を説明する図である。
図４は、図１のネットワークシステムの動作を説明するフローチャートである。
図５は、図１のネットワークシステムの動作を説明するフローチャートである。
図６は、図１のネットワークシステムの動作を説明するフローチャートである。
図７は、図１のネットワークシステムの動作を説明するフローチャートである。
図８は、プロファイルスペースの例を示す図である。
図９は、プロファイルディスクリプションの例を示す図である。
図１０は、プロファイルアトムの例を示す図である。
図１１は、サービスプロバイダの一覧の表示例を示す図である。
図１２は、パーソナルコンピュータの構成例を示すブロック図である。
図１３は、プロファイルの構成を示す図である。
図１４はプロファイルの基本単位を説明する図である。
図１５は、プロファイルの領域を説明する図である。
図１６は、プロファイルディスクリプション作成処理を説明するフローチャートである。
図１７は、プロファイルディスクリプション作成処理を説明するフローチャートである。
図１８は、プロファイルの階層構造を説明する図である。
図１９は、プロバイダプロファイルの例を示す図である。
図２０は、コンシューマプロファイルの例を示す図である。
図２１は、プロファイルアトム生成処理を説明するフローチャートである。
図２２は、プロファイルアトム生成処理を説明するフローチャートである。
【発明を実施するための最良の形態】  図１は、本発明を適用したネットワークシステムの構成例を表している。このネットワークシステムにおいては、インターネット１を介して、メディアインスタントメッセージサーバ（Ｍｅｄｉａ  ＩＭ  Ｓｅｒｖｅｒ）１４に対して、ユーザ端末として、パーソナルコンピュータ１１，１２，並びにＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔｓ）１３が接続されている。メディアＩＭサーバ１４にはまた、アプリケーションサーバ１５もインターネット１を介して接続されている。
パーソナルコンピュータ１１には、ミドルウェアとしてメディアＩＭクライアント＃１が実装されており、パーソナルコンピュータ１２には、ミドルウェアとしてメディアＩＭクライアント＃２が実装されている。同様に、ＰＤＡ１３には、ミドルウェアとしてメディアＩＭクライアント＃３が実装されている。
アプリケーションサーバ１５には、ミドルウェアとしてメディアＩＭクライアント＃４が実装されている。アプリケーションサーバ１５は、プリントサービス＃１乃至プリントサービス＃７を、アクセスしてきたユーザに対して提供する。
メディアＩＭサーバ１４は、これらのメディアＩＭクライアント＃１乃至メディアＩＭクライアント＃４の相互のインスタントメッセージ処理を制御する。
図２は、ソフトウェアの構成を表している。上述したメディアＩＭクライアント＃１乃至メディアＩＭクライアント＃４は、図２において、メディアＩＭクライアントミドルウェア３２として示されている。このメディアＩＭクライアントミドルウェア３２は、ＩＰネットワークトランスポート層３１とＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）３３との間に配置されている。ＡＰＩ３３は、アプリケーション＃１乃至アプリケーション＃Ｎと、メディアＩＭクライアントミドルウェア３２との間のインタフェース処理を実行する。メディアＩＭクライアントミドルウェア３２は、ＡＰＩ３３とＩＰネットワークトランスポート層３１とのインタフェース処理を実行する。
アプリケーション（Ａｐｐｌｉｃａｔｉｏｎ）＃１乃至アプリケーション＃Ｎは、それぞれサービスエンティティを構成する。
このネットワークシステムにおいては、図３に示されるように、サービスを提供する側のアプリケーション（図３の例では、Ａｐｐｌｉｃａｔｉｏｎ＃１）がサービスプロバイダ（Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）５１とされ、そのサービスの提供を受ける側のアプリケーション（図３の例では、Ａｐｐｌｉｃａｔｉｏｎ＃ｎ）が（サービスを消費する側が）サービスコンシューマ（Ｓｅｒｖｉｃｅ  Ｃｏｎｓｕｍｅｒｓ）５２とされる。
サービスプロバイダ５１とサービスコンシューマ５２は、対応するメディアＩＭクライアント＃Ｐ１またはメディアＩＭクライアント＃Ｃ１を介して、インスタントメッセージのプレゼンス機能、メッセージング機能、またはＩｎｆｏ／Ｑｕｅｒｙ機能を用いて、接続のためのネゴシエーション処理を実行する。ネゴシエーションにより、相手側と接続が可能であることが確認された後、サービスプロバイダ５１とサービスコンシューマ５２は、ピアツーピア（Ｐ２Ｐ）で、接続処理を実行する。
サービスプロバイダ５１とサービスコンシューマ５２は、それぞれサービスエンティティを構成する。サービスエンティティは、そのものが１つのアプリケーションである場合もあれば、複数のサービスエンティティの集合が１つのアプリケーションを形成する場合もある。以下においては、簡単のため、１つのサービスエンティティが１つのアプリケーションに対応しているものとする。
次に、接続処理の詳細を図４乃至図７のフローチャートを参照して説明する。
ステップＳ１において、サービスプロバイダ５１としてのアプリケーション＃１は、名簿（Ｒｏｓｔｅｒ）に登録されている各メンバー（Ｂｕｄｄｙ）に対して、自分自身が提供可能なサービスの種別を表すプロファイルスペースＩＤ（Ｐｒｏｆｉｌｅ  Ｓｐａｃｅ  ＩＤ）をアナウンスすることを、メディアＩＭクライアント＃Ｐ１に指令する。メディアＩＭクライアント＃Ｐ１は、ステップＳ２において、この指示を受け取ると、ステップＳ３において名簿に予め登録されているメンバーに対して、プロファイルスペースＩＤをプレゼンスによって通知する。
ここで、メンバー（Ｂｕｄｄｙ）は、メディアＩＭサーバ１４が提供するインスタントメッセージサービスにおいて、あるユーザ（または、メディアＩＭクライアント）に対するメッセージ通信の相手のことであり、メディアＩＭサーバ１４に予め登録されているユーザＩＤや、ユーザＩＤに対応付けられたニックネーム等で表される情報である。
また、名簿（Ｒｏｓｔｅｒ）は、そのメンバー（Ｂｕｄｄｙ）のリストであり、すなわち、ユーザ（またはメディアＩＭクライアント）が、メッセージ通信の相手として設定した他のユーザ（または、他のメディアＩＭクライアント）のユーザＩＤ（またはニックネーム）のリストである。この、ユーザ毎の名簿（Ｒｏｓｔｅｒ）は、メディアＩＭサーバ１４において一元管理される。
例えば、メディアＩＭクライアント＃Ｐ１のユーザがメディアＩＭクライアント＃Ｃ１のユーザをメッセージ通信の相手として設定している場合、メディアＩＭクライアント＃Ｐ１に対応する名簿には、メディアＩＭクライアント＃Ｃ１のユーザ（ユーザＩＤ等）がメンバーとして登録されている。逆に、メディアＩＭクライアント＃Ｃ１のユーザがメディアＩＭクライアント＃Ｐ１のユーザをメッセージ通信の相手として設定している場合、メディアＩＭクライアント＃Ｃ１に対応する名簿には、メディアＩＭクライアント＃Ｐ１のユーザがメンバーとして登録されている。
このように、インスタントメッセージによるメッセージ通信を行う場合、互いをメンバーとして予め名簿に登録しておかなければならない。例えば、第１のユーザが、他のメディアＩＭクライアントの第２のユーザをメンバーとして名簿に登録しているが、第２のユーザが第１のユーザをメンバーとしてそのクライアントに登録してない場合、メッセージ通信を行うためには、第１のユーザは、メッセージ通信の前に第２のユーザにメンバーとして名簿に登録させる必要がある。
この名簿は、メディアＩＭクライアントよりユーザがメディアＩＭサーバ１４にログイン（接続）すると、必要に応じてメディアＩＭサーバ１４よりそのメディアＩＭクライアントに提供され、ディスプレイ等にＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）として表示される。その際、メディアＩＭサーバ１４は、上述した名簿とともに、ユーザが目的のメンバーを容易に識別することができるようにするためのアイコンや、そのメンバーに関する情報（例えば、通信可能か否かを示す情報）であるプレゼンス等の情報をメディアＩＭクライアントに供給する。名簿等を供給されたメディアＩＭクライアントは、その名簿の各メンバーにアイコンやプレゼンスを関連付けて表示する。
なお、以上のような名簿を一元管理する専用のサーバを設けるようにしてももちろんよい。
なお、プロファイルスペースＩＤ並びにアプリケーションＩＤは、図１のネットワークシステムに示されるような、インスタントメッセージのプレゼンス機能、メッセージング機能、およびＩｎｆｏ／Ｑｕｅｒｙ機能をベースとして、アプリケーションレベルでのプロファイルのネゴシエーションを実現するアプリケーションプラットフォームの運用者によって、予め登録され、管理されている。従って、サービスコンシューマ５２は、そのＩＤに基づいて、その内容を特定することが可能となる。
図８は、パーソナルコンピュータ１１において動作するＭＰＥＧ４ストリーミングサーバアプリケーションを定義するためのプロファイルスペースの例を表している。同図に示されるように、プロファイルスペースは、そのパーソナルコンピュータにおいて提供されるサービスを表現するＭ次元の空間（スペース）であり、各プロファイルスペースを識別するためのＩＤであるプロファイルスペースＩＤとＭ次元のパラメータにより構成される。この例においては、プロファイルスペースＩＤは、「１００００００１」とされている。また、パラメータは、ａｃｃｅｓｓ  ｍｅｔｈｏｄ，ｂｉｔ  ｒａｔｅ（ｌｉｎｋ  ｓｐｅｅｄ），Ｘ  ｓｃａｌｅ，Ｙ  ｓｃａｌｅ，ａｕｄｉｏ  ｃｏｄｅｃにより構成されている。この例の場合、通信に用いられるプロトコルを表すａｃｃｅｓｓ  ｍｅｔｈｏｄの値は、１（ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰ）または２（ＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇ）とされる。接続されている通信回線の速度を表すｂｉｔ  ｒａｔｅは、６ｋ乃至５１２ｋｂｐｓとされる。画面の横方向の大きさを表すＸ  ｓｃａｌｅは１２８ｐｉｘｅｌ乃至３５２ｐｉｘｅｌとされ、また画面の縦方向の大きさを表すＹ  ｓｃａｌｅは９６ｐｉｘｅｌ乃至２８８ｐｉｘｅｌとされている。
ここで、プロファイルのａｃｃｅｓｓ  ｍｅｔｈｏｄは、通信に用いられるプロトコルを表しており、例えば、番号１で表されるＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）／ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）＋ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）、または番号２で表されるＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ｔｕｎｎｅｌｌｉｎｇのいずれかとされる。また、ｂｉｔ  ｒａｔｅは、使用されている通信回線のデータ転送速度を表す。すなわち、ｂｉｔ  ｒａｔｅは、アプリケーション＃１がＭＰＥＧ４ストリーミングサービスを行う際のＭＰＥＧ４データ転送速度を決定するための情報である。
さらに、ビデオの圧縮伸長方式を表すＶｉｄｅｏ  Ｃｏｄｅｃは、ＭＰＥＧ４とされている。オーディオの圧縮伸長方式を表すａｕｄｉｏ  ｃｏｄｅｃは、なし（ｎｏｎｅ）、ＣＥＬＰ（Ｃｏｄｅ  Ｅｘｃｉｔｅｄ  Ｌｉｎｅａｒ  Ｐｒｅｄｉｃｔｉｖｅ）８ｋ，ＣＥＬＰ  １６ｋ，ＡＡＣ（Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）１６ｋ，ＡＡＣ  ３２ｋ，ＡＡＣ  ４４．１ｋ，ＡＡＣ  ４８ｋのいずれかとされる。
このように、パラメータは全て数値によって表現されている。これにより、サービスを提供するサービスプロバイダと、サービスの提供を受ける（サービスを利用する）サービスコンシューマとの間で、迅速且つ簡単に、サービスの利用の可否を判定することができる。
図４に戻って、メディアＩＭサーバ１４は、ステップＳ４において、メディアＩＭクライアント＃Ｐ１からの通知を受け取ると、ステップＳ５において、これを名簿内の各メンバーにアナウンスする。
アナウンスを受けたメンバー（サービスコンシューマ５２）の１人であるメディアＩＭクライアント＃Ｃ１は、ステップＳ６において、この通知を受け取ると、ステップＳ７において、プロファイルスペースＩＤとサービスプロバイダ５１側のアプリケーションＩＤ（いまの場合、アプリケーション＃１のＩＤ）に基づいて、自分自身がこのプロファイルを受け入れ可能であるか否かを判定する（検証する）。上述したように、このシステムの参加者は、これらのＩＤに基づいて、その内容（図８に示されているような、相手側装置の機能）を特定することができるので、この判定が可能である。
例えば、各メディアＩＭクライアント（すなわち、パーソナルコンピュータ１１，１２等）は、図８に示されるような、プロファイルに含まれるパラメータの種類や、そのパラメータが取り得る値の集合に、アプリケーションＩＤおよびプロファイルＩＤを関連付けたテーブルと、サービスコンシューマとなるアプリケーションに関する情報を予め保持しており、ステップＳ７において、保持しているテーブルを参照し、ステップＳ６において取得したアプリケーションＩＤやプロファイルＩＤに対応するプロファイルに含まれるパラメータの種類やそのパラメータが取り得る値の集合を特定し、さらに、保持しているアプリケーションに関する情報に基づいて、その特定されたパラメータ（パラメータに対応するプロファイル）が、サービスコンシューマとなるアプリケーションの有する機能に対応しているか否か（すなわち、受け入れ可能であるか否か）を判定する。
なお、この、ＩＤと内容の対応関係を記述したテーブルを各装置（パーソナルコンピュータ１１，１２等）に記憶させておくこともできるが、所定のサーバ（例えば、メディアＩＭサーバ１４）に記憶させておくこともできる。この場合、ユーザが検証のために、このテーブルを利用する度に、ユーザに対して課金するようにすることもできる。これにより、メディアＩＭサーバ１４の運用者は、利益を得ることができる。
メディアＩＭクライアント＃Ｃ１は、サービスプロバイダ５１からプレゼンスを受けたプロファイルの内容が、サービスコンシューマが受け入れ可能であると判断した場合、ステップＳ８において、その受け入れ可能なサービスコンシューマ５２となるアプリケーション＃ｎに対して、プレゼンスの内容（図８に示されるような、プロファイルスペースＩＤに対応するプロファイル）を通知する。ステップＳ９において、アプリケーション＃ｎは、メディアＩＭクライアント＃Ｃ１からの通知を受信する。
なお、サービスプロバイダからのアナウンス（ステップＳ４乃至Ｓ６）を受け取った各メディアＩＭクライアントは、ステップＳ７における検証の結果、サービスコンシューマとなる適切なアプリケーションが存在しないと判断した場合、受信したアナウンスを無視する。
サービスコンシューマ５２としてのアプリケーション＃ｎは、サービスプロバイダ５１のプレゼンスの内容を受信すると、ステップＳ１０において、サービスプロバイダ５１から提供されたサービスの詳細情報を取得するように、メディアＩＭクライアント＃Ｃ１に指示する。ステップＳ１１において、メディアＩＭクライアント＃Ｃ１は、この指示を受け取ると、ステップＳ１２において、サービスプロバイダ５１が提供するサービスの、上述したプロファイルスペースのパラメータ群の一部または全部のパラメータにより構成されるプロバイダプロファイルの送信を、メッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能を用いて要求する。この要求には、サービスプロバイダ５１を指定するための宛先情報が含められている。
なお、Ｉｎｆｏ／Ｑｕｅｒｙ機能を用いて通知や要求を行った場合、メッセージング機能を用いた場合と異なり、受け手側より受信確認の応答が送り手側に供給される。例えば、メディアＩＭクライアント＃Ｐ１のアプリケーション＃１がメディアＩＭサーバ１４より名簿（Ｒｏｓｔｅｒ）を取得する場合、メディアＩＭクライアント＃Ｐ１は、Ｉｎｆｏ／Ｑｕｅｒｙ機能により、ＧＥＴコマンド等をメディアＩＭサーバ１４に供給する。メディアＩＭサーバ１４は、このＧＥＴコマンドを取得すると、取得したことを示す応答を送信元のメディアＩＭクライアント＃Ｐ１を介してアプリケーション＃１に供給する。アプリケーション＃１は、この応答により、ＧＥＴコマンドがメディアＩＭサーバ１４に供給されたことを確認することができる。
このようにアプリケーションレベルにおいて確認応答が送信先より送信元に対して供給されるので、アプリケーションは、Ｉｎｆｏ／Ｑｕｅｒｙ機能を用いて通知や要求を行うことにより、確実にその通知や要求を送信先に供給することができる。
これに対してメッセージング機能を用いて通知や要求を行う場合、その通知や要求を取得した送信先のアプリケーションは、送信元に上述した確認応答を供給しない。従って、送信元のアプリケーションは、メッセージング機能を用いて供給した通知や要求を、その送信先が取得したか否かを把握することができないので、Ｉｎｆｏ／Ｑｕｅｒｙ機能を用いた場合と比較して、目的の送信先に確実に供給することができない。しかしながら、メッセージング機能を用いた通知や要求の場合、Ｉｎｆｏ／Ｑｕｅｒｙ機能を用いた場合と比較して、通信処理が簡潔になるので、処理の負荷を減らすことができる。このメッセージング機能は、例えば、メディアＩＭクライアント間におけるテキスト文書からなるインスタントメッセージ（ＩＭＳＴＡＮＴ  ＭＥＳＳＡＧＩＮＧ）の授受に用いられる。
なお、以上のようなＩｎｆｏ／Ｑｕｅｒｙ機能を用いた通知や要求、またはメッセージング機能を用いた通知や要求は、メディアＩＭクライアントだけでなくメディアＩＭサーバも使用可能であり、メディアＩＭクライアントとメディアＩＭサーバ間における通知や要求だけでなくメディアＩＭクライアント間における通知や要求等にも使用可能である。
さらに、これらのＩｎｆｏ／Ｑｕｅｒｙ機能やメッセージング機能を用いた通知や要求は、コマンドだけでなく、メッセージやパラメータ等、どのようなデータを含んでいても良く、どのような内容であっても良い。
以上のように、メディアＩＭクライアント＃Ｐ１、メディアＩＭクライアント＃Ｃ１、およびメディアＩＭサーバ１４は、メッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能を用いてデータ（通知や要求等も含む）の授受を行う。
上述したように、プロバイダプロファイルを送信する場合、メディアＩＭクライアント＃Ｐ１等は、メッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能のいずれを用いて送信してもよい。ただし、Ｉｎｆｏ／Ｑｕｅｒｙ機能を用いてプロバイダプロファイルを送信する場合、そのプロバイダプロファイルの送信に対する応答が、送信先より送信元に供給される。
メディアＩＭサーバ１４は、ステップＳ１３において、メディアＩＭクライアント＃Ｃ１からの要求を受信すると、ステップＳ１４において、これをメディアＩＭクライアント＃Ｐ１に送信する。メディアＩＭクライアント＃Ｐ１は、ステップＳ１５において、メディアＩＭサーバ１４からの要求を受信すると、ステップＳ１６において、これをサービスプロバイダ５１としてのアプリケーション＃１に供給する。
アプリケーション＃１は、ステップＳ１７において、メディアＩＭクライアント＃Ｐ１からの要求を受信すると、ステップＳ１８において、サービスコンシューマ５２に対して提供するプロバイダプロファイルを組み立て、メディアＩＭクライアント＃Ｐ１に送信する。このプロバイダプロファイルの組み立ての詳細は、図１６と図１７のフローチャートを参照して後述する。
アプリケーション＃１により生成されるプロバイダプロファイルの内容は、プロファイルスペース（図８）で定義されているパラメータ群のうち、サービスプロバイダ５１がネットワークのリンクスピードやＣＰＵの負荷状況などのランタイム環境を考慮した上で、サービスコンシューマ５２に対して実際に提供できるパラメータの値の範囲を具体的に設定したものとされる。
図９は、このようにして、生成されるプロバイダプロファイルの例を表している。図９では、このプロバイダプロファイルが、プロファイルディスクリプション（Ｐｒｏｆｉｌｅ  Ｄｅｓｃｒｉｐｔｉｏｎ）として表されている。
図９は、サービスプロバイダ５１としてのアプリケーション＃１がＶＧＡ（Ｖｉｄｅｏ  Ｇｒａｐｈｉｃｓ  Ａｒｒａｙ）系の画角（１６０ｐｉｘｅｌ×１２０ｐｉｘｅｌまたは３２０ｐｉｘｅｌ×２４０ｐｉｘｅｌ）のみをサポートし、かつＰＨＳ（Ｐｅｒｓｏｎａｌ  Ｈａｎｄｙｐｈｏｎｅ  Ｓｙｓｔｅｍ）相当のネットワーク（リンクスピードの最大値が１２８ｋｂｐｓのネットワーク）に接続されている場合の例を表している。従って、図９の例においては、ネットワークのリンクスピードとの兼ね合いから、画角が図８のプロファイルスペースで規定されている範囲のうち、１６０ｐｉｘｅｌ×１２０ｐｉｘｅｌ（Ｘ  ｓｃａｌｅ×Ｙ  ｓｃａｌｅ）のみに限定されている。
また、図９の例においては、プロファイルスペースＩＤは、「１００００００１」とされており、図８に示されるプロファイルスペースに対応するプロファイルディスクリプションであることが示されている。すなわち、上述したように、メディアＩＭクライアント＃Ｃ１がステップＳ１２においてプロバイダプロファイルを要求すると、その要求に応じて、図９に示されるような、ステップＳ３においてメディアＩＭクライアント＃Ｐ１が供給したプロファイルスペースＩＤに対応するプロファイルディスクリプション（プロバイダプロファイル）が生成される。
図９のａｃｃｅｓｓ  ｍｅｔｈｏｄは、ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰまたはＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇのいずれかとされる。ｂｉｔ  ｒａｔｅは、６ｋ乃至１２８ｋｂｐｓとされている。さらに、ａｕｄｉｏ  ｃｏｄｅｃは、なし（ｎｏｎｅ）またはＣＥＬＰ  ８ｋとされている。
メディアＩＭクライアント＃Ｐ１は、ステップＳ１９において、アプリケーション＃１からのプロバイダプロファイルの応答を受信すると、ステップＳ２０において、これをアプリケーション＃ｎに向けてメッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能を用いて返信する。
メディアＩＭサーバ１４は、ステップＳ２１において、メディアＩＭクライアント＃Ｐ１からの返信を受信すると、ステップＳ２２において、これをメディアＩＭクライアント＃Ｃ１に送信する。ステップＳ２３において、メディアＩＭクライアント＃Ｃ１は、この返信を受信すると、それをステップＳ２４において、アプリケーション＃ｎに送信する。アプリケーション＃ｎは、ステップＳ２５において、このサービスプロバイダ５１からの返信（図９に示されるプロバイダプロファイルが含まれている）を受信する。
アプリケーション＃ｎは、ステップＳ２５の処理で受信したサービスプロバイダ５１のプロバイダプロファイルと、自分自身が形成するコンシューマプロファイルとのマッチング（比較）を行う。上述したプロバイダプロファイルとコンシューマプロファイルは、後述する図１６と図１７のフローチャートで示される処理で生成される。
ここで、プロバイダプロファイルは、上述したように、メディアＩＭクライアント＃Ｃ１によりサービスコンシューマが受け入れ可能であると判断された内容のプロファイルスペースに基づいて、アプリケーション＃１が作成したプロファイルである。すなわち、このプロバイダプロファイルに対応するプロファイルスペースは、サービスコンシューマとしてのアプリケーション＃ｎにも対応している。従って、アプリケーション＃ｎは、アプリケーション＃１がプロバイダプロファイルを作成する場合と同様の処理を行い、サービスコンシューマに対応する、このプロファイルスペースのパラメータ群の一部または全部のパラメータにより構成されるプロファイル（すなわち、コンシューマプロファイル）を作成することができる。アプリケーション＃ｎは、受信したサービスプロバイダ５１のプロバイダプロファイルと、このように作成されたコンシューマプロファイルとのマッチングを行う。
上述したように、サービスプロバイダが提示するプロバイダプロファイル（プロファイルディスクリプション）は、数値だけで表現されているため、サービスコンシューマ５２は、自分自身のプロファイルを構成する各パラメータの値の範囲と単純に１次元での比較を行うだけで、整合性を簡単に検証することができる。
ここで、次元とは、パラメータの実質的な数を意味する。すなわち、サービスコンシューマ５２は、コンシューマプロファイルの各パラメータの値の範囲を、そのパラメータに対応するプロバイダプロファイルのパラメータの値の範囲とを１対１で、１つずつ比較する。
そして、コンシューマプロファイルの各パラメータの値の範囲の一部または全部が、そのパラメータに対応するプロバイダプロファイルのパラメータの値の範囲に重なる場合、すなわち、サービスコンシューマ５２が、サービスプロバイダ５１より提供されたサービスを取得することができる（アプリケーション＃１が送信したデータを、アプリケーション＃ｎが受け入れることができる）範囲が存在すると判定した場合、サービスコンシューマ５２は、整合性が確認できたと判定する。
アプリケーション＃ｎは、整合性が確認できた場合、ステップＳ２６において、サービスプロバイダ５１に対して、提供されたサービスへの自分自身（サービスコンシューマ５２）の登録を要求する。メディアＩＭクライアント＃Ｃ１は、ステップＳ２７において、アプリケーション＃ｎからこの指示を受け取ると、ステップＳ２８において、サービスプロバイダ５１に対して、プロファイルスペースＩＤに対応させて、サービスコンシューマ５２のアプリケーション＃ｎのアプリケーションＩＤを登録することにより、サービスの提供先としてサービスコンシューマ５２を登録する、サービスへの登録を、メッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能を用いて要求する。このとき、プロファイルスペースＩＤとアプリケーションＩＤ（アプリケーション＃ｎのＩＤ）がその要求に含められる。
メディアＩＭサーバ１４は、ステップＳ２９において、メディアＩＭクライアント＃Ｃ１からの要求を受け取ると、ステップＳ３０において、これをメディアＩＭクライアント＃Ｐ１に送信する。メディアＩＭクライアント＃Ｐ１は、ステップＳ３１において、メディアＩＭサーバ１４からの要求を受信すると、ステップＳ３２において、これをアプリケーション＃１に送信する。アプリケーション＃１は、ステップＳ３３において、サービスコンシューマ５２からの登録要求を受信する。
サービスプロバイダ５１としてのアプリケーション＃１は、ステップＳ１８の処理でサービスコンシューマ５２に対して提供したサービスに対応してサービスコンシューマ５２を登録する。具体的には、プロファイルスペースＩＤに対応して、サービスコンシューマ５２のアプリケーション＃ｎのアプリケーションＩＤが対応して登録される。
このように登録されたサービスコンシューマ５２に関する情報は、アプリケーション＃１によりサービスが提供される際に利用される。すなわち、アプリケーション＃１は、この登録された情報を参照し、その情報に基づいてサービスコンシューマ５２のアプリケーション（アプリケーションＩＤに対応するアプリケーション）に対して、サービスを提供する。
ステップＳ３４において、アプリケーション＃１は、サービスコンシューマ５２より供給された要求であり、アプリケーション＃１がプロファイルスペースＩＤに対応させてサービスコンシューマ５２のアプリケーション＃ｎのアプリケーションＩＤを登録することにより、サービスの提供先としてサービスコンシューマ５２を登録させる要求である、サービスへの登録要求に対応する応答（すなわち、アプリケーション＃ｎの登録が完了したか否かを示す情報の供給）をメディアＩＭクライアント＃Ｐ１に指示し、ステップＳ３５において、この指示を受け取ったメディアＩＭクライアント＃Ｐ１は、ステップＳ３６において、供給された登録要求に対応する応答である登録結果を、メッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能を用いて通知する。ステップＳ３７において、この登録結果の通知を受信したメディアＩＭサーバ１４は、ステップＳ３８において、それをメディアＩＭクライアント＃Ｃ１に送信する。メディアＩＭクライアント＃Ｃ１は、ステップＳ３９において、これを受信すると、ステップＳ４０において、アプリケーション＃ｎに送信する。アプリケーション＃ｎは、ステップＳ４１において、登録結果の通知を受信する。
アプリケーション＃ｎは、ステップＳ４２において、サービスプロバイダ５１からのプロファイルディスクリプション（ステップＳ２５の処理で受信したプロバイダプロファイル）に基づく接続性を保証するためのパラメータを、プロファイルアトム（Ｐｒｏｆｉｌｅ  Ａｔｏｍ）として決定する。すなわち、アプリケーション＃１が送信したデータを、アプリケーション＃ｎがそのまま利用することが可能な（アプリケーション＃ｎが受け入れることが可能な）パラメータが決定される。このプロファイルアトムの決定処理の詳細は、図２１と図２２のフローチャートを参照して後述する。
図１０は、このプロファイルアトムのディスクリプションの例を表している。この例においては、プロファイルスペースＩＤが「１００００００１」とされており、図８に示されるプロファイルスペースに対応するプロファイルアトムであることが示されている。すなわち、上述したように、メディアＩＭクライアント＃Ｃ１の要求に応じてプロファイルスペースＩＤに対応するプロファイルディスクリプション（プロバイダプロファイル）がメディアＩＭクライアント＃Ｐ１により作成され、供給されると、メディアＩＭクライアント＃Ｃ１は、プロファイルスペースＩＤに対応するコンシューマプロファイルを作成し、それを供給されたプロバイダプロファイルと比較し、整合すると判定した場合、提供されたサービスへの登録処理を行うとともに、それらのプロファイルに対応するプロファイルスペースの各パラメータの範囲から、接続性を保証するための範囲を特定し、図１０に示されるような、それらの範囲のパラメータにより構成されるプロファイルアトムを生成する。
ａｃｃｅｓｓ  ｍｅｔｈｏｄは、ＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇとされている。すなわち、図９のプロバイダプロファイルにおけるａｃｃｅｓｓ  ｍｅｔｈｏｄのうち、番号２に対応する方が選択されている。
また、ｂｉｔ  ｒａｔｅは４８ｋｂｐｓ、Ｘ  ｓｃａｌｅは１６０、Ｙ  ｓｃａｌｅは１２０とされている。さらに、ａｕｄｉｏ  ｃｏｄｅｃは、ＣＥＬＰ  ８ｋとされている。
アプリケーション＃ｎは、ステップＳ４２において、このようにして決定したプロファイルアトムを伴ったコネクト要求を発行する。ステップＳ４３において、メディアＩＭクライアント＃Ｃ１は、この要求を受信すると、ステップＳ４４において、この要求を、メッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能を利用して、サービスプロバイダ５１に送信する。メディアＩＭサーバ１４は、ステップＳ４５において、この要求を受信すると、ステップＳ４６において、その要求をメディアＩＭクライアント＃Ｐ１に送信する。メディアＩＭクライアント＃Ｐ１は、ステップＳ４７において、メディアＩＭサーバ１４からの要求を受信すると、これをステップＳ４８において、アプリケーション＃１に送信する。アプリケーション＃１は、ステップＳ４９において、この要求を受信する。
アプリケーション＃１は、この要求を受信すると、ステップＳ５０において、サービスコンシューマ５２（アプリケーション＃ｎ）がサービスプロバイダ５１（アプリケーション＃１）に対して接続するために必要な接続情報を含む応答を、サービスコンシューマ５２に送信する。この接続情報は、例えば、サービスコンシューマ５２がサービスプロバイダ５１に接続する際にアクセスするアドレスである、サービスプロバイダ５１のアドレスを示すＵＲＩ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｉｄｅｎｔｉｆｉｅｒ）（サービスＵＲＩ）とすることができる。
アプリケーション＃１からステップＳ５０の処理で送信された応答は、ステップＳ５１において、メディアＩＭクライアント＃Ｐ１で受信され、メディアＩＭクライアント＃Ｐ１は、ステップＳ５２において、その応答を、メッセージング機能またはＩｎｆｏ／Ｑｕｅｒｙ機能を利用して、サービスコンシューマ５２に向けて送信する。メディアＩＭサーバ１４は、ステップＳ５３において、メディアＩＭクライアント＃Ｐ１からの応答を受信すると、ステップＳ５４において、これをメディアＩＭクライアント＃Ｃ１に送信する。メディアＩＭクライアント＃Ｃ１は、ステップＳ５５において、メディアＩＭサーバ１４からの応答を受信すると、ステップＳ５６において、これをアプリケーション＃ｎに送信する。アプリケーション＃ｎは、ステップＳ５７において、この応答を受信する。
アプリケーション＃１は、ステップＳ５０において、応答の送信を指示した後、アプリケーション＃ｎからの直接の（メディアＩＭサーバ１４を介さない）アクセスを待機している。そこで、ステップＳ５８において、アプリケーション＃ｎは、メディアＩＭサーバ１４を介さずに、ピアツーピアで、アプリケーション＃１のサービスＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）にアクセスする。ステップＳ５９において、アプリケーション＃１は、アプリケーション＃ｎからのピアツーピアのＵＲＬへのアクセスを受け付ける。
以後、アプリケーション＃１とアプリケーション＃ｎは、ピアツーピアで情報を授受することが可能となる。
以上に説明した手順を行うことにより、最終的に、プロファイルアトムというアプリケーション＃１とアプリケーション＃ｎは、実行可能な機能を事前に交換しているため、アプリケーション＃１とアプリケーション＃ｎとの間の接続性が保証され、情報が授受できないといった事態が発生することが防止される。
以上のように、本発明のアプリケーションプラットフォームは、インスタントメッセージのプレゼンス機能、メッセージング機能、およびＩｎｆｏ／Ｑｕｅｒｙ機能をベースとして、アプリケーションレベルでのプロファイルのネゴシエーションを実現する新たなプロトコルアーキテクチャを構築している。その結果、このアプリケーションプラットフォームにおけるマッチングメーキングの仕組みを用いることによって、パーソナルコンピュータ、モバイル機器などの能力が異なる（勿論、同一でもよいが）様々なデバイスに実装されたアプリケーション同志が、簡単かつ確実に接続可能となる。これにより、文字、音声、音楽、動画、静止画といった様々な情報からなるリッチメディア情報を、ピアツーピアコミュニケーションで伝送することが可能なシステムを実現することができる。この場合において、最終的に接続性が保証されたアプリケーション（サービスエンティティ同志）がピアツーピアでコミュニケーションを図ることができる。従って、ユーザは、特別の操作を行わずとも、簡単かつ確実に、情報を授受することが可能となる。
上述したアプリケーション（サービスエンティティ）は、パーソナルコンピュータやネットワーク対応のＣＥ（Ｃｏｎｓｕｍｅｒ  Ｅｌｅｃｔｒｏｎｉｃｓ）機器のみならず、インターネット１上の商用アプリケーションサーバにも適用することが可能となる。
例えば、図１のアプリケーションサーバ１５においては、商用プリントサービスのアプリケーションが、サービスプロバイダとして、メディアＩＭクライアント＃４上で実行される。従って、図１におけるパーソナルコンピュータ１１，１２あるいはＰＤＡ１３は、アプリケーションサーバ１５との間で上述した手順を実行することで、アプリケーションサーバ１５が提供するプリントサービスを、インターネット１を介して利用することができる。
従って、本発明においては、インターネット１に接続されている各サーバが提供しているサービスを検索することで、サービスプロバイダの一覧をＢｕｄｄｙリストとして、例えば、図１１に示されるように、表示することができる。
図１１の例においては、ＰＤＡ１３に実装されたメディアＩＭクライアント＃３上で、サービスコンシューマとして動作しているプリントサービスのアプリケーションが利用できるサービスプロバイダの一覧が表示されている。この場合において、プレゼンス機能を用いることによって、サービスコンシューマに応じてきめ細かく、かつ自由に、商用サービスのステータスを表現することができる。例えば、図１１の例において、商用サービスを運用中であるか否かを、ランプアイコン１３Ａで表示するようにすることができる。この場合、例えば、運用中の商用サービスは、緑色で表示し、休止中の商用サービスは、赤色で表示するようにすることができる。また、図１１の例においては、依頼したプリントが仕上がる時刻、価格などの細かい状況も、ステータス情報として表示されている。
なお、当然のことながら、ユーザ端末上のサービスプロバイダとサービスコンシューマのアプリケーション間においても、ユーザインタフェースおよびプレゼンス機能により、相手先に応じたきめ細かいステータス表示をアプリケーション毎に行うことが可能である。
図１２は、パーソナルコンピュータ１１の構成例を表している。なお、図示は省略するが、他のパーソナルコンピュータ１２も同様に構成される。従って、この図１２には、パーソナルコンピュータ１２の構成としても、適宜、引用される。
図１２において、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１２１は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１２２に記憶されているプログラム、または記憶部１２８からＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１２３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１２３にはまた、ＣＰＵ１２１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１２１、ＲＯＭ１２２、およびＲＡＭ１２３は、バス１２４を介して相互に接続されている。このバス１２４にはまた、入出力インタフェース１２５も接続されている。
入出力インタフェース１２５には、キーボード、マウスなどよりなる入力部１２６、ＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  ｄｉｓｐｌａｙ）などよりなるディスプレイ、並びにスピーカなどよりなる出力部１２７、ハードディスクなどより構成される記憶部１２８、モデム、ターミナルアダプタなどより構成される通信部１２９が接続されている。通信部１２９は、インターネットを含むネットワークを介しての通信処理を行う。
入出力インタフェース１２５にはまた、必要に応じてドライブ１３０が接続され、磁気ディスク１４１、光ディスク１４２、光磁気ディスク１４３、或いは半導体メモリ１４４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部１２８にインストールされる。
上述したアプリケーション＃１（サービスプロバイダ５１）及びメディアＩＭクライアント＃Ｐ１またはアプリケーション＃ｎ（サービスコンシューマ５２）及びメディアＩＭクライアント＃Ｃ１は、ＣＰＵ１２１により、ＲＡＭ１２３によりロードされ、実行される。
本発明においては、以上に説明したように、プロファイルにより、サービス内容を記述して、サービスコンシューマに提供される。このプロファイル（プロファイルディスクリプション）は、Ｍ次元のパラメータで表記される。ここで次元とは、パラメータの実質的な数を意味する。図１３に示される例では、プロファイルが５次元のパラメータにより構成されている（Ｍ＝５とされている）。
図１３は、図８の例におけるプロファイルスペースとは異なる、ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）４のストリーミングサーバのプロファイルスペースを表している。図１３の例の場合、パラメータは、主に、全体に関連するパラメータ、ビデオに関するパラメータ、並びにオーディオに関するパラメータの３つにより構成される。そのうちの全体に関連するパラメータは、アクセスメソッド（ａｃｃｅｓｓ  ｍｅｔｈｏｄ）とリンクスピード（Ｌｉｎｋ  Ｓｐｅｅｄ）とにより構成され、ビデオに関するパラメータは、Ｘ  ｓｃａｌｅとＹ  ｓｃａｌｅとにより構成される。すなわち、ａｃｃｅｓｓ  ｍｅｔｈｏｄ，Ｌｉｎｋ  Ｓｐｅｅｄ，Ｘ  ｓｃａｌｅ，Ｙ  ｓｃａｌｅ，ａｕｄｉｏ  ｃｏｄｅｃの５次元の（５個の）パラメータにより構成される。そして、この５次元のパラメータは、「１００００００２」のプロファイルスペースＩＤにより識別される。
このプロファイルのａｃｃｅｓｓ  ｍｅｔｈｏｄは、通信に用いられるプロトコルを表し、番号１で表されるＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅａｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）／ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）＋ＲＴＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）／ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）、または番号２で表されるＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）ｔｕｎｎｅｌｌｉｎｇのいずれかとされる。
使用されている通信回線のデータ転送速度を表すＬｉｎｋ  Ｓｐｅｅｄは、図８の例におけるｂｉｔ  ｒａｔｅに対応し、６ｋｂｐｓ乃至１０００００ｋｂｐｓの範囲のいずれかの値とされる。
画面のＸ軸方向の大きさを表すＸ  ｓｃａｌｅは、１２８ｐｉｘｅｌ乃至３５２ｐｉｘｅｌの範囲とされ、Ｙ軸の方向の大きさを表すＹ  ｓｃａｌｅは、９６ｐｉｘｅｌ乃至２８８ｐｉｘｅｌの範囲とされる。
オーディオの圧縮伸長方式を表すａｕｄｉｏ  ｃｏｄｅｃは、番号０で表されるなし（ｎｏｎｅ）、番号１で表されるＣＥＬＰ  ８ｋ、番号２で表されるＣＥＬＰ（Ｃｏｄｅ  Ｅｘｃｉｔｅｄ  Ｌｉｎｅａｒ  Ｐｒｅｄｉｃｔｉｖｅ）１６ｋ、番号３で表されるＡＡＣ（Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）１６ｋ、番号４で表されるＡＡＣ  ３２ｋ、番号５で表されるＡＡＣ  ４４．１ｋ、または番号６で表されるＡＡＣ  ４８ｋのいずれかとされる。
このように、パラメータは、全て整数値で表現される。また、１つの次元を構成する１つのパラメータが、複数の整数値の組み合わせとして表現される場合、次のような論理記号が用いられる。
１つのパラメータが、複数の整数値のいずれか１つとして表現される場合、「ＯＲ」（または）の論理記号が用いられる。「ＯＲ」は、［ｋ］｜［ｍ］｜［ｎ］のように、［｜］で区切って表される。これは、そのパラメータが、ｋ，ｍ，ｎのいずれか１つとされることを意味する。この場合、ｋ，ｍ，ｎは整数とされ、小さい順番に（ｋ＜ｍ＜ｎのように）、配置される。
例えば、後述する図１５において、ａｃｃｅｓｓ  ｍｅｔｈｏｄが、、「１｜２」とされているが、これは、ａｃｃｅｓｓ  ｍｅｔｈｏｄが、１（ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰ）または２（ＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇ）のいずれかであることを意味する。
１つのパラメータが、所定の範囲の中の整数値で表される場合、その範囲を表す論理記号「：」が用いられる。範囲は、［ｍ］：［ｎ］＃［ｋ］のように表される。［ｍ］は、始値を表し、［ｎ］は、終値を表す。［ｍ］と［ｎ］は、省略することができない。また、当然のことながら、始値［ｍ］は、終値［ｎ］と等しいか、それより小さい値とされる。＃［ｋ］は、始値［ｍ］と終値［ｎ］の間の変化幅を規定するステップを表し、［ｋ］は、自然数かつ正規化のための基本単位を１とする倍数値とされる。［ｋ］は、省略することができる。
例えば、ビデオＸ軸が、「８：２２＃２」と表される場合、これは、ビデオＸ軸が、（８，１０，１２，１４，１６，１８，２０，２２）のいずれかであることを表す。すなわち、正規化のための基本単位が１６ピクセルであるとすると（１６ピクセルがｋ＝１に対応するものとすると）、この表現は、１２８ピクセル乃至３５２ピクセルを、３２ピクセル（ｋ＝２に対応する）おきにサンプリングした値の集合を表す。
サービスを受けることが可能であるのか否の容易な判定が困難になるため、範囲（レンジ）と「ＯＲ」の複合記述は禁止される。適用できない（Ｎ／Ａ（ｎｏｔ−ａｐｐｌｉｃａｂｌｅ）のパラメータは、空（，，）（ｎｕｌｌ）で表される。
さらに、プロファイルを具体的に記述する場合には、各パラメータは、正規化のための単位として予め定められた基本単位で正規化される。図１４に示されるように、Ｌｉｎｋ  Ｓｐｅｅｄの基本単位は、ｋｂｐｓとされ、Ｘ  ｓｃａｌｅとＹ  ｓｃａｌｅの基本単位は、それぞれ１６ｐｉｘｅｌとされる。従って、図１３に示されるＸ  ｓｃａｌｅの１２８ｐｉｘｅｌ乃至３５２ｐｉｘｅｌは、１６ｐｉｘｅｌで正規化すると、８乃至２２と表記され、Ｙ  ｓｃａｌｅの９６ｐｉｘｅｌ乃至２８８ｐｉｘｅｌは、６乃至１８と表記される。
以上がパラメータのスタンダードの表記方法とされるが、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌｕｎｇｕａｇｅ）Ｄｏｃｕｍｅｎｔでカスタムな表記を追加することが可能とされる。
また、各次元を構成する要素は、適宜追加することが可能である。例えば、ａｕｄｉｏ  ｃｏｄｅｃは、図１３の例の場合、番号０から番号６で表される７個のいずれかとされるが、それ以外の番号７あるいは番号８で表される要素を追加、拡張することができる。
ただし、追加した場合には、下位互換性が確保されることが要求される。すなわち、番号７または番号８で表される追加したａｕｄｉｏ  ｃｏｄｅｃの要素を有しない装置も、このプロファイルスペースＩＤが「１００００００２」であるプロファイルスペースを利用することができることが要求される。各装置が、プロファイルスペースＩＤによりその内容を判定することができることを保証するためである。従って、各次元を構成する要素の数が増加されても、各装置が、プロファイルスペースＩＤによりその内容を判定することができるので（互換性が確保されるので）、プロファイルスペースＩＤは、変更されない。逆に、次元が増加された場合には、各装置が、プロファイルスペースＩＤによりその内容を判定することができないので（互換性が確保できないので）、プロファイルスペースＩＤは変更される。
また、本発明においては、プロファイルは、他のパラメータとの共存が制限される可能性が最も高い主要因パラメータに基づいて、複数の領域（ｒｅｇｉｏｎ）に区分して、作成することが可能とされる。
他のパラメータとの共存が制限されるとは、そのパラメータの値が所定の値を取ると、他のパラメータとの組み合わせが困難になるようなパラメータをいう。本発明においては、リンクスピードが主要因パラメータとされる。
例えば、ユーザに、Ｌｉｎｋ  Ｓｐｅｅｄとして任意の値を選択させ、ａｕｄｉｏ  ｃｏｄｅｃとして任意の値を選択させると、実際には実現できないか、実現が困難となる環境が規定されてしまうことがある。例えば、リンクスピードが５０ｋｂｐｓ未満であるアナログの電話回線に接続されているパーソナルコンピュータが、ａｕｄｉｏ  ｃｏｄｅｃとして番号５で示されるＡＡＣ  ４４．１ｋや、番号６で示されるＡＡＣ  ４８ｋといったａｕｄｉｏ  ｃｏｄｅｃを選択したとしても、そのような関係は、実際には、実現することが困難となる。
そこで、本発明においては、図１５に示されるように、アナログ電話回線などにおける場合のように、リンクスピードが５０ｋｂｐｓ未満（４９ｋｂｐｓ以下）の第１の領域（（１）のｒｅｇｉｏｎ）、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ  Ｓｅｒｖｉｃｅ  Ｄｉｇｉｔａｌ  Ｎｅｔｗｏｒｋ）やＰＨＳなどにおける場合のような、５０ｋｂｐｓ以上２００ｋｂｐｓ未満（１９９ｋｂｐｓ以下）の第２の領域（（２）のｒｅｇｉｏｎ）、さらにＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）における１．５Ｍｂｐｓまたは８Ｍｂｐｓなどにおける場合のような、２００ｋｂｐｓ以上の第３の領域（（３）のｒｅｇｉｏｎ）に区分される。さらに、リンクスピードが２００ｋｂｐｓ以上であって、その装置が使用しているＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）の能力が高い場合の領域として、第４の領域（（４）のｒｅｇｉｏｎ）が規定される。
図１５の例の場合、第１の領域においては、アクセスメソッドは１または２とされ、リンクスピードは３５ｋｂｐｓ乃至４９ｋｂｐｓとされる。Ｘ  ｓｃａｌｅは１０とされ、Ｙ  ｓｃａｌｅは７とされる。ａｕｄｉｏ  ｃｏｄｅｃは、０または１のいずれかとされる。
第２の領域においては、アクセスメソッドは１または２とされ、リンクスピードは５０ｋｂｐｓ乃至１９９ｋｂｐｓとされる。Ｘ  ｓｃａｌｅとＹ  ｓｃａｌｅは、第１の領域における場合と同様に、それぞれ、１０または７とされる。ａｕｄｉｏ  ｃｏｄｅｃは、１または２とされる。
第３の領域においては、アクセスメソッドは１または２とされ、リンクスピードは２００ｋｂｐｓ乃至１０００００ｋｂｐｓとされる。Ｘ  ｓｃａｌｅは１０とされ、Ｙ  ｓｃａｌｅは７とされる。ａｕｄｉｏ  ｃｏｄｅｃは１乃至６のいずれかとされる。
第４の領域においては、アクセスメソッドは１または２とされ、リンクスピードは第３の領域における場合と同様に、２００ｋｂｐｓ乃至１０００００ｋｂｐｓとされる。Ｘ  ｓｃａｌｅは２０とされ、Ｙ  ｓｃａｌｅは１５とされる。ａｕｄｉｏ  ｃｏｄｅｃは、１乃至６のいずれかとされる。
各領域においては、５次元の各パラメータは、１次元の整数値として規定される。すなわち、１個の数値として規定される。
プロファイルの分割の数（領域の数）は、各サービスプロバイダが任意に行うことができる。また、プロファイルディスクリプションの値（各領域における各次元の構成要素の値）をいずれの値にするかも、サービスプロバイダが任意に設定することができる。
なお、領域の数が変更されても、プロファイルスペースＩＤは変更されない。
このように、主要因パラメータに基づいて、複数の領域に分割しておくと、１つの領域内においては、サービスコンシューマが５次元のパラメータの値をいずれの値に設定したとしても、実現困難あるいは実現不可能な環境が設定されることがない。従って、サービスコンシューマが複数の領域の中から１つの領域を選択し、その領域の５次元のパラメータの中から任意の値を適宜選択することが可能となる。
具体的には、上述した図５のステップＳ２５の処理で、サービスプロバイダ５１のプロバイダプロファイル（プロファイルディスクリプション）を受信したとき、サービスコンシューマ５２（アプリケーション＃ｎ）は、プロバイダプロファイルの各領域に記述されている主要因パラメータ（リンクスピード）の値を、自分自身のコンシューマプロファイルの主要因パラメータと比較し、整合する部分が存在する領域を抽出する。主要因パラメータは、上述したように、整数で表されているため、単純な整数値演算によって、整合する範囲があるか否かを容易に算出することが可能となる。
パラメータをこのように、領域に区分しない場合には、複雑な場合分けを伴ったプログラムを駆使しなければ、サービスコンシューマ５２は、適用可能なサービスを選択することができなくなる。
以上のように、サービスは、Ｍ次元のパラメータで構成される空間（スペース）により表現される。個々の空間は、プロファイルスペースＩＤにより識別される。個々の空間を構成するパラメータは、整数値と論理記号の組み合わせで表現される。論理記号としては、複数の整数値のいずれか１つの選択を表現する「ＯＲ」と、整数値の集合を表す「範囲」が用いられる。サービスをこのようなデータ構造で表現することで、サービスを提供するサービスプロバイダと、サービスの提供を受ける（サービスを利用する）サービスコンシューマとの間で、迅速且つ簡単に、サービスの利用の可否を判定することが可能になる。
次に、サービスプロバイダ５１（アプリケーション＃１）が、サービスコンシューマ５２（アプリケーション＃ｎ）に提供するプロファイル（プロファイルディスクリプション）を作成する処理について、図１６と図１７のフローチャートを参照して説明する。この処理は、図５のステップＳ１８におけるプロバイダファイルの組立処理に対応する処理である。
いま、アプリケーション＃１が、図１３に示されたプロファイルスペースＩＤが「１００００００２」のプロバイダプロファイル（自分自身の機能に関するプロファイル）を生成するものとする。そして、アプリケーション＃１は、８ＭｂｐｓのＡＤＳＬ回線に接続されており、その実際の回線のスループットの値（ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄ（カレントリンクスピード））から、主要因パラメータであるリンクスピードは４８００ｋｂｐｓであり、ビデオの表示系はＶＧＡ（Ｖｉｄｅｏ  Ｇｒａｐｈｉｃｓ  Ａｒｒａｙ）系であり、ＣＰＵの処理能力は、比較的低いものであるとする。
以下の各ステップにおいて、アプリケーション＃１は、各領域に対応する自分自身の能力（機能）を調べ、各パラメータに、各領域に対応する自分自身の能力に対応する値を設定する。従って、以下に述べる各ステップにおいて各パラメータに設定される具体的数値は、各領域に対応する自分自身の能力に対応する値である。アプリケーション＃１は、自分自身の能力を、各ステップにおいて、その都度調べてもよいし、予め、調べて記憶しておいたものを読み出して使用するようにしてもよい。
ステップＳ７１において、アプリケーション＃１は、パラメータを設定する変数ＰＳＩｄに、いま対象とされているプロファイルスペースＩＤの値「１００００００２」を設定する。
以下、ステップＳ７２乃至ステップＳ７８において、第１の領域に関するパラメータの設定処理が行われ、ステップＳ７９乃至ステップＳ８５において、第２の領域に関するパラメータの設定が行われ、ステップＳ８６乃至ステップＳ９２において、第３の領域に関するパラメータの設定が行われ、そして、ステップＳ９３乃至ステップＳ９８において、第４の領域に関するパラメータの設定が行われる。
ステップＳ７２において、アプリケーション＃１は、領域が第１の領域であることを表す変数ＰＳＩｄ．ｒｅｇｉｏｎに値「１」を設定する。
すなわち、図１８に示されるように、プロファイルスペースＩＤが１００００００２のプロファイルは、ＰＳＩｄ（プロファイルスペースＩＤ）をルートとして、ｒｅｇｉｏｎ（Ｒｅｇｉｏｎ）毎に、ａｃｃｅｓｓ（Ａｃｃｅｓｓ  Ｍｅｔｈｏｄ），ｌｉｎｋＳｐｅｅｄ（Ｌｉｎｋ  Ｓｐｅｅｄ），ｘＳｃａｌｅ（Ｘ  ｓｃａｌｅ），ｙＳｃａｌｅ（Ｙ  ｓｃａｌｅ），ａｕｄｉｏ（Ａｕｄｉｏ  Ｃｏｄｅｃ）の各パラメータで構成される。以下、上記ツリーの構造は、各階層を（．）で区切り、例えば、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｃｃｅｓｓという記述方法で記述する。
従って、ＰＳＩｄ．ｒｅｇｉｏｎには、具体的には、「１００００００２．１」が設定されることになる。ただし、図１６と図１７においては、記述が長くなるので、新たに設定されたパラメータだけが示されている。
ステップＳ７３において、アプリケーション＃１は、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄとして、１：ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰ、または２：ＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇを示す｛１｜２｝をＰＳＩｄ．ｒｅｇｉｏｎ．ａｃｃｅｓｓに設定する。これは、上述したように、アプリケーション＃１が、「ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰ」を用いた通信を行う機能を有するとともに、「ＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇ」を用いた通信を行う機能をも有するからである。仮に、アプリケーション＃１が、「ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰ」を用いた通信を行う機能しか有していないのであれば（「ＨＴＴＰ  ｔｕｎｎｅｌｌｉｎｇ」を用いた通信を行う機能を有していないのであれば）、アプリケーション＃１は、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄとして、１：ＲＴＳＰ／ＴＣＰ＋ＲＴＰ／ＵＤＰを示す｛１｝をＰＳＩｄ．ｒｅｇｉｏｎ．ａｃｃｅｓｓに設定することになる。
ステップＳ７４において、アプリケーション＃１は、Ｌｉｎｋ  Ｓｐｅｅｄとして、３０ｋｂｐｓから４９ｋｂｐｓを表す｛３９：４９｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに設定する。これは、いま処理対象としている領域が第１の領域であり、第１の領域のデフォルトのＬｉｎｋ  Ｓｐｅｅｄが、３０ｋｂｐｓから４９ｋｂｐｓであるからである（従って、後述するように、対応する第２乃至第４の領域のステップＳ８１，Ｓ８８，Ｓ９５の処理では、各領域におけるデフォルトのＬｉｎｋ  Ｓｐｅｅｄである、５０ｋｂｐｓから１９９ｋｂｐｓ，２００ｋｂｐｓから１０００００ｋｂｐｓ，または２００ｋｂｐｓから１０００００ｋｂｐｓが、それぞれ設定される）。
ステップＳ７５において、アプリケーション＃１は、Ｘｓｃａｌｅとして、１６０ｐｉｘｅｌを示す｛１０｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｘＳｃａｌｅに設定し、Ｙ  ｓｃａｌｅとして、１１４ｐｉｘｅｌを示す｛７｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｙＳｃａｌｅに設定する。これらの値も、アプリケーション＃１が有する画像表示の画角に関する機能に基づくものである。
ステップＳ７６において、アプリケーション＃１は、ａｕｄｉｏ  Ｃｏｄｅｃとして０：ｎｏｎｅ、または１：ＣＥＬＰ  ８ｋを表す｛０｜１｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｕｄｉｏに設定する。これも、アプリケーション＃１が、ａｕｄｉｏ  Ｃｏｄｅｃとして０：ｎｏｎｅ、または１：ＣＥＬＰ  ８ｋの両方の機能に対応しているからである。
次に、ステップＳ７７において、アプリケーション＃１は、自分自身が実際に接続されている回線の実効スループットを示すカレントスピード（Ｃｕｒｒｅｎｔ  Ｌｉｎｋ  Ｓｐｅｅｄ）の値が、次の第２の領域の下限値である５０ｋｂｐｓと比較して、それより小さいか否かを判定する。カレントリンクスピードが５０ｋｂｐｓより小さい場合には、第２の領域以上の領域を規定することができないので、ステップＳ７８に進み、アプリケーション＃１は、Ｌｉｎｋ  Ｓｐｅｅｄとして３０ｋｂｐｓからカレントリンクスピード（ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄ）までの値を示す｛３０：ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄ｝をＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに再度設定する。すなわち、ステップＳ７４の処理で設定された値｛３０：４９｝の値が更新される。これにより、使用可能な最大の値がパラメータとして設定される。
いまの場合、アプリケーション＃１のＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄは、４８００ｋｂｐｓであるため、５０ｋｂｐｓより大きいのでステップＳ７９に進み、第２の領域のパラメータ設定処理が実行される。
ステップＳ７９において、アプリケーション＃１は、ＰＳＩｄ．ｒｅｇｉｏｎに第２の領域である値「２」を設定する。具体的には、ＰＳＩｄ．ｒｅｇｉｏｎに「１００００００２．２」が設定されることになる。
ステップＳ８０において、ステップＳ７３における場合と同様に、アプリケーション＃１は、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄとして｛１｜２｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｃｃｅｓｓに設定する。
ステップＳ８１において、アプリケーション＃１は、Ｌｉｎｋ  Ｓｐｅｅｄとして、５０ｋｂｐｓから１９９ｋｂｐｓを示す｛５０：１９９｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに設定する。
ステップＳ８２において、アプリケーション＃１は、ステップＳ７５における場合と同様に、Ｘ  Ｓｃａｌｅとして｛１０｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｘＳｃａｌｅに設定し、Ｙ  Ｓｃａｌｅとして｛７｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｙＳｃａｌｅに設定する。
ステップＳ８３において、アプリケーション＃１は、Ａｕｄｉｏ  Ｃｏｄｅｃとして１：ＣＥＬＰ  ８ｋ、または２：ＣＥＬＰ  １６ｋを示す｛１｜２｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｕｄｉｏに設定する。
ステップＳ８４において、アプリケーション＃１は、ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値が、次の第３の領域の下限値である２００ｋｂｐｓと比較して、それより小さいか否かを判定する。ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値が２００ｋｂｐｓより小さい場合には、第３の領域のパラメータを設定することができないので、ステップＳ８５に進み、アプリケーション＃１は、Ｌｉｎｋ  Ｓｐｅｅｄとして｛５０：ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄ｝を、ＰＳＩｄ：ｒｅｇｉｏｎ：ｌｉｎｋＳｐｅｅｄに再度設定する。すなわち、ステップＳ８１で設定された｛５０：１９９｝の値が更新される。
ステップＳ８４において、ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値が、２００ｋｂｐｓより大きいと判定された場合、ステップＳ８６に進み、第３の領域のパラメータ設定処理が実行される。いまの場合、アプリケーション＃１は、そのＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値は、４８００ｋｂｐｓであるため、ステップＳ８４において、ＮＯの判定が行われ、ステップＳ８６以降の処理が実行される。
ステップＳ８６において、アプリケーション＃１は、第３の領域の値「３」をＰＳＩｄ．ｒｅｇｉｏｎに設定する。具体的には、ＰＳＩｄ．ｒｅｇｉｏｎに「１００００００２．３」の値が設定される。
ステップＳ８７において、アプリケーション＃１は、ステップＳ８０における場合と同様に、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄとして｛１｜２｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｃｃｅｓｓに設定する。
ステップＳ８８において、アプリケーション＃１は、Ｌｉｎｋ  Ｓｐｅｅｄとして、２００ｋｂｐｓから１０００００ｋｂｐｓを示す｛２００：１０００００｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに設定する。
ステップＳ８９において、アプリケーション＃１は、ステップＳ８２における場合と同様に、Ｘ  Ｓｃａｌｅとして｛１０｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｘＳｃａｌｅに設定し、Ｙ  Ｓｃａｌｅとして｛７｝を、ＰＩＳｄ．ｒｅｇｉｏｎ．ｙＳｃａｌｅに設定する。
ステップＳ９０において、アプリケーション＃１は、Ａｕｄｉｏ  Ｃｏｄｅｃとして、１：ＣＥＬＰ８ｋ，２：ＣＥＬＰ１６ｋ，３：ＡＡＣ１６ｋ，４：ＡＡＣ３２ｋ，５：ＡＡＣ４４．１ｋ、または６：ＡＡＣ  ４８ｋを示す｛１｜２｜３｜４｜５｜６｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｕｄｉｏに設定する。
ステップＳ９１において、アプリケーション＃１は、次の第４の領域のパラメータを設定する条件として、ＣＰＵの性能が低いか否かを判定する。ＣＰＵは、そのクロックの周波数が予め設定されている所定の基準の周波数（例えば、８００ＭＨｚ）より低い場合、あるいは所定の種類（例えば、Ｐｅｎｔｉｕｍ（登録商標）４）より低い機能のＣＰＵである場合には、ＣＰＵの性能が低いと判定される。
いまの場合、アプリケーション＃１のＣＰＵは性能が低いため、ステップＳ９１でＹＥＳと判定され、ステップＳ９２において、アプリケーション＃１は、第３の領域のＬｉｎｋ  Ｓｐｅｅｄの更新処理を行う。これにより、Ｌｉｎｋ  Ｓｐｅｅｄとして｛２００：ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄ｝と設定されていたものが、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに再度設定される。すなわち、ステップＳ８８の処理で設定された｛２００：１００００００｝の値が、使用可能な最大値に更新される。
ステップＳ９１において、ＣＰＵの性能が低くない（高い）と判定された場合（クロック周波数が８００ＭＨｚ以上であるか、またはＰｅｎｔｉｕｍ（登録商標）４と同等か、それ以上の機能のＣＰＵである場合）には、ステップＳ９３に進み、第４の領域のパラメータ設定処理が実行される。
ステップＳ９３において、アプリケーション＃１は、第４の領域であることを表す値「４」を、ＰＳＩｄ．ｒｅｄｉｏｎに設定する。具体的には、「１００００００２．４」が設定される。
ステップＳ９４において、アプリケーション＃１は、ステップＳ８７における場合と同様に、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄとして｛１｜２｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｃｃｅｓｓに設定する。
ステップＳ９５において、アプリケーション＃１は、ステップＳ８８における場合と同様に、Ｌｉｎｋ  Ｓｐｅｅｄとして｛２００：１０００００｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに設定する。
ステップＳ９６において、アプリケーション＃１は、Ｘ  ｓｃａｌｅとして３２０ｐｉｘｅｌを示す｛２０｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｘＳｃａｌｅに設定し、Ｙ  ｓｃａｌｅとして２４０ｐｉｘｅｌを示す｛１５｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｙＳｃａｌｅに設定する。
ステップＳ９７において、アプリケーション＃１は、ステップＳ９０における場合と同様に、Ａｕｄｉｏ  Ｃｏｄｅｃとして｛１｜２｜３｜４｜５｜６｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｕｄｉｏに設定する。
最後に、ステップＳ９８において、アプリケーション＃１は、Ｌｉｎｋ  Ｓｐｅｅｄとして｛２００：ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄ｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに再度設定する。すなわち、ステップＳ９５の処理で設定された｛２００：１０００００｝の値が更新される。
以上のようにして、設定されたサービスプロバイダ５１としてのアプリケーション＃１のプロバイダプロファイル（プロバイダプロファイルディスクリプション）が図１９に示されている。同図に示されるように、この場合、上述したステップＳ７１乃至ステップＳ９２の処理により、３つの領域のパラメータが設定されている。設定されているパラメータは、図１６と図１７を参照して説明した値の通りである。
図１６と図１７に示されるプロファイルディスクリプション作成処理は、サービスコンシューマ５２としてのアプリケーション＃ｎにおいても実行され、それによりコンシューマプロファイルが作成される。但し、図１６と図１７の各ステップに記載されているパラメータの具体的な値は、アプリケーション＃１のものであり、アプリケーション＃ｎのものではないので、各ステップで設定される値は異なるものとなる。
例えば、サービスコンシューマ５２としてのアプリケーション＃ｎが比較的低速なＩＳＤＮ６４ｋｂｐｓの回線に接続され、実効スループットであるＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄが４８ｋｂｐｓであるとする。この場合、図１６と図１７に示されるプロファイルディスクリプション作成処理が実行されると、ステップＳ７１乃至ステップＳ７８の第１の領域の処理のみが実行される。すなわち、ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値（４８ｋｂｐｓ）が５０ｋｂｐｓより小さいため、ステップＳ７７において、ＹＥＳと判定され、ステップＳ７９以降の処理は実行されない。
すなわち、この場合、アプリケーション＃ｎは、ステップＳ７１において、ＰＳＩｄに、「１００００００２」を設定し、ステップＳ７２において、ＰＳＩｄ．ｒｅｇｉｏｎとして第１の領域であることを示す値「１」を設定する。具体的には、ＰＳＩｄ．ｒｅｇｉｏｎに「１００００００２．１」が設定される。
ステップＳ７３において、アプリケーション＃ｎは、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄとして｛１｜２｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ａｃｃｅｓｓに設定する。
ステップＳ７４において、アプリケーション＃ｎは、Ｌｉｎｋ  Ｓｐｅｅｄとして｛３０：４８｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに設定する。
ステップＳ７５において、アプリケーション＃ｎは、Ｘ  Ｓｃａｌｅとして｛１０｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｘＳｃａｌｅに設定し、Ｙ  Ｓｃａｌｅとして｛７｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｙＳｃａｌｅに設定する。
ステップＳ７７において、ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値は、４８ｋｂｐｓであるため、５０ｋｂｐｓより小さいと判定され、ステップＳ７８において、アプリケーション＃ｎは、Ｌｉｎｋ  Ｓｐｅｅｄとして｛３０：ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄ｝を、ＰＳＩｄ．ｒｅｇｉｏｎ．ｌｉｎｋＳｐｅｅｄに再度設定する。すなわち、ステップＳ７４で設定された｛３０：４９｝の値が更新される。
以上のようにして、アプリケーション＃ｎにより生成されたコンシューマプロファイル（コンシューマプロファイルディスクリプション）は、図２０に示されるようになる。同図に示されるように、領域は、第１の領域だけとされる。この領域に設定される各パラメータは、上述したステップＳ７１乃至ステップＳ７８の処理で設定された値である。
アプリケーション＃ｎが図２０に示されるコンシューマプロファイルを有する場合、アプリケーション＃１から図１９に示されるようなプロバイダプロファイルが送信されてくると、図６のステップＳ２６において、アプリケーション＃ｎは、コンシューマプロファイルの主要因パラメータとしてのリンクスピード３０：４８（図２０）が、プロバイダプロファイルの主要因パラメータの値に整合する部分があるか否かを判定することになる。図１９のプロバイダプロファイルは、第１の領域のリンクスピードが３０：４９であり、第２の領域のリンクスピードが５０：１９９であり、第３の領域のリンクスピードが２００：４８００であるため、少なくとも１つの領域（第１の領域）において、整合する部分（重なる部分）がある（３０乃至４９の範囲は、３０乃至４８の値で、３０乃至４８の範囲と重なっている）と判定されることになる。その結果、上述したように、図６のステップＳ２６で、アプリケーション＃ｎは、提供されたサービスへの登録要求処理を実行し、その後、ステップＳ４２で、プロファイルアトムを作成することになる。
次に、図２１と図２２のフローチャートを参照して、このプロファイルアトム生成処理について説明する。この処理は、図７のステップＳ４２において実行される処理に対応する。
この処理では、最初に、ステップＳ１１１乃至ステップＳ１１５の処理で、サービスプロバイダが提示した各領域毎のパラメータ群から、サービスコンシューマが接続されているネットワークのＬｉｎｋ  Ｓｐｅｅｄ（主要因パラメータ）を考慮して、領域（Ｒｅｇｉｏｎ）が選択される。
すなわち、ステップＳ１１１において、アプリケーション＃ｎは、アプリケーション＃１から送信されてきたプロバイダプロファイルディスクリプション（図１９）を受信する。この処理は、図６のステップＳ４１の処理に対応する。
次に、ステップＳ１１２において、アプリケーション＃ｎは、内部の変数Ｎの値を０に初期化する。ステップＳ１１３において、アプリケーション＃ｎは、ステップＳ１１１の処理で受信したプロバイダプロファイルと、自分自身が図１６と図１７の処理を実行することで作成したコンシューマプロファイル（図２０）の中から、Ｎ＋１の領域の（いまの場合、Ｎ＝０であるので、第１の領域の）パラメータを抽出する。
ステップＳ１１４において、アプリケーション＃ｎは、ステップＳ１１３の処理で抽出した領域のＬｉｎｋ  Ｓｐｅｅｄが重なるか否かを判定する。いまの場合、第１の領域のＬｉｎｋ  Ｓｐｅｅｄが重なるか否かが判定される。両者のＬｉｎｋ  Ｓｐｅｅｄが重ならない場合には、ステップＳ１１６に進み、値Ｎが０外の値であるか否かを判定する。いまの場合、値Ｎは０であるため、Ｎ０と判定される。すなわち、この場合には、Ｌｉｎｋ  Ｓｐｅｅｄが重なる領域が１個も存在しないことになるので、アプリケーション＃ｎは、アプリケーション＃１と通信することができないことになる。そこで、処理は終了される。
図１９と図２０に示される例の場合、図２０の第１の領域のＬｉｎｋ  Ｓｐｅｅｄの３０：４８は、図１９の第１の領域のＬｉｎｋ  Ｓｐｅｅｄの３０：４９と重なるので、ステップＳ１１５に進み、アプリケーション＃ｎは、変数Ｎの値を１だけインクリメントする（いまの場合、Ｎ＝１とする）。
その後、ステップＳ１１３に戻り、アプリケーション＃ｎは、Ｎ＋１の領域（いまの場合、Ｎ＝１なので、第２の領域）のプロバイダプロファイルとコンシューマプロファイルのパラメータをアプリケーション＃ｎは取り出す。
ステップＳ１１４において、アプリケーション＃ｎは、ステップＳ１１３の処理で取り出されたパラメータのうちの、Ｌｉｎｋ  Ｓｐｅｅｄが重なるか否かを判定する。第２の領域のＬｉｎｋ  Ｓｐｅｅｄが重なる場合には、ステップＳ１１５に進み、変数Ｎの値がさらに１だけインクリメントされる（いまの場合、Ｎ＝２とされる）。
そして、ステップＳ１１３において、Ｎ＋１の領域（いまの場合、Ｎ＝２なので、第３の領域）のプロバイダプロファイルとコンシューマプロファイルが読み出される。ステップＳ１１４において、ステップＳ１１３で取り出されたパラメータのＬｉｎｋ  Ｓｐｅｅｄが重なるか否かが判定され、重なる場合には、再び、ステップＳ１１５に進み、変数Ｎの値が１だけインクリメントされる（いまの場合、Ｎ＝３とされる）。
以上のようにして、ステップＳ１１３乃至ステップＳ１１５の処理が繰り返し実行されることで、Ｌｉｎｋ  Ｓｐｅｅｄが重なる全ての領域が抽出される。プロバイダプロファイルとコンシューマプロファイルのうち、対応する領域がもはや存在しない場合、あるいは存在したとしても、Ｌｉｎｋ  Ｓｐｅｅｄが重ならないと判定された場合には、処理はステップＳ１１４からステップＳ１１６に進められ、値Ｎが０以外の値であるか否かが判定される。この場合における値Ｎは、ステップＳ１１３乃至ステップＳ１１５の処理により、Ｌｉｎｋ  Ｓｐｅｅｄが重なる領域のうちの、最も番号が大きい領域（最も高機能の領域）のその番号に対応している。従って、Ｌｉｎｋ  Ｓｐｅｅｄが１個でも重なる領域が存在する場合には、値Ｎは、０以外の値ということになる。
この場合、ステップＳ１１７に進み、アプリケーション＃ｎは、第Ｎ番目の領域のプロバイダプロファイルとコンシューマプロファイルのパラメータを取り出す。ステップＳ１１８において、アプリケーション＃ｎは、ステップＳ１１７の処理で取り出したプロバイダプロファイルのＡｃｃｅｓｓ  ＭｅｔｈｏｄとコンシューマプロファイルのＡｃｃｅｓｓ  Ｍｅｔｈｏｄが重なるか否かを判定する。
図１９と図２０に示される例の場合、第１の領域のＡｃｃｅｓｓ  Ｍｅｔｈｏｄは、いずれも｛１｜２｝であるから、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄが重なると判定される。もし、Ａｃｃｅｓｓ  Ｍｅｔｈｏｄが重ならないと判定された場合には、ステップＳ１１９に進み、変数Ｎの値が１だけデクリメントされる。すなわち、処理対象とされる領域が、１つだけ番号の値が小さい領域に変更される。そして、ステップＳ１１６において、値Ｎが０以外の値であるか否かが判定され、０以外の値ではない、すなわち、０であると判定された場合には、結局、プロファイルアトムが見つからなかったことになるため、処理は終了される。
このように、５次元のパラメータのうちの、１つでも重ならないパラメータが存在する場合には、１つ下の番号の領域に処理対象が移される。同様に、後述するステップＳ１２６において、Ｘ  ｓｃａｌｅとＹ  ｓｃａｌｅが重ならないと判定された場合、並びにステップＳ１２９において、Ａｕｄｉｏが重ならないと判定された場合にも、１つ下の番号の領域に処理対象が移されることになる。
図１９と図２０の例の場合、第１の領域のＡｃｃｅｓｓ  Ｍｅｔｈｏｄは、いずれも｛１｜２｝であるため、両者が重なることになるので、ステップＳ１２０に進み、アプリケーション＃ｎは、ＨＴＴＰ  Ｔｕｎｎｅｌｌｉｎｇを優先することが選択されているか否かが判定される。ファイアウォールがインターネット１との間に存在する場合には、ＨＴＴＰ  Ｔｕｎｎｅｌｌｉｎｇを優先することが選択されている。
この場合、ステップＳ１２１に進み、アプリケーション＃ｎは、プロファイルアトム（Ｐｒｏｆｉｌｅ  Ａｔｏｍ）のＡｃｃｅｓｓ  ＭｅｔｈｏｄであるＡｔｏｍＡｃｃｅｓｓに｛２｝（図１３）を設定する。これに対して、ステップＳ１２０において、ＨＴＴＰ  Ｔｕｎｎｅｌｌｉｎｇが優先されていないと判定された場合には、ステップＳ１２２において、アプリケーション＃ｎは、ＡｔｏｍＡｃｃｅｓｓに｛１｝（図１３）を設定する。
ステップＳ１２１、またはステップＳ１２２の処理の後、ステップＳ１２３に進み、アプリケーション＃ｎは、ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値が、プロバイダプロファイルのＬｉｎｋＳｐｅｅｄの最大値と等しいか、それより小さいか否かを判定する。アプリケーション＃ｎが接続されている回線の実効スループットを示すＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値が、プロバイダプロファイルのＬｉｎｋ  Ｓｐｅｅｄのパラメータの最大値以下である場合には、ステップＳ１２４において、アプリケーション＃ｎは、ＡｔｏｍＬｉｎｋＳｐｅｅｄにＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値を設定する。
これに対して、ステップＳ１２３において、ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄの値が、プロバイダプロファイルのＬｉｎｋ  Ｓｐｅｅｄの最大値より大きいと判定された場合には、ステップＳ１２５において、アプリケーション＃ｎは、ＡｔｏｍＬｉｎｋＳｐｅｅｄにプロバイダプロファイルのＬｉｎｋＳｐｅｅｄの最大値を設定する。
例えば、ＣｕｒｒｅｎｔＬｉｎｋＳｐｅｅｄが４８ｋｂｐｓであり、プロバイダプロファイルのＬｉｎｋＳｐｅｅｄのパラメータの最大値が４９ｋｂｐｓであれば、ステップＳ１２５において、プロファイルアトムのＡｔｏｍＬｉｎｋＳｐｅｅｄに｛４８｝が設定される。
次に、ステップＳ１２６において、アプリケーション＃ｎは、プロバイダプロファイルとコンシューマプロファイルのＸ  ｓｃａｌｅとＹ  ｓｃａｌｅが重なるか否かを判定する。両者が重ならない場合には、上述したように、ステップＳ１１９に進み、値Ｎを１だけデクリメントして、番号が１だけ小さい領域の処理に移行する。
ステップＳ１２６において、Ｘ  ｓｃａｌｅとＹ  ｓｃａｌｅが重なると判定された場合、ステップＳ１２７において、アプリケーション＃ｎは、プロファイルアトムのＸ  ｓｃａｌｅであるＡｔｏｍＸｓｃａｌｅに、重なったＸ  ｓｃａｌｅの最大値を設定する。さらに、ステップＳ１２８において、アプリケーション＃ｎは、プロファイルアトムのＹ  ｓｃａｌｅであるＡｔｏｍＹｓｃａｌｅに、重なったＹ  ｓｃａｌｅの最大値を設定する。
例えば、プロバイダプロファイルとコンシューマプロファイルのいずれもＸ  ｓｃａｌｅの最大値が１６０ｐｉｘｅｌ（１０×１６ｐｉｘｅｌ）であり、Ｙ  ｓｃａｌｅの最大値が１１２ｐｉｘｅｌ（７×１６ｐｉｘｅｌ）となっている場合、プロファイルアトムのＡｔｏｍＸｓｃａｌｅに｛１０｝が設定され、ＡｔｏｍＹｓｃａｌｅに｛７｝が設定される。
ステップＳ１２９において、プロバイダプロファイルとコンシューマプロファイルのＡｕｄｉｏ  Ｃｏｄｅｃの重なりが判定される。両者が重ならない場合には、上述したように、ステップＳ１１９に進み、値Ｎが１だけデクリメントされ、１つだけ小さい番号の領域の処理に移行する。
ステップＳ１２９において、プロバイダプロファイルとコンシューマプロファイルのＡｕｄｉｏ  Ｃｏｄｅｃが重なると判定された場合、ステップＳ１３０に進み、アプリケーション＃ｎは、プロファイルアトムのＡｕｄｉｏ  ＣｏｄｅｃであるＡｔｏｍＡｕｄｉｏに、重なったＡｕｄｉｏ  Ｃｏｄｅｃの中で最も音質の良いものを選択し、設定する。本例においては、プロファイル内に記述される各Ａｕｄｉｏ  Ｃｏｄｅｃに対して、音質の低いものから高いものの順番に値が大きくなるようにパラメータの番号付けが行われており、重なったＡｕｄｉｏ  Ｃｏｄｅｃの中で最も大きい番号のものを選択することによって、音質の高いものが選択される。例えば、プロバイダプロファイルとコンシューマプロファイルのいずれも、Ａｕｄｉｏ  Ｃｏｄｅｃが０：Ｎｏｎｅ、または１：ＣＥＬＰ  ８ｋとなっている場合、プロファイルアトムのＡｔｏｍＡｕｄｉｏには｛１｝が設定される。
ステップＳ１３１において、アプリケーション＃ｎは、以上の各ステップの処理で決定されたプロファイルアトムのパラメータの値を基に、プロファイルアトムを作成する（組み立てる）。
以上のようにして生成されたプロファイルアトムは、図７のステップＳ４２の処理により、アプリケーション＃１に通知される。
以上のようにして、本発明によれば、サービスに関するパラメータであって、数値化されたＭ次元のパラメータによりサービスの内容を表す詳細情報を生成するようにしたので、サービスの内容を、容易に識別することができ、ネットワークを介して、２つの装置が迅速且つ確実に情報を授受することが可能となる。
パラメータを基本単位により、正規化するようにすることで、より小さい数字で詳細情報を表現することが可能となる。従って、比較処理が容易となる。
パラメータを複数の領域に区分することで、複雑なアルゴリズムを用いることなく、簡単に、実際に情報を転送することが可能なパラメータを選択することが可能となる。
パラメータを１次元の整数値として表現することで、パラメータを容易に比較することが可能となる。
詳細情報を、整数値と論理記号の組み合わせで表現するようにすることで、パラメータを容易に比較することが可能な形式で表現することができる。
論理記号として、複数の前記整数値のいずれか１つの選択を表現する第１の記号と、前記整数値の集合を表す第２の記号を用いるようにすることで、パラメータを容易に比較することが可能な形式で表現することができる。
第２の記号として、範囲の始まりを表す始値、前記範囲の終わりを表す終値、並びに前記始値と前記終値の間の変化幅を規定するステップを用いるようにすることで、範囲を容易に比較することが可能な形式で表現することができる。
サービスは、ネットワークを介してデータを送信または受信するサービスとすることで、ネットワークを介して、２つの装置が迅速且つ確実に情報を授受するのに必要な情報を交換することが可能となる。
識別子を詳細情報に付加することで、詳細情報の特定が容易となる。
識別子をネットワークを介して送信先に送信することで、送信先に詳細情報を簡単に識別させることが可能となる。
送信先に識別子に対応する詳細情報を送信し、送信先から送信されてきたＭ次元のパラメータを受信するようにすることで、始めから詳細情報を送信する必要がなくなり、伝送路を効率的に利用しながら、確実に情報を授受することが可能となる。
ネットワークを介して送信されてきた識別子を受信することで、詳細情報を簡単に識別することが可能となる。
受信された識別子に対応する詳細情報の送信を要求するようにすることで、通信不能な相手側と無駄に詳細情報を交換するようなことが防止される。
データ構造を、Ｍ次元のパラメータで構成し、前記パラメータを、整数値と論理記号の組み合わせで構成することで、内容を容易に識別可能な形式でデータを記述することが可能となる。
以上においては、Ｍ：５としたが、それより大きい次元または小さい次元とすることも可能である。
また、以上においては、ＡＶデータを提供するサービスを例として説明したが、ＡＶデータを授受するサービスの他、各種のサービスを提供し、利用する場合に、本発明は適用することができる。
なお、上述した処理は、ネットワーク対応のＣＥ機器等の場合、ハードウェアにより実行することもできる。勿論、ソフトウェアにより実行することもできる。
一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。
この記録媒体は、図１２に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク１４１（フロッピディスクを含む）、光ディスク１４２（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｋ−Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）を含む）、光磁気ディスク１４３（ＭＤ（Ｍｉｎｉ−Ｄｉｓｋ）を含む）、もしくは半導体メモリ１４４などよりなるパッケージメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているＲＯＭ１２２や、記憶部１２８に含まれるハードディスクなどで構成される。
なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【産業上の利用可能性】  以上の如く、第１の本発明によれば、サービスの内容を表す情報を生成することができる。特に、サービスの内容を容易に確認することが可能な詳細情報を生成することができる。それにより、サービスの内容を確実に相手側に知らしめることが可能となり、相手側の装置と迅速且つ確実に接続し、データを授受することができる。
第２の本発明によれば、サービスの内容を表現することができる。特に、サービスの内容を容易に確認することが可能な状態で表現することができる。それにより、サービスの内容を確実に確認することが可能となり、相手側の装置と迅速且つ確実に接続し、データを授受することができる。
【図１】
2004012088.tif 000003
【図２】
2004012088.tif 000004
【図３】
2004012088.tif 000005
【図４】
2004012088.tif 000006
【図５】
2004012088.tif 000007
【図６】
2004012088.tif 000008
【図７】
2004012088.tif 000009
【図８】
2004012088.tif 000010
【図９】
2004012088.tif 000011
【図１０】
2004012088.tif 000012
【図１１】
2004012088.tif 000013
【図１２】
2004012088.tif 000014
【図１３】
2004012088.tif 000015
【図１４】
2004012088.tif 000016
【図１５】
2004012088.tif 000017
【図１６】
2004012088.tif 000018
【図１７】
2004012088.tif 000019
【図１８】
2004012088.tif 000020
【図１９】
2004012088.tif 000021
【図２０】
2004012088.tif 000022
【図２１】
2004012088.tif 000023
【図２２】
2004012088.tif 000024
【国際調査報告】
2004012088.tif 000025
2004012088.tif 000026
2004012088.tif 000027
2004012088.tif 000028