JP2005522759A - グループ管理 - Google Patents

Abstract

例えば、プレゼンス（３６ｃ）、メッセージング等（３６ａ）の特定のサービスを含み、グループ管理サービス（３６ｄ）を含むデータ構造と、このデータ構造を用いる装置及びシステムである。データ構造を変更して、グループ管理サービス（３６ｄ）内に特定のサービスを別個のサービスとしてでなく備える。これにより、固有のサービスとグループ管理との両方を呼び出す必要性をなくし、信号送信を減らす。

Description

本発明は、グループ管理に関し、特に詳しくは、サービスのコンテクストにおいてグループ管理をより効果的に用いることができるグループ管理機能の向上に関する。

現在、グループ管理の要件は、管理機能が全種類のサービスに渡って包括的であることと、特定の（グループ）サービスに特化した要件を何も含まないことである。この形式においては、グループがそのサービス内でどのように利用されるかが記述されている或るサービスに対しては、サービス管理手順と並行して、グループ管理機能が用いられる。言い換えれば、そのような特定のサービスに特化したサービスはグループ管理のためのグループ管理サービスを用いる必要がある。その理由はかかるサービスにはグループ管理機能がないからである。このことにより複雑さが増して、信号送信負荷を増加させる。一方、グループ管理の代わりに、各種の特定のサービス内でグループサービスを指定することは現実的には困難である。その理由は、異なるサービスのための要件が多様であり、現時点で可能性を全て予測することが難しいからである。

例えば、チャットサービスを想定する。チャットグループの“オーナー”が、個人ＡとＢには送信されたメッセージを全て見ることを許すが、何も書き込めないシステムを構築したいとする。個人Ｃ、Ｄ及びＥは、’全’権利を持つとする。すなわち、彼らはディスカッションを見て、メッセージを送信してディスカッションに貢献することができる。

グループ管理における従来技術によれば、グループＸＸ（ＡとＢとを含む）及びＹＹ（Ｃ、Ｄ及びＥを含む）が形成される。これに加えて、これらのグループのプロパティ／権利を表す特定のサービスに特化されたコマンドを指定する必要がある。例えばそれは、ＧＲＯＵＰ＿ＲＯＬＥＳ＿ＭＥＳＳＡＧＥである（グループＸＸ：リード権のみ、グループＹＹはリード権とライト権とを有する）。このアプローチを用いると、何らかの標準化をさらに行わない限り、全ＩＰネットワークに対して新しいサービスを作成することが難しくなってしまう。

別の形式を用いても上述の場合と同じようになってしまうが、現行のグループ管理の定義がゆるやかになって上述の場合を特に考慮することになる。かかる“グループ管理”を考慮に入れたとしても、その考えられ得る全サービスと最終決定とを標準化するのが困難であったり、将来の保証がなかったりする。

本発明の目的は、サービスが異なっていてもグループ管理をより効果的に用いることができる機構を提供することである。

本発明の第一の側面によれば、グループ管理サービスの機能を実行するプリミティブを備え、プリミティブが、クライアントのコンピュータ読取可能媒体内と、プリミティブをクライアントとサーバとの間のネットワークで伝送する間サーバのコンピュータ読取可能媒体内とに少なくとも一時的に格納され、プリミティブが、個別の機能に関する情報を有する少なくとも一つの情報要素を含み、プリミティブが、グループ管理サービスの機能を識別する情報を有する情報識別要素を有するデータ構造であって、プリミティブはまた特定サービス向けの機能に関する情報要素を含むか、あるいはそれに関するヘッダ又はフィールドに対応付けられ、特定サービス向けの機能はグループ管理サービス内に包含されることを特徴とする。

さらに本発明によれば、データ構造は、特定サービス向けの機能がプレゼンスサービスに関することを特徴とし、データ構造は、グループ管理機能内でクライアントからサーバへ供給されるプレゼンス情報要素、ヘッダ又はフィールドを含むことを特徴とする。

さらに別の本発明によれば、データ構造は、特定サービス向けの機能がリッチコールサービスに関することを特徴とし、データ構造は、グループ管理機能内でクライアントからサーバへ供給されるリッチコール情報要素、ヘッダ又はフィールドを含むことを特徴とする。

さらに本発明によれば、データ構造は、特定サービス向けの機能がメッセージングサービスに関することを特徴とし、データ構造は、グループ管理機能内でクライアントからサーバへ供給されるメッセージ情報要素、ヘッダ又はフィールドを含むことを特徴とする。

さらに別の本発明によれば、データ構造は、特定サービス向けの機能がコンテンツ管理サービスに関することを特徴とし、データ構造は、グループ管理機能内でクライアントからサーバへ供給されるコンテンツ管理情報要素、ヘッダ又はフィールドを含むことを特徴とする。

さらに別の本発明によれば、データ構造は、プリミティブに対応付けられるのがグループアクセス権限であることを特徴とする。

さらに別の本発明によれば、データ構造は、前記グループ管理サービスの前記個別機能がグループ作成機能、グループ削除機能、グループ変更機能、グループ情報機能、プレゼンス登録機能、プレゼンス登録解除機能又はプレゼンス要求機能であることを特徴とする。

さらに別の本発明によれば、データ構造は、プリミティブを受信して、特定サービス向けの機能に関する情報要素、ヘッダ又はフィールドを含むプリミティブを用いてグループ管理サービスの前記個別機能を実行する際に、プリミティブを受信するクライアント又はサーバが、情報要素、ヘッダ又はフィールドを認識しない場合は、エラーメッセージを必ずしも作成する必要はないことを特徴とする。

本発明の第二の側面によれば、少なくとも一時的にデータ構造を格納して送信又は受信する手段を有する装置であって、データ構造が本発明の第一の側面によることを特徴とする。

本発明の第三の側面によれば、複数の装置と通信可能なサーバを少なくとも一つ有するシステムであって、少なくとも一つのサーバと複数の装置との間で通信プロトコルを使用するシステムは、本発明の第一の側面によるデータ構造を特徴とする。

本発明の第四の側面によれば、サービス固有の情報要素、ヘッダ又は拡張フィールドをグループ管理に追加して、個別のメンバと共に全グループにリンクさせる。グループコマンドを受信するエンティティが、例えばサーバが、拡張を解釈しない場合は、エラー指示をせずにこれを無視する。

本発明により、グループとグループ内の個別のメンバとの両方が、特定サービス向けの情報を搬送できる拡張可能な汎用フィールド、ヘッダ等を有するようにグループ管理を編成することを提案する。複数のフィールド又はヘッダを用いて同様の効果を発揮することもできる。このヘッダ又はフィールドが、どのサービスに対しさらに命令が適用され、命令がどんなものであるかという識別を搬送する。サーバがサービスＩＤを解釈しない場合は、エラーを何も生成することなくフィールドを無視する。例えば、インスタントメッセージング（ＩＭ）の場合では、上述のようにフィールドを用いることができる。ユーザＡが、ＢとＣとからのメッセージを全て拒否したいとする。Ａは、’グループプロパティ’ＩＭサービス、つまり拒否リストを用いてグループＸＸ（ＢとＣとを含む）を作成する。もう一つの例は上述のものである。ユーザが、Ａ、Ｂ、Ｃ、Ｄ及びＥがメンバである一つのグループＺＺＺを作成するとする。各メンバの後に、一つ以上の特定サービス向けのフィールドＡ（リード）；Ｂ（リード）；Ｃ（リード／ライト）；Ｄ（リード／ライト）及びＥ（リード／ライト）が存在する。さらに別の例は、プレゼンス許可である。フィールドが、プレゼンスサービス用の情報を搬送する。グループ管理コマンドがグループのメンバ全員のリストを作成し、プレゼンスサービス向けのフィールドにはこれらの個人が見る／登録できる、組になっている識別子が全て含まれる。

添付の図面に示されているように、本発明のこれらの目的、他の目的、特徴及び利点は、最良の実施の形態についての以下の詳細な説明により、一層明らかになるであろう。

図１は、物理装置１２、１４、クライアント１６、１８、ユーザ２０、２２、２４、２６及びサーバ２８、３０を備えるシステム１０を示す。ユーザはシステムの顧客であり、物理装置１２、１４を用いて提供されるシステムのサービスを受けている。クライアントは、一人以上のユーザがサービスにアクセスできる、任意のサービスを実現するものである。クライアントは、ハードウェア、ソフトウエア、ファームウェア又はこれらの任意の組み合わせであってよい。クライアントの概念は装置に依存しないが、実際に使用するためにクライアントを物理装置にインストールする。図示しないが、任意の物理装置に２つ以上のクライアントを常駐させ、同じユーザが同じ装置上の別々のクライアントにアクセスすることができる。例えば、図示しないクライアント３を装置１４にインストールして、ユーザ３がアクセスすることもできる。サーバは、ネットワーク装置であって、サービスを提供し、ユーザデータを維持する。サーバを相互接続しても良い。

ユーザは、（一つ又は複数の装置を用いて）いくつかのクライアントからサーバに同時にアクセスできる。同様に、クライアントが、何人かのユーザに同時にアクセスさせることもできる。

例えばモバイルハンドセット又はＰＣといった物理装置が複数のクライアントインスタンスを有する場合、これらを個別に識別できるようにする必要がある。しかし多くの場合、装置識別とクライアント識別とを同じものと考えることができる。従ってこのような場合には、事実上、物理装置はクライアントと同じものである。

図１のクライアント及びサーバは共に、ネットワークでのサービス提供を円滑にするために、例えば図２に示すような階層化プロトコルアプローチを有する。しかしクライアントを仲介するサーバはたいていの場合、最上位層、すなわち、サービス層３４を利用しない。図２に示すモデルは、サービスケーパビリティ層３６と、セッション層３８と、トランスポート層４０とを含む。サービス層３４は、例えば、メッセージング（チャット、デーティング、ミーティング、会議等）、プレゼンス、リッチコール等のサービスを含む。その下のサービスケーパビリティ層３６は、情報要素とメッセージフローを有するプリミティブ等の、上位のプロトコルの記述を含む。サービスケーパビリティ層１２は、抽象メッセージ内の情報要素を定義する。この層はまた、このレベルのなかで選択されるテクノロジ（例えば、情報要素の符号化）を提案する。サービス層３４の各種のサービスは、サービスケーパビリティ層３６をツールボックスとして用いて各種のサービスを作成することができる。

図３に例示のサービスケーパビリティの区分を示す。その下のセッション層３８は、例えば、ＭＭＳ（マルチメディアメッセージサービス）、ＳＩＰ（セッション開始プロトコル）、ＳＭＳ（ショートメッセージサービス）、及びＵＳＳＤ（非構造化補助データ：Ｕｎｓｔｒｕｃｔｕｒｅｄ Ｓｕｐｐｌｅｍｅｎｔａｒｙ Ｄａｔａ）といった既存のセッションを介して、サービスケーパビリティをマッピングすることを含む。最下位のトランスポート層４０は、ＴＣＰ／ＵＤＰ／ＩＰ（トランスポート制御プロトコル／ユーザデータグラムプロトコル／インターネットプロトコル）、ベアラとしてのＳＭＳ／ＵＳＳＤ、ＷＡＰ／ＷＳＰ（ワイヤレスアプリケーションプロトコル／ワイヤレスセッションプロトコル）といったトランスポートの用い方についての定義を含む。上述のように図３の図では、最上位のサービス層がサーバに存在しないことを除き、これらの各種の層は全てクライアントとサーバとの両方に示されている。

図３の階層構造を有するクライアントは、通信リンク４２を通じて、最上位のサービス層はないが同様の階層構造を有するサーバと通信する。サーバは次に、直接又は他のサービスを介して、最終的に他のクライアントと通信する。これらのクライアントは、図３のクライアントがかかるサービス層を有するのと同じ方法でサービス層を有する。前述のように、サービス層は、例えば、メッセージング、プレゼンス、リッチコール等のサービスを含む。

サービスケーパビリティ層３６に注目すると、この層は図示のような各種の構成要素を含むことができる。例えば、これらの一つはメッセージング構成要素３６ａで、インスタントメッセージの交換を行う。同様に、リッチコール構成要素３６ｂが設けられる。プレゼンス構成要素３６ｃも設けられる。ユーザグループ管理３６ｄは、メッセージング、リッチコール及びプレゼンス等の他のサービスの各種の側面を管理することに関わる。すなわち、特定のサービスに特化したサービスには全て、ユーザグループ管理サービスが不可欠で、必要な場合にはグループ管理サービスを用いて、これらが持つ個別機能の実行の助けとする。コンテンツ管理３６ｅは、例えば、画像及び文書といった共通のコンテンツを管理する。登録者管理３６ｆも設けられる。図３のサーバ２７側には、同じ構成要素である３６ａ、３６ｂ、３６ｃ、３６ｄ、３６ｅが、クライアントテクノロジー２８ａとして簡略的に示されているが、登録者管理構成要素２８ｂは、相互接続管理構成要素２８ｃと共に単独で示されている。

サービスケーパビリティ層３６の各構成要素は、サービスケーパビリティ構成要素を共に決定するクライアントとサーバとの間で交換される、定義済のプリミティブのセットを有する。例えば、図４に示すように、ユーザグループ管理構成要素３６ｄは、例えば図示のような複数のプリミティブを含むことができる。これらのプリミティブはそれぞれ、たいていの場合必須であるが、必ずしも必須であるとは限らない。ＣｒｅａｔｅＧｒｏｕｐプリミティブは、クライアントからサーバへとライン５０上に供給され、サーバへの特定のクライアント要求毎にグループを作成する機能に関する複数の情報要素を含む。ＣｒｅａｔｅＧｒｏｕｐプリミティブに対するこれらの情報要素は、例えば、メッセージ識別子、仕様のバージョン、トランザクション識別子、クライアント識別子、ユーザ識別子、グループの要求されたプロパティのリスト、作成されたグループでのメンバシップのための初期ユーザのリスト及びグループ名を含む。グループ作成の際にグループに名前を付けることは必須である。このグループ名は明瞭である必要はないが、言い換えれば、グループを参照するのに使用することはできない（代わりに、例えばＵＲＬのようなグループＩＤを使用しなければならない）。グループを作成する際又はグループを一意に識別する際に、グループＩＤをグループに対応付けなければならない（ユーザが何かを提案して、これが良ければサーバがこれを受け付ける様なことでこれが可能とある。良くなければ、すなわち一意でなければ、サーバが、ほとんど同じであるが一意であるようにわずかに変更されたものを提案する）。図５は、例えば、図４のプリミティブ５０のようなプリミティブを組み立てるためにサービスケーパビリティ層３６に組み込まれて設けられる複数の情報要素５２、５４、５６、５８…６０を示す。ここで、グループ管理機能を作成するために用いられる他のプリミティブについて説明する。

グループを作成する際に、適当な情報要素を用いてグループの視認性を定義することができる。図４に示されるＤｅｌｅｔｅＧｒｏｕｐプリミティブをライン６２上に供給してグループを削除することもできる。同様に、１つのＭｏｄｉｆｙＧｒｏｕｐプリミティブをライン６４上に供給する毎にグループに１人以上のメンバを追加したり、グループから１人以上のメンバをはずしたりすることができる。ＧｅｔＧｒｏｕｐＩｎｆｏプリミティブがクライアントからサーバへライン６６上に供給されると、サーバは、例えば、グループメンバを表示したり、ユーザがグループメンバであるグループのリストを表示したりする、ＧｒｏｕｐＩｎｆｏプリミティブをライン６８上に応答する。

例えば、ＭｏｄｉｆｙＧｒｏｕｐプリミティブをライン６４上で用いて、グループ名、グループ視認性等のグループプロパティを変更することもできる。ＭｏｄｉｆｙＧｒｏｕｐプリミティブ又は定義された適当な情報要素を有する同様のプリミティブを用いて、グループメンバアクセス権を変更することもできる。例えば、表Ｉに示されるような他の要件を課しても良い。例えば、グループ概念は柔軟であるが、少なくともグループ名と、グループ識別と、グループメンバリストを取得できるユーザ（ユーザアクセス権限を持つ個人）を少なくとも１人定義するグループ視認性とを含む。使用される用語は次の通りである。
グループ−例えば、リッチコール、プレゼンス及びメッセージング等のグループ通信サービス内で用いられる個人で構成されるグループ。グループは、人数、グループ数又はこれらの組み合わせから成る。
グループ管理−いかにしてグループオーナー又はモデレータが、例えば、グループプロパティを含むグループを作成し、削除し、変更できるかという動作の集合。
グループメンバ−グループに所属する個人。
グループオーナー＝グループ作成者＝アドミニストレータ−グループを作成し、このグループに対するアドミニストレータ権限を持つ個人。グループメンバであってもよい。
グループプロパティ−例えば、グループ名、グループＩＤ、グループ視認性というグループプロパティ。
グループ（関連）サービス−グループ管理により管理されるグループを利用するサービス。
グループ視認性−グループ視認性は、誰がグループを見るかを定義するグループプロパティ。
モデレータ−グループに対するモデレータ権限を持ち、かつグループメンバでもある個人。

アクセス権限がグループプロパティに対応付けられる。
グループに対するアクセス権限には三つのレベルがある。
−アドミニストレータ
−モデレータ
−ユーザ

アドミニストレータは、グループ内で何でも実行できる。あるグループの作成者は、グループが存在する限り常にアドミニストレータ権限を持つ（アドミニストレータ権限を剥奪することはできない）。一つのグループに付き一名のアドミニストレータに限る。

モデレータは、メンバを追加／除外できるが、それは一般ユーザのみであって、モデレータやアドミニストレータではない。グループ毎にモデレータを数人置くことができる。

管理権限を何も持たないがグループメンバである個人がユーザロールを持つ。グループメンバとしてのグループは、ユーザ権限のみを持つ。

個人は、この個人がグループメンバであるグループについての情報のみを取得できる（アドミニストレータ権限、モデレータ権限又はユーザ権限を持つ）。

次の表ＩＩは、各権限レベルに対するトランザクションの可用性について述べたものであり、Ｙ＝可、Ｎ＝不可である。

図２及び図３のサービスケーパビリティ層３６のユーザグループ管理構成要素に加えて、他の構成要素３６ａ、３６ｂ、３６ｃ、３６ｅ及び３６ｆも、プリミティブのグループを有する。プリミティブは、各プリミティブが図５に示すように組み立てるための各自の所定の情報要素のセットを有するように定められる。従って、これらの他の構成要素３６ａ、３６ｂ、３６ｃ、３６ｅ及び３６ｆのステータスがサービスケーパビリティ層３６の個別の構成要素であるので、これらの構成要素がクライアントとサーバとの間の信号送信をうまく処理する必要があることを理解されたい。このことが、発明の背景の項で述べられている、現行のグループ管理機能が、特定の（グループ）サービスに特化した要件を何も含まずに、全種類のサービスに従って包括的であるものであることを意味している。この形においては、例えば、各々所有の特定のユーザグループに対応付けられるプレゼンス又はメッセージングといった、１つ以上の他のサービスケーパビリティ層構成要素と共にグループ管理機能を利用する。

本発明によれば、特定サービスに特化した機能を、グループ管理構成要素に対し定義される信号送信プリミティブに挿入することにより、このアプローチで必要とされる信号送信負荷を改良する。例えば、図６に示すように、グループ管理プリミティブ８０は、ヘッダ８２と複数の定義済情報要素５２、５４、５６…６０とを備える。例えば、図３のユーザグループ管理構成要素３６ｄに対し定義されるＣｒｅａｔｅＧｒｏｕｐプリミティブの一部としても良い。図６に示す情報要素の他に、ヘッダ８２は、図７に示すような特定サービスに特化したタイプの識別１００と命令１０２とを含むこともできる。グループ管理プリミティブ８０の受信者は次に、（命令を用いて）ヘッダから特定サービス向けの機能の識別子を判定することができる。また、このことを１つ以上の条件付又はオプションの特定サービス向けの情報要素で実施することもできる。図５は、上述のように、サービス識別子１００と命令１０２とを有するヘッダ８２を、サービスケーパビリティ層３６内の情報要素５２、５４、５６、５８…６０と共に、同様な方法でどのように組み立てることができるか示している。このように、図３の汎用のユーザグループ管理構成要素３６ｄを用いて特定サービス向けの情報を搬送し、従ってクライアントとサーバとの間で信号送信を減らすことができる。これは、個々の特定サービス向けの構成要素３６ａ、３６ｂ、３６ｃ、３６ｅ及び３６ｆを省くことを必ずしも意味するものではない。

上述で示唆したように、ヘッダアプローチの代わりに、特定サービス向けの情報要素を各種のグループ管理プリミティブのプリミティブに単に追加するだけで実施できる。

図８は、図３のプレゼンス構成要素３６ｃの一部としてサーバとクライアントとの間で交換されるプレゼンスプリミティブをいくつか示している。各プリミティブは、対応する必須、条件付及びオプションの情報要素（ＩＥ）の標準セットを有している。下の表ＩＩＩは、図８のＡｕｔｈｏｒｉｚｅＰｒｅｓプリミティブ１１０のＩＥのセットを示す。

これらのＩＥのうちのいくつかは、オプションの又は条件付のカテゴリーとしてグループ管理プリミティブに追加できる。例えば、ＡｕｔｈｏｒｉｚｅＰｒｅｓプリミティブの１つ以上のＩＥを、図４のＣｒｅａｔｅＧｒｏｕｐプリミティブ５０と共に用いてグループを作成することができる。かかる追加のプレゼンス情報要素により、特定プレゼンス向けのサービスケーパビリティのいくつかを用いてグループを作成できる。

グループ管理プリミティブ内でプレゼンス配信情報要素を利用できることの他に、例えば、コンタクトリスト及び属性リストといった他のプレゼンス機能から情報要素を用いることもできる。図９に示すように、コンタクトリストトランザクションのセットがプリミティブとして示されており、各々対応する情報要素のグループを有している。例えば、ＧｅｔＬｉｓｔＲｅｑｕｅｓｔプリミティブ１２２をクライアントからサーバへ供給して、メッセージ識別子、トランザクション識別子、セッション識別子等の情報要素に対応付ける。これに応じて、サーバは、ライン１２４上にＧｅｔＬｉｓｔＲｅｓｐｏｎｓｅプリミティブを供給する。ライン１２４上のＧｅｔＬｉｓｔＲｅｓｐｏｎｓｅプリミティブは、それに対応するメッセージ識別子、トランザクション識別子、セッション識別子、全コンタクトリスト及びデフォルトコンタクトリスト識別子等の情報要素を有しても良い。これらの最後の二つのうちのどちらか又は両方は、グループ管理プリミティブに追加して利用する情報要素として、本発明に従って使用するのに適当なものである。このように、ＧｅｔＬｉｓｔＲｅｑｕｅｓｔ及び／又はＧｅｔＬｉｓｔＲｅｓｐｏｎｓｅプリミティブを、クライアントとサーバとの間で別々に送受信する必要はない。例えば２つ以上のコンタクトリストを作成するために、クライアントからサーバへリスト作成要求プリミティブをライン１２６上に供給する。コンタクトリストを作成した後、ユーザが特定コンタクトリストに特化したプレゼンス値、タプル等を作成しても良い。サーバへのリスト作成要求メッセージには、メッセージ識別子、トランザクション識別子、セッション識別子、作成されたコンタクトリスト、リストの初期プロパティ及び識別された初期ユーザの識別子等の、各種の情報要素が含まれる。サーバは次に、コンタクトリストを作成して、ライン１２８上にステータスメッセージを応答する。クライアントはサーバへ、コンタクトリストを削除するためにＤｅｌｅｔｅＬｉｓｔＲｅｑｕｅｓｔプリミティブをライン１３０上に送信することができる。サーバは次に、指示されたコンタクトリストを削除して、ステータスメッセージをライン１３２上に応答する。クライアントは、ライン１３４上のクライアントからサーバへのＬｉｓｔＭａｎａｇｅＲｅｑｕｅｓｔプリミティブを用いて、このコンタクトリスト又は複数のリストを管理できる。このプリミティブを用いてメンバの追加及び除外ができ、リスト名を変更でき、デフォルトコンタクトリストを設定でき、また、リストを検索することもできる。サーバは要求された動作を実行して、ＬｉｓｔＭａｎａｇｅＲｅｓｐｏｎｓｅプリミティブをライン１３６上に応答する。ライン１３４上のＬｉｓｔＭａｎａｇｅＲｅｑｕｅｓｔプリミティブは、メッセージ識別子、トランザクション識別子、セッション識別子、コンタクトリストの識別、コンタクトリストに追加するユーザの識別、コンタクトリストから除外するユーザの識別、及び設定するコンタクトリストのプロパティを含むことができる。ライン１３６上のリスト管理応答プリミティブもまた、メッセージ識別子、トランザクション識別子及びセッション識別子を含む。これはさらに、要求の結果、コンタクトリストのプロパティ及びコンタクトリストに記載のユーザを伝える情報要素を含む。本発明によれば、図９に示す上述のコンタクトリストプリミティブのうちのこれらの情報要素のいずれについても、グループ管理プリミティブ内で用いて上述のように信号送信を減らすことができる。

図１０を参照すると、図３のプレゼンスサービス等のプレゼンスサービスの属性リストの特徴に関するトランザクションを表すプリミティブがいくつか示されている。属性リストはプレゼンス属性のセットで、いくつかのものは定義済みであるが、その他のものは柔軟性を与えるためと、ユーザ定義もできるように、後で利用できるように残してある。これらは、例えばクライアントステータス及びユーザステータスのクラスといった別々のクラスに分けることができる。クライアントは、クライアントソフトウエアとハードウェア装置とに関連し、移動体又は固定ネットワークに関するクライアント及び／又は装置のステータスを記述するプレゼンス属性を含む。ユーザステータス属性は、ハードウェア装置のユーザのステータス及び／又は内在するクライアントソフトウエアに関する。ユーザの可用性、好ましいコンタクト方法と共にユーザのコンタクト情報を記述する属性を含むこともできる。ユーザステータス属性はまた、例えば気分といったユーザの感情の状態を記述する情報を含むこともできる。

図１０に示すように、一つのかかるトランザクションを、クライアントからサーバへのライン１５０上のＣｒｅａｔｅＡｔｔｎｂｕｔｅＬｉｓｔＲｅｑｕｅｓｔプリミティブとすることもできる。これにより、ユーザにユーザ属性リスト又は特定コンタクトリストに特化した属性リストを作成させることができる。ライン１５０上のプリミティブは、例えば、メッセージ識別子、トランザクション識別子、セッション識別子、ユーザに許可するプレゼンス属性のリスト、コンタクトリスト又はリストを識別して属性リストアソシエーションと対応付けられるリスト、及び属性が別の属性リストの代わりにデフォルト属性リストを対象としているかどうかを示すデフォルトリストといった情報要素を含むこともできる。サーバはクライアントへ、ステータスプリミティブをライン１５２上に応答する。クライアントは、ユーザから、及び／又はコンタクトリストから属性リストを削除するために、ライン１５４上のＤｅｌｅｔｅＡｔｔｒｉｂｕｔｅＬｉｓｔＲｅｑｕｅｓｔプリミティブとして示されるような属性リスト削除トランザクションを実行することができる。サーバはクライアントへ、ステータスプリミティブをライン１５６上に応答する。クライアントのユーザが一つ又は複数の特定のコンタクトリスト又は一人又は複数のユーザと、あるいはデフォルト属性リストと対応付ける属性をクライアントに検索させるために、ライン１５８上のＧｅｔＡｔｔｒｉｂｕｔｅＬｉｓｔＲｅｑｕｅｓｔプリミティブをクライアントからサーバへ供給する。かかるプリミティブは、通常のメッセージ識別子、トランザクション識別子及びセッション識別子と共に、要求されたデフォルト属性リストを識別する情報要素、コンタクトリスト又はリストを識別して対応する属性リスト４を検索する情報要素、及び一人又は複数のユーザを識別して対応する属性リスト４を検索する情報要素を含む。ライン１６０上のＧｅｔＡｔｔｒｉｂｕｔｅＬｉｓｔＲｅｓｐｏｎｓｅプリミティブをサーバからクライアントへ返送して、要求の結果を示し、そして場合によってはユーザとコンタクトリスト表示属性とのアソシエーションリスト及び／又はリストあるいはデフォルトリストに対応付けられプレゼンス属性を示す。本発明によれば、１つ以上のグループ管理プリミティブに対応付けてクライアントとサーバとの間でより効率的な信号送信を行う代わりに、これらのプリミティブのいずれかと対応付けられる情報要素を”借りる”こともできる。

図１１に示すように、図３のサービスケーパビリティ層のメッセージング構成要素３６ａから別の例を述べる。以下の表ＩＶは、メッセージプリミティブ２００に対応付けられる標準セットのＩＥを示す。

表ＩＶに示すＩＥから、１つ以上のＩＥを、選択したグループ管理プリミティブに標準のオプションの又は条件付ＩＥとして追加できる。例えば、コンテンツタイプ及びコンテンツＩＥを１つ以上のユーザグループ管理３６ｄプリミティブに追加できる。同様に、どの機能がいいか、あるいはどの機能が対応付けに適当かということにより、図４のプリミティブが実行する各種のグループ管理機能を増加して、メッセージング機能を実行することができる。

例えば、プレゼンスやメッセージング等の異なるサービスから情報要素をグループ管理サービス機能へ追加することにより、異なるサービスから機能を組み合われることもできる。信号送信を減らすために、元々別々のサービスの各種の機能をグループ管理サービス内に包含できることをこれまで述べてきたが、適切な場合には本発明の技術を用いるだけで、これらの別々のサービスをこのまま維持することもできることを理解されたい。このように、アプローチの一つ又は両方を用いて、より柔軟なシステムを開発することができる。

最良の実施の形態について本発明を示し、かつ述べてきたが、本発明の精神及び範囲から逸脱することなく、形や詳細において前述の各種の他の変更、省略及び追加ができることを当業者なら理解できるであろう。

本発明のグループ管理に用いられるシステムを示す。 図１のクライアント及びサーバに用いられるプロトコル構造を示す。 クライアント及びサーバの両方における図２のより詳細なサービスケーパビリティ層を示す。ユーザグループ管理要件を現在どのように指定して、全種類のサービスで広く用いられているかを特に示す。 クライアントとサーバとの間で交換され、グループ管理機能の能力のいくつかを定義するプリミティブ・セットを示す。 本発明の、情報要素をプリミティブへと組み立て、あるいは逆にプリミティブから個別の情報要素にするサービスケーパビリティ層と、ヘッダとを示す。 例えば、図５に図示のヘッダと共に本発明のプリミティブを示す。しかし、ヘッダをさらに好適なオプションとして実現したとしても、本発明を、ペイロードの一部に組み込むことができることを理解されたい。 図５及び図６のさらに詳細なヘッダを示す。複数のサービスの情報を含むことができるし、いくつかのヘッダがそれぞれ一つのサービスのみに特化された情報を含むこともできる。 図３のプレゼンスサービスケーパビリティ構成要素３６により、サーバとクライアントとの間で交換される複数のプリミティブを示す。 図３のプレゼンスサービスケーパビリティ構成要素に関する各種のコンタクトリストトランザクションにより、サーバとクライアントとの間で交換される複数のプリミティブを示す。 図３のプレゼンスサービスケーパビリティ構成要素の属性リストトランザクションにより、サーバとクライアントとの間で交換される複数のプリミティブを示す。 図３のメッセージングサービスケーパビリティ構成要素３６ａにより、サーバとクライアントとの間で交換される複数のプリミティブを示す。

Claims (23)

1. グループ管理サービスの機能を実行するプリミティブを備え、前記プリミティブが、クライアントのコンピュータ読取可能媒体内と、前記プリミティブをクライアントとサーバとの間のネットワークで伝送する間サーバのコンピュータ読取可能媒体内とに少なくとも一時的に格納され、前記プリミティブ（８０）が、前記機能に関する情報を有する少なくとも一つの情報要素（５２、５４、５６、．．．、６０）を含み、前記プリミティブが、前記グループ管理サービスの前記機能を識別する情報を有する情報識別要素を有するデータ構造であって、前記プリミティブはまた特定サービス向けの機能に関する情報要素を含むか、あるいはそれに関するヘッダ（８２）又はフィールドに対応付けられ、前記特定サービス向けの機能は前記グループ管理サービス内に包摂されることを特徴とするデータ構造。
2. 特定サービス向けの機能がプレゼンスサービスに関し、
   データ構造は、前記グループ管理機能内でクライアントからサーバへ供給されるプレゼンス情報要素、ヘッダ又はフィールドを含むことを特徴とする請求項１に記載のデータ構造。
3. 特定サービス向けの機能がリッチコールサービスに関し、
   データ構造は、前記グループ管理機能内でクライアントからサーバへ供給されるリッチコール情報要素、ヘッダ又はフィールドを含むことを特徴とする請求項１に記載のデータ構造。
4. 特定サービス向けの機能がメッセージングサービスに関し、
   データ構造は、前記グループ管理機能内でクライアントからサーバへ供給されるメッセージ情報要素、ヘッダ又はフィールドを含むことを特徴とする請求項１に記載のデータ構造。
5. 特定サービス向けの機能がコンテンツ管理サービスに関し、
   データ構造は、前記グループ管理機能内でクライアントからサーバへ供給されるコンテンツ管理情報要素、ヘッダ又はフィールドを含むことを特徴とする請求項１に記載のデータ構造。
6. プリミティブに対応付けられるのがグループアクセス権限であることを特徴とする請求項１に記載のデータ構造。
7. 前記グループ管理サービスの前記個別機能はグループ作成機能であることを特徴とする請求項１に記載のデータ構造。
8. 前記グループ管理サービスの前記個別機能はグループ削除機能であることを特徴とする請求項１に記載のデータ構造。
9. 前記グループ管理サービスの前記個別機能はグループ変更機能であることを特徴とする請求項１に記載のデータ構造。
10. 前記グループ管理サービスの前記個別機能はグループ情報機能であることを特徴とする請求項１に記載のデータ構造。
11. 前記プレゼンス情報要素、ヘッダ又はフィールドは、プレゼンス登録機能に関することを特徴とする請求項２に記載のデータ構造。
12. 前記プレゼンス情報要素、ヘッダ又はフィールドは、プレゼンス登録解除機能に関することを特徴とする請求項２に記載のデータ構造。
13. 前記プレゼンス情報要素、ヘッダ又はフィールドは、プレゼンス要求機能に関することを特徴とする請求項２に記載のデータ構造。
14. 前記プリミティブを受信して、前記特定サービス向けの機能に関する前記情報要素、ヘッダ又はフィールドを含む前記プリミティブを用いて前記グループ管理サービスの前記個別機能を実行する際に、前記プリミティブを受信する前記クライアント又はサーバが、前記情報要素、ヘッダ又はフィールドを認識しない場合は、エラーメッセージを必ずしも作成する必要はないことを特徴とする請求項１に記載のデータ構造。
15. 前記プレゼンス情報要素、ヘッダ又はフィールドは、コンタクトリスト作成トランザクションに関することを特徴とする請求項２に記載のデータ構造。
16. 前記プレゼンス情報要素、ヘッダ又はフィールドは、前記クライアントが開始して前記サーバへ応答する、コンタクトリスト検索トランザクションに関することを特徴とする請求項２に記載のデータ構造。
17. 前記プレゼンス情報要素、ヘッダ又はフィールドは、前記クライアントが開始して前記サーバへ応答する、コンタクトリスト削除トランザクションに関することを特徴とする請求項２に記載のデータ構造。
18. 前記プレゼンス情報要素、ヘッダ又はフィールドは、要求された動作を実行してリスト管理応答メッセージで応答する前記サーバへ前記クライアントが供給する、リスト管理要求トランザクションに関することを特徴とする請求項２に記載のデータ構造。
19. 前記プレゼンス情報要素、ヘッダ又はフィールドは、前記クライアントから前記サーバへ供給されてユーザ又はコンタクトリスト固有の属性リストを作成する、属性リスト作成要求メッセージに関することを特徴とする請求項２に記載のデータ構造。
20. 前記プレゼンス情報要素、ヘッダ又はフィールドは、前記クライアントから前記サーバへ供給されてユーザから及び／又はコンタクトリストから属性リストを削除する、属性リスト削除要求メッセージに関することを特徴とする請求項２に記載のデータ構造。
21. 前記プレゼンス情報要素、ヘッダ又はフィールドは、前記クライアントから前記サーバへ供給されて固有のコンタクトリスト又はユーザ、あるいはデフォルト属性リストに対応付けられる属性を検索する、属性リスト取得要求に関することを特徴とする請求項２に記載のデータ構造。
22. 少なくとも一時的にデータ構造を格納して送信又は受信する手段を有する装置であって、前記データ構造が請求項１に記載のものであることを特徴とする装置。
23. 複数の装置と通信可能なサーバを少なくとも一つ有するシステムであって、請求項１に記載のデータ構造を用いて少なくとも一つのサーバと複数の装置との間で通信プロトコルを使用するシステム。
    

Images