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