(57)【要約】パブリッシュ−サブスクライブ環境におけるオブジェクトのための解決法が説明される。オブジェクト決定ユニット（２２）が、オブジェクトに対するオブジェクト識別子を決定し（１０）、受信者決定ユニット（２３）が、オブジェクトを操作することになる受信者に対する受信者識別子を決定する（１１）。次いで、少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求が、パブリッシュ−サブスクライブ環境に出力される（１２）。オブジェクト要求の受信者は、オブジェクトの操作が必要とされるかどうかを確認し（３１）、必要に応じてオブジェクトを操作する（３２）。
2016514870.tif 000002
【特許請求の範囲】
【請求項１】
オブジェクトの操作を要求するための方法であって、
前記オブジェクトに対するオブジェクト識別子を決定するステップ（１０）と、
前記オブジェクトを操作することになる受信者に対する受信者識別子を決定するステップ（１１）と、
少なくとも前記オブジェクト識別子および前記受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境に出力するステップ（１２）と、
を含む、前記方法。
【請求項２】
前記オブジェクトの操作は、前記オブジェクトの作成、前記オブジェクトの修正、前記オブジェクトの削除、および前記オブジェクトの移動のうちの１つを含む、請求項１に記載の方法。
【請求項３】
前記オブジェクト要求は、前記オブジェクトの名前および前記オブジェクトの特性をさらに含む、請求項１または２に記載の方法。
【請求項４】
オブジェクトの操作を要求するように構成された装置（２０）であって、
前記オブジェクトに対するオブジェクト識別子を決定する（１０）ように構成されたオブジェクト決定ユニット（２２）と、
前記オブジェクトを操作することになる受信者に対する受信者識別子を決定する（１１）ように構成された受信者決定ユニット（２３）と、
少なくとも前記オブジェクト識別子および前記受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境に出力する（１２）ように構成された出力部（２４）と、
を備える、前記装置。
【請求項５】
前記オブジェクトの操作は、前記オブジェクトの作成、前記オブジェクトの修正、前記オブジェクトの削除、および前記オブジェクトの移動のうちの１つを含む、請求項４に記載の装置（２０）。
【請求項６】
前記オブジェクト要求は、前記オブジェクトの名前および前記オブジェクトの特性をさらに含む、請求項４または５に記載の装置（２０）。
【請求項７】
オブジェクトの操作の要求を可能にする命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、コンピュータによって実行されたとき、前記コンピュータに、
前記オブジェクトに対するオブジェクト識別子を決定させ（１０）、
前記オブジェクトを操作することになる受信者に対する受信者識別子を決定させ（１１）、
少なくとも前記オブジェクト識別子および前記受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境に出力させる（１２）、
前記コンピュータ可読記憶媒体。
【請求項８】
前記オブジェクトの操作は、前記オブジェクトの作成、前記オブジェクトの修正、前記オブジェクトの削除、および前記オブジェクトの移動のうちの１つを含む、請求項７に記載のコンピュータ可読記憶媒体。
【請求項９】
前記オブジェクト要求は、前記オブジェクトの名前および前記オブジェクトの特性をさらに含む、請求項７または８に記載のコンピュータ可読記憶媒体。
【請求項１０】
オブジェクトを操作するための方法であって、
少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境から受け取るステップ（３０）と、
前記オブジェクト要求を受け取るステップ（３０）に応答して、オブジェクトの操作が必要とされるかどうかを確認するステップ（３１）と、
必要に応じて前記オブジェクトを操作するステップ（３２）と、
を含む、前記方法。
【請求項１１】
前記オブジェクトの操作は、前記オブジェクトの作成、前記オブジェクトの修正、前記オブジェクトの削除、および前記オブジェクトの移動のうちの１つを含む、請求項１０に記載の方法。
【請求項１２】
オブジェクトを操作するように構成された装置（４０）であって、
少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境から受け取る（３０）ように構成された入力部（４１）と、
前記オブジェクト要求を受け取ること（３０）に応答して、オブジェクトの操作が必要とされるかどうかを確認する（３１）ように構成された評価ユニット（４２）と、
必要に応じて前記オブジェクトを操作する（３２）ように構成された操作ユニット（４３）と、
を備える、前記装置。
【請求項１３】
前記オブジェクトの操作は、前記オブジェクトの作成、前記オブジェクトの修正、前記オブジェクトの削除、および前記オブジェクトの移動のうちの１つを含む、請求項１２に記載の装置（４０）。
【請求項１４】
オブジェクトの操作を可能にする命令を記憶したコンピュータ可読記憶媒体であって、前記命令は、コンピュータによって実行されたとき、前記コンピュータに、
少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境から受け取らせ（３０）、
前記オブジェクト要求を受け取ること（３０）に応答して、オブジェクトの操作が必要とされるかどうかを確認させ（３１）、
必要に応じて前記オブジェクトを操作させる（３２）、
前記コンピュータ可読記憶媒体。
【請求項１５】
前記オブジェクトの操作は、前記オブジェクトの作成、前記オブジェクトの修正、前記オブジェクトの削除、および前記オブジェクトの移動のうちの１つを含む、請求項１４に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オブジェクトライフサイクル管理のための解決法に関する。より詳細には、本発明は、パブリッシュ−サブスクライブ環境におけるオブジェクトライフサイクル管理のための解決法に関する。
【背景技術】
【０００２】
ソフトウェアアーキテクチャドメインにおいて、パブリッシュ−サブスクライブ（publish-subscribe：Ｐ／Ｓ）は、パブリッシャ（publisher）と呼ばれるメッセージの送信者が、メッセージをサブスクライバ（subscriber）と呼ばれる特定の受信者に直接送られるようにプログラムしないメッセージングパターンである。むしろ、パブリッシュされたデータは、（存在する場合）どのようなサブスクライバが存在するかに関する知識なしに、マルチキャストされる。同様に、サブスクライバは、特定のデータをサブスクライブし、（存在する場合）どのようなパブリッシャが存在するかに関する知識なしに、関心のあるメッセージのみを受け取る。
【０００３】
例示的Ｐ／Ｓフレームワークが図１に示されている。Ｐ／Ｓエンティティに加えて、Ｐ／Ｓトピック間の関係、およびアプリケーションによって使用されるようなオブジェクトインスタンスが図示されている。図１ではＤＤＳの用語（ＤＤＳ：データ配信サービス）が使用されていることに留意されたい。
【０００４】
パブリッシャからサブスクライバへのパブリッシュアクションは、それらがリンクされたオブジェクトすなわちトピックインスタンスが、たとえば、何らかの方法でそれをハンドリングするアプリケーション、または変更された環境に起因して、変更を受ける場合にある。
【０００５】
上述のＰ／Ｓ環境では、オブジェクトのハンドリング、特にオブジェクトライフサイクル、の問題がある。
【０００６】
以下のオブジェクトライフサイクルメソッドが考えられる。  
・オブジェクトを作成する（create）、
・オブジェクトを更新する（update）、
・オブジェクトを削除する（delete）、
・オブジェクトを別のコンテキストへ移動する（move）、すなわち、あるコンテキストでオブジェクトを削除し、同じオブジェクトを別のコンテキストに作成する、
・可能であれば、上記のメソッドの組合せを同時に実行する、たとえば、オブジェクトの移動および更新を組み合わせて行う。
【０００７】
実際、Ｐ／Ｓ環境はデータ指向であるが、上記のアクションはむしろメソッド指向である。さらに、メソッドは、オブジェクトに対してそれが作成されない限り作用することができない。別の問題は、メソッドを発行するエンティティ（役割）と、メソッドを実行するエンティティ（役割）とがあるべきことである。
【発明の概要】
【０００８】
本発明の目的は、パブリッシュ−サブスクライブ環境におけるオブジェクトを操作するための改良された解決法を提案することである。
【０００９】
本発明の１つの態様によると、オブジェクトの操作を要求するための方法は、
上記オブジェクトに対するオブジェクト識別子を決定するステップと、
上記オブジェクトを操作することになる受信者に対する受信者識別子を決定するステップと、少なくとも上記オブジェクト識別子および上記受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境に出力するステップと、
を含む。
【００１０】
したがって、オブジェクトの操作を要求するように構成された装置は、
上記オブジェクトに対するオブジェクト識別子を決定するように構成されたオブジェクト決定ユニットと、
上記オブジェクトを操作することになる受信者に対する受信者識別子を決定するように構成された受信者決定ユニットと、
少なくとも上記オブジェクト識別子および上記受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境に出力するように構成された出力部と、
を備える。
【００１１】
同様に、コンピュータ可読記憶媒体は、オブジェクトの操作の要求を可能にする命令を記憶しており、命令は、コンピュータによって実行されたとき、上記コンピュータに、
上記オブジェクトに対するオブジェクト識別子を決定させ、
上記オブジェクトを操作することになる受信者に対する受信者識別子を決定させ、
少なくとも上記オブジェクト識別子および上記受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境に出力させる。
【００１２】
好ましくは、上記オブジェクト要求は、上記オブジェクトの名前および上記オブジェクトの特性をさらに含む。
【００１３】
本発明のさらなる態様によると、オブジェクトを操作するための方法は、
少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境から受け取るステップと、
上記オブジェクト要求を受け取るステップに応答して、オブジェクトの操作が必要とされるかどうかを確認するステップと、
必要に応じて上記オブジェクトを操作するステップと、
を含む。
【００１４】
したがって、オブジェクトを操作するように構成された装置は、
少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境から受け取るように構成された入力部と、
上記オブジェクト要求を受け取ることに応答して、オブジェクトの操作が必要とされるかどうかを確認するように構成された評価ユニットと、
必要に応じて上記オブジェクトを操作するように構成された操作ユニットと、
を備える。
【００１５】
同様に、コンピュータ可読記憶媒体は、オブジェクトの操作の要求を可能にする命令を記憶しており、上記命令は、コンピュータによって実行されたとき、上記コンピュータに、
少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境から受け取らせ、
上記オブジェクト要求を受け取ることに応答して、オブジェクトの操作が必要とされるかどうかを確認させ、
必要に応じて上記オブジェクトを操作させる。
【００１６】
本発明は、Ｐ／Ｓ環境におけるオブジェクトライフサイクルのためのフレームワークを説明する。それは、そのフレームワークにおける関係付けられた役割を定義し、すべてのオブジェクトライフサイクル方法を実行するための一要求機構を定義する。より詳細には、２つの役割、すなわち、方法を発行するオブジェクトマネージャ（Object Manager）の役割、および方法を実行するオブジェクトプロバイダ（Object Provider）の役割が説明される。ＣＲＥＡＴＥ（作成）、ＵＰＤＡＴＥ（更新）、ＤＥＬＥＴＥ（削除）、およびＭＯＶＥ（移動）方法が、単一のＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴ（オブジェクト要求）方法に一体化される。
【００１７】
フレームワークは、オブジェクトマネージャが、それ自体の制御された環境でそれが管理しないがオブジェクトプロバイダによって制御される環境で管理するオブジェクトを、制御または管理することを可能にする。
【００１８】
提案される解決法は、動的オブジェクト作成およびハンドリングを要求する環境でのデータ指向制御システムにおけるオブジェクトライフサイクル管理のための方法を使用することを可能にする。１つのみの方法を用いて、完全なオブジェクトライフサイクルをなすことができ、したがって、解決法は非常に単純である。同時に、提案される解決法はフレームワークを説明する。このようなものとして、それは、動的オブジェクトハンドリングを要求する多くの異なるアプリケーションのために再使用され得る。それは、単に、一般的オブジェクトライフサイクルの役割を、特定のアプリケーションによって提供される特定の関数にマッピングする問題である。
【００１９】
本発明をより良く理解するために、ここで図面を参照してより詳細に説明する。本発明はこの例示的実施形態に制限されず、また、添付の特許請求の範囲に規定される本発明の範囲から逸脱することなく、特定された態様が便宜的に組み合わせられおよび／または修正されてもよいことは理解されよう。
【図面の簡単な説明】
【００２０】
【図１】例示的Ｐ／Ｓフレームワークを概略的に示す図である。
【図２】オブジェクトの操作を要求するための本発明による方法を示す図である。
【図３】図２の方法を実行するように構成された装置を概略的に示す図である。
【図４】オブジェクトを操作するための本発明による方法を示す図である。
【図５】図４の方法を実行するように構成された装置を概略的に示す図である。
【図６】オブジェクトマネージャおよびオブジェクトプロバイダを有する本発明によるＰ／Ｓフレームワークを示す図である。
【図７】オブジェクトマネージャからオブジェクトプロバイダへのＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴの転送を示す図である。
【図８】本発明によるオブジェクトハンドリング機構の概略を示す図である。
【図９】提案されたオブジェクトライフサイクル管理を使用して実現されるＣＲＥＡＴＥアクションを示す図である。
【図１０】提案されたオブジェクトライフサイクル管理を使用して実現されるＵＰＤＡＴＥアクションを示す図である。
【図１１】提案されたオブジェクトライフサイクル管理を使用して実現されるＭＯＶＥアクションを示す図である。
【図１２】提案されたオブジェクトライフサイクル管理を使用して実現されるＤＥＬＥＴＥアクションを示す図である。
【発明を実施するための形態】
【００２１】
図２は、オブジェクトの操作を要求するための本発明による方法を示す。第１のステップで、オブジェクトに対するオブジェクト識別子が決定される［１０］。また、オブジェクトを操作することになる受信者に対する受信者識別子が決定される［１１］。次いで、少なくとも決定されたオブジェクト識別子および受信者識別がオブジェクト要求に含められ、オブジェクト要求がパブリッシュ−サブスクライブ環境に出力される［１２］。意図された操作によっては、オブジェクト要求は、オブジェクトの名前およびオブジェクトの特性をさらに含む。
【００２２】
図２の方法を実行するように構成された装置２０が、図３に概略的に示されている。装置２０は、オブジェクトの操作の要求を開始するための要求を受け取るための入力部２１を備える。入力部２１は、たとえば、ユーザインターフェースまたはアプリケーションである。オブジェクト決定ユニット２２が、オブジェクトに対するオブジェクト識別子を決定し［１０］、受信者決定ユニット２３が、オブジェクトを操作することになる受信者に対する受信者識別子を決定する［１１］。次いで、決定されたオブジェクト識別子および受信者識別は、必要とされる場合はさらなるデータと共に、オブジェクト要求に含められ、オブジェクト要求は、出力部２４を介してパブリッシュ−サブスクライブ環境に出力される［１２］。もちろん、装置２０の異なる要素が、同様のやり方で、単一のユニットに組み合わされてもよく、またはプロセッサ上で動作するソフトウェアとして実装されてもよい。
【００２３】
図４は、オブジェクトを操作するための本発明による方法を示す。少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求が、パブリッシュ−サブスクライブ環境から受け取られる［３０］。オブジェクト要求を受け取ること［３０］に応答して、オブジェクト要求の受信者が、オブジェクトの操作が必要とされるかどうかを確認する［３１］。この場合には、オブジェクトは必要に応じて操作される［３２］。
【００２４】
図４の方法を実行するように構成された装置４０が、図５に概略的に示されている。装置４０は、少なくともオブジェクト識別子および受信者識別子を含むオブジェクト要求を、パブリッシュ−サブスクライブ環境から受け取る［３０］ように構成された入力部４１を備える。評価ユニット４２は、オブジェクト要求を受け取ること［３０］に応答して、オブジェクトの操作が必要とされるかどうかを確認する［３１］。この場合には、操作ユニット４３は、必要に応じてオブジェクトを操作する［３２］。該当する場合、操作されたオブジェクトは、出力部４４を介してパブリッシュ−サブスクライブ環境に出力される。もちろん、装置４０の異なる要素が、同様のやり方で、単一のユニットに組み合わされてもよく、またはプロセッサ上で動作するソフトウェアとして実装されてもよい。
【００２５】
本発明によるＰ／Ｓオブジェクトライフサイクルフレームワークは、動的に作成、修正、削除、および移動されたオブジェクトがＰ／Ｓ環境においてどのようにハンドリングされるかを説明する。図６に示されるように、フレームワークは２つの役割を見越している。オブジェクトマネージャは、ライフサイクル要求をオブジェクトプロバイダに送る役割を果たす。オブジェクトプロバイダは、要求に応答して、特定のオブジェクトについて要求されたアクション、すなわち、作成、修正、削除、または移動を実行する。オブジェクトプロバイダは、オブジェクトのコンテナであり、オブジェクトマネージャの要求に応じてオブジェクトのライフサイクルをハンドリングする。複数のオブジェクトマネージャが、複数のオブジェクトプロバイダに要求を発行してもよい。また、複数のオブジェクトプロバイダが、複数のオブジェクトマネージャから要求を受け取ってもよい。
【００２６】
通常、オブジェクトマネージャは、ユーザインターフェースを介してユーザによって制御されるアプリケーションであり、これは、デバイス上に配置されたデータまたはデバイス上のアプリケーション内のデータに作用する。オブジェクトプロバイダは、アプリケーションもしくはデバイス内の制御ユニット、またはデバイスそれ自体であり、一組のオブジェクトをグループ化および制御する。オブジェクトプロバイダは、オブジェクトマネージャの要求のあったときに動作する。異なるオブジェクトプロバイダが互いの存在の知識を有することは必ずしも必要とされない。それらは互いに独立している。
【００２７】
どのようなオブジェクトがあり得るかについていくつかの例を与えると、ノートハンドリングアプリケーション（「付箋（sticky note）」）では、オブジェクトは、任意の特定の時間に利用可能な異なるノートである。ドキュメントハンドリングアプリケーションでは、オブジェクトは、異なるドキュメントの表現である。マルチメディアアプリケーションでは、オブジェクトは、アプリケーションによって制御されるメディアエンドポイントである。
【００２８】
以下では、すべてのオブジェクトライフサイクルメソッドを表す単一オブジェクトライフサイクル要求が、図７を参照して説明される。この要求の例示的フォーマットは、次の通りである。
【００２９】
ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴ（Ｏｂｊｅｃｔ＿ＩＤ，Ｏｂｊｅｃｔ＿Ｐｒｏｖｉｄｅｒ＿ＩＤ，Ｎａｍｅ，パラメータ（値））
オブジェクトは、「トピック（topic）」名およびＯｂｊｅｃｔ＿ＩＤ（オブジェクトＩＤ）によって識別される。特定のオブジェクトの特性は、値を有する、オブジェクトに関係付けられたパラメータによって記述される。Ｐ／Ｓドメイン内で、Ｏｂｊｅｃｔ＿ＩＤ番号およびＯｂｊｅｃｔ＿Ｐｒｏｖｉｄｅｒ＿ＩＤ（オブジェクトプロバイダＩＤ）番号は一意である。
【００３０】
たとえば、オブジェクトがノートである場合、各ノートは、番号またはタイトルである名前を有し、特性は、寸法、フォント、最大の文字などとすることができる。
【００３１】
Ｐ／Ｓ環境において、ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴは、Ｏｂｊｅｃｔ／Ｔｏｐｉｃそれ自体として考えられ、そのパラメータ値は、オブジェクトマネージャが値を変更したときにパブリッシュされる。ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴをサブスクライブしているすべてのオブジェクトプロバイダが、要求を受け取る。指定されたオブジェクトプロバイダのみが、要求に応じてアクションを行う。
【００３２】
種々のライフサイクルアクションを求めるオブジェクトライフサイクル要求の使用は、以下の通りである。
ＣＲＥＡＴＥ
ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴ（Ｏｂｊｅｃｔ＿ＩＤ＝ｊ，Ｏｂｊｅｃｔ＿Ｐｒｏｖｉｄｅｒ＿ＩＤ＝ｐ，Ｎａｍｅ＝ｎ，パラメータ＝値）
Ｏｂｊｅｃｔ＿ＩＤ  ｊは、（オブジェクトプロバイダのいずれにおいても）存在しないものである。オブジェクトプロバイダｐは、要求に対する応答としてそのエリア内にオブジェクトを作成する。ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴにおける値は、オブジェクトのパラメータに割り当てられる。
ＤＥＬＥＴＥ
ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴ（Ｏｂｊｅｃｔ＿ＩＤ＝ｊ，Ｏｂｊｅｃｔ＿Ｐｒｏｖｉｄｅｒ＿ＩＤ＝ｖｏｉｄ）
オブジェクトプロバイダｐは、それがオブジェクトｊをそのエリア内に有することを知っている。オブジェクトプロバイダｐは、要求に対する応答としてオブジェクトｊを削除する。
ＵＰＤＡＴＥ
ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴ（Ｏｂｊｅｃｔ＿ＩＤ＝ｊ，Ｏｂｊｅｃｔ＿Ｐｒｏｖｉｄｅｒ＿ＩＤ＝ｐ，Ｎａｍｅ＝ｎ，パラメータ＝他の値）
オブジェクトプロバイダｐは、それがオブジェクトｊをそのエリアに有することを知っている。オブジェクトプロバイダｐは、指示された新しい値を用いて要求に対する応答としてオブジェクトｊのパラメータを更新する。
ＭＯＶＥ
ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴ（Ｏｂｊｅｃｔ＿ＩＤ＝ｊ，Ｏｂｊｅｃｔ＿Ｐｒｏｖｉｄｅｒ＿ＩＤ＝ｑ，Ｎａｍｅ＝ｎ，パラメータ＝値）
オブジェクトプロバイダｐは、それがオブジェクトｊをそのエリアに有することを知っている。オブジェクトｊがオブジェクトプロバイダｑに現在属することを要求が示しているので、オブジェクトプロバイダｐは、オブジェクトｊをそのエリアから削除する。オブジェクトプロバイダｑは、指示されたパラメータの値を用いてオブジェクトｊをそのエリアに作成する。
【００３３】
図８は、本発明によるオブジェクトハンドリング機構の概略を示す。
【００３４】
オブジェクトマネージャにおけるユーザインターフェースおよび／またはアプリケーションを介して、オブジェクト要求アクション（作成、更新、…）が入力される［１］。それに応じて、オブジェクトマネージャにおけるＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴオブジェクト内のＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴオブジェクトデータが変更される。次いで、ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴオブジェクトがＰ／Ｓドメインを介してパブリッシュされる［２］。ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴオブジェクトは、ＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴトピックをサブスクライブしているすべてのオブジェクトプロバイダによって読み取られる。対象とされたオブジェクトプロバイダは、要求を参照し、要求に応じて、指定されたオブジェクトを作成、更新、削除する［３］。移動は、１つのオブジェクトプロバイダでの作成、および別のオブジェクトプロバイダでの削除を意味することに留意されたい。このオブジェクトは、その状態および特性（作成された、更新された、削除された）をパブリッシュする［４］。移動に関してＰ／Ｓドメインを介した２つの通知、すなわち「削除された」および「作成された」があることに留意されたい。最後に、要求の結果が、オブジェクトマネージャユーザインターフェースまたはアプリケーションに示される［５］。
【００３５】
次に、付箋アプリケーションの例を使用して本発明がさらに説明される。付箋は、仮想壁に付着される。付箋アプリケーションは、その環境内に存在する任意の壁においてノートを示し操作（作成、更新、削除、移動）することができる。さらに、付箋アプリケーションそれ自体が、それ自身の仮想壁を提供することができる。
【００３６】
先に既に示されたように、２つの役割が、付箋アプリケーションの対話で識別される。壁プロバイダが、仮想壁の働きをし、その壁に付着されたノートを所持し、すなわちパブリッシュを担う。ノートユーザインターフェースが、ユーザにノートを示し、ノートを操作するための制御をユーザに与える。付箋アプリケーションは、同時に両方の役割を行うことができる。何らかのヘッドレスデバイス、たとえばゲートウェイが、壁プロバイダだけの働きをするアプリケーションを実装してもよいと考えられる。
【００３７】
付箋アプリケーションのデータモデルは、３つの主要部分、すなわち、ノートが付着され得る仮想壁の表現、ノートそれら自体の表現、およびノート操作要求の表現を含む。これらのノート操作要求は、ノートを作成すること、ノートのテキストを変更すること、ノートを異なる壁へ移動すること、およびノートを削除することを含む。
【００３８】
（上述のＯＢＪＥＣＴ＿ＲＥＱＵＥＳＴに対応する）ＮｏｔｅＲｅｑｕｅｓｔ（ノート要求）のフィールドに対する値のすべての可能な組合せは、意味を有する。すべての要求は、与えられた壁プロバイダとは無関係であるか、または作成、削除、もしくは更新要求として解釈可能である。
【００３９】
ノートユーザインターフェースの視点から、解釈は同様に単純である。新しいノートを作成するために、（ＯＢＪＥＣＴ＿ＩＤに対応する）新しい一意のノートＩＤが作られ、（ＯＢＪＥＣＴ＿ＰＲＯＶＩＤＥＲ＿ＩＤに対応する）その適切な壁ＩＤを有する壁が選択され、要求がパブリッシュされる。既存のノートを更新するために、要求が、対応するノートＩＤ、現行の壁ＩＤ、および新しいメッセージと共にパブリッシュされる。ノートを移動するために、要求が、ノートＩＤ、移動したい先の壁の壁ＩＤ、および既存のメッセージと共にパブリッシュされる。実際には、これは、新しい壁の作成アクションと、古い壁の削除アクションとが１つの要求に組み合わされたものである。ノートを削除するために、要求が、ノートＩＤおよび空（void）の壁ＩＤと共にパブリッシュされる。この場合、（「特性」に対応する）メッセージは無関係である。
【００４０】
図９は、ＣＲＥＡＴＥアクションを示す。
【００４１】
１．ユーザは、ＩＤ１２３４を有する壁に付着されるべきメッセージ「Ｈｅｌｌｏ」を有する新しいノートを作成する。ノートユーザインターフェースは、ノートに対する一意のＩＤ（この場合は１）を選択し、ＮｏｔｅＲｅｑｕｅｓｔをパブリッシュする。
【００４２】
２．ＮｏｔｅＲｅｑｕｅｓｔイベントが受信されると、壁プロバイダ１２３４は、それをノートの作成を求める要求として解釈する。壁プロバイダ３４５６は、要求がその壁と関係ないので要求を無視する。
【００４３】
３．次いで、壁プロバイダ１２３４は、ノートトピックに対する新しいノートインスタンスをパブリッシュする。
【００４４】
４．ノートユーザインターフェースは、トピックに対する変更を通知され、新しいノートを発見し、そのユーザインターフェースを更新する。
【００４５】
図１０は、ＵＰＤＡＴＥアクションを示す。
【００４６】
１．ユーザは、ノートのメッセージを「Ｈｅｌｌｏ」から「Ｗｏｒｌｄ」に変更することを決める。ノートユーザインターフェースは、適切なＮｏｔｅＲｅｑｕｅｓｔをパブリッシュする。
【００４７】
２．ＮｏｔｅＲｅｑｕｅｓｔイベントが受信されると、壁プロバイダ１２３４は、それを既存ノートについての更新要求として解釈する。壁プロバイダ３４５６は、要求がその壁と関係ないので要求を無視する。
【００４８】
３．壁プロバイダ１２３４は、ノートトピックに対する更新されたノートインスタンスをパブリッシュする。
【００４９】
４．ノートユーザインターフェースは、トピックに対する変更を通知され、更新されたノートを発見し、そのユーザインターフェースを更新する。
【００５０】
図１１は、ＭＯＶＥアクションを示す。
【００５１】
１．ユーザは、ノートを壁３４５６に移動する。ノートユーザインターフェースは、適切なＮｏｔｅＲｅｑｕｅｓｔをパブリッシュする。
【００５２】
２．ＮｏｔｅＲｅｑｕｅｓｔイベントが受信されると、壁プロバイダ１２３４は、それを既存ノートについての削除要求として解釈する。壁プロバイダ３４５６は、同じイベントを新しいノートについての作成要求として解釈する。
【００５３】
３．壁プロバイダ１２３４は、トピックからノートインスタンスを除去し、壁プロバイダ３４５６は、トピックに対する新しいノートインスタンスをパブリッシュする。
【００５４】
４．ノートユーザインターフェースは、トピックに対する変更を通知され、更新されたノートを発見し、そのユーザインターフェースを更新する。
【００５５】
最後に、図１２は、ＤＥＬＥＴＥアクションを示す。
【００５６】
１．ユーザは、ノートを削除する。ノートユーザインターフェースは、適切なＮｏｔｅＲｅｑｕｅｓｔをパブリッシュし、それは空の壁ＩＤ（０）を選択する。
【００５７】
２．ＮｏｔｅＲｅｑｕｅｓｔイベントが受信されると、壁プロバイダ１２３４は、要求がその壁と関係ないので要求を無視する。壁プロバイダ３４５６は、要求を削除要求として解釈する。
【００５８】
３．壁プロバイダ３４５６は、そのノートをトピックから除去する。
【００５９】
４．ノートユーザインターフェースは、トピックに対する変更を通知され、ノートインスタンスがトピックから除去されたことを発見し、そのユーザインターフェースを更新する。
【図１】
2016514870.tif 000003
【図２】
2016514870.tif 000004
【図３】
2016514870.tif 000005
【図４】
2016514870.tif 000006
【図５】
2016514870.tif 000007
【図６】
2016514870.tif 000008
【図７】
2016514870.tif 000009
【図８】
2016514870.tif 000010
【図９】
2016514870.tif 000011
【図１０】
2016514870.tif 000012
【図１１】
2016514870.tif 000013
【図１２】
2016514870.tif 000014
【国際調査報告】
2016514870.tif 000015
2016514870.tif 000016