(57)【要約】【課題】  インスタントメッセージングオブジェクトストアの提供。【解決手段】  この方法は、リモートコンピュータ上のユーザに関連する名前を受け取ることを含み、名前はロケーションデータと、ユーザを表すデータオブジェクトに一意に関連するハッシュ値とを含む。方法はさらに、ハッシュ値に基づくローカルキャッシュ、およびロケーションデータによって識別されるロケーションの一方からデータオブジェクトを取り出すことを含む。インスタントメッセージング会話においてユーザを表すオブジェクトを管理するためのシステムは、ユーザを表すデータオブジェクトを含み、データオブジェクトはロケーション識別子とハッシュ値とを含むオブジェクト名を有する。システムはさらに、ロケーション識別子によって識別されるロケーションからデータオブジェクトを取り出し、ハッシュ値に基づいてローカルキャッシュに格納するように働くオブジェクトストアを含む。【選択図】  図１
2005025759.tif 000002
【特許請求の範囲】
【請求項１】
オブジェクトデータを通信するための方法であって、
ローカルコンピュータのユーザを表すオブジェクトデータに基づいてハッシュ値を生成することと、
前記オブジェクトデータをストレージロケーションに格納することと、
前記ハッシュ値と、前記ストレージロケーションを識別するロケーション識別子とを有するオブジェクト名を返すことであって、前記オブジェクト名によってリモートコンピュータのユーザが前記オブジェクトデータにアクセスすることができることと
を備えたことを特徴とする方法。
【請求項２】
前記オブジェクトデータに対する要求であって、前記オブジェクト名を含む前記要求を受け取ることと、
前記オブジェクトデータを前記ハッシュ値に基づいてローカルキャッシュから取り出すことと
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記オブジェクトデータに対する要求であって、前記オブジェクト名を含む前記要求を受け取ることと、
前記要求を受け取ることに応答して、前記ロケーション識別子を使用して前記オブジェクトデータを前記ロケーションから取り出すことと
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記オブジェクトデータに対する要求であって、前記オブジェクト名を含む前記要求を受け取ることと、
前記要求オブジェクトデータがローカルキャッシュにあるかどうかを前記ハッシュ値に基づいて判定することと、
前記要求されたオブジェクトデータが前記ローカルキャッシュにある場合、前記ローカルキャッシュから前記オブジェクトデータを取り出すことと、
そうでない場合、前記ロケーション識別子によって識別される前記ロケーションから前記要求されたオブジェクトデータを取り出すことと
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項５】
前記ロケーション識別子によって識別される前記ロケーションから前記要求されたオブジェクトデータを取り出すことは、
前記要求されたオブジェクトデータをネットワークストレージから取り出すこと
を備えることを特徴とする請求項４に記載の方法。
【請求項６】
前記ロケーション識別子によって識別される前記ロケーションから前記要求されたオブジェクトデータを取り出すことは、
前記要求されたオブジェクトデータをローカルファイルシステムから取り出すこと
を備えることを特徴とする請求項４に記載の方法。
【請求項７】
前記ロケーション識別子によって識別される前記ロケーションから前記要求されたオブジェクトデータを取り出すことは、
前記要求されたオブジェクトデータをリモートファイルシステムから取り出すこと
を備えることを特徴とする請求項４に記載の方法。
【請求項８】
前記要求されたオブジェクトデータをリモートファイルシステムから取り出すことは、
ピアツーピア接続を介して前記リモートファイルシステムにアクセスすること
を備えることを特徴とする請求項７に記載の方法。
【請求項９】
前記要求されたオブジェクトデータをリモートファイルシステムから取り出すことは、
スイッチボードサーバを通した接続を介して前記リモートファイルシステムにアクセスすること
を備えることを特徴とする請求項７に記載の方法。
【請求項１０】
方法を実行するためのコンピュータ実行可能命令を格納したコンピュータ可読媒体であって、前記方法は、
リモートコンピュータ上のユーザに関連付けられた名前であって、ロケーションデータと、前記ユーザを表すデータオブジェクトに一意に関連付けられたハッシュ値とを含む前記名前を受け取ることと、
前記ハッシュ値に基づくローカルキャッシュまたは前記ロケーションデータによって識別されるロケーションの一方から前記データオブジェクトを取り出すことと
を備えたことを特徴とするコンピュータ可読媒体。
【請求項１１】
前記ハッシュ値に基づくローカルキャッシュまたは前記ロケーションデータによって識別されるロケーションの一方から前記データオブジェクトを取り出すことは、
前記データオブジェクトがローカルキャッシュにあるかどうかを前記ハッシュ値に基づいて判定することと、
前記データオブジェクトが前記ローカルキャッシュにある場合、前記ローカルキャッシュから前記データオブジェクトを取り出すことと、
そうでない場合、前記ロケーションデータによって識別される前記ロケーションから前記データオブジェクトを取り出すことと
を備えたことを特徴とする請求項１０に記載のコンピュータ可読媒体。
【請求項１２】
前記ロケーションデータによって識別される前記ロケーションから前記データオブジェクトを取り出すことは、前記データオブジェクトをリモートファイルシステムから取り出すことを備えたことを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１３】
前記ロケーションデータによって識別される前記ロケーションから前記データオブジェクトを取り出すことは、前記データオブジェクトをローカルファイルシステムから取り出すことを備えたことを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１４】
前記ロケーションデータによって識別される前記ロケーションから前記データオブジェクトを取り出すことは、前記データオブジェクトをネットワークストレージから取り出すことを備えたことを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１５】
前記ロケーションデータによって識別される前記ロケーションから前記データオブジェクトを取り出すことは、ピアツーピア接続を介してリモートコンピュータにアクセスすることを備えたことを特徴とする請求項１１に記載のコンピュータ可読媒体。
【請求項１６】
インスタントメッセージング会話においてユーザを表すオブジェクトを管理するためのシステムであって、
ユーザを表すデータオブジェクトであって、ロケーション識別子およびハッシュ値を含むオブジェクト名を有する前記データオブジェクトと、
前記ロケーション識別子によって識別されるロケーションから前記データオブジェクトを取り出し、前記データオブジェクトを前記ハッシュ値に基づいてローカルキャッシュに格納するように働くオブジェクトストアを備えたことを特徴とするシステム。
【請求項１７】
前記オブジェクト名は、前記データオブジェクトの作成者を識別する作成者識別子をさらに備えたことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記オブジェクトストアがピアツーピア接続を介してリモートストレージロケーションから前記データオブジェクトを取り出すことを可能にするトランスポートプロトコルスタックをさらに備えたことを特徴とする請求項１６に記載のシステム。
【請求項１９】
前記データオブジェクトは、前記データオブジェクトを記述するメタデータをさらに備えたことを特徴とする請求項１６に記載のシステム。
【請求項２０】
前記メタデータは、
フレンドリ名フィールドと、
データオブジェクトのタイプを示すタイプフィールドと、
前記メタデータに基づくハッシュ値と
を備えたことを特徴とする請求項１９に記載のシステム。
【請求項２１】
前記ロケーション識別子は、ユニフォームリソースロケータ（ＵＲＬ）を備えたことを特徴とする請求項１６に記載のシステム。
【請求項２２】
前記ロケーション識別子は、ユニフォームリソース識別子（ＵＲＩ）を備えたことを特徴とする請求項１６に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本記載の内容はコンピュータ通信に関する。より詳細には、本内容はインスタントメッセージングのためのオブジェクトストアに関する。
【背景技術】
【０００２】
インスタントメッセージングは、コンピュータデバイスのユーザに非常に人気のある通信ツールになりつつある。インスタントメッセージング（ＩＭ）アプリケーション（例えば、米国ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ  ＣｏｒｐｏｒａｔｉｏｎのＷＩＮＤＯＷＳ（登録商標）Ｍｅｓｓｅｎｇｅｒシステム、Ｙａｈｏｏ！  Ｍｅｓｓｅｎｇｅｒ、ＡＯＬインスタントメッセンジャー（ＡＩＭ）など）により、ユーザは、ユーザの連絡先のプライベートリストで特定される１人または複数の連絡先と、リアルタイムの会話をすることができる。通常、プライベートリストはスイッチボード（ｓｗｉｔｃｈｂｏａｒｄ）、あるいは中継サーバ（ｒｅｌａｙ  ｓｅｒｖｅｒ）などのサーバに保管されており、このサーバを介して通信が確立される。次いで、スイッチボードサーバは、インバウンドメッセージを適切な受信者にルーティングする。
【０００３】
インスタントメッセージングシステムの進歩に伴い、これらのシステムは、インスタントメッセージングの会話をより豊かな体験にするフィーチャ（ｆｅａｔｕｒｅ）をより多く提供することができる。このようなフィーチャは、テキストに加えて、様々なタイプのデータオブジェクト上でも機能する。例えば、カスタムユーザタイル（ｔｉｌｅ）フィーチャにより、ユーザが、ユーザを別のユーザのコンピュータ上で一意に表すカスタムユーザタイルを生成し、送信することができる。このようなフィーチャオブジェクトを送信するには通常、受信側に対してエラーなしで表示されるように、テキストの場合よりも広い帯域幅が必要である。さらに、会話中にユーザを表すオブジェクトは、通常、このようなオブジェクトがアクセスされる頻度に比べて、それほど頻繁に変化しないであろう。
【０００４】
【特許文献１】米国特許出願第１０／６１１，５７５号明細書
【非特許文献１】Donald E. Eastlake, III, and Paul E. Jones, 「US Secure Hash Algorithm 1 (SHA1)」, Request for Comments 3174 (RFC 3174), The Internet Society, September, 2001
【非特許文献２】Federal Information Processing Standards Publication (FIPS PUB) 180-2, August 1, 2002
【発明の開示】
【発明が解決しようとする課題】
【０００５】
残念ながら、従来のインスタントメッセージングアプリケーションは、このようなオブジェクトをみだりに変更するのを防止しつつフィーチャオブジェクトを効率的に管理するためのメカニズムを提供していない。例えば、ユーザが単純に自身の固有のカスタムユーザタイルを第２のユーザに送信する場合、第２のユーザは、第１のユーザのタイルを変更して、タイルがもはや第１のユーザの望むような仕方で第１のユーザを表していないように変更することができる。
【課題を解決するための手段】
【０００６】
前述の問題および他の問題を解決する例示的な実装形態について述べる。
【０００７】
１つの実装形態は、オブジェクトデータを通信するための方法を含む。この方法は、リモートコンピュータ上のユーザに関連する名前であって、ロケーションデータと、ユーザを表すデータオブジェクトに一意に関連するハッシュ値とを含む名前を受け取り、ハッシュ値に基づくローカルキャッシュおよびロケーションデータにより識別されるロケーションのうちの一方からデータオブジェクトを取り出すことによって行われる。
【０００８】
別の実装形態は、インスタントメッセージングの会話においてユーザを表すオブジェクトを管理するためのシステムを含む。このシステムは、ユーザを表すデータオブジェクトを含み、データオブジェクトは、ロケーション識別子とハッシュ値とを含むオブジェクト名を有する。システムはさらに、ロケーション識別子により識別されるロケーションからデータオブジェクトを取り出し、データオブジェクトをハッシュ値に基づいてローカルキャッシュに格納するように働くオブジェクトストアを備える。
【発明を実施するための最良の形態】
【０００９】
図面に移ると、同様の参照番号は同様の要素を表しており、様々な方法が適したコンピューティング環境において実施されるものとして示されている。必須ではないが、様々な例示的な方法について、プログラムモジュールなど、パーソナルコンピュータおよび／またはその他のコンピューティングデバイスによって実行されるコンピュータ実行可能命令の一般的なコンテキストで述べることにする。一般にプログラムモジュールは、特定のタスクを実行するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、様々な例示的な方法は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなど、その他のコンピュータシステム構成で実施されうることは、当業者なら理解するであろう。また、様々な例示的な方法は、通信ネットワークを介してリンクされるリモート処理デバイスによってタスクが実行される分散コンピューティング環境において実施することもできる。分散コンピューティング環境では、プログラムモジュールは、ローカルとリモートの両方のメモリストレージデバイスにロケーションすることができる。
【００１０】
本明細書のいくつかの図面では、様々なアルゴリズム動作を個々の「ブロック」に要約している。このようなブロックは、プロセスの進行に伴って為されるか、または行われる特定の動作または決定を記述する。マイクロコントローラ（または均等物）が採用される場合、本明細書に提示したフローチャートは、そのようなマイクロコントローラ（または均等物）によって所望の制御を達成するために使用することのできる「制御プログラム」またはソフトウェア／ファームウェアのための基礎を提供する。このように、プロセスは、プロセッサによって実行されるとき、ブロックとして示された様々な動作を実行する、メモリに記憶可能なマシン可読命令として実装される。
【００１１】
当業者であれば、本明細書に提示したフローチャートおよびその他の記述に基づいて、このような制御プログラムを容易に書くことができるであろう。本明細書に記載の内容は、後述の動作を実行するようにプログラムされる場合のデバイスおよび／またはシステムを含むだけでなく、マイクロコントローラをプログラムするように構成されるソフトウェア、さらに、そのようなソフトウェアが具体化される可能性のあるすべてのあらゆるコンピュータ可読媒体を含むことが理解され、認識されるべきである。このようなコンピュータ可読媒体の例には、限定しないが、フロッピー（登録商標）ディスク、ハードディスク、ＣＤ、ＲＡＭ、ＲＯＭ、フラッシュメモリなどが含まれる。
【００１２】
（概観）
インスタントメッセージングシステムにおいてオブジェクトを管理するための例示的な方法、システム、およびデバイスを開示する。一般に、オブジェクトストアは、一度書き込み、何度も読み出す（ｗｒｉｔｅ−ｏｎｃｅ，ｒｅａｄ−ｍａｎｙ）オブジェクトストレージおよび取り出しシステムを提供し、この場合オブジェクトは不変である。オブジェクトストアは、フィーチャアプリケーションがオブジェクト名を使用してオブジェクトを格納または取り出すことができるインターフェースを提供する。オブジェクトストアは、オブジェクトデータをエンコードして固有の識別子を生成する。この識別子を介して、オブジェクトストアは、ローカルキャッシュからのオブジェクト、または複数のロケーションのうちの１つからのオブジェクトにアクセスすることができる。オブジェクトは、ローカルまたはリモートに格納することができる。オブジェクトストアは、オブジェクト名をデコードして、ロケーション情報および／または作成者情報を入手して、ローカルまたはリモートのストレージからオブジェクトを取り出すことができる。
【００１３】
（インスタントメッセージングのシナリオにおいてオブジェクトを格納するための例示的なシステム）
図１に、インスタントメッセージングの会話のための例示的なネットワーク環境１００を示す。一般に、２つのクライアント１０２および１０４は、ネットワーク１０６を介して、または直接接続１０８を介して直接、相互に通信することができる。スイッチボードサーバ１１０は、ネットワーク１０６経由のクライアント（１）１０２およびクライアント（２）１０４の間の通信を容易にする。クライアント（１）１０２および／またはクライアント（２）１０４は、スイッチボードサーバ１１０に接続してインスタントメッセージングセッションを確立することができる。直接接続１０８を使用すると、データはスイッチボードサーバ１１０を介してルーティングする必要はなく、むしろクライアント（１）１０２およびクライアント（２）１０４の間でピアツーピア方式でデータを通信することができる。
【００１４】
インスタントメッセージング（ＩＭ）プラットフォーム１１２は、クライアント（１）１０２およびクライアント（２）１０４がインスタントメッセージングの会話を行うことができるようにする。ＩＭプラットフォーム１１２のユーザは、ユーザインターフェース（図示せず）を介してＩＭプラットフォーム１１２とやりとりし、メッセージおよび他のデータをクライアント（２）１０４との間で送受信する。ＩＭプラットフォーム１１２は、１つまたは複数のフィーチャ１１４（エンドユーザフィーチャ（ＥＵＦ）とも呼ばれる）と、オブジェクトストア１１６と、オブジェクトキャッシュマネージャ１１８と、トランスポートプロトコルスタック１２０とを含む。トランスポートプロトコルスタック１２０は、アプリケーションプログラミングインターフェース（ＡＰＩ）１２２を提供するが、このＡＰＩにより、フィーチャ１１４やオブジェクトストア１１６などの上位機能は、トランスポートプロトコルスタック１２０中の機能を使用してデータを送受信することができる。
【００１５】
一般に、トランスポートプロトコルスタック１２０およびトランスポートＡＰＩ１２２は、クライアント（１）１０２がネットワーク１０６を介して、そして／またはピアツーピア方式で直接接続１０８を介して、クライアント（２）１０４と通信するための手段を提供する。トランスポートプロトコルスタック１２０は、フィーチャ１１４およびオブジェクトストア１１６に関係するデータを含むインスタントメッセージングデータを通信するために必要な接続を確立する。トランスポートプロトコルスタック１２０およびトランスポートＡＰＩ１２２の例示的な実装形態は、特許文献１にさらなる詳細が記載されている。
【００１６】
フィーチャ１１４は、フィーチャ１１４に関連するデータを提示するためにＩＭアプリケーション１１２によってまたはアプリケーション１１２内でホストされるか、または実行される機能またはアプリケーションである。フィーチャ１１４は、フィーチャ１１４が提示するデータのタイプ、データの提示方法、フィーチャ１１４がデータ上で行うことができる操作、および／または、データとやりとりするためにフィーチャ１１４がユーザに提供するインタラクティブオプションによって特徴付けることができる。例えば、カスタムユーザタイルフィーチャ１１４は、ユーザインターフェース上のスクリーンタイルに画像データを提示し、ファイル転送フィーチャ１１４は、ユーザがファイルを選択しインスタントメッセージングの連絡先にファイル送信できるようにする。限定ではなく例として、フィーチャ１１４には、カスタム感情アイコン（ｅｍｏｔｉｃｏｎ）、インク、埋め込み画像、およびその他のアプリケーションが含まれうる。
【００１７】
フィーチャ１１４は、インスタントメッセージング会話中にオブジェクトを使用して、データを提示する。オブジェクトは、オブジェクトストア１１６によって管理される。オブジェクトストア１１６は、インスタントメッセージングにおいて使用されるデータオブジェクトを格納し、アクセスし、そうでなければ管理するための方法およびデータを提供する。例えば、オブジェクトストア１１６がカスタム感情アイコンフィーチャ１１４によって使用されて、クライアント（２）１０４からのカスタム感情アイコンをクライアント（１）１０２で表示することができる。後でさらに詳細に論じるが、オブジェクトストア１１６は、オブジェクトに関連する識別子データをハッシュするなど、データを暗号化することによって、データセキュリティの度合いを提供することができる。
【００１８】
クライアントコンピュータ（１）１０２は、ファイルシステム１２４およびキャッシュ１２６を含む。オブジェクトは、ファイルシステム１２４およびキャッシュ１２６の両方に格納することができる。ファイルシステム１２４は、クライアントコンピュータ（１）１０２内のファイルをカタログ化するための標準的なコンピュータファイルシステムである。キャッシュ１２６は、ハードディスクもしくはフロッピー（登録商標）ディスク、および／またはランダムアクセスメモリ（ＲＡＭ）などのメモリを含む。オブジェクトキャッシュマネージャ１１８は、キャッシュ１２６中のオブジェクトを管理する。
【００１９】
オブジェクトキャッシュマネージャ１１８の１つの実装形態では、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＣｏｒｐｏｒａｔｉｏｎからのＩｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ（登録商標）によって使用されるキャッシュであるＷｉｎＩＮＥＴ（登録商標）キャッシュを使用する。この実装形態では、オブジェクトがウェブアドレス（例えばユニフォームリソースロケータ（ＵＲＬ））から取り出されると、ＷｉｎＩＮＥＴ（登録商標）は、自動的にオブジェクトをＷｉｎＩＮＥＴ（登録商標）キャッシュに書き込むことになる。オブジェクトがＵＲＬロケーション以外のロケーションから取り出される場合は、オブジェクトキャッシュマネージャ１１８は、トランスポートプロトコルスタック１２０がオブジェクトを取り出すことを要求することになり、オブジェクトキャッシュマネージャ１１８がオブジェクトをＷｉｎＩＮＥＴ（登録商標）キャッシュに書き込む。
【００２０】
ネットワーク１０６はストレージ１２８を含み、ストレージ１２８もまた、クライアント１０２および１０４によって使用できるオブジェクトデータを保持することができる。クライアント（１）１０２は、ネットワーク１０６を介して、ネットワークストレージ１２８にアクセスしてオブジェクトを取り出すことができる。クライアント（１）１０２上のオブジェクトはクライアント（２）１０４によって取り出し、使用することができ、またその逆もできる。後でより詳細に論じるが、オブジェクトストア１１６は、要求されたオブジェクトがどこにあるか決定し、決定したロケーションからオブジェクトを取り出すことにより、オブジェクトに対する要求を処理する。したがって図１に示すように、オブジェクトストア１１６は、オブジェクトがローカルキャッシュ１２６、ローカルファイルシステム１２４、ネットワークストレージ１２８、および／またはリモートクライアント（２）１０４にあると判定することができる。
【００２１】
図示していないが、クライアント（１）１０２上に含まれたモジュールと類似したモジュールが、クライアント（２）１０４にも含まれている。それゆえ、クライアント（２）１０４は、メッセンジャープラットフォーム、フィーチャ、オブジェクトストア、オブジェクトキャッシュマネージャ、トランスポートプロトコルスタック、ファイルシステム、およびキャッシュメモリを含む。
【００２２】
図１の例示的な環境１００には会話中の２つのクライアント１０２および１０４のみが示されているが、３つ以上のクライアントが会話に関与していてもよいことを理解されたい。２つ以上のクライアントはマルチポイント方式で通信することができ、各クライアントは他の２つ以上のクライアントへの接続（例えばピアツーピアまたはサーバ経由）を有することができる。ネットワーク環境１００で採用することのできる例示的な動作およびシステムについて、以下により詳細な説明を提供する。
【００２３】
図２に、オブジェクト管理を提供するためにメッセンジャープラットフォーム（例えば図１のＩＭプラットフォーム１１２）中でインスタンス化することのできる例示的なクラスを有するクラス図２００を示す。１つのクラスは、クライアントコンピュータ（例えば図１のクライアント（１）１０２）上のオブジェクトストア（例えば図１のオブジェクトストア１１６）を表すＯｂｊｅｃｔＳｔｏｒｅクラス２０２である。ＯｂｊｅｃｔＳｔｏｒｅクラス２０２は、格納されたオブジェクトを表すＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４を使用する。タイプ列挙子（ｔｙｐｅ  ｅｎｕｍｅｒａｔｏｒ）２０６は、オブジェクトの１つまたは複数のタイプを定義する。オブジェクト指向ソフトウェア設計、および図２のクラス図２００などのクラス図設計は、当業者にはよく知られているであろう。
【００２４】
メッセンジャーアプリケーション（例えば図１のＩＭプラットフォーム１１２）中のフィーチャ（例えば図１のフィーチャ１１４）は、ＯｂｊｅｃｔＳｔｏｒｅクラス２０２（またはＯｂｊｅｃｔＳｔｏｒｅクラス２０２のインスタンス）とインターフェースして、ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンスを格納および取り出す。特定の一実装形態では、ＯｂｊｅｃｔＳｔｏｒｅクラス２０２は静的なシングルトンである。すなわち、実行されている可能性のあるすべてのフィーチャからの要求を処理するのに、ＯｂｊｅｃｔＳｔｏｒｅクラス２０２のインスタンスが１つだけ生成される。
【００２５】
例示的なオブジェクトタイプを、ＳｔｏｒｅｄＯｂｊｅｃｔＴｙｐｅＥｎｕｍ２０６中に提供する。図示のように、図２の特定の実装形態では、列挙されたタイプは、カスタム感情アイコン、ユーザタイル、バックグラウンド、アバター、共有ファイルである。これらのタイプは、ユーザが作成することができる、ユーザを表すオブジェクトを参照することができる。ユーザは、カスタム感情アイコン、アバター、ユーザタイルなど、ユーザに固有のオブジェクトを作成することができる。
【００２６】
図２に示すように、ＯｂｊｅｃｔＳｔｏｒｅクラス２０２は３つの関数、ＧｅｔＯｂｊｅｃｔ（ＳｔｏｒｅｄＯｂｊｅｃｔ）、ＳｔｏｒｅＯｂｊｅｃｔ（ＳｔｏｒｅｄＯｂｊｅｃｔ）、ＤｅｌｅｔｅＯｂｊｅｃｔ（ＳｔｏｒｅｄＯｂｊｅｃｔ）を提供している。関数名が示すとおり、フィーチャは、ＧｅｔＯｂｊｅｃｔ関数を呼び出すことによって格納されたオブジェクトを取り出すことができ、ＳｔｏｒｅＯｂｊｅｃｔ関数を呼び出すことによってオブジェクトを格納することができ、ＤｅｌｅｔｅＯｂｊｅｃｔ関数を呼び出すことによってオブジェクトを削除することができる。関数のそれぞれは、タイプＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のパラメータを含む。
【００２７】
ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４は、データのオブジェクトを参照する。オブジェクト中のデータは、任意のサイズまたはタイプのデータの任意のバイナリラージオブジェクト（ＢＬＯＢ）で構成される。ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンスは、そのインスタンスが参照するオブジェクトデータと共に格納される必要はない。例えば、クライアント（１）１０２（図１）は、ネットワークストレージ１２８（図１）に格納されるか、またはクライアント（２）１０４（図１）など他のクライアントに格納されているオブジェクトデータを参照するＳｔｏｒｅｄＯｂｊｅｃｔ２０４のインスタンスを有することがある。オブジェクトデータの実際のロケーションは、ＯｂｊｅｃｔＳｔｏｒｅクラス２０２およびＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンスを使用するフィーチャにはトランスペアレントである。
【００２８】
ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４は、オブジェクトデータを記述するオブジェクトメタデータ２０８を含む。例示的なメタデータ２０８は、Ｎａｍｅフィールド、Ｔｙｐｅフィールド、ＦｒｉｅｎｄｌｙＮａｍｅフィールド、Ｈａｓｈ１フィールド、Ｈａｓｈ２フィールド、Ｃｒｅａｔｏｒフィールド、Ｌｏｃａｔｉｏｎフィールドを含む。Ｎａｍｅは、オブジェクトを識別する文字列である。１つの実施形態では、Ｎａｍｅフィールドは、１つまたは複数のメタデータ２０８フィールドの組合せである。Ｔｙｐｅフィールドは、オブジェクトのタイプを指定するＳｔｏｒｅｄＯｂｊｅｃｔＴｙｐｅＥｎｕｍ２０６中のタイプの１つである。ＦｒｉｅｎｄｌｙＮａｍｅフィールドは、ユーザがオブジェクトに与えることのできるユーザに可読の名前である。
【００２９】
１つの実施形態では、Ｈａｓｈ１フィールドは、オブジェクトデータに一意に関連付けられた値を有し、キャッシュ中でオブジェクトデータを突き止めるのに使用することができる。Ｈａｓｈ１値は、ＳＨＡ１（Ｓｅｃｕｒｅ  Ｈａｓｈ  Ａｌｇｏｒｉｔｍ  １）などの暗号ハッシング関数を使用して生成される。ＳＨＡ１関数は、入力としてオブジェクトデータを取ってＨａｓｈ１値を生成する。ＳＨＡ１関数の呼出しシグニチャ（ｃａｌｌｉｎｇ  ｓｉｇｎａｔｕｒｅ）の例はＳＨＡ１（Ｄａｔａ）であり、Ｄａｔａは、格納されるべきオブジェクトデータを参照する。
【００３０】
ＳＨＡ１は、オブジェクトデータの「凝縮された表現」を計算するためのアルゴリズムである。「凝縮された表現」は、固定長であり、「メッセージダイジェスト」または「フィンガプリント」として知られている。Ｈａｓｈ１フィールドの一般的な固定長の１つは１６０ビットであり、この長さにより、Ｈａｓｈ１値があらゆるオブジェクトにとって固有となることがほぼ保証される。Ｈａｓｈ１値が固有であることにより、Ｈａｓｈ１値は、オブジェクトデータの「フィンガプリント」として働き、データ保全性（ｄａｔａ  ｉｎｔｅｇｒｉｔｙ）を確実にし、データ比較チェックを可能にすることができる。例えば、オブジェクトデータがダウンロードされるとき、Ｈａｓｈ１値を計算し、前のＨａｓｈ１値と比較して、オブジェクトデータが改変されていないことを保証することができる。また、Ｈａｓｈ１値をキャッシュ中への索引として使用して、前に格納されたオブジェクトデータを突き止めることもできる。
【００３１】
Ｈａｓｈ１値は、Ｒｏｎａｌｄ  Ｌ．Ｒｉｖｅｓｔ教授によって開発されたＭＤ５（Ｍｅｓｓａｇｅ  Ｄｉｇｅｓｔ  Ａｌｇｏｒｉｔｈｍ  ５）など、その他の知られているアルゴリズムを使用して計算することもできる。ＭＤ５、ＳＨＡ１、または同様のアルゴリズムを使用すると、Ｈａｓｈ１値は不可逆であり、Ｈａｓｈ１値からオブジェクトデータを生成することはできない。ＳＨＡやＭＤなどのハッシングアルゴリズムまたはメッセージダイジェストアルゴリズムを実施するためのリソースは、当業者には容易に入手可能である。ＳＨＡ１アルゴリズムの特定の一実装形態に関する詳細が非特許文献１で入手可能である。また、非特許文献２は、セキュアハッシュ規格について規定している。
【００３２】
Ｈａｓｈ２フィールドは、メタデータフィールド（すなわちＣｒｅａｔｏｒフィールド、Ｔｙｐｅフィールド、ＦｒｉｅｎｄｌｙＮａｍｅフィールド、Ｌｏｃａｔｉｏｎフィールド、Ｈａｓｈ１フィールド）が、上述したＳＨＡ１関数などのハッシュ関数に入力されるときに得られるハッシュ値である。
【００３３】
ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のＣｒｅａｔｏｒフィールドは、オブジェクトを作成したユーザ、ピア、またはクライアントを表す。Ｃｒｅａｔｏｒフィールドは、作成者の名前、ｅメールアドレス、またはオブジェクトの作成者を指定するその他の任意の識別子を有する文字列とすることができる。ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のＬｏｃａｔｉｏｎフィールドは、オブジェクトデータのロケーションを指定する。図２に示すように、ロケーションはユニフォームリソースロケータ（ＵＲＬ）によって提供される。一般に知られているように、ＵＲＬは、ウェブ上またはその他の任意のネットワーク機構上のデータへのルートを定義するアドレスである。以下により詳細に論じるが、ＯｂｊｅｃｔＳｔｏｒｅクラス２０２は、ＣｒｅａｔｏｒフィールドおよびＬｏｃａｔｉｏｎフィールドを使用してオブジェクトデータを取り出すことができる。
【００３４】
例示的なＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンスは、多重定義関数（ｏｖｅｒｌｏａｄｅｄ  ｆｕｎｃｔｉｏｎ）である「Ｃｒｅａｔｅ」関数を提供し、これにより、様々なタイプの格納されたオブジェクトを作成することができる。このように、Ｃｒｅａｔｅ関数がＩＤと共に呼び出されると、そのＩＤを有するオブジェクトが作成され、Ｃｒｅａｔｅ関数がＦｉｌｅハンドルと共に呼び出されると、参照されたＦｉｌｅを使用してオブジェクトが作成され、以下同様である。
【００３５】
ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンスは、「ＧｅｔＤａｔａ（）」関数を有する。ＧｅｔＤａｔａ（）関数が呼び出されると、ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンスによって参照されるオブジェクトデータが返される。このように、フィーチャがオブジェクトを提示する必要があるとき、フィーチャは、データが感情アイコン、アバター、ユーザタイル、ファイル、バックグラウンド、またはその他のどれを定義しているか、ＧｅｔＤａｔａ（）を呼び出して実際のデータを得ることができる。
【００３６】
（オブジェクトストアを使用してオブジェクトを格納および取り出すための例示的な動作）
図３に、図１のオブジェクトストア１１６および／または図２のＯｂｊｅｃｔＳｔｏｒｅクラス２０２などのオブジェクトストアを使用してオブジェクトを作成し、このオブジェクトを格納するための例示的な動作を有するオブジェクト格納動作フロー３００を示す。１つのシナリオでは、フィーチャが、ＯｂｊｅｃｔＳｔｏｒｅクラス２０２およびＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンスとやりとりして、オブジェクトを作成および格納する。フィーチャは、オブジェクトストアからオブジェクト名を受け取るが、これは後でオブジェクトを取り出すのに使用することができる。
【００３７】
開始動作３０２の後、作成動作３０４によりオブジェクトが作成される。作成動作３０４の１つの実装形態では、ＳｔｏｒｅｄＯｂｊｅｃｔクラス２０４のインスタンス（図２）が作成される。格納すべきデータを参照して共にＣｒｅａｔｅ（）関数に対して呼び出しが行われる。例えば、ユーザはカスタム感情アイコンフィーチャを使用して、カスタム感情アイコンタイプのＳｔｏｒｅｄＯｂｊｅｃｔを作成することができる。カスタム感情アイコンフィーチャは、カスタム感情アイコンを参照してＣｒｅａｔｅ（）関数を呼び出す。
【００３８】
計算動作３０６で、ＳｔｏｒｅｄＯｂｊｅｃｔ（作成動作３０４で作成したもの）に関連するデータに対応する第１のハッシュ値を計算する。計算動作３０６で、ＳｔｏｒｅｄＯｂｊｅｃｔ中のメタデータフィールドに基づいて第２のハッシュ値を計算することがある。ハッシュ値を計算するための様々なリソースおよびアルゴリズムは前述のとおりであり、ここでは繰り返さない。格納動作３０８で、オブジェクトデータをローカルキャッシュに格納する。オブジェクトデータは、第１のハッシュ値に対応するキャッシュ中のロケーションに格納され、それゆえ、このオブジェクトデータはキャッシュから後で容易に取り出すことができる。
【００３９】
設定動作３１０で、ＳｔｏｒｅｄＯｂｊｅｃｔのメタデータにフィールド（図２のメタデータフィールドを参照）を設定する。オブジェクトメタデータのＣｒｅａｔｏｒフィールドおよびＬｏｃａｔｉｏｎフィールドは、ユーザログイン設定に基づいて設定することができる。Ｔｙｐｅフィールドは、格納されたオブジェクトデータのタイプに設定される。ＦｒｉｅｎｄｌｙＮａｍｅは、ユーザによって指定することができる。Ｈａｓｈ１フィールドおよびＨａｓｈ２フィールドは、計算動作３０６で計算された第１のハッシュ値および第２のハッシュ値にそれぞれ設定される。
【００４０】
返し動作３１２で、オブジェクト名を返す。オブジェクト名は、設定動作３１０で設定されたメタデータ中の１つまたは複数のフィールドの連結である。１つの実装形態では、返されるオブジェクト名は、ＣｒｅａｔｏｒフィールドおよびＬｏｃａｔｉｏｎフィールドを含む。ＣｒｅａｔｏｒフィールドおよびＬｏｃａｔｉｏｎフィールドにより、ＯｂｊｅｃｔＳｔｏｒｅは、必要ならローカルキャッシュ以外のロケーションからオブジェクトデータを後で取り出すことができるようになる。
【００４１】
返し動作３１２で返される名前は、ユニフォームリソース識別子（ＵＲＩ）やユニフォームリソース名（ＵＲＮ）など、指定のフォーマットとすることができる。ＵＲＩは、画像、テキスト、ビデオ、オーディオ、プログラムを含め、インターネット上のいかなる種類のリソースでも識別することのできるキャラクタ文字列である。ＵＲＩの一般的なバージョンの１つは、ユニフォームリソースロケータ（ＵＲＬ）である。ＵＲＮは、オブジェクトについて永続的で、グローバルに固有の名前であるように定義される。以下に、例示的なＵＲＩおよびＵＲＮを示す。
ＵＲＩ：／／［Ｃｒｅａｔｏｒ］／［Ｔｙｐｅ］／［Ｈａｓｈ1］／［Ｈａｓｈ２］？ｆｎ＝［ＦｒｉｅｎｄｌｙＮａｍｅ］＆ＵＲＬ＝［Ｌｏｃａｔｉｏｎ］；
ＵＲＮ：［Ｔｙｐｅ］：［Ｃｒｅａｔｏｒ］：［ＦｒｉｅｎｄｌｙＮａｍｅ］：［Ｌｏｃａｔｉｏｎ］：［Ｈａｓｈ１］：［Ｈａｓｈ２］
【００４２】
図４は、コンピュータネットワーク上の様々なロケーションのいずれかに格納される可能性のあるオブジェクトを取り出すための例示的な動作を有するオブジェクト取り出し動作フロー４００である。図１に関して論じたように、オブジェクトおよびオブジェクトデータは、ローカルキャッシュ、ローカルファイルシステム、ネットワークストレージ（例えばネットワークサーバ上のディスク）、および／または、リモートクライアントやピアコンピュータに格納することができる。動作フロー４００は、オブジェクトに対する要求に対して、オブジェクトがどこにロケーションするかを決定し、次いでそのロケーションからオブジェクトを取り出すことによって応答する。
【００４３】
要求動作４０２で、返し動作３１０（図３）で返されたオブジェクト名などのオブジェクト名を使用して、オブジェクトデータを要求する。要求動作４０２により、リモートクライアントコンピュータまたはネットワークサーバから得られるオブジェクト名を渡すことができる。オブジェクト名は、要求されたオブジェクトのロケーションを指定するロケーション情報（例えばＵＲＬ、または図２のＳｔｏｒｅｄＯｂｊｅｃｔ２０４中のＬｏｃａｔｉｏｎフィールド）を含むものと想定されている。また、オブジェクト名は、要求されたオブジェクトに一意に関係するハッシュ値も含む。要求動作４０２には、ＯｂｊｅｃｔＳｔｏｒｅ２０２（図２）のＧｅｔＯｂｊｅｃｔ（）関数を呼び出すことを伴うことがある。
【００４４】
照会動作４０４で、要求されたオブジェクトがローカルキャッシュにあるかどうかを判定する。照会動作４０４の１つの実装形態では、入力Ｎａｍｅ中のＨａｓｈ１値を使用して、オブジェクトがローカルキャッシュにあるかどうかを判定する。Ｈａｓｈ１値は、ＳｔｏｒｅｄＯｂｊｅｃｔに関連するデータのハッシュである。このように、Ｈａｓｈ１は、取り出されるオブジェクトデータだけに基づいており、オブジェクトに関連する他のいかなるＮａｍｅデータからも独立している。Ｈａｓｈ１値はキャッシュ中への固有の索引なので、Ｈａｓｈ１値を使用して、Ｈａｓｈ１値に関連するデータがローカルキャッシュに格納されているかどうかを判定することができる。要求されたオブジェクトがローカルキャッシュにあると判定された場合、オブジェクト取り出し動作４００は「ＹＥＳ」に分岐して、取り出し動作４０６に進む。取り出し動作４０６で、Ｈａｓｈ値を使用して、ローカルキャッシュ中に索引し、オブジェクトデータを取り出す。
【００４５】
オブジェクトに初めてアクセスする場合、オブジェクトデータがローカルキャッシュにないことがある。要求されたオブジェクトがローカルキャッシュにないと判定された場合、オブジェクト取り出し動作４００は「ＮＯ」に分岐して、取り出し動作４０８に進む。取り出し動作４０８で、ローカルキャッシュ以外のロケーションから要求されたオブジェクトを取り出す。このロケーションは、入力Ｎａｍｅ中のＬｏｃａｔｉｏｎフィールドによって指定される。以下に、どのようにＬｏｃａｔｉｏｎフィールドを使用してローカルキャッシュ以外のロケーションから要求されたオブジェクトを取り出すかを示すいくつかのシナリオを提示する。
【００４６】
ローカルキャッシュ以外のロケーションから要求されたオブジェクトを取り出した後、格納動作４１０で、オブジェクトをローカルキャッシュに格納する。要求されたオブジェクトをローカルキャッシュから取り出した後、または要求されたオブジェクトをローカルキャッシュに格納した後、返し動作４１２で要求されたオブジェクトを返す。
【００４７】
（例示的なオブジェクト取り出しシナリオ）
図５に、要求されたオブジェクトデータがローカルファイルシステムに位置する場合の例示的なオブジェクト取り出しシナリオ５００を示す。フィーチャ５０２が、オブジェクト名をオブジェクトストア５０４に渡すことによって、オブジェクトストア５０４からのオブジェクトデータを要求する。オブジェクトストア５０４は、要求されたオブジェクトがローカルキャッシュ５０６にあるかどうかを判定する。シナリオ５００では、要求されたオブジェクトがローカルキャッシュ５０６中で見つからないと想定している。オブジェクトストア５０４は、オブジェクト名をパース（ｐａｒｓｅ）して、要求されたオブジェクトデータのロケーションを判定する。シナリオ５００では、オブジェクト名の中のロケーションデータがローカルファイルシステム５０８のようにそのロケーションを指定している。
【００４８】
このように、ローカルファイルシステム５０８にアクセスして要求オブジェクトデータを取り出す。次いで、要求オブジェクトデータをローカルキャッシュ５０６に格納し、要求元フィーチャ５０２に返す。したがって理解されるように、例示的なシナリオ５００は完全に、単一のクライアントにおいて行われる。
【００４９】
図６に、要求されたオブジェクトデータがネットワークストレージデバイス上にロケーションする場合の別の例示的なオブジェクト取り出しシナリオ６００を示す。フィーチャ６０２は、ハッシュ値とロケーション情報とを有するオブジェクト名を渡すことによって、オブジェクトストア６０４からのオブジェクトデータを要求する。オブジェクトストア６０４は、要求されたオブジェクトデータのハッシュ値を使用して、要求されたオブジェクトがローカルキャッシュ６０６にあるかどうかを判定する。この例示的なシナリオでは、要求されたオブジェクトがローカルキャッシュ６０６にないと想定している。オブジェクトストア６０４は、要求されたオブジェクトがネットワーク６０８上のロケーションに格納されていることをロケーション情報から判定する
このロケーションは、ネットワークストレージ６１０を指定するＵＲＬによって与えられる。要求されたオブジェクトをネットワークストレージ６１０から取り出す。その後、要求されたオブジェクトをローカルキャッシュ６０６に格納し、要求元フィーチャ６０２に返す。
【００５０】
図７に、要求されたオブジェクトがピアコンピュータに位置する場合の別の例示的なオブジェクト取り出しシナリオ７００を示す。クライアント１であるクライアント上で稼動しているフィーチャ７０２が、ハッシュ値とロケーション情報とを有するオブジェクト名を渡すことによって、オブジェクトストア７０４からのオブジェクトデータを要求する。オブジェクトストア７０４は、要求されたオブジェクトデータがローカルキャッシュ７０６にないと判定する。オブジェクトストア７０４は、オブジェクト名をパースすることによって、クライアント２であるクライアントコンピュータに要求されたオブジェクトがあると判定する。
【００５１】
クライアント２から要求されたオブジェクトデータを取り出すために、要求がトランスポートプロトコルスタック７０８に送られる。トランスポートプロトコルスタック７０８は、クライアント２上のトランスポートプロトコルスタック７１０へのピアツーピア接続を利用する。クライアント２上のトランスポートプロトコルスタック７１０に、オブジェクトデータの要求を送信する。トランスポートプロトコルスタック７１０は、クライアント２上のリモートオブジェクトストア７１２にコールバックを発行する。リモートオブジェクトストア７１２は、クライアント２上のリモートファイルシステム７１４から要求されたオブジェクトデータを取り出す。
【００５２】
その後、トランスポートプロトコルスタック７０８および７１０を介して、要求されたオブジェクトデータをクライアント２からクライアント１に送信する。クライアント１で、要求されたオブジェクトデータをローカルキャッシュ７０６に格納する。このように、今後のこのオブジェクトデータに対する要求は、ピアツーピア要求に頼ることなくローカルキャッシュ７０６から容易に満たされる。次いで、要求されたオブジェクトデータを要求元フィーチャ７０２に返す。
【００５３】
（例示的な動作環境）
図８および対応する考察は、オブジェクトを格納および取り出すための前述の配置構成および手順を実施することのできる、適したコンピューティング環境の一般的な記述を提供するものである。例示的なコンピューティング環境８２０は、適したコンピューティング環境の一例に過ぎず、この記載内容の使用または機能の範囲についていかなる制限を示唆するものではない。また、コンピューティング環境８２０は、この例示的なコンピューティング環境８２０に示したコンポーネントのいずれか１つまたは組合せに関していかなる依存性や要件を有するものとも解釈すべきではない。
【００５４】
ネットワーク環境でオブジェクトを管理するための例示的な配置構成および手順は、その他多くの汎用または専用のコンピューティングシステム環境または構成でも機能する。記載の内容と共に使用するのに適する可能性のある周知のコンピューティングシステム、環境、および／または構成の例には、これらに限定されないが、パーソナルコンピュータ、サーバコンピュータ、シンクライアント、シッククライアント、ハンドヘルドもしくはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、メインフレームコンピュータ、これらのシステムもしくはデバイスのいずれかを含むサーバファームや企業イントラネットなどの分散コンピューティング環境が含まれる。
【００５５】
コンピューティング環境８２０は、コンピュータ８３０の形の汎用コンピューティングデバイスを含む。コンピュータ８３０は、前述のオブジェクトストアの例示的な一実装形態を含み、そして／またはその働きをすることがある。コンピュータ８３０のコンポーネントには、これらに限定されないが、１つまたは複数のプロセッサまたは処理ユニット８３２、システムメモリ８３４、およびシステムメモリ８３４を含む様々なシステムコンポーネントをプロセッサ８３２に結合するバス８３６が含まれうる。
【００５６】
バス８３６は、様々なバスアーキテクチャのいずれかを用いた、メモリバスもしくはメモリコントローラ、周辺バス、ＡＧＰ（ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ）、プロセッサもしくはローカルバスを含む、いくつかのタイプのバス構造のいずれかの１つまたは複数を表す。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バス（メザニンバスとも呼ばれる）が含まれる。
【００５７】
通常、コンピュータ８３０は様々なコンピュータ可読媒体を含む。このような媒体は、コンピュータ８３０によってアクセス可能な任意の利用可能な媒体とすることができ、揮発性および不揮発性、取外し可および取外し不可の両方の媒体が含まれる。
【００５８】
システムメモリは、ランダムアクセスメモリ（ＲＡＭ）８４０などの揮発性メモリ、および／または読取り専用メモリ（ＲＯＭ）８３８などの不揮発性メモリの形のコンピュータ可読媒体を含む。起動中などにコンピュータ８３０内の要素間で情報の通信を助ける基本ルーチンが入っているＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）８４２は、ＲＯＭ８３８に格納されている。ＲＡＭ８４０は、通常、プロセッサ８３２によってすぐにアクセス可能な、そして／または現在操作されているデータおよび／またはプログラムモジュールを収容している。
【００５９】
コンピュータ８３０は、その他の取外し可／取外し不可、揮発性／不揮発性コンピュータ記憶媒体をさらに備えることもある。例に過ぎないが図８には、取外し不可の不揮発性の磁気媒体（図示していないが通常「ハードドライブ」と呼ばれる）に対して読み書きするためのハードディスクドライブ８４４と、取外し可の不揮発性の磁気ディスク８４８（例えば「フロッピー（登録商標）ディスク」）に対して読み書きするための磁気ディスクドライブ８４６と、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、その他の光媒体など、取外し可の不揮発性の光ディスク８５２に対して読み書きするための光ディスクドライブ８５０を示している。ハードディスクドライブ８４４、磁気ディスクドライブ８４６、光ディスクドライブ８５０はそれぞれ、１つまたは複数のインターフェース８５４によってバス８３６に接続される。
【００６０】
これらのドライブおよび関連するコンピュータ可読媒体は、コンピュータ８３０のコンピュータ可読命令、データ構造、プログラムモジュール、その他のデータの不揮発性記憶を提供する。本明細書に記載のこの例示的な環境はハードディスク、取外し可の磁気ディスク８４８、取外し可の光ディスク８５２を採用しているが、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）など、コンピュータによってアクセス可能なデータを格納することのできる他のタイプのコンピュータ可読媒体をこの例示的な動作環境で使用することができることが当業者には理解されるはずである。
【００６１】
限定ではなく例として、オペレーティングシステム８５８、１つまたは複数のアプリケーションプログラム８６０、その他のプログラムモジュール８６２、プログラムデータ８６４を含むいくつかのプログラムモジュールがハードディスク、磁気ディスク８４８、光ディスク８５２、ＲＯＭ８３８、またはＲＡＭ８４０に格納することができる。アプリケーションプログラム８６０は、本明細書に記載のフィーチャアプリケーションを備えるインスタントメッセージングプログラム、オブジェクトストア、およびトランスポートプロトコルスタックを含むことができる。
【００６２】
ユーザは、キーボード８６６やポインティングデバイス８６８（「マウス」など）などオプションの入力デバイスを介して、コンピュータ８３０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星アンテナ、シリアルポート、スキャナなどを含めることができる。これらおよび他の入力デバイスは、バス８３６に結合されているユーザ入力インターフェース８７０を介して処理ユニット８３２に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（「ＵＳＢ」）など、その他のインターフェースおよびバス構造によって接続されてもよい。
【００６３】
オプションのモニタ８７２または他のタイプの表示デバイスが、ビデオアダプタ８７４などのインターフェースを介してバス８３６に接続される。モニタに加えて、パーソナルコンピュータは通常、スピーカやプリンタなど他の周辺出力デバイス（図示せず）を含み、これらは出力周辺インターフェース８７５を介して接続することができる。
【００６４】
コンピュータ８３０は、リモートコンピュータ８８２など、１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ８８２は、コンピュータ８３０に関して本明細書に記載した要素および特徴の多くまたはすべてを含むことができる。図８に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）８７７および一般的なワイドエリアネットワーク（ＷＡＮ）８７９である。ＬＡＮ８７７および／またはＷＡＮ８７９は、有線ネットワーク、無線ネットワーク、または有線もしくは無線ネットワークの任意の組合せとすることができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、インターネットでよくみられるものである。
【００６５】
ＬＡＮネットワーキング環境で使用されるとき、コンピュータ８３０は、ネットワークインターフェースまたはアダプタ８８６を介してＬＡＮ８７７に接続される。ＷＡＮネットワーキング環境で使用されるとき、コンピュータ８３０は通常、ＷＡＮ８７９を介して通信を確立するためのモデム８７８または他の手段を含む。モデム８７８は、内蔵でも外付けでもよく、ユーザ入力インターフェース８７０または他の適切なメカニズムを介してシステムバス８３６に接続することができる。図８には、インターネットを介した特定の実装形態のＷＡＮが示されている。コンピュータ８３０は通常、インターネット８８０を介して通信を確立するためのモデム８７８または他の手段を含む。モデム８７８は、インターフェース８７０を介してバス８３６に接続される。
【００６６】
ネットワーク化された環境では、パーソナルコンピュータ８３０に関して示したプログラムモジュールまたはその一部をリモートのメモリストレージデバイスに格納することができる。限定ではなく例として、図８には、リモートアプリケーションプログラム８８９をリモートコンピュータ８８２のメモリデバイス上にあるものとして示している。図示および記述したネットワーク接続は例示的なものであり、コンピュータ間で通信リンクを確立するための他の手段を使用することもできることが理解されるであろう。
【００６７】
（結び）
記載の配置構成、手順、およびコンポーネントを構造上の特徴および／または方法上の動作に特有の言葉で述べたが、添付の特許請求の範囲に規定された内容は、記載の具体的な特徴または動作に必ずしも限定されないことを理解されたい。そうではなく、これらの具体的な特徴および動作は、請求項に記載の本内容を実施する好ましい形態として開示されている。
【図面の簡単な説明】
【００６８】
【図１】オブジェクトストアを利用したインスタントメッセージング会話のための例示的なネットワーク環境を示す図である。
【図２】オブジェクト管理のためのオブジェクトストアを提供するためにメッセンジャープラットフォームにおいてインスタンス化することのできる例示的なクラスを有するクラス図である。
【図３】オブジェクトを作成し、オブジェクトストアを使用してそのオブジェクトを格納するための例示的な動作を有するオブジェクト格納動作フローを示す図である。
【図４】インスタントメッセージングにおける使用のためにコンピュータネットワーク上の様々なロケーションのいずれかに格納されている可能性のあるオブジェクトを取り出すための例示的な動作を示すフローチャートである。
【図５】要求されたオブジェクトデータがローカルファイルシステムに位置する場合の例示的なオブジェクト取り出しシナリオ５００を示す図である。
【図６】要求されたオブジェクトデータがネットワークストレージデバイス上に位置する場合の別の例示的なオブジェクト取り出しシナリオ６００を示す図である。
【図７】要求されたオブジェクトデータがピアコンピュータに位置する場合の別の例示的なオブジェクト取り出しシナリオ７００を示す図である。
【図８】フィーチャオブジェクトを管理するためにオブジェクトストアを使用してインスタントメッセージング会話を行うのに適した動作環境を提供する例示的なシステムを示す図である。
【符号の説明】
【００６９】
１００  ネットワーク環境
１０２  クライアントコンピュータ（１）
１０４  クライアントコンピュータ（２）
１０６  ネットワーク
１０８  直接接続
１１０  スイッチボードサーバ
１１２  インスタントメッセージングプラットフォーム
１１４  フィーチャ（Ａ）．．．フィーチャ（Ｎ）
１１６  オブジェクトストア
１１８  オブジェクトキャッシュマネージャ
１２０  トランスポートプロトコルスタック
１２２  トランスポートＡＰＩ
１２４  ファイルシステム
１２６  キャッシュ
１２８  ストレージ
５００  オブジェクト取り出しシナリオ
５０２  フィーチャ
５０４  オブジェクトストア
５０６  キャッシュ
５０８  ファイルシステム
６００  オブジェクト取り出しシナリオ
６０２  フィーチャ
６０４  オブジェクトストア
６０６  キャッシュ
６０８  ネットワーク
６１０  ストレージ
７００  オブジェクト取り出しシナリオ
７０２  フィーチャ
７０４  オブジェクトストア
７０６  ローカルキャッシュ
７０８  トランスポートプロトコルスタック
７１０  トランスポートプロトコルスタック
７１２  オブジェクトストア
７１４  リモートファイルシステム
【図１】
2005025759.tif 000003
【図２】
2005025759.tif 000004
【図３】
2005025759.tif 000005
【図４】
2005025759.tif 000006
【図５】
2005025759.tif 000007
【図６】
2005025759.tif 000008
【図７】
2005025759.tif 000009
【図８】
2005025759.tif 000010