JP5254005B2

JP5254005B2 - 協調的招待システムおよび方法

Info

Publication number: JP5254005B2
Application number: JP2008508819A
Authority: JP
Inventors: マニオン，トッド・アール; ターラー，ディヴィッド・ジー; グプタ，ロヒット; シングハル，サンディープ・ケイ; ラオ，ラヴィ・ティー; ウェイスバーグ，トマー
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-04-25
Filing date: 2005-08-01
Publication date: 2013-08-07
Anticipated expiration: 2025-08-01
Also published as: CN101167068B; EP1875368A1; TWI387287B; RU2007139520A; US20060242639A1; JP2008539504A; KR20080010390A; BRPI0520057A2; EP1875368A4; TW200638717A; MY147346A; RU2385487C2; WO2006115527A1; CN101167068A; US7752253B2; MX2007013353A; KR101122801B1

Description

本発明は、一般的には、ネットワーク型計算環境に関し、更に特定すれば、ネットワーク型計算環境における協調(collaboration)の促進に関する。

ネットワーク型計算環境は、作業場や家庭においても珍しくない機構となっている。これらの環境は、電子メール、インスタント・メッセージング、マルチメディア文書サーバ、ディスカッション・グループ、ならびにストリーミング・オーディオおよびビデオ、更には没入型対話感覚環境(immersive interactive sensory environment)を含む種々の通信モードを容易にする。従来のソフトウェア・アプリケーションは、これら豊富な通信モードを利用し始めているが、統合化および伸張可能なコンピュータ化協調プラットフォームの視点から考慮すると、各々には限界および／または欠点がある。

従来のコンピュータ・ソフトウェア・アプリケーションの中には、協調サービスの形態を提供するものもあるが、協調者(collaborator)に有効なアクセスを与えることができていない。協調者に対するアクセスが厄介であったり、および／または制限されていると、協調への加入(initiation)に対する障壁となる可能性があり、それ以外の機能的な協調ツールの使用が妨げられる。効果的でない協調者へのアクセスには、従来のソフトウェア・アプリケーションが事実上現況の物理的および／または仮想的場所を認識できないという一面がある。また、一部の従来のソフトウェア・アプリケーションが協調的機能性に関する互換性を事実上認識できないという別の一面もある。

個々にリリースされる協調的サービスの形態を提供する従来のソフトウェア・アプリケーションの機能における欠陥を克服することができないため、従来のソフトウェア・アプリケーションの一部は、伸張可能な協調プラットフォーム、フレームワーク、および／またはアーキテクチャに対する準備ができてきない。これは、些細な障害ではない。効果的なアーキテクチャであれば、長年続けて使用することができ、何百万ものノードを有するネットワーク計算環境に組み込むことができる。確立されているアーキテクチャに拡張性、柔軟性、保守性、および／またはスケーラビリティ(scalability)が欠けることは、１つのソフトウェア製品のリリースに対するよりも、遥かに重大な問題となる虞れがある。

この章では、本発明の実施形態の一部について、簡略化した摘要を紹介する。この摘要は、本発明の広い全体像ではない。本発明の鍵となる／なくてはならない要素を特定することや、発明の範囲を正確に叙述することは意図していない。その唯一の目的は、後に提示する更に詳細な説明に対する序論として、簡略化した形態で、本発明の実施形態の一部を紹介することである。

本発明の一実施形態では、１つ以上のコンタクトを、グラフィカル・ユーザ・インターフェース（ＧＵＩ）のような招待ユーザ・インターフェースによって選択することができる。協調的活動に参加するための招待は、招待ユーザ・インターフェースから、または協調的アプリケーション、例えば、協調的活動を促進する協調的アプリケーションから、選択したコンタクトに発送することができる。招待を招待ユーザ・インターフェースまたは協調的アプリケーションのどちらから発送するかは、設定可能な選択肢である。招待を招待ユーザ・インターフェースから発送する場合、協調的アプリケーションを起動し、次いで招待ユーザ・インターフェースから招待を発送することができる。招待を協調的アプリケーションから発送する場合、協調的アプリケーションを起動し、次いで協調的アプリケーションから招待を発送することができる。

本発明の実施形態では、協調的アプリケーションに参加するための招待は、例えば、協調的サービス・プラットフォームによって受信することができる。協調的サービス・プラットフォームのユーザには、招待に応答して、受入、断り、および無視の内１つを選択する機能(ability)と共に、招待を紹介することができる。ユーザは、招待を受け入れる、断る、または明示的に無視することを選択することができ、ユーザの選択を示す応答を、招待の発送元に送ることができる。

本発明の実施形態では、協調的招待サービスのアプリケーション・プログラミング・インターフェースは、招待エレメント、招待発送エレメント、招待応答エレメント、および招待取り消しエレメントを含む。招待エレメントは、協調的活動に参加するための招待に対応する招待データへのアクセスを与えることができる。招待発送エレメントは、招待を１つ以上のコンタクトに発送するために用いることができる。招待応答エレメントは、協調的招待に応答するために用いることができ、招待取り消しエレメントは、発行した招待を取り消すために用いることができる。

添付した特許請求の範囲は、発明の特徴を特定的に明記するが、本発明およびその利点は、添付図面と関連付けた以下の詳細な説明から最良に理解することができる。

本発明の種々の実施形態の説明を進める前に、本発明の種々の実施形態を実用化することができるコンピュータについて、ここで説明しておく。必須ではないが、本発明の説明は、全体的に、コンピュータが実行するプログラム・モジュールのような、コンピュータ実行可能命令に関して行う。一般に、プログラムは、ルーチン、オブジェクト、コンポーネント、データ構造等を含み、特定のタスクを実行するか、または特定の抽象的データ・タイプを実現する。「プログラム」という用語は、ここで用いる場合、１つのプログラム・モジュールまたは一緒に作用する多数のプログラム・モジュールを暗示する。「コンピュータ」および「計算デバイス」という用語は、ここで用いる場合、パーソナル・コンピュータ（ＰＣ）、ハンドヘルド・デバイス、マルチ・プロセッサ・システム、マイクロプロセッサ系プログラマブル消費者用電子製品、ネットワークＰＣ、ミニコンピュータ、タブレットＰＣ、ラップトップ・コンピュータ、マイクロプロセッサまたはマイクロコントローラを有する消費者用器具、ルータ、ゲートウェイ、ハブ等のような、１つ以上のプログラムを電子的に実行するあらゆるデバイスを含む。また、本発明は、分散型計算環境においても採用することができ、その場合、通信ネットワークを通じてリンクされているリモート処理デバイスによってタスクを実行する。分散型計算環境では、プログラムは、ローカルおよびリモートメモリ記憶デバイス双方に位置することもできる。

図１を参照すると、ここに記載する発明の形態を実施することができるコンピュータ１０２の基本的構成の一例が示されている。その最も基本的な構成では、コンピュータ１０２は、通例、少なくとも１つの演算装置１０４およびメモリ１０６を含む。演算装置１０４は、本発明の種々の実施形態にしたがってタスクを遂行する命令を実行する。このようなタスクを遂行する際、演算装置１０４は、電子信号をコンピュータ１０２の別の部分、およびコンピュータ１０２外部のデバイスに送り、何らかの結果を出させる。コンピュータ１０２の正確な構成および形式に応じて、メモリ１０６は、（ＲＡＭのような）揮発性、（ＲＯＭまたはフラッシュ・メモリのような）不揮発性、またはこれら２つの何らかの組み合わせとすることができる。図１では、この最も基本的な構成を破線１０８で示す。

また、コンピュータ１０２は、更に別の機構／機能性も有することができる。例えば、コンピュータ１０２は、限定ではないが、磁気または光学的ディスクまたはテープを含む、追加のストレージ（リムーバブル１１０および／または非リムーバブル１１２）も含むことができる。コンピュータ記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピュータ実行可能命令、データ構造、プログラム・モジュール、またはその他のデータを含む情報の記憶のためのいずれの方法または技術でも実現できる。コンピュータ記憶媒体は、限定ではなく、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、ＣＤ−ＲＯＭ、ディジタル多様ディスク（ＤＶＤ）またはその他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気記憶デバイス、あるいは所望の情報を格納するために用いることができしかもコンピュータ１０２がアクセス可能なその他のいずれの媒体も含む。このようなコンピュータ記憶媒体のいずれもが、コンピュータ１０２の一部をなすことができる。

好ましくは、コンピュータ１０２は、デバイスに、リモート・コンピュータ１１６のような、他のデバイスと通信させる、通信接続部１１４も内蔵する。通信媒体は、通例、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、またはその他のデータを、搬送波またはその他の移送機構のような変調データ信号において具体化し、あらゆる情報配信媒体を含む。限定ではなく一例として、「通信媒体」という用語は、音響、ＲＦ、赤外線、およびその他のワイヤレス媒体というようなワイヤレス媒体を含む。「コンピュータ読み取り可能媒体」という用語は、ここで用いる場合、コンピュータ記憶媒体および通信媒体双方を含む。

また、コンピュータ１０２は、キーボード／キーパッド、マウス、ペン、音声入力デバイス、接触入力デバイス等のような入力デバイス１１８も有することができる。ディスプレイ、スピーカ、プリンタ等のような出力デバイス１２０も含むことができる。これらのデバイスは全て当技術分野では周知であり、ここで詳細に説明する必要はない。

以下に続く説明では、特に明記していない限り、１つ以上の計算デバイスが実行する動作のアクト(act)および象徴的表現を参照しながら、本発明について述べる。したがって、このようなアクトおよび動作は、コンピュータが実行するものとして言及する場合もあり、構造化した形態でデータを表す電気信号の、コンピュータの演算装置による操作を含むことは言うまでもない。この操作は、データを変形し、またはそれをコンピュータのメモリ・システムにおける場所に維持し、当業者には良くわかっているやり方でコンピュータ動作の設定変更またはそれ以外の変更を行う。データを維持するデータ構造は、メモリの物理的な場所であり、データのフォーマットによって定義される特定のプロパティを有する。しかしながら、本発明を以上の文脈で記載しているが、当業者には認められるように、限定を意図するのではなく、以下に記載する種々のアクトおよび動作は、ハードウェアで実施してもよい。

本発明の実施形態では、コンピュータ・ソフトウェアのアーキテクチャが、伸張性、柔軟性、保守性、および拡張性がある協調プラットフォームを規定する。アーキテクチャの形態は、適したネットワーク型計算環境に組み込むことができる。アーキテクチャは、従来のコンピュータ・ソフトウェア・アプリケーションと統合した協調を可能とし、および／または拡張することができる。即ち、このアーキテクチャは、総合的な協調的コンタクト管理に備えることができ、ネットワーク型計算環境における現在のコンタクトのプレゼンス(presence)、そして、例えば、利用可能な協調的活動に関する現在のコンタクト能力(contact capabilities)を含む。

図２は、本発明の実施形態を組み込むのに適したネットワーク型計算環境例２００を示す。このネットワーク型計算環境では、ネットワーク２０２は、コンピュータ２０４、２０６、および２０８をネットワーク・ハブ２１０と通信するように接続する。ネットワーク２０２は、ローカル・エリア・ネットワーク（ＬＡＮ）、都市エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、個人エリア・ネットワーク（ＰＡＮ）、またはその組み合わせとすることができる。ネットワーク２０２は、ハブ、ゲートウェイ、ルータ、ブリッジ、ポート等のように、適したネットワーク構成機器であればいずれでも、そして適したコンピュータ読み取り可能媒体であればいずれでも組み込むことができる。例えば、コンピュータ２０４、２０６、２０８およびネットワーク・ハブ２１０は、各々、コンピュータ１０２（図１）のインスタンスとすることもできる。

ネットワーク・ハブ２１０は、コンピュータ２１２、２１４および２１６を通信するように接続する。ネットワーク・ハブ２１０ならびにコンピュータ２１２、２１４および１６は、全体で、サブネットワーク即ちサブネット２１８の一例と見なすことができるが、勿論、限定的な例ではない。コンピュータ２１２、２１４および２１６は、同じサブネット上にあるとは言わず、その結果、互いに対して特権ネットワーク通信(privileged network communication)を享受することができる。例えば、各コンピュータ２０４、２０６、２０８、２１２、２１４および２１６は、二点間型メッセージを各他のコンピュータ２０４、２０６、２０８、２１２、２１４および２１６に送ることができるが、サブネット２１８は、サブネット２１８におけるブロードキャスト型メッセージをサブネット２１８におけるこれらのコンピュータ２１２、２１４および２１６が受信するように構成することもできる。

協調プラットフォームの伸張性、柔軟性、保守性、および／または拡張性(scalable)がある属性は、そのモジュール構造の１つ以上の側面、その全体としてもモジュール状構造、モジュールの１つずつ同士の双方向処理モード、および／または全体としてのモジュール状構造の双方向処理パターンから得ることができる。図３は、本発明の実施形態によるコンピュータ・ソフトウェア・アーキテクチャ例３００を示す。アーキテクチャ３００の各側面は、各コンピュータ２０４、２０６、２０８、２１２、２１４および２１６（図２）に設けることができるが、本発明の各実施形態はそのように限定されるのではない。アーキテクチャ３００の側面は、全体的にネットワーク型計算環境２００を含む、ネットワーク型計算環境２００のいずれの適した部分集合を跨いででも、相応しく分散することができる。アーキテクチャ３００の異なるバージョンを異なるコンピュータ毎に設けてもよく、アーキテクチャ３００の各バージョンが、アーキテクチャ３００の他の各バージョンとの互換性を有する度合いは様々であってよい。

アーキテクチャ３００は、協調サービス・プラットフォーム３０２を含むことができる。協調サービス・プラットフォーム３０２は、コンタクト管理サービス３０４、公開サービス(publication service)３０６、シグナリング・サービス３０８、活動サービス３１０、データ共有サービス３１２、認証サービス３１４、および接続性サービス３１６を含むことができる。コンタクト管理サービス３０４は、コンタクト・ストア３１８、プレゼンス・ストア３２０、およびコンタクト場所サービス３２２を含むことができる。公開サービス３０６は、同期サービス３２４を含むことができる。シグナリング・サービス３０８は、招待サービス３２６を含むことができる。活動サービス３１０は、オーディオ／ビジュアル（Ａ／Ｖ）サービス３２８を含むことができる。接続性サービス３１６は、ピア・ツー・ピア（Ｐ２Ｐ）サービス３３０、ならびに従来のトランスポート制御プロトコルおよびインターネット・プロトコル（ＴＣＰ／ＩＰ）スタック３３２を含むことができる。各サービス３０４、３０６、３０８、３１０、３１２、３１４、３１６は、サービスを実施するメッセージを発送および受信することができるピアを含むこと、および／またはその中に組み込むことができる。

本発明の一実施形態では、コンタクト管理サービス３０４は、協調者(collaborator)、即ち、協調的サービス・プラットフォーム３０２のユーザへの有効なアクセスを与える。例えば、コンタクト管理サービス３０４は、協調的サービス・プラットフォーム３０２のユーザの一部または全部に対して、コンタクト情報を提供することができる。コンタクト管理サービス３０４は、１つ以上のデータ・ストアに、コンタクトのデータベースを維持することができる。各コンタクトは、潜在的な協調者となることができる、即ち、協調サービス・プラットフォームのユーザが、各コンタクトにより、１つ以上の協調活動に関与しようとすることができる。コンタクト管理サービス３０４は、グラフィカル・ユーザ・インターフェース（ＧＵＩ）を含む、１つ以上のユーザ・インターフェースを設けることができ、例えば、ユーザが選択するためにコンタクトを呈示し、ユーザが個々のコンタクトに関して協調サービス・プラットフォーム３０２の行動(action)を呼び出すことができるようにする。

コンタクト・ストア３１８は、コンタクト・オブジェクトおよび"MeContact"オブジェクト（図４を参照して以下で更に詳しく説明する）を格納することができる。プレゼンス・ストア３２０は、コンタクト・オブジェクトに対するプレゼンス・オブジェクト（図４を参照して以下で更に詳しく説明する）を格納することができる。本発明の実施形態では、プレゼンス・データはコンタクト・データよりも頻繁に変化するので、オブジェクトの異なる更新頻度に合わせて、別個のデータ・ストア３１８、３２０を最適化するとよい。

コンタクト場所サービス３２２は、所与のコンタクトに関して、種々の場所データの内１つ以上を提供することができる。物理的近接度がコンタクト場所の一形態とすることができ、例えば、物理的場所に対して１つ以上のプロキシを利用して、ユーザからコンタクトの物理的距離を推定することができる。無線受信機における信号強度は、物理的距離プロキシの一例である。仮想場所は、コンタクト場所の別の形態とすることができる。例えば、コンタクトは、図２のネットワーク２０２のように、１つ以上のネットワークにおいて、および／またはコンピュータ２０４、２０６、２０８、２１２、２１４、および２１６のような１つ以上のネットワークノードにおいてアクティブであってもよい。加えて、コンタクトをインアクティブで登録すること、オンラインであるが発見されないこと、またはその他の何らかの相応しい場所的ステータス(locative status)を有することもできる。コンタクト場所サーバ３２２は、適した登録所に問い合わせこと、および／または、例えば、ピア・ツー・ピア探索またはピア・ツー・ピア名称解明メカニズムを開始して、個々のコンタクトを突き止めることもできる。

公開サービス３０６は、コンタクトが公開したデータに対するアクセスを与えることができる。本発明の実施形態では、関心のあるユーザは、コンタクトが公開するオブジェクトに申し込み、公開したオブジェクトが公開元のコンタクトによって更新されるときにはいつでも通知を受信することができる。同期サービス３２４は、公開申し込みのデータベース維持を責務とすることができる。即ち、公開サービス２ー６は、コンタクトが公開するプレゼンス情報に対するアクセスを与えることができる。

シグナリング・サービス３０８は、ネットワーク型計算環境２００（図２）内にいるコンタクト間における協調的会議の設定(establishment)および終了、そして進行中の会議のパラメータ更新に備えることができる。本発明の実施形態では、協調的会議の設定、更新、および終了は、公開／申し込みセマンティックス(semantics)に応じて行われる。本発明の一実施形態では、シグナリング・サービス３０８は、Handley et al., "SIP: Session Initiation Protocol"（セッション開始プロトコル）、Internet Engineering Task Force (IETF) Request for Comments (RFC) 2543, March 1999のような、セッション開始プロトコル（ＳＩＰ）の一実現例を組み込む。

招待サービス３２６は、招待および関係するメッセージをコンタクトに発送すること、およびコンタクトから発送することを可能にする。例えば、ネットワーク型計算環境２００（図２）に１つのコンピュータ２１２からアクセスしているシステム・ユーザが、他のいずれかのコンピュータ２０４、２０６、２０８、２１２、２１４および／または２１６におけるコンタクトを、協調的活動に参加することを招待することができる。招待サービス３２６は、コンタクト場所サービス３２２を利用して、コンタクトを突き止め、招待を配信することができる。招待サービス３２６は、招待の詳細を被招待者に呈示するため、そして被招待者が招待を受け入れる、断る、および／または明示的に無視することができるようにするために、グラフィカル・ユーザ・インターフェース（ＧＵＩ）のような種々のインターフェースを含むことができる。招待サービス３２６の一例について、図１３を参照して以下で更に詳しく説明する。

活動サービス３１０は、協調的活動を実施すること、および／または協調的アプリケーションの協調サービス・プラットフォーム３０２への統合のためのサポートを設けることができる。例えば、活動サービス３１０は、従来の協調アプリケーションに、協調サービス・プラットフォーム３０２に準拠したアプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供することができる。準拠するＡＰＩは、活動能力に関して個々のコンタクトまたはコンピュータ２０４、２０６、２０８、２１２、２１４、２１６（図２）に問い合わせを行い、アプリケーション特定の招待要件を確認する機能性を含むことができる。オーディオ／ビジュアル・サービス３２８は、活動サービス３１０への組み込みに適した協調活動の一例である。

データ共有サービス３１２は、ファイル、文書、ストリーム、およびオブジェクトを含む、あらゆる適したフォーマットのデータの共有を可能にすることができる。データ共有サーバ３１２は、データ転送、データ複製、および／またはデータ同期に備えることができる。コンタクト、活動への参加、会議への参加、および／またはネットワーク型計算環境２００（図２）のユーザ・グループのような、あらゆる適したアクセス制御リスト（ＡＣＬ）に基づいて、データ共有をイネーブルおよびディスエーブルすることができる。

認証サービス３１４は、認証証明書、例えば、コンタクトおよびその他の活動ならびに会議参加者に対する認証証明書を発行し検証することができる。認証サービス３１４は、コンタクトを信頼できるコンタクトと信頼できないコンタクトとに分類することを可能にする。認証サービス３１４は、コンタクトの場所とは無関係に、および／または洗練されたネットワーク型計算環境２００（図２）の存在に応じて、コンタクトを信頼できるものにすることができる。

本発明の実施形態では、接続性サービス２１６は、ネットワーク型計算環境２００（図２）全域において、例えば、コンピュータ２１２における第１シグナリング・サービス３０８のインスタンスとコンピュータ２０８における第２シグナリング・サービス３０８のインスタンスとの間で、協調サービス・プラットフォーム３０２のサービス・インスタンス間の通信を可能にする。接続性サービス３１６の通信設備は、アプリケーション・プログラミング・インターフェース（ＡＰＩ）によって利用可能にすることができるので、他の協調サービス・プラットフォーム３０２のサービス３０４、３０６、３０８、３１０、３１２、３１４は、基礎のトランスポート・メカニズムには関係なく、インスタンス間で通信することができる。

接続性サービス３１６は、ＴＣＰ／ＩＰスタック３３２および／または、Microsoft(R) Windows(R) Sockets 2 (Winsock) APIのような、それよりも上位の通信アプリケーション・プログラミング・インターフェースを含むことができる。これは、２００５年３月付けのMicrosoft Developer Network (MSDN(R)) LibraryのWindows (R) Sockets 2 sectionに記載されている。ピア・ツー・ピア（Ｐ２Ｐ）サービス３３０は、ネットワーク計算環境２００のオーバーレイ・ネットワークにおいて接続性を提供することができる。例えば、ピア・ツー・ピア・サービス３３０は、２００５年３月付けのMicrosoft Developer Network (MSDN(R))におけるMicrosoft(R) Windows(R) Platform Software Development Kit (SDK) のWindows(R) Platform Networking sectionに記載されているピア・ツー・ピア・アプリケーション・プログラミング・インターフェースに応じて設けることができ、グラフ作成、グループ作成、アイデンティティ・マネージャ、およびピア名称解明プロトコル（ＰＮＲＰ）名称空間(namespace)プロバイダ・アプリケーション・プログラミング・インターフェースを含む。

サービス３０４、３０６、３０８、３１０、３１２、３１４、および３１６は、協調オブジェクト・モデルにおいて相互に関係付けられた１組の協調オブジェクトを含む、１組のプログラム・オブジェクトによって実施することができる。図４は、本発明の実施形態による１組の協調オブジェクトの一例および協調オブジェクト・モデル４００の一例を示す。協調オブジェクト・モデル４００は、コンタクト・オブジェクト４０２、プレゼンス・オブジェクト４０４、MeContactオブジェクト４０６およびMyPresenceオブジェクト４０８、終点オブジェクト４１４、活動オブジェクト４１６、ならびに公開オブジェクト４１８を含むことができる。勿論、協調サービス・プラットフォーム３０２は、協調オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８の各タイプの多くのインスタンスを含むことができる。

コンタクト・オブジェクト４０２は、協調的参加者、および／または協調的サービス・プラットフォーム３０２（図３）のユーザを表すのに適した属性を組み込むことができる。即ち、コンタクト・オブジェクト４０２は、協調的プレゼンス、例えば、ネットワーク型計算環境２００（図２）におけるコンタクトのプレゼンスを参照することができる。本発明の実施形態では、コンタクト・オブジェクト４０２は、プレゼンス・オブジェクト４０４のインスタンスを参照することによって、協調的プレゼンスを参照する。コンタクト・オブジェクト４０２の一例については、図５を参照して以下で更に詳しく説明する。

プレゼンス・オブジェクト４０４は、協調的プレゼンス、例えば、個々の協調サービス・プラットフォーム３０２のユーザが近い過去におけるいずれかの時点でアクティブになっているネットワーク型計算環境２００の１組のコンピュータ２０４、２０６、２０８、２１２、２１４、および／または２１６（図２）を表すのに適した属性を組み込むことができる。ここで、「近い」過去(recent past)は、協調的文脈(collaborative context)によっては、秒から時間、日、そして年単位までも変化する場合もある。プレゼンス・オブジェクト４０４は、ネットワーク型計算環境２００の場所を表す、１つ以上の終点オブジェクト４１０のインスタンスを参照することができる。例えば、終点オブジェクト４１０はネットワーク型計算環境２００のオーバーレイ・ネットワークにおけるピアに対応することができるので、終点オブジェクト４１０は、１対１で、ネットワーク型計算環境２００のコンピュータ２０４、２０６、２０８、２１２、２１４、２１６と対応する必要はない。

更に、プレゼンス・オブジェクト４０４は、例えば、１つ以上の協調的終点における協調的能力、および／またはプレゼンス・オブジェクト４０４と関連のある一部または全部の終点に跨る総計協調的能力を表す、０以上の能力オブジェクト４１２のインスタンスも参照することができる。加えて、プレゼンス・オブジェクト４０４は、０以上の公開オブジェクト４１８のインスタンスも参照することができる。プレゼンス・オブジェクト４０４の一例については、図１６を参照して以下で更に詳しく説明する。公開オブジェクト４１８の一例については、図７を参照して以下で更に詳しく説明する。能力オブジェクト４１２の一例については、図８を参照して以下で更に詳しく説明する。

MeContactオブジェクト４０６は、コンタクト・オブジェクト４０２の一タイプとすることができ、コンタクト・オブジェクト４０２の属性および挙動を多形的に継承することができる。MeContactオブジェクト４０６は、協調サービス・プラットフォームのユーザ自身のコンタクト情報が、他のユーザのコンタクト情報に関して行うことができる特殊な役割のために、コンタクト・オブジェクト４０２とは差別化するとよい。例えば、MeContactオブジェクト４０６は、その特定のユーザの既知の協調的コンタクトを表す０以上のコンタクト・オブジェクト４０２のインスタンスを参照することができる。MeContactオブジェクト４０６は、例えば、他のMeContactオブジェクト４０６のインスタンスを参照する必要はない。本発明の実施形態では、こうして、不要な複雑さを回避し、協調サービス・プラットフォーム３０２（図３）の伸張性、柔軟性、維持性、および／または拡張性に寄与する。

MeContactオブジェクト４０６は、更に、MyPresenceオブジェクト４０８のインスタンスも参照することができる。MyPresenceオブジェクト４０８は、プレゼンス・オブジェクト４０４の一タイプとすることができ、プレゼンス・オブジェクト４０４の属性および挙動を多形的に継承することができる。この場合も、MyPresenceオブジェクトは、協調サービス・プラットフォームのユーザ自身のプレゼンスが、他のユーザのプレゼンスに対して行うことができる特殊な役割のために、プレゼンス・オブジェクト４０４とは差別化するとよい。例えば、本発明の実施形態では、ユーザは彼ら自体のMyPresenceオブジェクト４０８を明示的に更新することができるが、他のユーザのプレゼンス・オブジェクト４０４のインスタンスを明示的に更新することはできない。

加えて、MeContactオブジェクト４０６は、MeContactオブジェクト４０６と関連があるユーザが、他の協調サービス・プラットフォームのユーザと共に、現在および／または最近参加している協調的会議を表す０以上の会議オブジェクト４１４のインスタンスを参照することができる。会議オブジェクト４１４は、協調的活動を表す１つ以上の活動オブジェクト４１６のインスタンスを参照することができる。本発明の実施形態では、会議オブジェクト４１４は、活動オブジェクト４１６の一タイプであり、活動オブジェクト４１６の属性および挙動を多形的に継承することができる。活動オブジェクト４１６の一タイプであることの結果、会議オブジェクト４１４が参照する活動オブジェクト４１６のインスタンスは、会議オブジェクト４１４のインスタンスとなることもできる。MeContactオブジェクト４０６の一例については、図９を参照して以下で更に詳しく説明する。会議オブジェクト４１４の一例については、図１０を参照して以下で更に詳しく説明する。

各協調的オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８は、協調的オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８のインスタンスを作成および削除するため、ならびに協調的オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８の属性の相応しい問い合わせおよび操作のために、アプリケーション・プログラミング・インターフェースを提供することができる。本発明の実施形態では、協調的オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８が他の協調的オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８を参照するように記載する場合、参照されるオブジェクト、またはそのコピーは、代わりに、参照するオブジェクトに組み込むこと、またはこれと統合することもできる。１つのプログラム・オブジェクトは、適したプログラム参照メカニズムであればいずれを用いても、他のプログラム・オブジェクトを参照することができる。適したプログラム参照メカニズムは、ポインタ、明示的参照、関連するハッシュ・コードおよびその同等物、ならびにこの目的のために特別に設計したプログラム言語の機構を含む。

図４を参照して先に紹介したプログラム・オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８について、これより更に詳細に説明する。各プログラム・オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８は、１つ以上のアプリケーション・プログラミング・インターフェース・エレメントを含むことができる。各アプリケーション・プログラミング・インターフェース・エレメントは、協調サービス・プラットフォーム３０２（図３）のサービスを含む、コンピュータ１０２（図１）のシステム・コンポーネントが、プログラム・オブジェクト４０２、４０４、４０６、４０８、４１０、４１２、４１４、４１６および４１８を構成および制御し、これらと双方向処理するやり方を指定する１つ以上のインターフェース仕様を含むことができる。当業者には明白であろうが、インターフェース仕様は、オブジェクト属性仕様、変数仕様、関数コール仕様、プログラム・オブジェクト仕様、要求／応答メッセージ対のようなメッセージ仕様、および／またはその他のあらゆる相応しいプログラミング・インターフェース仕様を含むことができる。

図５は、本発明の実施形態によるコンタクト・オブジェクト５００の一例を示す。コンタクト・オブジェクト５００は、協調オブジェクト・モデル４００（図４）に組み込むのに適している。コンタクト・オブジェクト５００は、名称エレメント５０２、プレゼンス・エレメント５０４、バディ・フラグ・エレメント(buddy flag element)５０６、および近接エレメント５０８を含む、アプリケーション・プログラミング・インターフェース・エレメントを組み込むことができる。

名称エレメント５０２は、コンタクト・オブジェクト５００と関連のあるコンタクトに対する親しみやすい名称を含むことができる。親しみやすい名称は、例えば、リッチ・テキスト・ストリングとしてエンコードすることができる。プレゼンス・エレメント５０４は、プレゼンス・オブジェクト４０４（図４）のインスタンスに対する参照を含むことができる。

バディ・フラグ・エレメント５０６は、コンタクト・オブジェクト５００と関連のあるコンタクトが「バディ」（仲間）クラス・コンタクト(buddy class contact)に分類されていることのインディケータを含むことができる。バディに分類されたコンタクトは、種々の点で特権を得ることができる。例えば、バディは信頼できるコンタクトとなることができ、バディには、優先権、例えば、招待の優先権を与えることができ、協調サービス・プラットフォームのユーザが、例えば、プレゼンス・データのために申し込む１組のコンタクトに、バディを自動的に含むことができる。バディ・クラス・コンタクトは、通常のコンタクトよりも計算上費用が嵩むこともあり、その数は、例えば、バディ・フラグ・アプリケーション・プログラミング・インターフェース・エレメント５０６に埋め込まれた検査によって、制限するとよい。

近接エレメント５０８は、物理的近接メトリックおよび／または仮想的近接メトリックを含むことができる。例えば、物理的近接メトリックは、ワイヤレス・ネットワーク・インターフェースにおいて受信する信号強度の尺度とすることができる。勿論、近接アプリケーション・プログラミング・インターフェース・エレメント５０８を、近接クエリに応答する１つのメトリックに限定する必要はない。例えば、近接クエリは、生の近接メトリック、時間平均近接メトリック、量子化近接メトリック（「信号強度バー」）、および／またはその他の適した近接メトリックであればいずれでも要求することができる。

図６は、本発明の実施形態によるプレゼンス・オブジェクト６００の一例を示す。プレゼンス・オブジェクト６００は、協調オブジェクト・モデル４００（図４）に組み込むのに適している。プレゼンス・オブジェクト６００は、リッチ・テキスト記述エレメント６０２、終点エレメント６０４、総計ステータス・エレメント６０６、総計能力エレメント６０８、公開オブジェクト・エレメント６１０、新活動招待エレメント６１２、既存活動招待エレメント６１４、タイプ別発見能力エレメント６１６、タイプ別公開オブジェクト発見エレメント６１８、および公開オブジェクト・エレメント６２０を含む、アプリケーション・プログラミング・インターフェース・エレメントを組み込むことができる。

リッチ・テキスト記述エレメント６０２は、プレゼンス・オブジェクト６００と関連のあるネットワーク型計算環境２００（図２）のプレゼンスを記述するリッチ・テキスト・ストリングを含むことができる。単純な例では、「現在建物９にいる」、「Halo(R)、レベル４の再生」、および「利用不可」が含まれる。終点エレメント６０４は、アクティブな協調的終点、最近アクティブになった協調的終点、および／または１つ以上の協調的活動においてアクティブな参加者となることができる１組の協調的終点を含むことができる。適した協調的終点の例には、コンピュータ２０４、２０６、２０８、２１２、２１４および２１６、ならびにネットワーク型計算環境２００のオーバーレイ・ネットワークのピアが含まれる。

総計ステータス・エレメント６０６は、１組の協調的終点を跨ぐ協調的プレゼンスを表す、総計プレゼンス・ステータス・インディケータを含むことができる。各協調的終点は、関連するプレゼンス・ステータス、例えば、ONLINE、AWAY、OUT TO LUCH、BE RIGHT BACK、IDLE、ON THE PHONE、またはBUSYを有することができる。１組の終点に関連する総計プレゼンス・ステータスは、その１組の中にある終点のいずれの１つに関連するステータスと同一である必要はない。総計プレゼンス・ステータスが組における終点の少なくとも１つと同一であっても、１つ以上の他の終点とは異なっていてもよい。

総計プレゼンス・ステータスは、種々の総計プレゼンス・ステータス・アルゴリズムの１つ以上によって判定することができる。プレゼンス・ステータスのレベルを格付けすることもでき、総計ステータスを１組の終点における最も高い格付けのステータスに設定することができる。総計ステータスは、個々のステータス値の加重平均、あるいは個々のステータス値のその他の適した線形または非線形の変形としてもよい。また、個々のステータス値は、変換の前に、相応しく並び換えしておくとよい。利用する総計プレゼンス・ステータス・アルゴリズムは、１組における個々の終点の数によって異なってもよい。

総計能力エレメント６０８は、協調的プレゼンスに関連する総計能力の集合体を含むことができる。協調的プレゼンスにおける個々の各終点には、１組の能力、例えば、協調的活動に関する能力を関連付けることができる。総計能力は、個々の終点の各々の能力の各々の単なる総計であってもよい。一方、総計能力の集合体を、個々の終点の各々にある能力に限定してもよい。更に洗練した総計能力判定アルゴリズムのように、これら両極端の組み合わせも可能である。例えば、総計能力の集合体は、あるいは個々の終点の能力の加重平均プロセス、あるいはその他の適した線形または非線形変換の結果とすることもできる。加えて、総計能力の格付けまたは割合を、総計能力の集合体における各能力に関連させてもよい。

公開オブジェクト・エレメント６１０は、協調的プレゼンスと関連のある公開オブジェクトの集合体を含むことができる。能力オブジェクト４１２（図４）は、公開オブジェクト４１８の一タイプとすることができるが、これら２つは、能力オブジェクト４１２のインスタンスと関連のある能力が通例長寿命である（例えば、日、週、または年単位のこともある）のに対して、基本公開オブジェクト４１８のインスタンスと関連のある公開データは通例短寿命であるという相違がある。この相違は、コンピュータ・システムの性能を最適化するために利用することができる。

新活動招待エレメント６１２は、協調サービス・プラットフォーム３０２（図３）のユーザが、プレゼンス・オブジェクト６００と関連のあるコンタクトを、新しい協調的活動に参加するように招待することを可能にする。つまり、活動をホストする関連の会議が既に存在せず、招待が受け入れられれば、作成することができる。招待は、終点エレメント６０４が参照する各終点、ONLINEプレゼンス・ステータスと関連のある終点のみに配信することができ、招待は、協調的プレゼンスと関連のある各終点に、ある順序で、例えば、順序における各終点に伴うプレゼンス・ステータスによって決定した順序で、またはその他の適した招待配信計画によって配信することができる。

コンタクトに既存の会議および／または活動に加入するように招待する場合、既存の活動アプリケーション・プログラミング・インターフェース・エレメント６１４への招待が好ましい場合がある。会議および／または活動が既に確立されている場合、一部の協調的パラメータを流通可能にしなくてもよく、または流通し難くする、例えば、現在の参加者による使用において協調的パラメータによって決定される範囲内でのみ流通可能にしてもよい。加えて、柔軟性を低下させると、参加の資格が得られる、したがって招待を受ける候補となるプレゼンスの終点を制限することができる。

タイプ別発見能力エレメント６１６は、協調サービス・プラットフォーム３０２（図３）のユーザが、プレゼンス・オブジェクト６００と関連のあるプレゼンスに、複数の能力タイプの１つ以上と関連のある能力について問い合わせることを可能にする。能力タイプの例には、チャット、オーディオ、およびビデオのようなアプリケーション・タイプ、オーディオ出力、オーディオ入力、ビデオ出力、ビデオ入力のようなアプリケーション能力、帯域幅、オーディオ品質、およびビデオ解像度のような終点リソース、あるいはあらゆる適した協調的能力タイプが含まれる。タイプ別発見能力エレメント６１６は、問い合わせに対して、個々の終点の能力および／または総計プレゼンス能力で応答することができる。

タイプ別公開オブジェクト発見エレメント６１８は、協調サービス・プラットフォーム３０２（図３）のユーザが、プレゼンス・オブジェクト６００と関連のあるプレゼンスに、当該プレゼンスと関連のある公開オブジェクトについて、例えば、公開オブジェクト・エレメント６１０によってアクセス可能な公開オブジェクトについて問い合わせることを可能にする。公開オブジェクト・タイプは、関連するリッチ・テキスト・ストリングによって判定することができる。例えば、同じリッチ・テキスト・ストリングが関連する公開オブジェクト４１８（図４）は、同じタイプであると判定することができる。

公開オブジェクト・エレメント６２０は、プレゼンスに関連するデータの公開を可能にすることができる。例えば、公開オブジェクト・エレメント６１０によって維持されている１組のプレゼンス・オブジェクトを更新することができる。本発明の実施形態では、公開オブジェクト・アプリケーション・プログラミング・インターフェース・エレメント６２０を、公開オブジェクト・アプリケーション・プログラミング・インターフェース・エレメント６１０に組み込むことができる。

図７は、本発明の実施形態による公開オブジェクト７００の一例を示す。公開オブジェクト７００は、協調オブジェクト・モデル４００（図４）への組み入れに適している。公開オブジェクト７００は、公認加入者エレメント(authorized subscribers element)７０２および公開データ・エレメント７０４を含む、アプリケーション・プログラミング・インターフェース・エレメントを組み込むことができる。

公認加入者エレメント７０２は、公開オブジェクト７００に関連するデータに申し込むことを許可されているコンタクトと関連のある１つ以上のコンタクト・オブジェクト４０２（図４）のインスタンスを参照することができる。データ・アクセス制御は、木目が粗くてよく、例えば、許可または遮断でよく、あるいは木目を細かくして、データ作成、読み取り、更新、および削除の特権に対する制御を含んでもよい。公開データ・エレメント７０８４は、公開オブジェクト７００に関連する公開データの集合を維持することができる。公開オブジェクト７００に関連して、適したデータ集合であればいずれでも公開することができる。

図８は、本発明の実施形態による能力オブジェクト８００の一例を示す。能力オブジェクト８００は、協調オブジェクト・モデル４００（図４）に組み込むのに適している。能力オブジェクト８００は、関連するアプリケーション・エレメント８０２、およびアプリケーション・データ・エレメント８０４を含むアプリケーション・プログラミング・インターフェース・エレメントを組み込むことができる。

関連アプリケーション・エレメント９０２は、能力オブジェクト８００に関連する能力を実現する１組の協調的アプリケーションに対する参照を含むことができる。アプリケーション・データ・エレメント８０４は、関連アプリケーション・エレメント８０２が参照する１組の協調的アプリケーションの各々を構成するために必要なデータ、および／またはデータの仕様を含むことができる。

図９は、本発明の実施形態によるMeContactオブジェクト９００の一例を示す。MeContactオブジェクト９００は、協調オブジェクト・モデル４００（図４）に組み込むのに適している。MeContactオブジェクト９００は、コンタクト・エレメント９０２、バディ・エレメント９０４、公認加入者エレメント９０６、アクティブ加入者エレメント９０８、会議エレメント９１０、タイプ別能力発見オブジェクト９１２、およびタイプ別公開オブジェクト発見エレメント９１４を含む、アプリケーション・プログラミング・インターフェース・エレメントを組み込むことができる。

コンタクト・エレメント９０２は、MeContactオブジェクト９００と関連のある協調サービス・プラットフォーム３０２（図３）のユーザには分かっているコンタクトと関連のあるコンタクト・オブジェクト４０２（図４）の１組のインスタンスに対する参照を含むことができる。バディ・エレメント９０４は、例えば、コンタクト・オブジェクト５００のバディ・フラグ・エレメント５０６（図５）で示すような、協調サービス・プラットフォーム３０２（図３）のユーザには分かっているコンタクトと関連があり、更にバディ・クラス・コンタクトでもあるコンタクト・オブジェクト４０２（図４）の１組のインスタンスに対する参照を含むことができる。バディ・エレメント９０４が参照するコンタクト・オブジェクト４０２の１組のインスタンス内に単に存在するだけの場合、関連するコンタクトがバディ・クラス・コンタクトであることを示すことができる。コンタクト・エレメント９０２およびバディ・エレメント９０４が参照するコンタクト・オブジェクト４０２の１組のインスタンスは、重複する可能性があるが、少なくとも本発明の実施形態では、この１組は排他的である。

公認加入者エレメント９０６は、能力データのような、MeContactオブジェクト９００に関連する公開データに申し込むことを許可されているコンタクトと関連のあるコンタクト・オブジェクト４０２（図４）の１組のインスタンスに対する参照を含むことができる。公開データ・アクセス制御は、木目が粗くてもよく、例えば、全ての公開データに対するアクセスを拒否または許可すればよく、あるいは、木目を細かくして、例えば、各公開オブジェクト４１８、またはその組み合わせに対する許可を作成し、読み取り、更新し、および／または削除するようにしてもよい。

アクティブ加入者エレメント９０８は、MeContactオブジェクト９００と関連がある協調サービス・プラットフォーム３０２（図３）のユーザによって公開されたデータに対して積極的に(actively)申し込んでいるコンタクトと関連のあるコンタクト・オブジェクト４０２の１組のインスタンスに対する参照を含むことができる。勿論、アクティブ加入者エレメント９０８が参照するコンタクト・オブジェクト４０２のインスタンスは、公認加入者エレメント９０６が維持する許可に従わなければならない。

会議エレメント９１０は、MeContactオブジェクト９００と関連のある協調サービス・プラットフォーム３０２（図３）のユーザが現在参加している会議、ユーザが最近参加した会議、および／またはユーザが間もなく参加する会議と関連のある会議オブジェクト４１４（図４）の１組のインスタンスに対する参照を含むことができる。

タイプ別能力発見オブジェクト９１２は、協調サービス・プラットフォーム３０２（図３）のユーザが、MeContactオブジェクトと関連のあるコンタクトに、複数の能力タイプの１つ以上と関連のある能力について問い合わせることを可能にする。例えば、タイプ別能力発見オブジェクト９１２は、コンタクト・エレメント９０２、バディ・エレメント９０４、および／またはMeContactオブジェクト９００自体が参照するコンタクト・オブジェクト４０２（図４）のインスタンスに問い合わせることができる。タイプ別能力発見オブジェクト９１２は、クエリに対して、個々の終点の能力および／または総計能力で応答することができる。タイプ別公開オブジェクト発見エレメント９１４は、ユーザが、MeContactオブジェクト９００と関連のあるコンタクトに、公開データについて問い合わせることを可能にする。タイプ別能力発見オブジェクト９１２の場合と同様、タイプ別公開オブジェクト発見エレメント９１４は、コンタクト・エレメント９０２、バディ・エレメント９０４、および／またはMeContactオブジェクト９００自体が参照する公開オブジェクト４１８に問い合わせることができる。

図１０は、本発明の実施形態による会議オブジェクト１０００の一例を示す。会議オブジェクト１０００は、協調オブジェクト・モデル４００（図４）に組み込むのに適している。会議オブジェクト１０００は、セッション情報エレメント１００２、活動エレメント１００４、アドミニストレータ・エレメント１００６、許可会員エレメント１００８、および活動着手エレメント(launch activity element)１０１０を含むアプリケーション・プログラミング・インターフェース・エレメントを組み込むことができる。

本発明の実施形態では、会議、例えば、会議オブジェクト１０００と関連のある会議の役割は、１つ以上の協調サービス・プラットフォーム３０２（図３）のユーザが参加している１つ以上の協調的活動を組織し、管理し、および／または維持することを含む。セッション情報エレメント１００２は、会議レベルのセッション情報を含むことができる。会議レベルにおいて活動レベルのセッション情報を収集することにより、性能の最適化を遂行することができる。活動エレメント１００４は、１つ以上の活動オブジェクト４１６（図４）のインスタンスに対する参照を含むことができる。

アドミニストレータ・エレメント１００６は、会議に対してアドミニストレータとして行動することを許可されているコンタクトと関連のある１つ以上のコンタクト・オブジェクト４０２（図４）のインスタンスを参照することができる。管理運営特権は、許可された参加者および／または活動の追加および除去を含むことができる。許可会員エレメント１００８は、会議と関連のある活動に参加することを許可されたコンタクトと関連のある１つ以上のコンタクト・オブジェクト４０２のインスタンスを参照することができる。許可は、木目が粗くてもよく、例えば、全ての会議活動に参加することを特定のコンタクトに許可または拒否すればよく、あるいは、木目を細かくして、例えば、新たな活動を起動するまたは既存の活動を終了すること、個々の活動に最大限参加すること、または限定的に参加すること（例えば、「オブザーバ・ステータス」）、あるいはこれらの組み合わせに対して許可を付与してもよい。

活動着手エレメント１０１０は、新たな活動を会議に追加することができる。活動の加入および離脱は、会議、活動、またはこれら２つの組み合わせによって管理することができる。各場合において、会議オブジェクト１０００のアプリケーション・プログラミング・インターフェース・エレメントは、アドミニストレータ・エレメント１００６および／または許可会員エレメント１００８との調和を施行することができる。

例えば、協調サービス・プラットフォーム３０２（図３）によって、協調オブジェクト・モデル４００（図４）に応じて実行する方法の詳細について、これより説明する。図１１は、本発明の実施形態にしたがって協調サービス・プラットフォーム３０２が実行するステップの例を示す。ステップ１１０２において、コンタクト・オブジェクト４０２のインスタンスを選択することができる。例えば、コンタクト・ストア３１８に格納されているコンタクト・オブジェクト４０２のインスタンスを、コンタクト管理サービス３０４のユーザ・インターフェースによって選択することができる。

ステップ１１０４において、選択したコンタクト・オブジェクト４０２（図４）のインスタンスに、それに関連のあるプレゼンス・オブジェクト４０４のインスタンスについて問い合わせを行うことができる。例えば、選択したコンタクト・オブジェクト５００のプレゼンス・エレメント５０４（図５）は、関連のあるプレゼンス・オブジェクト４０４のインスタンスにアクセスするために利用することができる。

ステップ１１０６において、選択したコンタクト・オブジェクト４０２（図４）のインスタンスと関連のあるコンタクトが、ネットワーク型計算環境２００（図２）内にいるか否か判定を行うことができる。例えば、コンタクトの総計プレゼンス・ステータを、ステップ１１０４において検索したプレゼンス・オブジェクト６００の総計ステータス・エレメント６０６から得ることができ、そしてコンタクトの総計プレゼンス・ステータスがONLINEである場合、コンタクトがいると判断することができる。コンタクトがいると判断した場合、手順はステップ１１０８に進むことができる。それ以外の場合、手順を終了することができる。この時点では、コンタクトは協調のためには利用できない。

あるいは、ステップ１１０４および１１０６を、選択したコンタクトのプレゼンス情報に申し込むステップと入れ替えて、選択したコンタクトがいることを通知が示すまで待ってからステップ１１０８に進むようにしてもよい。この代替案を、破線１１１０で示す。

ステップ１１０８において、選択したコンタクト・オブジェクト４０２（図４）に、関連する能力オブジェクト４１２の１組のインスタンスについて問い合わせることができる。例えば、ステップ１１０４（および／またはステップ１１１０）において検索したプレゼンス・オブジェクト４０４のインスタンスのタイプ別発見能力エレメント６１６を利用して、１組の関連する能力を得ることができる。検査すべき１組の特定の能力は、１つ以上の目標の協調的活動に応じて異なる場合がある。例えば、音声を伴う会議は、オーディオ・入力能力についてのチェックを誘起することができる。ステップ１１１２において、選択したコンタクトには必要な能力があるか否か判定を行うことができる。選択したコンタクトには必要な能力がない場合、手順は図１２のステップ１２０２に進むことができる。それ以外の場合、手順を終了することができる。ステップ１１１２は、単純な検査に限定する必要はない。ステップ１１１２は、例えば、シグナリング・サービス３０８（図３）によって調整する折衝(negotiation)を含み、１組の能力の内のいずれかが１つ以上の目標の活動に対して十分であるか否か判定を行うこともできる。

図１２は、本発明の実施形態による協調サービス・プラットフォーム３０２が実行するステップの更に別の例を示す。図１１および１２のステップは、１１１４および１１１６で示す円で繋がれている。選択したコンタクトがネットワーク型計算環境２００（図２）内にあり、１つ以上の所望の協調的活動に参加することができることを判定した後、ステップ１２０２において１つ以上の招待を、選択したコンタクトに送ることができる。例えば、コンピュータ２１２（図２）において、招待サービス３２６（図３）によって招待を送ることができる。

ステップ１２０４において、１つ以上の招待は、選択したコンタクトによって受信することができる。例えば、招待の１つは、コンピュータ２０８（図２）において招待サービス３２６（図３）によって受信することができる。ステップ１２０６において、選択したコンタクトは、１つ以上の招待に応答することができる。例えば、選択したコンタクトは、コンピュータ２０８において招待サービス３２６のユーザ・インターフェースを利用して、招待の１つに応答することができる。

ステップ１２０８において、招待が受け入れられたか否か判定を行うことができる。例えば、コンピュータ２１２における招待サービス３２６は、ステップ１２０６において送った応答を受信することができ、応答の内容から、招待が受け入れられたか否か判定することができる。招待が受け入れられた場合、手順はステップ１２１０に進むことができる。それ以外の場合、手順を終了することができる。

ステップ１２０４、１２０６および１２０８には破線１２１２で印を付けて、招待に応答するときにおける手順の変動の可能性を強調している。多数の招待を同じ活動に送出する理由の１つは、ネットワーク型計算環境２００（図２）では、選択したコンタクトのプレゼンスが多数の終点に跨る場合があるからである。例えば、協調サービス・プラットフォーム３０２（図３）のユーザが、同じ活動に対する３つの招待をコンピュータ２１２からコンピュータ２１６、２０６および２０８に送ることもできる。例えば、コンピュータ２１６は、選択したコンタクトの事務所のデスクトップＰＣである場合があり、コンピュータ２０６は選択したコンタクトのラップトップである場合もあり、コンピュータ２０８は、選択したコンタクトのパーソナル・ディジタル・アシスタント（ＰＤＡ）である場合もある。招待は、１箇所よりも多い終点において、選択したコンタクトに表示することができる。例えば、選択したコンタクトは、コンピュータ２０８（この例ではＰＤＡ）において招待を断るまたは無視するが、コンピュータ２０６（ラップトップ）ではこの招待を受け入れることもあり得る。選択したコンタクトは単に招待に応答しないという可能性もある。その結果、時間切れとなり、手順が終了する場合もある。

ステップ１２１２における別の可能性は、コンピュータ２１２（図２）における協調サービス・プラットフォーム３０２（図３）のユーザが、活動に対する招待を、サブネット２１８における他の各コンピュータ２１４および２１６に送出することである。この場合、各コンタクトは並行して応答することができる。

招待を受け入れた後、ステップ１２１０において、選択したコンタクトは、協調的活動に対して関連のある会議に加入することができる。例えば、会議は、コンピュータ２１２（図２）によってホストすることができ、選択したコンタクトは、シグナリング・サービス３０８（図３）および／または活動サービス３１０を利用して、コンピュータ２０６から会議に加入することができる。ステップ１２１４において、活動を組み込んだ協調が得られる。

招待サービス３２６（図３）の一例について、これより詳細に説明する。即ち、招待サービス３２６、協調的サービス・プラットフォーム３０２、および協調的サービス・プラットフォーム３０２とは別個の協調的アプリケーション（通例それによって参照されるが）の間における双方向処理を強調する。本発明の実施形態では、このような双方向処理の扱いは、協調サービス・プラットフォーム３０２の使い勝手、拡張性、柔軟性、保守性、および／またはスケーラビリティに寄与し、したがってその広い階級的採用(scale adoption)に対する適格性に寄与する。

図１３は、本発明の実施形態による招待場面の一例を示す。第１コンピュータ１３０２には、第２コンピュータ１３０４との１つ以上の協調的活動を開始するタスクを指示することができる。例えば、コンピュータ１３０２および１３０４は、図２のネットワーク型計算環境２００におけるコンピュータ２０４、２０６、２０８、２１２、２１４または２１６のいずれでもよい。各コンピュータ１３０２および１３０４は、コンピュータ・オペレーティング・システム１３０６および１３０８を含むことができる。各コンピュータ・オペレーティング・システム１３０６および１３０８は、協調的サービス・プラットフォーム・モジュール１３１０および１３１２を含むことができる。コンピュータ・オペレーティング・システム１３０２および１３０４は、同一である必要はない。協調的サービス・プラットフォーム・モジュール１３１０および１３１２は、協調的サービス・プラットフォーム３０２（図３）にしたがうことができる。

コンピュータ・オペレーティング・システム１３０６および１３０８は、グラフィカル・ユーザ・インターフェース（ＧＵＩ）のような、招待ユーザ・インターフェース（ＵＩ）１３１４および１３１６を含むことができる。本発明の実施形態では、招待ユーザ・インターフェース１３１４および１３１６を、それぞれ、協調的サービス・プラットフォーム・モジュール１３１０および１３１２に組み込む。コンピュータ１３０２および１３０４は、更に、協調的アプリケーション１３１８および１３２０も含むことができる。この例では、協調的サービス・プラットフォーム・モジュール１３１０および１３１２とは別個であるが、本発明の実施形態では、協調的アプリケーション１３１８および１３２０を、協調的サービス・プラットフォーム・モジュール１３１０および１３１２に組み込むこともできる。

基本的な協調的招待プロトコルは、３つのメッセージ、協調招待メッセージ１３２２、協調応答メッセージ１３２４、および招待取り消しメッセージ１３２６を含むことができる。

協調招待メッセージ１３２２は、招待識別子、１つ以上の能力識別子、アプリケーション・データ、およびメッセージを含むことができる。招待識別子は、招待を一意に識別することができる。例えば、招待識別子は、Microsoft(R) Developer Network (NSDN(R)) LibraryにおけるGuid Structure section of .NET Framework Class Library（．ＮＥＴフレームワーク・クラス・ライブラリのＧｕｉｄ構造の章）、 documentation version 1.1.1.に記載されているような、大域的な一意の識別子（ＧＵＩＤ）とするとよい。各能力識別子は、招待と関連のある協調的活動に必要な協調的能力を表す能力オブジェクトを参照することができる。例えば、各能力識別子は、帯域的な一意の識別子（ＧＵＩＤ）とすればよい。アプリケーション・データは、例えば、協調的活動を開始するために、協調的アプリケーションに渡すべきデータを含む、および／または指定することができる。メッセージは、標準的またはカスタム招待テキストを収容するリッチ・テキスト・ストリングとすればよい。

協調応答メッセージ１３２４は、招待識別子、招待応答アクション、応答メッセージ、および拡張応答データを含むことができる。招待識別子は、応答メッセージ１３２４が応答する宛先である協調招待を識別することができる。例えば、招待識別子は、協調招待メッセージ１３２２が供給するＧＵＩＤとすればよい。招待応答アクションは、応答のタイプを示すことができる。例えば、招待応答は、断り、受入、無視、および誤りの内の１つとすることができる。応答メッセージは、標準的またはカスタム招待応答テキストを収容するリッチ・テキスト・ストリングとすればよい。拡張応答データは、招待および／または協調的活動に関する適した追加の応答データであればいずれでも含むことができる。

招待取り消しメッセージ１３２６は、当該取り消しメッセージ１３２６が取り消している招待を識別する招待識別子を含むことができる。例えば、協調招待メッセージ１３２２は、コンピュータ１３０２からコンピュータ１３０４に送り、協調的サービス・プラットフォーム１３１２のユーザに、協調的サービス・プラットフォーム１３１０のユーザと共に、協調的活動に参加するように招待することができる。これに応答して、協調応答メッセージ１３２４をコンピュータ１３０４からコンピュータ１３０２に送り、招待が、例えば、受け入れられたのかまたは断られたのか示すことができる。本発明の実施形態では、協調的サービス・プラットフォーム１３１０のユーザが、コンピュータ１３０２からコンピュータ１３０４に招待取り消しメッセージ１３２６を送ることによって、招待を取り消すことが可能である。

協調的招待方法の例を更に詳細に説明する前に、招待サービス３２６（図３）のアプリケーション・プログラミング・インターフェース（ＡＰＩ）の一例について説明しておくと役に立つであろう。図１４は、本発明の実施形態による招待サービス３２６のアプリケーション・プログラミング・インターフェース（ＡＰＩ）１４００の一例を示す。招待サービスＡＰＩ１４００は、招待エレメント１４０２、招待リスナ作成エレメント(create invitation listener element)１４０４、保証付招待発送エレメント１４０６、無保証招待発送エレメント(send unsecured invitation element)１４０８、招待取り消しエレメント１４１０、招待応答エレメント１４１２、招待応答取り込みエレメント１４１４、登録／登録抹消能力エレメント１４１６、能力列挙エレメント１４１８、および能力情報取り込みエレメント１４２０を含むことができる。各アプリケーション・プログラミング・インターフェース・エレメント１４０２、１４０４、１４０６、１４０８、１４１０、１４１２、１４１４、１４１６、１４１８および１４２０は、各コンピュータ１３０２および１３０４における協調的サービス・プラットフォーム・モジュール１３１０および１３１２（図１３）に組み込まれた招待サービス３２６（図３）のアプリケーション・プログラミング・インターフェースに含めることもできるが、コンピュータ１３０２、１３０４が招待元、招待先、または双方のどれかに応じて、エレメント１４０２、１４０４、１４０６、１４０８、１４１０、１４１２、１４１４、１４１６、１４１８、および１４２０のそれぞれを別個にコンピュータ１３０２および１３０４によって利用することもできる。

招待エレメント１４０２は、協調招待メッセージ１３２２と同じデータの一部または全部に対するアクセスを含み、提供することができる。例えば、協調招待メッセージ１３２２、またはその一部分は、招待エレメント１４０２を用いて、招待サービス３２６（図３）に格納すること、および／またはここから検索することができる。

招待リスナ作成エレメント１４０４は、コンピュータ１３０２および１３０４（図１３）のような協調的終点における招待リスナ(invitation listener)をインスタンス化することができる。インターフェース指定パラメータは、インターネット・プロトコル（ＩＰ）アドレスまたはＰ２Ｐピア識別子（コンピュータ１３０２、１３０４毎に多数の終点がある場合もある）、ポート識別子（終点毎に多数の通信ポートがある場合もある）、ならびに招待リスナを設定(configure)または削除(destroy)するための招待リスナ識別子を含むことができる。例えば、オペレーティング・システム１３０８は、招待リスナ作成エレメント１４０４を利用して、標準的な招待および／または協調的サービス・ポートにおいて聞いている招待リスナを作成することができる。協調的アプリケーション１３２０は、招待リスナ作成エレメント１４０４を利用して、協調的アプリケーション１３２０と協調するために、招待を予測して聞くことを専用としたカスタム招待ポートにおいて招待リスナを作成することができる。

保証付招待発送エレメント１４０６は、招待メッセージ１３２２（図１３）の安全な発送を可能にする。インターフェース指定パラメータは、コンタクト・オブジェクト４０２（図４）のインスタンスに対する参照、終点オブジェクト４１０のインスタンスに対する参照、送出する招待メッセージ１３２２に対する参照、一旦招待に対する応答が受信されたならば知らせるべきイベントのような、実行スレッドの同期オブジェクトに対する参照、および保証付招待発送エレメント１４０６が設定する招待識別子に対する参照を含むことができる。招待メッセージ１３２２は、参照されるコンタクト・オブジェクト４０２のインスタンスと関連のあるコンタクトに送ることができる。終点オブジェクト４１０のインスタンスが設けられている場合、招待メッセージ１３２２を、関連のある終点に送ることができ、それ以外の場合、招待メッセージ１３２２は、参照されるコンタクト・オブジェクト４０２のインスタンスと関連のあるコンタクトがいる場合、各終点に送ることができる。

協調的活動に参加する判断には、安全性の意義(security consequence)があるとよい。例えば、双方向ファイル共有に参加する決定は、データに修正および／または削除を行わせる場合もある。その結果、協調的サービス・プラットフォーム３０２（図３）のユーザが、信頼できるソースからのみ協調的招待を受け入れることを決定するというようにすることができる。本発明の一実施形態では、コンタクト情報を以前に交換したことがあるユーザ間に、保証付通信接続を確立することができる。例えば、コンタクト情報は、暗号認証証明書を収容するとよく、そして保証付通信接続は、セキュア・ソケット・レイヤ（ＳＳＬ）またはオーバーレイ・ネットワーク用セキュリティ・サービス・プロバイダ（ＳＳＰ）技法のような、従来の安全プロトコルを用いて確立するとよい。

しかしながら、ある状況下では、ユーザが不安な招待を許可する決定をする場合もあり得る。無保証招待発送エレメント１４０８は、保証付招待発送エレメント１４０６と同様であってもよいが、例えば、招待の発送元および受信先が以前にコンタクト情報を交換したことがあるという要件がないことを除く。例えば、無保証招待発送エレメント１４０８は、招待メッセージ１３２２をサブネット２１８上の各コンピュータ２１２、２１４および２１６（図２）にブロードキャストするために利用することができる。不安な招待は、マルチプレーヤ・ゲームのような、その場だけの協調、および簡易ソーシャル設定における協調をし易くすることができる。

招待取り消しエレメント１４１０は、取り消しメッセージ１３２６（図１３）の発送を可能にすることができる。インターフェース指定パラメータは、無保証招待発送エレメント１４０８の保証付招待発送エレメント１４０６のよって設定された招待識別子のような、招待識別子を含むことができる。招待エレメント１４１２に対して応答することにより、応答メッセージ１３２４（図１３）の発送を可能にすることができる。インターフェース指定パラメータは、招待識別子および招待応答アクションを含むことができる。

保証付招待発送エレメント１４０６および無保証招待発送エレメント１４０８の各々は、同期および非同期バージョン双方を有することができる。例えば、非同期バージョンは、招待メッセージ１３２２（図１３）を送り、次いで招待に対する応答をチェックする前に、実行スレッドにおいて追加命令の実行を可能にすることができる。対照的に同期バージョンは、応答メッセージ１３２４が受信されるまで、または時間切れとなるまで、実行スレッドにおいて別の命令を実行することなく待機することができる。招待応答取り込みエレメント１４１４は、非同期的に送られた招待メッセージ１３２２に対する応答をチェックするため、および／または待つために利用することができる。インターフェース指定パラメータは、招待識別子と、応答メッセージ１３２４が到着したときにそれに対して設定する参照とを含むことができる。招待発送エレメント１４０６および１４０８の同期バージョンは、スレッド同期オブジェクトに対する参照を含む必要はない。

招待サービス１４００は、終点能力の登録簿を維持することができる。登録／登録抹消能力エレメント１４１６は、招待サービス１４００による登録および登録抹消を可能にすることができる。インターフェース指定パラメータは、１つ以上の能力オブジェクト４１２（図４）のインスタンスに対する参照、１つ以上の能力がある終点の特定のユーザまたはその終点のユーザ全てに関係するかについての指示を含むことができる。各能力オブジェクト４１２のインスタンスは、能力識別子、例えば、大域的に一意の識別子（ＧＵＩＤ）と関連付けることができる。本発明の実施形態では、各能力は、個々の協調的アプリケーション１３１８、１３２０（図３）と関連がある。招待サービス１４００は、登録能力および登録抹消能力のために別個のアプリケーション・プログラミング・インターフェース・エレメントを含むことができる。

能力列挙エレメント１４１８は、招待サービス１４００に登録されている能力の列挙を可能にすることができる。インターフェース指定パラメータは、列挙がある終点の特定のユーザまたはある終点の全てのユーザと関連のある能力のどちらを収容すべきかに関する指示を含むことができる。本発明の実施形態では、列挙は、例えば、能力オブジェクト４１２（図４）のインスタンスに対する参照の代わりに、能力識別子を含む。その場合、能力オブジェクト４１２のインスタンスは、能力情報取り込みエレメント１４２０によって検索することができる。

これより、協調招待方法の例について、更に詳しく説明する。協調的招待に対する基本的な文脈は、ユーザが、招待に対して発送および／または応答するために特定のアプリケーションと双方向処理するか否か（特定の場面）、またはユーザが招待に対して発送および／または応答するために、アプリケーションとは独立したメカニズムと双方向処理を行うか否か（包括的場面）ということである。４つの場面、包括から包括(from generic to generic)、特定から包括(from specific to generic)、包括から特定(from generic to specific)、そして特定から包括(from specific to generic)について、図１５から図１８に関して以下に説明する。

図１５は、本発明の実施形態にしたがって招待を発送するステップの一例を示す。ステップ１５０２において、招待ユーザ・インターフェース（ＵＩ）を呼び出すことができる。例えば、協調的サービス・プラットフォーム３０２（図３）は、招待サービス３２６のユーザ・インターフェースを呼び出すことができる。ステップ１５０４において、招待ユーザ・インターフェースを用いて、１つ以上のコンタクトを選択することができる。例えば、招待サービス３２６のユーザ・インターフェースは、コンタクト管理サービス３０４と双方向処理を行い、ユーザの既知のコンタクトのリスト、または、例えば、バディ・クラス・コンタクトのリストを表示することができ、そしてユーザは、リストを見ながら、これらの表示から１組のコンタクトを選択することができる。

ステップ１５０６において、招待ユーザ・インターフェースを用いて、活動を選択することができる。例えば、招待サービス３２６（図３）のユーザ・インターフェースは、活動サービス３１０と双方向処理を行い、利用可能な協調的活動のリスト、あるいは、例えば、人気のある活動または最後に用いられた活動のリストを表示することができ、ユーザは、リストを見ながら、これらの表示から協調的活動を選択することができる。ステップ１５０８において、招待ユーザ・インターフェースが招待を発送しようとしているか否か、または特定の協調的アプリケーションから招待が発送されようとしているか否か判定を行うことができる。例えば、この判定は、招待サービス３２６の設定変更可能な(configurable)パラメータに応じて行うことができる。招待ユーザ・インターフェースが招待を発送しようとしていると判定した場合、本手順はステップ１５１０に進むことができる。それ以外の場合、手順はステップ１５１２に進むことができる。

ステップ１５１０において、ステップ１５０６で選択した活動と関連のある協調的アプリケーションを起動することができる。ステップ１５１０を破線の外枠で示し、この時点においてアプリケーションを起動することができるが、招待ユーザ・インターフェースは、実行スレッドの制御を保持し、ステップ１５１４に進むことができることを示す。これは、ステップ１５１６とは対照的である。

ステップ１５１２において、ステップ１５０４において選択したコンタクトや、ステップ１５０６において選択した活動と関連のあるあらゆるコンフィギュレーション・パラメータのような、これまでに収集した招待に関する詳細を格納し、その活動と関連のある協調的アプリケーションによって検索できるようにする。ステップ１５１６において、その協調的アプリケーションを起動し、招待ユーザ・インターフェースは本手順の制御を渡す。

ステップ１５１４において、招待サービス１４００（図１４）のアプリケーション・プログラミング・インターフェースによって、例えば、前述のような保証付招待発送エレメント１４０６または無保証招待発送エレメント１４０８によって、招待を発送することができる。招待を発送する際、同じアプリケーション・プログラミング・インターフェース・エレメント１４０６、１４０８を利用することができるが、本手順がステップ１５１０からステップ１５１４に進むときには、エレメント１４０６、１４０８を呼び出すのは招待ユーザ・インターフェースであり、一方本手順がステップ１５１６からステップ１５１４に進むときには、エレメント１４０６、１４０８を呼び出すのは協調的アプリケーションである。その結果、エレメント１４０６、１４０８に渡されるインターフェース指定パラメータが異なる可能性がある。

ステップ１５０２において開始する手順は、招待ユーザ・インターフェースを利用するので、「包括から」の場面の１つを記述する。逆に、ステップ１５１８からは、「特定から」の場面が開始する。ステップ１５１８において、協調的アプリケーションを起動することができる。例えば、アプリケーション１３１８（図１３）を、従来のように、コンピュータ・オペレーティング・システム１３０６によって起動することができる。ステップ１５１８は、ステップ１５２０のための事前調整であり、ステップ１５１８および１５２０間しばらくの時間が経過する場合もある。

ステップ１５２０において、協調的アプリケーション１３１８（図１３）のユーザ・インターフェースを用いて、１つ以上のコンタクトを選択することができる。例えば、協調的アプリケーション１３１８は、協調的サービス・プラットフォーム１３１０のコンタクト管理サービス３０４（図３）と双方向処理を行い、アプリケーション・ユーザの既知のコンタクトのリスト、または、例えば、バディ・クラス・コンタクトのリストを表示することができ、そしてアプリケーション・ユーザはこれらの表示から１組のコンタクトを選択することができる。ステップ１５０４からの進展とは対照的に、協調的活動の選択は必要でなく、手順はステップ１５１４に進むことができる。協調的アプリケーション１３１８は、協調的活動を決定することができる。しかしながら、本発明の実施形態では、協調的アプリケーション１３１８は、多数の活動をサポートすることができ、その場合、ステップ１５０６の同等物を充当すればよい(appropriate)。ステップ１５１４において、協調的アプリケーション１３１８が招待発送エレメント１４０６または１４０８（図１４）を呼び出すことができる。

図１６は、招待サービス１４００（図１４）が本発明にしたがって招待を発送する際に実行するステップの一例を示す。ステップ１６０２において、次のコンタクト候補を選択する。例えば、コンタクト候補は、図１５のステップ１５０４または１５２０において選択した１組の中から選択することができる。

ステップ１６０４において、コンタクト候補の終点が分かっているか否か判定を行うことができる。例えば、コンタクト候補を表すコンタクト・オブジェクト４０３が参照するプレゼンス・オブジェクト４０４（図４）に、その１組の終点オブジェクト４１０について問い合わせることができる。分かっている終点がコンタクト候補にない場合（例えば、問い合わせの結果が空集合）、本手順はステップ１６０６に進むことができる。コンタクト候補の終点が分かっている場合、本手順はステップ１６０８に進むことができる。ステップ１６０６において、コンタクト候補の終点を突き止めることができる。例えば、招待サービス３２６（図３）は、コンタクト場所サービス３２２と双方向処理を行い、コンタクト候補に対して１組の有効な終点を決定することができる。

ステップ１６０８において、コンタクト候補に対して分かっている終点の中から、終点候補を選択することができる。ステップ１６１０において、終点候補との通信接続を確立することができる。例えば、接続性サービス３１６（図３）との接続を確立することができる。ステップ１６１２において、終点候補に招待を、例えば、招待メッセージ１３２２（図１３）によって発送することができる。

ステップ１６１４において、別の終点候補が未だあるか否か判定を行うことができる。未だ別の終点候補がある場合、手順はステップ１６０８に戻って、次の終点候補を選択することができる。それ以外の場合、手順はステップ１６１６に進むことができる。ステップ１６１６において、別のコンタクト候補が未だあるか否か判定を行うことができる。未だ別のコンタクト候補がある場合、手順はステップ１６０２に戻って、次のコンタクト候補を選択することができる。それ以外の場合、招待を発送したと見なすことができる。

４つの場面の内、「包括から」および「特定から」の部分について説明し終えたので、これより「包括へ」および「特定へ」の部分について、それぞれ、図１７および図１８を参照しながら説明する。図１７は、本発明の実施形態にしたがって、招待ユーザ・インターフェースから協調的招待に応答するためのステップの一例を示す。協調的招待を多数の終点に発送した場合、図１７および／または図１８に示すステップを各終点において実行すればよい。

ステップ１７０２において、協調的招待を、協調サービス・プラットフォーム３０２（図３）の標準的通信ポートにおいて受信することができる。例えば、招待メッセージ１３２２（図１３）は、協調的サービス・プラットフォーム３０２のために予約してあり、招待サービス３２７が監視するＴＣＰ／ＩＰポートに到達することができる。

ステップ１７０４において、終点が、招待と関連のある活動に参加することができるか否か判定を行うことができる。例えば、招待サービス３２６（図３）は、招待メッセージ１３２２（図１３）における能力識別子を、招待サービス３２８に登録されている能力と比較することができる。あるいは、終点のユーザと関連のあるMeContactオブジェクト４０６（図４）に問い合わせて、それと関連のある１組の能力オブジェクト４１２を求めることができ、これらを、招待メッセージ１３２２の中にある能力識別子と比較することができる。終点が、招待と関連のある活動に参加することができると判定した場合、手順はステップ１７０６に進むことができる。それ以外の場合、手順はステップ１７０８に進むことができる。

ステップ１７０６において、ユーザ波招待を受け入れる、断る、または無視することができる。例えば、招待サービス３２６（図３）は、判断、即ち、受入、断り、または無視に対応するユーザ・インターフェース・エレメントを有する招待ユーザ・インターフェースを表示することができる。ユーザは、対応するユーザ・インターフェース・エレメントを選択することにより、招待を受け入れる、断る、または無視することができる。ユーザが招待を受け入れる場合、手順はステップ１７１０に進むことができる。ユーザが招待を断る場合、手順はステップ１７０８に進むことができる。ユーザが招待を無視した場合、手順はステップ１７１２に進むことができる。

ステップ１７０８において、応答メッセージ１３２４（図１３）を送り、招待が断られたことを示すことができる。例えば、応答メッセージ１３２４は、招待サービス１４００のアプリケーション・プログラミング・インターフェースの招待エレメント１４１２（図１４）に対する応答と共に送ることができる。同様に、ステップ１７１２において、応答メッセージ１３２４を送り、ユーザが招待を無視することを選択したことを示すことができる。招待エレメント１４１２は、この応答を送るためにも用いることができる。本発明の実施形態では、明示的な無視応答を送ることができるので、協調的サービス・プラットフォーム３２０（図３）の効率が向上する。

ステップ１７１０において、受け入れた招待の詳細を格納し、協調的活動と関連のある協調的アプリケーション１３２０が検索できるようにする。例えば、招待メッセージ１３２２の内容の一部または全部を、招待サービス３２６（図３）によって、アプリケーション・プログラミング・インターフェースの招待エレメント１４０２（図１４）を用いて格納することができる。ステップ１７１４において、招待サービス３２６によって協調的アプリケーション１３２０を起動することができる。

ステップ１７１６において、招待の受入を示す応答メッセージ１３２４（図１３）を、例えば、招待サービス１４００のアプリケーション・プログラミング・インターフェースの招待エレメント１４１２に対する応答を利用して送ることができる。ステップ１７１６からステップ１７１８に進む際に、実行の制御を、ステップ１７１４において起動した協調的アプリケーション１３２０に渡すことができる。あるいは、並列の実行スレッドにおいて協調的アプリケーション１３２０を起動することもでき、必要に応じてスレッドの同期を取り、ステップ１７０２において招待を受信した招待サービス・スレッドは、ステップ１７１６において応答した後に、終了することができる。

ステップ１７１８において、協調的アプリケーション１３２０（図１３）は、ステップ１７１０において格納した招待の詳細を読み出すことができる。例えば、格納されている招待の詳細から、協調アプリケーション１３２０の何らかのコンフィギュレーション設定（再設定）を行うことができる。この時点において、協調アプリケーション１３２０は、協調的活動に参加し始める準備を整えることができ、ステップ１７２０において、協調的活動への参加を開始することができる。

図１８は、本発明の実施形態にしたがって、特定アプリケーション・ユーザ・インターフェースから協調的招待に応答するためのステップの一例を示す。ステップ１８０２において、協調的アプリケーションを起動することができる。例えば、コンピュータ・オペレーティング・システム１３０４によって、従来のように協調的アプリケーション１３２０（図１３）を起動することができる。ステップ１８０４において、協調的アプリケーション１３２０は、非標準的、アプリケーション特定協調通信ポートにおいて、招待リスナ(invitation listener)を作成することができる。例えば、協調的アプリケーション１３２０は、招待サービス１４００のアプリケーション・プログラミング・インターフェースの招待リスナ作成エレメント１４０４（図１４）を利用して、協調的サービス・プラットフォーム３０２（図３）のために予約してあるポートとは異なるＴＣＰ／ＩＰポート上に招待リスナを作成することができる。

後のある時点で、ステップ１８０６において、非標準的ポートにおいて協調的招待を受信することができる。例えば、ステップ１５１４（図１５）において送った招待メッセージ１３２２（図１３）は、アプリケーション特定ポートおよび／または終点に送られている可能性がある。ステップ１８０８において、協調的アプリケーション１３０２のユーザは、招待を受け入れる、断る、または明示的に無視することができる。例えば、協調的アプリケーション１３２０は、判断、即ち、受入、断り、および無視に対応するユーザ・インターフェース・エレメントを有するユーザ・インターフェースを表示することができる。次いで、ユーザは、対応するユーザ・インターフェース・エレメントを選択することにより、所望の応答を選択することができる。ユーザが招待を受け入れる場合、手順はステップ１８１０に進むことができる。ユーザが招待を断る場合、手順はステップ１８１２に進むことができる。ユーザが招待を明示的に無視する場合、手順はステップ１８１４に進むことができる。

ステップ１８１０、１８１２および１８１４の各々において、しかるべき招待応答を招待元に送ることができる。各ステップ１８１０、１８１２および１８１４は、例えば、招待サービス１４００の招待エレメント１４１２（図１４）に対する応答を利用して、招待応答アクションを受入、断りまたは無視にそれぞれ設定して、応答メッセージ１３２４（図１３）を送ることができる。所望の協調アプリケーション１３２０（図１３）は既に起動されているので、招待が受け入れられた場合、協調的活動は、これ以上の遅れを伴うことなく、ステップ１８１６において開始することができる。

協調的プレゼンス公開(collaborative presence publication)のための方法の例について、これより更に詳細に説明する。即ち、サーバレス・プレゼンス公開(serverless presence publication)、即ち、専用のサーバ・コンピュータの必要性とは独立して協調的プレゼンス情報を公開できることは、本発明の実施形態では有利である。例えば、サーバレス・ネットワーク型計算環境、ピア・ツー・ピア・ネットワーク、またはオーバーレイ・ネットワークは、専用のサーバ・コンピュータを必要とするネットワークおよびネットワーク・アプリケーションよりも優れたスケーラビリティを提供することができる。ネットワーク型計算環境２００（図２）は、ピア・ツー・ピアまたはオーバーレイ・ネットワークをサポートすることができる。コンピュータ２０４、２０６７、２０８、２１２、２１４および２１６の各々は、ピア・ツー・ピア・ネットワークの１つ以上のピアをサポートすることができる。各ピアは、協調的終点であり、終点オブジェクト４１０（図４）のインスタンスと関連付けることができる。

前述のように、協調的プレゼンスは、プレゼンス・オブジェクト４０４（図４）によって表すことができる。プレゼンス・オブジェクト４０４の、全てを含む、適したポートであればいずれでも、協調的サービス・プラットフォーム３０２（図３）のユーザに公開することができる。加えて、プレゼンス・オブジェクト４０４のインスタンスによるプログラム・オブジェクト・インスタンス(programmatic object instance)への参照も公開することができ、終点オブジェクト４１０、能力オブジェクト４１２、および更に包括的な公開オブジェクト４１８を含む。

しかしながら、本発明の実施形態では、通例、１回の公開では十分でない。プレゼンス情報は変化する可能性がある。例えば、公開オブジェクト４１８は、協調的アプリケーションによって更新することができ、特定の終点と関連のある総計ステータスおよび／またはプレゼンス・ステータスは１日中いつでも変化する可能性があり、例えば、ネットワーク型ワイヤレス・デバイスがオンまたはオフに切り替わることによって、あるいはワイヤレス・ネットワークのカバレッジ・エリアに対して出たり入ったりすることによって、終点が特定のコンタクトのプレゼンスに追加されること、またはそこから除去される可能性があり、新しい協調的アプリケーションをインストールする毎に、終点の能力が変化する可能性がある。効果的な協調には、プレゼンス情報を常に更新することが必要となる場合もある。本発明の実施形態では、プレゼンス申し込みおよびプレゼンス通知メッセージによって、協調的プレゼンス情報を、ネットワーク型計算環境２００（図２）のような、サーバレス・ネットワーク計算環境において分散させる。

図１９は、本発明の実施形態にしたがってサーバレス・プレゼンス公開に参加するためのステップの例を示す。ステップ１９０２において、コンピュータ・ユーザは、コンピュータのオペレーティング・システム（ＯＳ）によって認証を行うことができる。例えば、ユーザはネットワーク型計算環境２００のコンピュータ２０４、２０６、２０８、２１２、２１４または２１６（図２）の１つにログオンすることができる。相応しいコンピュータ・オペレーティング・システムは、"MICROSOFT WINDOWS（登録商標）"または"UNIX（登録商標）"コンピュータ・オペレーティング・システムのいずれかの適したバージョンのように、協調的サービス・プラットフォーム３０２（図３）をサポートすることができるコンピュータ・オペレーティング・システムを含む。コンピュータ・オペレーティング・システムによって認証を行うと、コンピュータ・ユーザに対してコンピュータが認識したアイデンティティを確定することができ、即ち、コンピュータ・ユーザをMeContactオブジェクト４０６（図４）のインスタンスと関連付けることができる。

ステップ１９０４において、協調的サービス・プラットフォーム３０２の公開サービス３０６（図３）との通信を初期化することができる。前述のように、公開サービス３０６はサーバレスとすることができる。例えば、ステップ１９０４において、コンピュータ・ユーザは、公開サービス３０６を組み込んだピア・ツー・ピア（Ｐ２Ｐ）ネットワークに加入することができる。ステップ１９０６において、コンピュータ・ユーザと関連のあるMeContactオブジェクト４０６（図４）に収容されている、および／またはこれによって参照されるデータの一部または全部を、例えば、１つ以上のプレゼンス通知メッセージによって、公開サービス３０６に公開することができ、これによって、コンピュータと協調的サービス・プラットフォーム３０２のユーザとの協調的プレゼンスを確立する。

ステップ１９０８において、コンタクト・ストア３１８（図３）との通信を初期化することができる。例えば、コンタクト・ストアは、データベースのような従来のデータ・ストアとすればよく、コンタクト・ストア３１８との通信の初期化は、データ・ストアとの通信セッションを確立することを含むことができる。ステップ１９１０において、コンタクト・ストア３１８に、ユーザのバディ・クラス・コンタクトについて問い合わせることができる。本発明の実施形態では、コンタクト・ストア３１８に問い合わせる際、MeContactオブジェクト４０６のバディ・エレメント９０４に含まれるコンタクト・オブジェクト４０２（図４）に対する１つ以上の参照を解除する(de-reference)ことを含む。

ステップ１９１２において、バディ・クラス・コンタクトのプレゼンスに対して、例えば、プレゼンス申し込みメッセージを用いて、申し込みを行うことができる。プレゼンス申し込みメッセージについては、図２０および図２１を参照しながら以下で更に詳しく説明する。ステップ１９１４において、申し込みに応答して、プレゼンス更新通知を受信することができる。例えば、プレゼンス通知メッセージは、申し込みが関連するプレゼンスに変更が生じたときに、ピア・ツー・ピア・ネットワークを通じて送ることができる。

図２０は、本発明の実施形態にしたがってプレゼンス申し込みを行うためのステップの一例を示す。例えば、図２０によって示すステップは、ステップ１９１２（図１９）の一部として実行することができる。申し込みを行おうとする１組のバディ・クラス・コンタクトは、例えば、ステップ１９１４等から入手可能とすることができる。ステップ２００２において、次のバディ・クラス・コンタクト候補を、この１組から選択することができる。

ステップ２００４において、バディ・クラス・コンタクトを探索することができる。例えば、ピア名称解明プロトコル（ＰＮＲＰ）を利用すれば、ピア・ツー・ピア・ネットワークにおけるバディ・クラス・コンタクトと関連のある終点を突き止めることができる。あるいは、または加えて、サブネット２１８（図２）のようなローカル・ネットワーク区画全域を通じて、コンタクトを探索することができる。適したネットワーク区間であればいずれでも隔離すること、および／またはそこでコンタクトを探索することができる。

探索が成功しない場合もある。例えば、バディ・クラス・コンタクトには、ピア・ツー・ピア・ネットワークおよび／またはローカル・ネットワーク区画内に、関連のある終点がない場合がある。ステップ２００６において、バディ・クラス・コンタクトが発見されたか否か判定を行うことができる。例えば、ピア名称解明プロトコルは、ピア・ツー・ピア・ネットワークにおいて関連する協調的終点（例えば、ピア）に対するバディ・クラス・コンタクトの名称を首尾良く解明することができ、あるいはローカル・ネットワーク区画全域においてブロードキャストされ、当該バディ・クラス・コンタクトに対して関連のある終点（例えば、ＴＣＰ／ＩＰアドレスおよび通信ポート番号）を識別するメッセージに対する回答を受信することができる。バディ・クラス・コンタクトを発見した場合、手順はステップ２００８に進むことができる。それ以外の場合、例えば、コンタクトがバディに分類されているために、一時的に発見されないと仮定することができ、手順はステップ２０１０に進むことができる。

バディに分類されると、コンタクトは通例アクティブな協調的参加者(collaborative participant)であるという仮定を導くことができるので、本発明の一実施形態では、見つからないバディ・クラス・コンタクトを周期的に探索することによって、計算およびネットワーク・リソースに対する要求増大にも拘わらず、協調的サービス・プラットフォーム３０２（図３）が価値のある機構であることの有効性を十分に高める。手順は、ステップ２０１０において、探索の合間中待機することができる。例えば、探索の合間の期間は１０分とすることができる。ステップ２０１０は、待機、そして恐らくは後続のステップが別個の実行スレッドにおいて行われる可能性があることを示すために、破線２０１２で囲まれている。待機ステップ２０１０のために別個の実行スレッドをインスタンス化した後、主実行スレッドはステップ２０１４に進むことができる。

バディ・クラス・コンタクトを発見した後、ステップ２００８において、プレゼンス申し込みメッセージを、そのコンタクトと関連のある終点、例えば、ステップ２００４において発見した終点に送ることができる。プレゼンス申し込みメッセージは、コンタクトと関連のある協調的プレゼンス情報の一部または全部に対する申し込みを指定することができる。例えば、プレゼンス申し込みメッセージは、プレゼンス・オブジェクト６００のアプリケーション・プログラミング・インターフェースのリッチ・テキスト記述エレメント６０２（図６）、終点エレメント６０４、総計ステータス・エレメント６０６、総計能力エレメント６０８、および公開オブジェクト・エレメント６１０内１つ以上を通じてアクセス可能なプレゼンス情報に対する申し込みを指定することができる。例えば、ステップ１９１４（図１９）において申し込みに応答して送られるプレゼンス通知メッセージは、申し込みによってカバーされるプレゼンスの一部が変化したときにのみ送ればよく、変化したプレゼンス情報の一部のみを含めばよい。

ステップ２０１４において、１組のバディ・クラス・コンタクトの中に別のバディ・クラス・コンタクトが未だあるか否か判定を行うことができる。そのようなコンタクトが未だある場合、本手順はステップ２００２に戻り、次のコンタクトを上記１組の中から選択することができる。そうでない場合、本手順は、ステップ１９１４（図１９）および／または図２１のステップ２１０２のような、別のステップに進むことができる。

図２１は、本発明の実施形態によるプレゼンス申し込みを受け入れるステップの一例を示す。ステップ２１０２において、プレゼンス申し込みメッセージを受信することができる。例えば、これは、ステップ２００８（図２０）において送ったプレゼンス申し込みメッセージとすることができる。ステップ２１０４において、プレゼンス申し込みメッセージの発送元と関連のあるコンタクト情報を検索することができる。例えば、プレゼンス申し込みメッセージは、発送元と関連のあるコンタクト・オブジェクト４０２（図４）のインスタンスを参照することができる。プレゼンス申し込みメッセージの受信先は、コンタクト管理サービス３０４（図３）によって、発送元のコンタクト情報を検索することができる。

ステップ２１０６において、プレゼンス申し込みメッセージの発送元に対して申し込み方針(subscription policy)が確定しているか否か判定を行うことができる。例えば、コンタクト管理サービス３０４（図３）が管理する発送元と関連があるコンタクト情報は、発送元と当該発送元の申し込み方針との間の関連を含むことができる。あるいは、申し込み方針は、全ての申し込み者、または発送元が一員である申し込み者の何らかのグループに対して適当な場合もある。

単純な申し込み方針の例には、拒否および許可が含まれる。即ち、コンタクトからの申し込み拒否要求、またはコンタクトからの申し込み許可要求である。本発明の実施形態では、発送元に対する申し込み方針は、受信先と関連のあるMeContactオブジェクト４０６の公認加入者エレメント９０６（図９）が参照するコンタクト・オブジェクト４０２（図４）の１組のインスタンスによって決定する。発送元と関連のあるコンタクト・オブジェクト４０２のインスタンスが、公認加入者エレメント９０６によって参照される組の中にある場合、発送元は許可され、それ以外の場合、発送元は拒否される。

本発明の実施形態では、申し込み方針を更に複雑にすることも可能である。例えば、申し込み方針を更に複雑にすれば、加入者のプレゼンス情報の１つ以上の部分集合に対する申し込みを拒否および／または許可することができる。プレゼンス・オブジェクト６００の総計ステータス６０６（図６）およびリッチ・テキスト記述６０２に対する申し込みを許可すること、ならびに他のプレゼンス・オブジェクト・エレメント６０４、６０８、６１０に対する申し込みを拒否することは、可能な一例である。プレゼンス・オブジェクト・エレメント６０２、６０４、６０６、６０８および６１０、および／またはプレゼンス・オブジェクト・エレメント６０２、６０４、６０６、６０８および６１０が参照するプログラム・オブジェクト４１０、４１２、４１８の、全ての含む、適した部分集合であればいずれでも、申し込み方針および／または申し込みの対象となることができる。

申し込み方針が申し込みメッセージの発送元に対して適当である場合、手順はステップ２１０８に進むことができる。それ以外の場合、手順はステップ２１１０に進むことができる。ステップ２１１０において、申し込みの対象である協調的プレゼンスと関連のある協調的サービス・プラットフォーム３０２（図３）のユーザに、プレゼンス申し込みメッセージの発送元に関する申し込み方針について問い合わせることができる。例えば、公開サービス３０６は、ユーザ・インターフェース（例えば、グラフィカル・ユーザ・インターフェース、即ち、ＧＵＩ）を呈示して、発送元と関連のあるコンタクト情報、ならびに拒否および許可のような申し込み方針選択肢を表示することができる。次いで、ユーザは、ユーザ・インターフェースを用いて、発送元に対する申し込み方針を選択することができる。

ステップ２１１２において、ユーザが選択した申し込み方針を発送元に対して設定することができる。例えば、申し込み方針を、協調的サービス・プラットフォーム３０２のコンタクト管理サービス３０４（図３）を通じて発送元と関連付けることができ、あるいは発送元と関連のあるコンタクト・オブジェクト４０２（図４）に対する参照を、受信先と関連のあるMeContactオブジェクト４０６のインスタンスの公認加入者エレメント９０６（図９）が維持する１組の参照に追加することができる。ステップ２１０８において、確定した発送元に関する申し込み方針を用いて、申し込み方針が申し込みを拒否するか否か判定を行うことができる。申し込み方針が発送元からの申し込みを拒否する場合、手順はステップ２１１４に進むことができる。それ以外の場合、手順はステップ２１１６に進むことができる。

ステップ２１１６において、協調的プレゼンス申し込みを受け入れることができる。例えば、プレゼンス申し込みメッセージによって指定された申し込みは、コンタクト管理サービス３０４（図３）を通じて、受信先と関連のあるMeContactオブジェクト４０６と関連付けることができる。本発明の実施形態では、発送元と関連のあるコンタクト・オブジェクト４０２（図４）のインスタンスを、受信先と関連のあるMeContactオブジェクト４０６のインスタンスのアクティブな加入者エレメント９０８（図９）によって参照されるコンタクト・オブジェクト９０８の１組のインスタンスに追加することによって、プレゼンス申し込みメッセージによって指定された申し込みを受け入れる。許可および拒否よりも申し込みを複雑にする場合、プレゼンス申し込みメッセージによって指定された申し込みは、受け入れる前に、発送元と関連のある申し込み方針に関してフィルタ処理することができる。例えば、申し込みが全てのプレゼンス情報を対象とするが、申し込み方針が申し込みを総計ステータスに制限する場合、総計ステータスに対してのみ、申し込みは受け入れられる。ステップ２１０８および２１１６は、合わせて、申し込み方針にしたがって申し込みが受け入れられることを保証することができる。

ステップ２１１４において、プレゼンス申し込みメッセージの発送元が、受信先のバディ・クラス・コンタクトであるか否か判定を行うことができる。例えば、受信先と関連のあるMeContactオブジェクト９００のバディ・エレメント９０４（図９）によって参照されるコンタクト・オブジェクト４０２（図４）の１組のインスタンスをチェックして、プレゼンス申し込みメッセージの発送元と関連のあるコンタクト・オブジェクト４０２のインスタンスを探すことができる。公開サービス３０６（図３）は、プレゼンス申し込みメッセージの発送元が受信先のバディ・クラス・コンタクトであるか否か、コンタクト管理サービス３０４を用いて判定することができる。プレゼンス申し込みメッセージの発送元が受信先のバディ・クラス・コンタクトである場合、手順はステップ２１１８に進むことができる。それ以外の場合、手順はステップ２１２０に進むことができる。

プレゼンス申し込みメッセージの発送元が受信先のバディ・クラス・コンタクトであると判定した後、プレゼンス申し込みメッセージの受信先が現在発送元のプレゼンスに申し込んでいるか否か判定を行うことができる。例えば、公開サービス３０６（図３）のアプリケーション・プログラミング・インターフェースは、申し込み列挙エレメントを有し、指定されたコンタクトが行った１組の申し込みを列挙することができ、１組の申し込みをチェックして、発送元のプレゼンスに対して行った申し込みを探すことができる。あるいは、または加えて、受信先と関連のあるMeContactオブジェクト４０６（図４）のインスタンスのバディ・エレメント９０４（図９）によって参照されるコンタクト情報は、バディ・クラス・コンタクト毎に、プレゼンスの申し込みがコンタクトによって受け入れられたか否かについての指示を含むことができる。

プレゼンス申し込みメッセージの受信先が現在発送元のプレゼンスに申し込んでいると判定した場合、手順はステップ２１２０に進むことができる。それ以外の場合、受信先はステップ２１２２において発送元のプレゼンスに申し込むことができる。例えば、プレゼンス申し込みメッセージの受信先が以前に、図２０を参照して先に説明した、発送元を探索するステップを実行しているが、発送元がオンラインになっておらず、受信先は、再度探索する前に、ステップ２０１０（図２０）において待っているという場合があり得る。次いで、発送元がオンラインとなり、プレゼンス申し込みメッセージを発送し終えている。待ち続けて、次いで発送元を再度探索するために計算およびネットワーク・リソースを使う代わりに、本発明の実施形態では、受信先が、往復プレゼンス申し込みメッセージを用いて、バディ・クラス・コンタクトからのプレゼンス申し込みメッセージに応答することができる。ステップ２１２２において、ステップ２００８（図２０）について先に説明したように、往復プレゼンス申し込みメッセージをバディ・クラス・コンタクトに送ることができる。

ステップ２１２０において、ステップ２１１６において受け入れたプレゼンス申し込みに応じて、１つ以上のプレゼンス通知メッセージを、プレゼンス申し込みメッセージの発送元に送ることができる。初期のプレゼンス通知メッセージは、受け入れた申し込みと一致する全てのプレゼンス情報、あるいは、例えば、受信先が既に所有することが分かっているプレゼンス情報に対するプレゼンスの１組の相違を収容することもできる。初期プレゼンス通知メッセージに続いて、追加のプレゼンス通知メッセージを送り、協調的プレゼンスの更新を加入者に通知することができる。例えば、特定の協調的サービス・プラットフォーム３０２（図３）のユーザの協調的プレゼンスに対する１つ以上の更新の後に、１つ以上のプレゼンス通知メッセージを公開サービス３０６（図３）に送ることができる。ユーザのプレゼンスに対する申し込み毎に、公開サービス３０６は、プレゼンス通知メッセージが参照するプレゼンス情報の１つ以上の部分集合が申し込みと一致するか否か判定を行うことができる。一致する申し込み毎に、公開サービス３０６はプレゼンス通知メッセージを、申し込みを行った協調的サービス・プラットフォーム３０２のユーザに伝搬することができる。

本文において引用した刊行物、特許出願、特許を含む全ての文献は、各文献が個々にかつ詳細に言及によって含まれるものとすると示しかつその全体が記載されていたのと同じ範囲で、言及により本文に含まれるものとする。

本発明を記載する文脈における用語「a」および「an」ならびに「the」、更には同様の指示物は、この中で特に明記しておらず明らかに文脈と矛盾するのではない限り、単数および複数双方に当てはまるように解釈することとする。「comprising」、「having」、および「containing」は、特に明記しない限り、開放端用語(open-ended terms)（即ち、「含むが限定されない」を意味する）として解釈することとする。この中において値の範囲を詳述する場合、特にこの中で明記しない限り、その範囲に該当する別個の各値に個々に言及する簡略的な伝達方法として供することを意図するに過ぎず、別個の各値は、あたかもそれがこの中で個々に詳述されたかのように、明細書に組み込まれているものとする。この中に記載した全ての方法は、特にこの中で明記しない限り、そして明らかに文脈と矛盾するのではない限り、適した順序であればそのいずれでも実行することができる。この中で与えたいずれの例そして全ての例、または例示的なことば（例えば、「such as」）の使用も、本発明を一層際立たせることを意図するに過ぎず、そうでないことを主張しない限り、本発明の範囲に対する限定を規定するのではない。明細書におけるどの記載も、特許請求しない任意の要素を発明の実施に必須であることを示すものとして解釈すべきでないことは当然である。

本発明の好適な実施形態についてここに説明したが、発明を実施するために発明者に分かっている最良の形態を含んでいる。これらの好適な実施形態の変形は、前述の説明を読めば、当業者には明白となるはずである。発明者は、当業者がこのような変形を適宜採用することを予期し、発明者は、ここに具体的に記載した以外で発明が実用化されることを意図している。したがって、本発明は、適用可能な法律によって許される範囲において、これに添付された特許請求の範囲に明記されている主題の変更物および均等物全てを含むこととする。更に、その可能な全ての変形における前述の要素のいずれの組み合わせも、特にこの中で明記されていない限り、または明らかに文脈と矛盾しない限り、本発明に包含されるものとする。

図１は、本発明の実施形態を実施するために使用可能なコンピュータ・システムの一例を概略的に示す模式図である。図２は、本発明の実施形態を組み込むのに適したネットワーク型計算環境の一例を示す模式図である。図３は、本発明の実施形態による協調サービス・プラットフォームに合ったコンピュータ・ソフトウェア・アーキテクチャの一例を示すブロック図である。図４は、本発明の実施形態による協調オブジェクト・モデルの一例を示すオブジェクト・モデリング図である。図５は、本発明の実施形態によるコンタクト・オブジェクトの一例を示すオブジェクト・インターフェース図である。図６は、本発明の実施形態によるプレゼンス・オブジェクトの一例を示すオブジェクト・インターフェース図である。図７は、本発明の実施形態による公開オブジェクトの一例を示すオブジェクト・インターフェース図である。図８は、本発明の実施形態による能力オブジェクトの一例を示すオブジェクト・インターフェース図である。図９は、本発明の実施形態によるMecontactオブジェクトの一例を示すオブジェクト・インターフェース図である。図１０は、本発明の実施形態による会議オブジェクトの一例を示すオブジェクト・インターフェース図である。図１１は、本発明の実施形態による協調サービス・プラットフォームが実行するステップの一例を示すフローチャートである。図１２は、本発明の実施形態による協調サービス・プラットフォームが実行するステップの別の例を示すフローチャートである。図１３は、本発明の実施形態による招待場面の一例を示す模式図である。図１４は、本発明の実施形態による招待サービス・アプリケーション・プログラミング・インターフェースの一例を示す模式図である。図１５は、本発明の実施形態にしたがって招待を送るステップの一例を示すフローチャートである。図１６は、本発明の実施形態にしたがって招待サービスが招待を送るために実行するステップの一例を示すフローチャートである。図１７は、本発明の実施形態にしたがって招待ユーザ・インターフェースから招待に対して応答するステップの一例を示すフローチャートである。図１８は、本発明の実施形態にしたがって、アプリケーション特定ユーザ・インターフェースから招待に応答するステップの一例を示すフローチャートである。図１９は、本発明の実施形態にしたがって、サーバレス・プレゼンス公開に参加するためのステップの一例を示すフローチャートである。図２０は、本発明の実施形態にしたがって協調的プレゼンス予約を行うためのステップの一例を示すフローチャートである。図２１は、本発明の実施形態にしたがって協調的プレゼンス予約を受け入れるためのステップの一例を示すフローチャートである。

Claims

ユーザが少なくとも１つコンタクトを該ユーザとの協調的な活動へ参加するよう招待するための協調的招待のためのコンピュータ実行可能命令を有するコンピュータ読み取り可能記憶媒体であって、前記協調的招待のためのコンピュータ実行可能命令は、コンピュータにより実行されると、該コンピュータに方法を実行させ、前記方法が、
招待ユーザ・インターフェースが、ユーザの少なくとも１つのコンタクトを含むコンタクト・リストと、ユーザが利用可能な少なくとも１つの協調的活動を含む協調的活動リストとを、ユーザに提供するステップであって、前記招待ユーザ・インターフェースは、前記コンピュータのオペレーティング・システムにより提供され、前記招待ユーザ・インターフェースは、招待の発送を開始するように構成されたグラフィカル・ユーザ・インターフェースを含む、ステップと、
前記招待ユーザ・インターフェースを介してユーザからの、前記コンタクト・リストのうちの少なくとも１つのコンタクトの選択と、前記協調的活動リストのうちの１つの協調的活動の選択とを受けるステップと、
前記招待ユーザ・インターフェースが、選択した前記少なくとも１つのコンタクトがオンラインであるか否かを、前記少なくとも１つのコンタクトのプレゼンス・データに基づいて判定するステップと、
選択した前記少なくとも１つのコンタクトがオンラインであるとき、前記招待ユーザ・インターフェースから、あるいは協調的アプリケーションから直接に、前記少なくとも１つのコンタクトに招待の発送を開始すべきか否かを、パラメータに基づいて判定するステップであって、前記協調的アプリケーションは前記招待ユーザ・インターフェースとは別個であり、前記協調的アプリケーションは前記オペレーティング・システムから起動される、ステップと、
前記招待ユーザ・インターフェースから前記招待の発送を開始すべきであると判定した場合、
前記招待ユーザ・インターフェースが前記少なくとも１つのコンタクトへの前記招待の発送を開始するステップと、
前記協調的アプリケーションから直接に前記招待の発送を開始すべきであると判定した場合、
前記招待の詳細を格納するステップであって、前記招待の詳細が、選択した前記少なくとも１つのコンタクトと、選択した前記協調的活動に関連するデータを含む、ステップと、
前記オペレーティング・システムが、選択した前記協調的活動に関連した前記協調的アプリケーションを起動するステップと、
前記協調的アプリケーションが、格納した前記招待の詳細に基づいて前記少なくとも１つのコンタクトへの前記招待の発送を開始するステップと、
を含む、コンピュータ読み取り可能記憶媒体。
請求項１記載の媒体において、前記招待ユーザ・インターフェースは、招待サービスのグラフィカル・ユーザ・インターフェースであり、前記招待サービスは、招待をコンタクトへ送ることおよび招待をコンタクトから受けることを可能にするように構成された、媒体。