(57)【要約】【課題】本発明の実施形態は改善された情報交換を提供し、特に、異なるソフトウェアシステム間でのデータオブジェクトの交換方法を提供する。【解決手段】一実施形態において、本発明は、オブジェクトの属性を分析するステップを含む情報交換方法を含む。オブジェクトは、貯蔵部に格納されてもよく、属性を用いて読み取られてもよい。或るアプリケーションでは、オブジェクトは、受信され、オブジェクト自体における情報を何らアクセスすることなく参加者に送信される。異なるアプリケーションは、異なるネームまたはネーム空間、クラス、エイリアス、グループ、地理空間情報、またはトークン、またはそれらの組合せを支援する異なる通信媒体を介して操作可能なオブジェクトウェアハウジングを含む。【選択図】図１
2008269595.tif 000002
【特許請求の範囲】
【請求項１】
情報を交換する方法であって、
データオブジェクトと該データオブジェクトの受信者を記述する第１属性情報とを含む第１トランスポートリクエストを受信するステップと、
前記データオブジェクトを格納するステップと、
前記第１属性情報を含む第１タグを生成するステップと、
前記データオブジェクトに前記第１タグを関連付けるステップと、
前記第１タグを格納するステップと、
前記第２トランスポートリクエストの送信者を記述する第２属性情報を含む第２トランスポートリクエストを受信するステップと、
前記第２属性情報を含む第２タグを生成するステップと、
前記第１属性情報と前記第２属性情報の少なくとも一部を比較するステップと、
前記第２属性情報の少なくとも一部が前記第１属性情報の少なくとも一部と一致すれば、前記第２トランスポートリクエストの送信者に前記データオブジェクトを送信するステップとを含む方法。
【請求項２】
前記第１属性情報は第１ネーム情報を含み、前記第２属性情報は第２ネーム情報を含む請求項１記載の方法。
【請求項３】
前記第１および第２ネーム情報は、ネーム及びネームフォームを含む請求項２記載の方法。
【請求項４】
前記ネーム及び前記ネームフォームはエンコードされる請求項３記載の方法。
【請求項５】
第３ネーム情報を含むエイリアスリストを前記第１タグに関連づけるステップを更に含み、当該方法は、
前記第２タグにおける前記第２ネーム情報を前記エイリアスリストにおける前記第３ネーム情報と比較するステップと、
前記第２ネーム情報が前記第３ネーム情報と一致すれば、前記第２トランスポートリクエストの前記送信者に前記データオブジェクトを送信するステップと
を更に含む請求項２記載の方法。
【請求項６】
前記第１属性情報を前記第１トランスポートリクエストにおける第１フォーマットから前記第１タグにおける第２フォーマットに変換するステップを更に含む請求項１記載の方法。
【請求項７】
前記第２属性情報を前記第２トランスポートリクエストにおける第１フォーマットから前記第２タグにおける第２フォーマットに変換するステップを更に含む請求項１記載の方法。
【請求項８】
前記第１属性情報は、１又は２以上のグループ属性を有し、当該方法は、前記グループ属性を用いて、複数の受信者を含むグループ情報をアクセスするステップと、前記グループ情報において特定される各受信者についてのタグを生成するステップとを更に含む請求項１記載の方法。
【請求項９】
前記第１および第２属性情報は地理空間情報を含む請求項１記載の方法。
【請求項１０】
地理空間ソフトウェアコンポーネントにおける前記第１および第２属性を処理するステップを更に含む請求項９記載の方法。
【請求項１１】
前記第１属性情報は、トークンが前記データオブジェクトを読み取るために必要とされることを示す情報を含む請求項１記載の方法。
【請求項１２】
トークンを有効化するステップを更に含み、トークンが受信されて有効化された場合にのみ前記データオブジェクトが送信される請求項１１記載の方法。
【請求項１３】
ビジネスプロセスを得る方法を実行するためにコンピュータシステムを制御するための命令を含むコンピュータ読み取り可能な記録媒体であって、前記方法は、
データオブジェクトと該データオブジェクトの受信者を記述する第１属性情報を含む第１トランスポートリクエストを受信するステップと、
前記データオブジェクトを格納するステップと、
前記第１属性情報を含む第１タグを生成するステップと、
前記第１タグを前記データオブジェクトに関連づけるステップと、
前記第１タグを格納するステップと、
第２トランスポートリクエストの送信者を記述する第２属性情報を含む前記第２トランスポートリクエストを受信するステップと、
前記第２属性情報を含む第２タグを生成するステップと、
前記第１属性情報と前記第２属性情報の少なくとも一部を比較するステップと、
前記第２属性情報の少なくとも一部が前記第１属性情報の少なくとも一部と一致する場合に前記第２トランスポートリクエストの前記送信者に前記データオブジェクトを送信するステップとを含むコンピュータ読み取り可能な記録媒体。
【請求項１４】
前記第１属性情報は第１ネーム情報を含み、前記第２属性情報は第２ネーム情報を含む請求項１３記載のコンピュータ読み取り可能な記録媒体。
【請求項１５】
前記第１および第２ネーム情報はネームおよびネームフォームを含む請求項１４記載のコンピュータ読み取り可能な記録媒体。
【請求項１６】
前記ネームおよび前記ネームフォームはエンコードされる請求項１５記載のコンピュータ読み取り可能な記録媒体。
【請求項１７】
第３ネーム情報を含むエイリアスリストを前記第１タグに関連づけるステップを更に含み、当該方法は、
前記第２タグにおける前記第２ネーム情報を前記エイリアスリストにおける前記第３ネーム情報と比較するステップと、
前記第２ネーム情報が前記第３ネーム情報と一致する場合に前記第２トランスポートリクエストの前記送信者に前記データオブジェクトを送信するステップとを更に含む請求項１４記載のコンピュータ読み取り可能な記録媒体。
【請求項１８】
前記第１属性情報を前記第１トランスポートリクエストにおける第１フォーマットから前記第１タグにおける第２フォーマットに変換するステップを更に含む請求項１３記載のコンピュータ読み取り可能な記録媒体。
【請求項１９】
前記第１または第２トランスポートリクエストは車両から受信される請求項１３記載のコンピュータ読み取り可能な記録媒体。
【請求項２０】
前記第１属性情報は、１又は２以上のグループ属性を有し、当該方法は、更に、前記グループ属性を用いて、複数の受信者を含むグループ情報をアクセスするステップと、前記グループ情報において特定される各受信者についてのタグを生成するステップとを含む請求項１３記載のコンピュータ読み取り可能な記録媒体。
【請求項２１】
前記第１および第２属性情報は地理空間情報を含む請求項１３記載のコンピュータ読み取り可能な記録媒体。
【請求項２２】
地理空間ソフトウェアコンポーネントにおける前記第１および第２属性を処理するステップを更に含む請求項２１記載のコンピュータ読み取り可能な記録媒体。
【請求項２３】
前記第１属性情報は、トークンが前記データオブジェクトを読み取るために必要とされることを示す情報を含む請求項１３記載のコンピュータ読み取り可能な記録媒体。
【請求項２４】
トークンを有効化するステップを更に含み、トークンが受信されて有効化された場合にのみ前記データオブジェクトが送信される請求項２３記載のコンピュータ読み取り可能な記録媒体。
【請求項２５】
コンピュータソフトウェアシステムであって、
データオブジェクトと該データオブジェクトの受信者を記述する第１属性情報とを含む第１トランスポートリクエストを受信する共に前記第１属性情報を含む第１タグを生成するためのトランスポートコントローラと、
前記データオブジェクトと該データオブジェクトに関連づけられた前記第１タグとを格納するための貯蔵部と、
マッチングルールエンジンとを含み、
前記トランスポートコントローラは、第２トランスポートリクエストの送信者を記述する第２属性情報を含む前記第２トランスポートリクエストを受信すると共に前記第２属性情報を含む第２タグを生成し、
前記マッチングルールエンジンは、前記第２属性情報の少なくとも一部と前記第１属性情報を比較し、
前記トランスポートコントローラは、前記第２属性情報の少なくとも一部が前記第１属性情報の少なくとも一部と一致する場合に前記第２トランスポートリクエストの前記送信者に前記データオブジェクトを送信するコンピュータソフトウェアシステム。
【請求項２６】
前記第１属性情報は第１ネーム情報を含み、前記第２属性情報は第２ネーム情報を含む請求項２５記載のシステム。
【請求項２７】
前記第１および第２ネーム情報はネームおよびネームフォームを含む請求項２６記載のシステム。
【請求項２８】
前記ネームおよび前記ネームフォームはエンコードされる請求項２７記載のシステム。
【請求項２９】
第３ネーム情報を含むエイリアスリストが前記第１タグに関連づけられ、前記マッチングルールエンジンは、前記第２タグにおける前記第２ネーム情報を前記エイリアスリストにおける前記第３ネーム情報と比較し、前記トランスポートコントローラは、前記第２ネーム情報が前記第３ネーム情報と一致する場合に前記第２トランスポートリクエストの前記送信者に前記データオブジェクトを送信する請求項２６記載のシステム。
【請求項３０】
前記第１属性情報を前記第１トランスポートリクエストにおける第１フォーマットから前記第１タグにおける第２フォーマットに変換するための変換処理を更に含む請求項２５記載のシステム。
【請求項３１】
前記第１または第２トランスポートリクエストは車両から受信される請求項２５記載のシステム。
【請求項３２】
グループルールエンジンを更に備え、前記第１属性情報は、１又は２以上のグループ属性を有し、前記グループルールエンジンは、前記グループ属性を用いて、複数の受信者を含むグループ情報をアクセスし、且つ、前記グループルールエンジンは、前記グループ情報において特定される各受信者についてのタグを生成する請求項２５記載のシステム。
【請求項３３】
前記第１および第２属性情報は地理空間情報を含む請求項２５記載のシステム。
【請求項３４】
前記第１および第２属性情報を処理するための地理空間ルールエンジンを更に含む請求項３３記載のシステム。
【請求項３５】
前記第１属性情報は、トークンが前記データオブジェクトを読み取るために必要とされることを示す情報を含む請求項２５記載のシステム。
【請求項３６】
トークンを有効化するためのトークンルールエンジンを更に含み、トークンが受信されて有効化された場合にのみ前記データオブジェクトが送信される請求項３５記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータソフトウェアアプリケーションに関し、特に、オブジェクトウェアハウジング(object warehousing)を用いた情報交換のためのシステム及び方法に関する。
【背景技術】
【０００２】
増え続ける多くのアプリケーションを支援するためにデータがソフトウェアシステム間を移動する。データは、そのタイプ、サイズ、頻度(frequency)、フォーマットが変化する。従来、データの移動は、通信ネットワークによって支援されるデータ配信モデル(data distribution model)として取り扱われてきた。このアプローチは、共通および統一ネーム空間(common and unified namespace)、固定または不変アドレス空間(fixed or stable address space)、持続的(persistent)かつ信頼性のある通信チャンネル、および同種配置スキーム(homogeneous deployment scheme)のような、基本的特性を提供する環境において正常に機能する。残念ながら、これらの特性は必ずしも最近のデータ通信システムに存在するとは限らない。
【０００３】
例えば、車両(vehicle)のような移動システムは、シームレスな情報交換を可能にする伝統的基盤要件(traditional foundation requirements)を支援することができない。車両の寿命(lifespan)を１０から１５年とすると、控えめなサイズの車両群(fleet)は、長年の技術時代および規制時代にわたる車両を含む。例えば、或る車両は、ＣＡＮ(Component Area Network)２．０技術を備える一方、他のものは、単純な有線コンポーネント(wired component)を備える。しかしながら、車両および他の無線システム（即ち、移動体装置）は固有の受信可能範囲の制約を有し、その制約は、ハンドオフ、ネーム変更、およびアドレス変更を長い時間をかけてもたらす。さらに、多くの最新の無線装置は必ずしもターンオンされているとは限らず、情報交換のためにその装置のネットワーク可用性を決定することを困難にする。
【０００４】
情報交換に関する問題に対する一つの解決策は、ソフトウェアアプリケーション間にバッファリングシステムを設けることである。バッファは、送信者(sender)がそのバッファに情報を入れ、受信者(receiver)がそのバッファから情報を読み出すように使用される。送信(sending)および読み出し(retrieving)動作は、時間内に入れ替えられてもよく、送信者と受信者との間で直接的通信リンクを用いずに異なるシステムが情報を交換することを可能にする。バッファリングシステムの例としては、電子メール、インスタントメッセージ、ボイスメール、およびメッセージキュー(message queues)が含まれる。これらのタイプのシステムでは、送信者と受信者との間に装置が配置され、この装置では、メッセージは、受信者がそれを受信する準備ができるまでバッファリングされることができる。しかしながら、多くの既存の解決策は、ユニークなネーム空間およびデータモデルと重なる。バッファリングコンポーネントは、ネーム空間の慣例のみならず、特定のドメインデータモデルも独自に認識し、一時的情報交換システムを基本的実施に堅く結びつける。
【０００５】
必要とされているものは、例えば、断続的(intermittent)な接続性、アドレスの変更、ネーム空間の不一致、異なる通信媒体、或いはセキュリティについての増大する要請、またはこのような課題の組合せを支援することが可能な柔軟なシステムである。
【特許文献１】米国特許出願公報第２００３００８７６３８号明細書
【特許文献２】米国特許出願公報第２００４００２４８４９号明細書
【特許文献３】国際公開第２００２／３５３５９号パンフレット
【特許文献４】国際公開第２００６／０６３８６８号パンフレット
【発明の開示】
【発明が解決しようとする課題】
【０００６】
従って、情報を交換するための改良されたシステム及び方法に対する要請が存在する。本発明は、オブジェクトウェアハウジングを用いた情報交換のための改善されたシステム及び方法を提供することにより、これらの問題および他の問題を解決する。
【課題を解決するための手段】
【０００７】
本発明の実施形態は、情報交換を改善し、詳細には、異なるソフトウェアシステム間でのデータオブジェクトの交換を改善する。一実施形態において、本発明は、オブジェクトの属性を分析するステップを含む情報交換方法を含む。オブジェクトは、貯蔵部(repository)に格納されてもよく、属性を用いて読み出されても良い。或るアプリケーションでは、オブジェクトは、オブジェクト自体にある情報を何らアクセスすることなく参加者(participants)に送られると共に受信される。別のアプリケーションは、異なるネームまたはネーム空間、クラス、エイリアス(aliases)、グループ、地理空間情報(geospatial information)、またはトークン(tokens)、またはそれらの組合せを支援する異なる通信媒体にわたって動作可能なオブジェクトウェアハウジングを含む。
【０００８】
次の詳細な説明および添付の図面は、本発明の本質および利点のより良好な理解を提供する。
【０００９】
図１は、本発明の一実施形態によるオブジェクトウェアハウスを例示する。
【００１０】
図２Ａは、本発明の一実施形態によるオブジェクトウェアハウジングを例示する。
【００１１】
図２Ｂは、本発明の他の実施形態によるオブジェクトウェアハウスを例示する。
【００１２】
図３は、本発明の一実施形態による情報交換方法を例示する。
【００１３】
図４は、本発明の一実施形態によるウェブサービスとして実施されるオブジェクトウェアハウスの一例である。
【００１４】
図５は、本発明の他の実施形態による情報交換システムを例示する。
【００１５】
図６は、本発明の他の実施形態による情報交換方法を例示する。
【００１６】
図７は、本発明の他の実施形態による情報交換方法の一例を示す。
【００１７】
図８は、本発明の他の実施形態による属性情報の一例を示す。
【００１８】
図９は、本発明の他の実施形態による情報交換の一例を示す。
【００１９】
図１０は、本発明の他の実施形態によるマッチング技術の別の例を示す。
【００２０】
図１１は、本発明の他の実施形態によるグループに基づく情報交換の一例を示す。
【００２１】
図１２は、本発明の他の実施形態による地理空間情報に基づく情報交換の一例を示す。
【００２２】
図１３は、本発明の他の実施形態によるトークンを用いた情報交換の一例を示す。
【００２３】
図１４は、本発明の他の実施形態による情報交換方法を例示する。
【００２４】
図１５は、本発明の他の実施形態によるトークンを用いた情報交換の一例を示す。
【００２５】
図１６は、本発明の他の実施形態によるトークンを用いたオブジェクトウェアハウスの一例を示す。
【発明を実施するための最良の形態】
【００２６】
ここでは、情報を交換するための技術を説明する。次の説明において、説明の目的上、本発明の完全な理解を提供するために、多くの事例と具体的詳細が述べられる。しかしながら、当業者であれば、特許請求の範囲によって規定される本発明は、これらの事例単体における特徴における特徴の幾つか又は全部、または後述する他の特徴との組合せにおける特徴の幾つか又は全部を含んでも良いことは明らかであり、本明細書で述べられる特徴および概念の均等物および変形を更に含んでも良い。
【００２７】
図１は、本発明の一実施形態によるオブジェクトウェアハウス１００を図式的に示す。一実施形態において、オブジェクトウェアハウス１００は、オブジェクト貯蔵部１０１とトランスポート制御ソフトウェア１０２を含む。オブジェクトウェアハウス１００は、異なるシステム間で情報が転送されるときに情報を配信し格納するための制御メカニズムを提供することにより、異なるネットワークにわたる種々のソフトウェアシステム間での情報交換を可能にしてもよい。或る実施形態では、ソフトウェアシステムは、同システムにおいて別な時間に使用されるデータを格納するための場所としてオブジェクトウェアハウス１００を使用してもよい。オブジェクトウェアハウス１００は、ネットワーク１５０を介したデータ通信のためのソフトウェアを用いて、アプリケーション１５１、移動体装置１５２、他のオブジェクトウェアハウス１５３、ソフトウェアサービス１５４（例えば、ウェブサービス）、または任意の他の装置またはシステムから情報を受信し格納してもよい。貯蔵部１０１に格納された情報は、トランスポートコントローラ１０２の制御の下で複数の受信者または唯一の受信者（即ち、読み出しエンティティ、レトリーバ、コンシューマ）によって読み出されてもよい。例えば、格納された情報は、目的とする情報の受信者が命令（例えば、ピックアップリクエスト）をオブジェクトウェアハウス１００に発行する場合、その単一の受信者（例えば、他のアプリケーション）に送信されてもよい。更に、トランスポート情報（例えば、トランスポート属性）は、オブジェクトウェアハウス１００によって受信されて格納されてもよく、例えば、単純または複雑なポリシー（例えば、配信またはセキュリティルールまたはアルゴリズム）を実施する種々の方法でトランスポートコントローラ１０２によって使用されてもよい。上記ポリシーは、配信用のウェアハウスに受信され格納されたオブジェクト、または読み出しシステムから受信されたピックアップリクエストの何れか、またはその両方に関連する情報に基づき選択され実行される所定のアルゴリズムとして実施されてもよい。
【００２８】
オブジェクトウェアハウスは、ソフトウェアシステム間の情報通信のための持続性のメカニズムを提供してもよい。例えば、オブジェクトウェアハウスは、ネットワーク上の固定アドレスに配置されてもよい。上記アドレスは、情報交換用のオブジェクトウェアハウスを使用するソフトウェアシステムに知られても良い。各ソフトウェアシステムは、上記オブジェクトウェアハウスまたは複数のオブジェクトウェアハウスのアドレスを格納してもよい。従って、或るソフトウェアシステムは、特定のオブジェクトウェアハウスのアドレスにトランスポートリクエストと共にデータオブジェクトを送信することにより、他のソフトウェアシステムと情報を交換してもよく、他のソフトウェアシステムは、上記オブジェクトウェアハウスのアドレスに読み出しトランスポートリクエストを送信することによりデータオブジェクトを読み出しても良く、これによりデータオブジェクトを読み出す。更に、或る実施形態では、オブジェクトウェアハウスは、例えば、各ソフトウェアシステムについての識別情報を格納してもよく、従ってオブジェクトウェアハウスは、特定のソフトウェアシステムが、このソフトウェアシステムについてピックアップ用に設計された任意のデータオブジェクトを備えているかどうかを判定することができる。
【００２９】
一実施形態において、本発明は、デジタルオブジェクト（例えば、メッセージまたはコンテンツ）と各デジタルオブジェクトについてのトランスポート情報とを区別してもよい。トランスポート情報は、デジタルオブジェクトを処理するための命令（即ち、オペレーション）と属性を含んでも良い。トランスポート命令は、オブジェクトウェアハウスが実施（即ち、格納、読み出し）すべきアクションを特定するために使用される。各命令は、特定のデジタルオブジェクトを処理するための特定のワークフローを有してもよい。トランスポート属性は、トランザクション中にデジタルオブジェクトがどのように操作されるかを制御し、異なるデジタルオブジェクトについてのセキュリティスキームおよび配信をユーザが特定することを可能にするために使用されてもよい。オブジェクトウェアハウス１００は、デジタルオブジェクト（“データオブジェクト”と称す）が、異なるソフトウェアシステム間で（または、同ソフトウェアシステムへ、または同じソフトウェアシステムから）伝送されるときに、格納され操作されることを可能にする。オブジェクト貯蔵部１０１は、これに限定されるものではないが、単一のデータベースまたは複数のデータベースを含む種々の異なるデータベースシステム構成から構成されてもよく、１又は２以上のデータベース管理システムによって管理されてもよい。他の貯蔵技術もデータオブジェクトを格納するために使用されることが可能であることが理解される。一実施形態において、データオブジェクト１１０Ａは、トランスポート情報（トランスポートリクエスト１１０Ｂ）と関連してもよい。一実施例において、トランスポートリクエストは、オブジェクト（“トランスポートオブジェクト”）として実施されてもよい。トランスポートリクエスト１１０Ｂは、各データオブジェクトがどのように操作されるかを決定するために、オブジェクトウェアハウス１００によって使用される。上述したように、トランスポートリクエストは、関連データオブジェクトに関して実行されるトランスポート（例えば配信）ポリシーを決定するために使用される命令を含む。データオブジェクトは、トランスポート情報に付随され、またはトランスポート情報にカプセル化されてもよい。他の実施形態では、トランスポート情報は、データオブジェクトに対するリファレンス（例えば、データオブジェクトをアクセスするためのＵＲＬまたはポインター）を含んでもよい。加えて、トランスポートリクエスト１１０Ｂは、データオブジェクトを処理するため使用される属性を含んでもよい。トランスポートコントローラ１０２は、トランスポートリクエスト１１０Ｂにおける情報を受信し、１又は２以上の種々のオブジェクト処理手順を実行してもよい。トランスポートコントローラ１０２は、関連データオブジェクトの操作においてトランスポートリクエストの属性を使用してもよい。以下に更に詳細に後述する一実施形態において、データオブジェクト１１０Ａは、トランスポートコントローラソフトウェア１０２により実行されるルールを特定する。ルールは、新たな配信ポリシーアルゴリズム、セキュリティアルゴリズム、またはデータオブジェクト処理アルゴリズムを実施するためのトランスポートコントローラ１０２に動的に付加されてもよい。従って、オブジェクトウェアハウス１００は、データオブジェクトを受信し、外部ソースから受信されたルール或いは予め規定されたルールに従って上記データオブジェクトを処理し、及び／又は必ずしも上記データオブジェクト自体をアクセスすることなく、制御された方法で上記オブジェクトを送信してもよい。
【００３０】
一実施形態において、オブジェクトウェアハウス１００は、データオブジェクトのセキュリティを維持するための認証機能(authentication functionality)を含む。例えば、データオブジェクト（またはリファレンス）がオブジェクト貯蔵部１０１に格納されるときに、そのデータオブジェクトは、そのデータオブジェクトをアクセスするのに適合されなければならないセキュリティプロトコルを特定するために使用されるトランスポート属性と関連づけられてもよい。加えて、セキュリティアルゴリズム（ルール）は、オブジェクト貯蔵部にデータオブジェクトとして格納されてもよく、そして格納されたデータオブジェクトをアクセスするためのリクエストを認証するために実行されてもよい。例えば、トランスポート属性は、関連するデータオブジェクトを暗号化するために使用される暗号化技術を特定してもよい。関連するデータオブジェクトに対する読み取りアクセス(retrieval access)をエンティティ（例えば他のソフトウェアシステム）が取得するために、適切な暗号化キーの提供が要求されてもよい。従って、そのオブジェクトに対するアクセスをリクエストするソフトウェアシステムは、最初に、特別な暗号化スキームを特定するトランスポート属性をアクセスしてもよい。その次に、何の暗号化が使用されているのかをソフトウェアシステムが一旦知ると、そのシステムは、暗号化されたデータオブジェクトを読み取り（例えば、オブジェクトウェアハウスにリクエストを発行することにより）、そのオブジェクトを解読するために必要なキー（それがキーを保持していると仮定し、或いは他の手段を通じてそのキーに対するアクセスを取得することができると仮定すれば）を使用してもよい。暗号化および解読は、例えば、オブジェクトウェアハウスにおいて実施されてもよい。他の例として、読み取りエンティティは、以下のように認証されることを要求されてもよい。最初に、読み取りエンティティは、そのエンティティのために設計された全てのデータオブジェクトを読み取るためにオブジェクトウェアハウスにリクエストを送信してもよい。読み取りリクエスト(retrieval request)は、そのリクエストを作成したエンティティを特定する属性を含んでもよい。もしオブジェクトウェアハウスにあるデータオブジェクトがその読み取りエンティティのために設計されたのであれば、データオブジェクトに対する読み取りアクセスが実施される前に、オブジェクトウェアハウスは、その読み取りエンティティの属性に基づき認証セキュリティアルゴリズムを実行することを要求されてもよい。実行されるべき特定のセキュリティアルゴリズムは、データオブジェクトと関連づけられてもよい。読み取りエンティティの認証は、読み取りアクセスが試みられたときに実行されてもよい。アルゴリズムは、そのアルゴリズムへの入力として読み取りエンティティから受信された属性を使用してもよく、そして、例えば、読み取りエンティティ特定の属性値に基づきデータオブジェクトに対するアクセスを許諾または拒否してもよい。もし読み取りアクセスが許諾されれば、データオブジェクトは、読み取りエンティティに返送されてもよい。同様に、トランスポートリクエストに関する属性は、貯蔵部にデータオブジェクトを格納す��ことが許容される前に、データオブジェクトに関連した到来するトランスポートリクエストに関する他のセキュリティアルゴリズムを認証または実施するために使用されてもよい。種々のセキュリティ特性が、同様に、データオブジェクトと関連する属性を使用して定義されてもよいことが理解される。
【００３１】
オブジェクトウェアハウス１００と他のソフトウェアシステムとの間のトランザクションは、他のソフトウェアシステム１５５Ａ−Ｄと、単一のネットワーク１５０または他のネットワーク１５５を介して接続されてもよい。ネットワーク１５０または１５５は、インターネット、遠隔通信ネットワーク、携帯電話ネットワーク、ＷＡＮ(Wide Area Network)、ＬＡＮ(Local Area Network)、または、例えば８０２．１１ネットワーク、WiMaxネットワーク、衛星のような無線ネットワークを含んでもよい。
【００３２】
図２Ａは、本発明の一実施形態によるオブジェクトウェアハウジングを図示する。概略的には、オブジェクトウェアハウスは、ソフトウェアシステム間の情報の流れを容易化するために複数の通信媒体を介して使用されてもよい。例えば、第１ソフトウェアシステム２５５Ａは、第１通信媒体２１０Ａを用いてオブジェクトウェアハウス２００Ａとの間で情報の送受信を行ってもよい。第２ソフトウェアシステム２５５Ｂは、第１通信媒体２１０Ａを介してオブジェクトウェアハウス２００Ａに情報を送信し、第２通信媒体２１０Ｂを介してオブジェクトウェアハウス２００Ａから情報を受信してもよい。オブジェクトウェアハウスとの間の或るトランザクションは、単一方向性の通信チャネルを介したものであってもよい。このようなシステムの例としては、オブジェクトウェアハウスから衛星（例えばデジタル衛星無線）を介して情報を受信すると共に無線通信チャネルを用いて上記オブジェクトウェアハウスに情報を送信する車両ソフトウェアシステムがある。
【００３３】
一実施形態において、複数のオブジェクトウェアハウス２００，２５５Ｃ，２５５Ｄは、同じ通信媒体（例えばネットワーク）上で使用されてもよく、或いは、配信オブジェクトウェアハウス(a distributed object warehouse)を実施するために複数の通信媒体を介して使用されてもよい。配信オブジェクトウェアハウスにおいて、各オブジェクトウェアハウスは、情報の流れを最適化するために他のオブジェクトウェアハウスのネットワーク接続性に関する情報を保持してもよい。オブジェクトウェアハウスは、例えば、マルチキャストまたはレジストリ法により発見されてもよい。ウェアハウスは、インターネットマルチキャストメッセージに応答することができ、或いは、ウェアハウスは、アクティブウェアハウスのリストを保持または共有する認識されたセントラルウェアハウスに登録することができる。オブジェクトウェアハウス間のパスに関する情報は、各ウェアハウスが配信ウェアハウスにおいて利用可能な通信媒体を理解することを可能にするために、他のオブジェクトウェアハウスにマッピングされて配信されてもよい。クライアントは、サービスをリクエストするために配信オブジェクトウェアハウスにおける特定のオブジェクトウェアハウスを選択してもよい。例えば、サービスは、選択(selected)され、学習(learned)され、方向付け(directed)られ、または指示(prescribed)された手段によって取得されてもよい。選択された手法では、クライアントが、接続すべき多くの推奨されたウェアハウスのうちの一つを選択する。学習された手法では、クライアントは、特定のウェアハウスが、リクエストを要望する配信サービスを提供するのに適することを学習する。これは、代表的には時間的に変化する状況であり、従って学習は継続中(ongoing)である。方向付けられた手法では、クライアントは、特定のウェアハウスを使用するために受信者によって方向づけられる。指示された手法では、上記選択された手法と同様であるが、通信媒体に制約される。もしクライアントがＧＰＲＳ接続を使用すれば、或るウェアハウスは、この通信手法を使用するために指示される。例えば、或るソフトウェアシステム（例えばアプリケーション）は、ネットワーク速度またはセキュリティ関係のため、配信オブジェクトウェアハウスにおける特定のオブジェクトウェアハウスとの間でデータオブジェクトの送受信を行ってもよい。加えて、データオブジェクトは、例えば、通信媒体のタイプ（例えば、タリフ(tariffed)ＧＰＲＳ、無料公衆ＷｉＦｉ）、トランザクションのネーム空間（例えば、このメッセージを全ＢＭＷに送信する）、またはリクエストタイプ（例えば、デュプリケートデリバリ(Duplicate Delivery)、ペイオンデリバリ(Pay on Delivery)）のようなトランスポート属性に基づいて配信オブジェクトウェアハウスにおける異なる貯蔵部間でトランスポートされてもよい。更に、複数の通信媒体を介して動作する配信オブジェクトウェアハウスは、例えば、読み取りソフトウェアシステムにとって最も都合のよい特定のオブジェクトウェアハウスに、オブジェクトウェアハウス間のデータオブジェクトを移動させてもよい。
【００３４】
図２Ｂは、本発明の他の実施形態によるオブジェクトウェアハウス２００Ｂを図示する。この例では、オブジェクトウェアハウス２００Ｂは、貯蔵部２０１、トランスポートインターフェイス２１１、リクエストプロセッサ２１２、およびルールエンジン２１３を備える。トランスポートインターフェイス２１１は、データオブジェクト２３０Ｂ（例えば、データオブジェクトを格納する）を有すると共にデータオブジェクト２２２（例えば、データオブジェクトを読み取る）を有しないトランスポートリクエストを受信する。この例では、トランスポートリクエストは、１又は２以上の配信ポリシーを含んで、命令および属性を特定する。命令は、例えばプット(put)またはゲット(get)を含む。ポリシーは、オブジェクトウェアハウスに格納された１又は２以上の所定の配信ポリシーを特定してもよい。命令（即ち、サービスリクエスト）とデータオブジェクトの両方を含むトランスポートリクエストは、データオブジェクトを発送(dispatch)する方法に関してオブジェクトウェアハウスリクエストプロセッサ２１２に命令してもよい。リクエストプロセッサ２１２は、トランスポートリクエストを受信し、そして、特定の命令、ポリシー、またはリクエストの他の属性、またはそれらの組合せに基づき、異なるリクエストについて従うべき配信ポリシーまたは特定のワークフローを決定する。命令の一例は、ポスト(post)（格納）、ゲット(get)（読み取り）、コネクト(connect)、ディスコネクト(disconnect)、リスト(list)、およびデリート(delete)を含むが、これに限定されない。命令は、データオブジェクトの操作または配信を決定するための他のトランスポート属性を使用する他のアルゴリズムまたはワークフローに従って実行されてもよい。
【００３５】
更に、トランスポート属性は、トランスポート属性は、各関連データオブジェクトまたはデータオブジェクトに対するリファレンスと共に格納されてもよい。属性は、配信ポリシーを特定してもよく、それは、データオブジェクトに対する制御されたアクセス及び／又はインテリジェント配信を提供するためにオブジェクト貯蔵部に格納されてもよい。配信ポリシーは、データオブジェクトの配信を制御するための所定のアルゴリズムであってもよく、オブジェクトウェアハウスにおける特定のオブジェクトをどのエンティティがアクセスすることができるのかできないのかを決定するために読み取りリクエストの属性を分析することによりセキュリティポリシーを実施してもよい。配信ポリシーは、配信ルール、配信条件（例えば、所定日後にのみ送信する）、オブジェクト削除（破壊）条件、またはごくわずかのネームへの受信者のクラスまたはグループの記述(specifications)を含んでもよい。トランスポートリクエストにおいて特定された配信ポリシーは、貯蔵部に格納された所定のルール（アルゴリズム）をアクセスしてもよく、例えばルールエンジン２１３によって実行されてもよい。配信ポリシーは、オブジェクトウェアハウス（例えば、メッセージを読み取ることができるアプリケーション、コンピュータ、人間）に格納されたデータオブジェクトをアクセスことができる１又は２以上の“リトリーバ(retrievers)”を特定することを含んでもよい。例えば、配信ポリシーは、オブジェクトウェアハウスにおけるデータオブジェクトがエンティティに方向付けられるか否かを決定するために読み取りエンティティの属性を使用してもよい。他の配信ポリシーは、例えば、マルチキャスト情報（即ち、メッセージが読み取られるグループの記述）、ブロードキャスト情報（例えば、特定のドメイン、クラス、またはリストにおける任意のものによるデータオブジェクトの読み取りを可能にする）、またはレプリケーション(replication)情報を含んでもよい。レプリケーション情報は、例えば、メッセージが削除される前に、同一の受信者がデータオブジェクト（例えば、メッセージ）を１００回読み取ってもよいことを特定することを含んでもく、複数の消費者（メッセージのリトリーバ）が、メッセージが削除される前に１又は２以上のの特定の回数だけそのメッセージをアクセスしてもよい。各ケースにおいて、データオブジェクトは、読み取られて１又は２以上の読み取りエンティティに送信されるときに複製（コピー）される。従って、データオブジェクトは貯蔵部に受信され、データオブジェクトが貯蔵部に保持されると共にコピーが読み取りエンティティに送信されてもよく、または、データオブジェクトは、読み取りエンティティに直接的に転送されて即座に削除されてもよい。当業者に知られているように、格納されたデータオブジェクトのコピーまたは格納されたデータオブジェクトを受信することの間に重大な違い(material difference)は存在しない。配信ポリシーおよびトランスポートリクエストの他の属性を用いて、データオブジェクトは、例えば、ユーザ（例えば、ＢＭＷのオーナー）のクラスに対する特定のデータオブジェクトの配信、或る期間後のデータオブジェクトの削除、データオブジェクトがアクセ���または複製される最大回数、特定の日または時間の前または後の配信のような、種々の属性値に従って操作または配信されてもよい。本発明の或る実施形態は、データオブジェクトに対するアクセスおよび配信を制御するために使用されるトランスポート属性からデータオブジェクトが区分化(partition)されるので、データオブジェクト（例えば、“コンテンツ”）の制御された配信を可能にする。従って、オブジェクトウェアハウスを用いて交換されるデータオブジェクトの例は、テキストメッセージ、イメージ、ビデオ、または任意の通信媒体を介して或るソフトウェアから他のものに（または同一のソフトウェアシステムから同一のソフトウェアに）転送される情報の任意の他のデジタル表現を含む。
【００３６】
配信ポリシーの他の例として、各トランスポートリクエストは、その属性の一つとしてポリシーナンバー(policy number)を含んでもよい。メッセージは、例えば、Ｎ，Ｘ，Ｙのような属性およびナンバーと共に送信されてもよい。或るポリシーナンバーは、メッセージが、１又は２以上のユニークなエンティティＸによってＮ回読み取られてもよいことを特定してもよく、ここで、ＮおよびＸは、トランスポートリクエストにおける属性として提供される。他のポリシーは、例えば、ピックアップエンティティにはかまわず、メッセージがＮ回読み取られることを特定してもよく、ここで、Ｎは、トランスポートリクエストにおける属性として提供される。他のポリシーは、メッセージが、特定のピックアップエンティティのみにＮ回読み取られることを特定してもよく、ここで、Ｎは、トランスポートリクエストにおける属性として提供される。他のポリシーは、メッセージが、Ｙ通信チャネルを用いてＮ回読み取られることを特定してもよく、ここで、ＮおよびＹは、トランスポートリクエストにおいて提供される。例えば、ポリシーの組合せもまた、配信のために使用され特定されてもよい。
【００３７】
トランスポート属性に基づくデータオブジェクトの操作および配信は、ルールエンジン２１３によって制御される。例えば、或るソフトウェアシステムは、オブジェクトウェアハウスによって生成されている信号からの利益を得てもよい。配信ポリシーおよびセキュリ手順のような、オブジェクトウェアハウスによって実施されるアルゴリズムは、ルールエンジン２１３によって実施されてもよい。ルールエンジン２１３は、アルゴリズムを実施するためのルールをアクセスしてもよい。このルールは、例えば入力として属性を受信してもよく、信号を生成してオブジェクトウェアハウス２００Ｂから１又は２以上のソフトウェアシステムに送信してもよい。例えば、データオブジェクト２２０Ａは、レプライ(replies)２２０Ｂとしてトランスポートリクエスト（例えば、ゲット）に送信されてもよい。しかしながら、リクエストまたは返信(replies)２２１（例えば、時間遅延された、または自動化された返信）は、ルールエンジン２１３において実行されるルールに基づき自動的に１又は２以上のソフトウェアシステムにデータオブジェクトを伴って送信されてもよく、またはデータオブジェクトを伴わずに送信されてもよい。格納されたトランスポート属性に基づくデータオブジェクトの配信またはデータオブジェクトを操作するための種々のルールのうちの何れかが特定されてもよい。以下に詳細に述べられるオブジェクトウェアハウス行政運営ソフトウェアシステム(an object warehouse administrative management software system)を用いて新たなアルゴリズムが付加されてもよい。
【００３８】
図３は、本発明の一実施形態によるオブジェクトウェアハウスを用いて情報を交換する方法を図示する。３０１では、第１トランスポートリクエストは、第１ソフトウェアシステムから受信される。トランスポートリクエストは第１属性を含んでもよく、ここで、第１トランスポート属性は、少なくとも一つのデータオブジェクトと関連する。３０２では、データオブジェクトは貯蔵部に格納される。３０３では、第２トランスポートリクエストが第２ソフトウェアシステムから受信される。第２トランスポートリクエストは第２属性を含んでもよい。３０３では、第１および第２トランスポートリクエスト属性は、所定のアルゴリズムを用いて処理されてもよく、その後、データオブジェクトまたはそのデータオブジェクトのリファレンスが第２ソフトウェアシステムに送信される。例えば、アルゴリズムは、配信またはセキュリティポリシーを特定するルールであってもよい。ルールは、貯蔵部に格納され、そして特定の属性を有するソフトウェアシステムに対する読み取りアクセスを可能とするためのルールエンジンによってアクセスされてもよい。
【００３９】
＜例１＞
持続性のウェブアーキテクチャ(PERSISTENT WEB ARCHITECTURE)
図４は、インターネット上で利用可能なソフトウェアサービス（即ち、“ウェブサービス”）として実施されるオブジェクトウェアハウス（“ＯＷ”）の例である。この例では、車両センサ(vehicle sensor)４０１、アプリケーション４０２−４０３、またはＯＷマネージャ４０４のようなソフトウェアシステムは、ウェブサービスインターフェイスを介してオブジェクトウェアハウス４１０のサービス４３１−４３５を起動してもよい。各アプリケーションは、ＯＷ４１０に含まれる接続マネージャ４２０との接続を確立してもよい。ＯＷ４１０に対する接続は、例えば、シリアルに（一度に一つづつ）、またはパラレルに（重複する時間での複数の接続）確立されてもよい。この例では、情報は、接続４０１Ａを介して、車両センサ４０１とＯＷ４１０との間で交換されてもよい。同様に、情報は、他の接続４０２Ａを介して、車両ソフトウェアアプリケーション４０２とＯＷ４１０との間で交換されてもよい。車両システム４０１と４０２の両方とも、ＷｉＦｉ、ＣＤＭＡ、ＧＳＭ、或いはＷｉＭａｘのようなワイドエリアネットワーク４５０を用いてインターネット４６０に対する接続を確立してもよい。ＯＷ４１０は、また、接続４０３Ａを介して１又は２以上のＥＰＲ(Enterprise Resource planning)アプリケーション４０３に接続されてもよく、上記接続４０３Ａは標準のインターネット接続であってもよい。ＯＷ４１０は、また、オブジェクトウェアハウスに関する種々の管理機能を実施するために接続４０４Ａを介してオブジェクトウェアハウスマネージャ４０４に接続されてもよい。
【００４０】
車両または他の移動体装置のケースでは、このような接続は、制約された無線接続、またはアプリケーションまたはそのホスティングプラットフォームのチューニングオフ（即ち、車両または携帯電話のチューニングオフ）の何れかのために断続的(intermittent)であってもよい。本発明の或る実施形態の特徴および利点は、ソフトウェアシステムのうちの一つが利用できないときに、ソフトウェアシステム間で情報を交換するための能力を含む。例えば、オブジェクトウェアハウスが持続的であるので、情報は、受信者の電源が投入され、活性化され、あるいはインスタンス化される前に送信されてもよい。例えば、アプリケーションまたはソフトウェアサービスは、同一のアプリケーションまたはサービスの他の部分（例えば、アルゴリズムにおける異なるポイントで、または異なる内部コンポーネントによって使用され生成されるデータについて）による使用のためにＯＷにデータオブジェクトを送信してもよい。或いは、アプリケーションまたはサービスは、他のアプリケーションまたはソフトウェアサービスが後で（例えば、アプリケーションまたはサービスが更なるデータを処理するために利用可能であるときに）データオブジェクトを読み出すように、データオブジェクトを生成し、そのデータオブジェクトをＯＷに格納してもよい。他の例として、ソフトウェア更新またはメッセージが、移動体システム（例えば、電話または車両）のユーザに送信されてもよく、その電話または車両の電源が投入されているときに、その移動体システムは、そのＯＷに対する接続を確立し、情報が自動的に読み取られる。一実施形態において、ＯＷは、ＯＷがＷＡＮ接続の広範囲にアクセス可能とするために、インターネット４６０上の持続性のあるアドレスに配置される。上述したように、ソース及び／又はターゲットのソフトウェアシステムの属性は、広範な種々の所定の配信またはセキュリティアルゴリズムに従ってデータオブジェクトの適切な配信を確保するために使用されてもよい。以下に詳細に説明するように、アルゴリズムは、接続のタイプに基づき実行されてもよく、その接続タイプに特有な認証の形式（例えば、“ｈｔｔｐ”接続のためのＳＳＬ認証交換）を含んでもよい。
【００４１】
この例では、ＯＷ４１０に対する接続が最初に確立され、それから各ソフトウェアシステムが、各特定のソフトウェアシステムに方向付けられたＯＷに格納されたオブジェクトのリストについてのリクエストを送信する。トランスポートリクエストは、内部接続４２１Ａを介してＯＷのコマンドインタプリタ４３０に渡される。例えば、もしリクエストがリスト命令を含むと判定されれば、“リストトランスポートリクエスト(List Transport Requests)”処理４３２（即ち、自分のために保持されたリストオブジェクト）に引き渡されてもよい。これは、例えば、プライベートソケット４３２Ａを用いて発生してもよい。処理４３２は、特定のソフトウェアシステムのために保持されているオブジェクトを検索するためのオブジェクトデータベース４４０に対するクエリー４３２Ｂを形成し、そして、そのオブジェクトを格納するデータベース４４０に対するクエリー４３２Ｂを実行してもよい。一実施形態において、その結果は、確立された接続を用いて、リクエストを発しているソフトウェアシステムに対する応答の中に構築されたプライオリティであってもよい。データオブジェクトのリストは、例えば、ユーザが読み取りのためのデータオブジェクトのうちの１又は２以上を選択してもよいように、ソフトウェアシステムに返送されてもよい。
【００４２】
リクエストを発しているソフトウェアシステムは、そのリストを受信し、そのオブジェクトの何れかが読み取りを望むのであれば、どちらが読み取るかを決定してもよい。そして、ソフトウェアシステムは、“プルトランスポートリクエスト(Pull Transport Request(s))”処理４３３（即ち、“自分のために保持されたオブジェクトのピックアップ(Pickup Object Held for Me)”）を活性化するためにインタープレットされるＯＷに命令を送信してもよい。このリクエストは、ＯＷのコマンドインタープリタ４３０へのオープン接続を介して配信されてもよい。そして、それは、プライベートソケット４３３Ａを介して“プルトランスポートリクエスト(pull Transport Request(s))”処理４３３に伝送される。その処理は、オブジェクトをフェッチするためのクエリーを形成し、それをソフトウェアサーバに戻す。一実施形態において、オープン接続は、このトランザクションのために使用されてもよい。加えて、ＯＷ４１０は、一度に一つのオブジェクトをプル(pull)するための命令を含んでもよく、或いは一つのトランザクションにおいて複数のオブジェクトをプルするための命令を含んでもよい。
【００４３】
ソフトウェアシステム４０１−４０４のうちの任意の一つは、ＯＷ４１０に格納されるべきデータオブジェクトを含むトランスポートリクエストを発行してもよい。例えば、ＥＲＰアプリケーション４０３は、“ピックアップのためのドロップオフオブジェクト(Dropoff Object for Pickup)”にリクエストする接続４０３Ａを介してオブジェクトトランスポートリクエスト（“ＯＴＲ(Object Transport Request)”）を発行してもよい。このＯＴＲは、コマンドインタープリタ４３０に到達し、そして、ポストトランスポートリクエスト(post transport request)処理４３１（即ち、“ピックアップのためのドロップオフ”）に送られる。そして、この処理は、他のソフトウェアシステムによるピックアップのために格納されているオブジェクトのデータベースにＯＴＲを付加するためのクエリーを形成してもよい。
【００４４】
上述したように、ＯＷ４１０は、また、ＯＷ上の種々の管理機能を実行するためのオブジェクトウェアハウスマネージャ４０４に接続されてもよい。例えば、ＯＷ４１０の動作のログがとられ、このログは、ＯＷマネージャアプリケーション(OW Manager Application)４０４によってアクセスされてもよい。加えて、ＯＷ４１０の内部ワーキング属性は、ＯＷマネージャアプリケーションによって調整されてもよい。ＯＷマネージャアプリケーションは、オブジェクトトランスポートリクエスト（“ＯＴＲ”）の形式でＯＷにコマンドを配信してもよく、ここで、配信されているデータオブジェクトは新たなＯＷコマンドである。この新たなコマンドは、ポストＯＷオブジェクト処理４３４（即ち、“ＯＷにおける格納のためのオブジェクト”）を用いてＯＷに格納されてもよい。ＯＷ４１０は、コマンドインタープリタ４３０を介してマネージャアプリケーション(Manager Application)４０４にＯＴＲを配信するＯＷマネージャアプリケーションに対する応答を生成してもよい。ＯＷによって生成されたＯＴＲ応答は、ポストトランスポートリクエスト処理４３１に送られる。従って、次のＯＷマネージャアプリケーション４０４は、保持されているオブジェクトのリストを要求し、それは、ピックアップを待つ応答オブジェクトが分かる。図４を参照して上述した実施例は、単なる一つの実施例に過ぎない。
【００４５】
上述したように、ＯＷは、例えばイベントが発生したときに信号をソフトウェアシステムに送る（即ち、コールバック）する能力を支援する。例えば、ＯＷ４１０は、ＯＷマネージャ４０４について記述された同一のドロップオフ／ピックアップのメカニズムを用いて新たなルールを備えるルールエンジン４３６（“ＲＥ”）を含んでもよい。このケースでは、ＯＴＲは、ＯＷによってピックアップされるべきシステムまたは任意のアプリケーションによってドロップオフされる。これらのＯＴＲにおけるオブジェクトは、ＯＷがアプリケーションまたはソフトウェアシステムに首尾よく信号で伝えること（コールバック）を可能にするためのルール定義または属性を含んでもよい。このルールは、“マネージャＯＷルール(Manager OW Rules)”処理４３５によってＯＷの内部で管理されてもよい。そのルール自体は、データベース４４０に格納されてもよく、クエリーを介してアクセスされてもよい。
【００４６】
＜例２＞
送信者／受信者の属性マッチング(SENDING/RECIPIENT ATTRIBUTE MATCHING)
図５は、本発明の他の実施形態による情報交換方法を図示する。この例では、トランスポートコントローラは、データオブジェクトを含むトランスポートリクエストを受信し、このデータオブジェクトを格納し、そしてこのデータオブジェクトをトランスポートリクエストの属性に基づき受信者に送信する。例えば、オブジェクトウェアハウス（“ＯＷ”）５００は、第１トランスポートリクエスト５１０を受信するトランスポートコントローラ５０１を含んでもよい。トランスポートリクエスト５１０は、属性情報５１１Ａと関連データオブジェクト５１１Ｂを含んでもよい。この例では、属性情報は、“プロクラメーション(proclamation)”とＯＷ５００にデータオブジェクトを“デポジット(deposit)”するための命令を含んでもよい。このプロクラメーションは、データオブジェクトを読み取る（即ちピックアップする）ための基準を規定する属性である。この例では、上記プロクラメーションは、データオブジェクトの対象受信者を記述してもよい。
【００４７】
トランスポートリクエスト５１０がトランスポートコントローラ５０１によって受信されると、トランスポートコントローラは、その受信されたトランスポートリクエストから属性を含むタグ（またはレコード）を生成してもよい。従って、データオブジェクトがＯＷ５００によって受信されると、複数のタグ５０４が生成されてもよい。これらのタグは、種々のフォーム(form)または形式(format)でシステムに格納され、一緒に受信されたデータオブジェクトと関連づけられる。例えば、一実施形態において、生成されたタグ５０４はデータベース５０３に格納されてもよく、各タグは、データオブジェクト（例えば、同一のデータベースまたは他のデータベースにおけるデータオブジェクト）と関連づけられてもよい。他の例として、タグは、データオブジェクトと関連するオブジェクトであってもよい。或る時点で、システムは、トランスポートリクエスト５１０の属性に記述された目標の受信者（単数または複数）からトランスポートリクエスト５１２を受信してもよい。トランスポートリクエスト５１２は、また、属性情報５１３を含んでもよい。ここで、属性情報５１３は、“ゲットリスト(GetList)”命令と“デクラレーション(declaration)”を含む。デクラレーションは、リクエスト５１２のイニシエータ(initiator)に関する情報を識別することを提供してもよい。例えば、属性情報は、トランスポートリクエスト５１２の送信者を記述してもよい。第２トランスポートリクエスト５１２の受信に応答して、システムは、トランスポートリクエスト５１２から属性情報を含む他のタグを生成してもよい。この例では、ＯＷ５００は、このＯＷにデータオブジェクトをデポジットしたトランスポートリクエストからの属性情報と、リクエスト５１２からの属性情報とを比較するマッチングソフトウェアコンポーネント５０２を含む。このマッチングコンポーネントは、トランスポートコントローラ５０１の一部または別個のコンポーネントであってもよい。もしトランスポートリクエスト５１２における属性情報５１３が、例えば、タグ５０４における属性情報５１１Ａと一致すれば、応答５１４がトランスポートリクエスト５１４の送信者に送信され、読み取り可能なデータオブジェクトが存在することを示す。例えば、データオブジェクトを記述する属性がリスト５１６に付加されてもよい。従って、リスト５１６は、トランスポートリクエスト５１２の属性情報と一致した関連タグを有する全てのオブジェクトを識別してもよい。このリストは応答５１４において送信されてもよい。アプリケーション、ユーザ、車両、または他のＯＷは、例えば、そのリストに関して識別されたデータオブジェクトのうちの１又は２以上を読み取るための他のトランスポートリクエスト５１６を生成してもよい。トランスポートリクエスト５１６は、“デクラレーション”におけるトランスポートリクエスト５１６の送信者を記述する情報と“ピックアップ”命令を含む属性情報５１７を含んでもよい。トランスポートリクエストにおける“ピックアップ”命令の受信に応答して、システムは、トランスポートリクエスト５１６における属性情報に基づき他のタグを生成してもよい。そして、マッチングコンポーネント５０２は、その属性情報���各タグ５０４における属性情報と比較し、各マッチングタグと関連するデータオブジェクト５１９を、応答５１８においてリクエスト５１６の送信者に返送してもよい。データオブジェクトの読み取りに先立ってリストを読み取るステップが、或るアプリケーションではオプションであってもよいことが理解される。同様に、他のアプリケーションでは、データオブジェクト自体ではなく、適格なデータオブジェクトのリストを読み取ることが望ましい。
【００４８】
他の実施形態では、各タグ５０４はタグＩＤを含んでもよく、リスト５１５は、トランスポートリクエスト５１２における属性情報と一致するタグのタグのＩＤを戻してもよい。この実施形態では、トランスポートリクエスト５１６は、読み取られるべきタグＩＤを格納するための１又は２以上の属性と“ピックアップ”命令を含んでもよい。トランスポートリクエスト５１６の受信に応答して、ＯＷ５００は、トランスポートリクエストにおいて特定されるタグＩＤを有する各タグをアクセスし、応答５１８において各タグと関連するデータオブジェクトを戻してもよい。
【００４９】
図６は、本発明の他の実施形態による情報交換方法を図示する。６０１では、第１トランスポートリクエストが受信され、この第１トランスポートリクエストは、データオブジェクトの受信者を記述する属性情報とおそらくは他の属性情報（例えば、データオブジェクトを記述する情報）とを含む属性情報と、データオブジェクトを有する。６０２では、データオブジェクトが格納される。６０３では、タグが生成される。このタグは、データオブジェクトの受信者とおそらくは他の情報とを記述するトランスポートリクエストからの属性情報を有する。６０４では、タグは、データオブジェクトと関連付けられる。例えば、タグとデータオブジェクトは一緒に格納されてもよく、或いは、タグとデータオブジェクトは個別に別々に格納されて、種々のソフトウェアプログラミング技術（例えば、ポインター、インデックス、或いはＩＤ）を用いて関連づけられてもよい。６０５では、タグは、後のアクセスにために格納される。６０６では、他のトランスポートリクエストが受信される（即ち、“第２”トランスポートリクエスト）。この第２トランスポートリクエストは、それらを受信者として指定するデータオブジェクトを受信することを望むエンティティからのものであってもよい。データオブジェクトを伴う任意の数の追加のトランスポートリクエストは、目標の受信者が読み取りを起動する前に受信されてもよい。従って、目標の受信者は、複数の異なるソースから複数の異なる通信媒体を介して彼らに送信された複数のデータオブジェクトを読み取ってもよい。６０７では、他のタグが、第２トランスポートリクエストからの属性を用いて生成される。６０８では、第１および第２トランスポートリクエストからの属性が比較される。例えば、第２トランスポートリクエストから生成されたタグにおける属性は、データオブジェクトをデポジットしたトランスポートリクエストの受信に応答して生成された多くのタグと比較されてもよい。この比較は、上述のようなマッチングコンポーネントによって実施されてもよい。もし一致すれば、１又は２以上のデータオブジェクトまたはデータオブジェクトのリストが、第２トランスポートリクエストの送信者に返送されてもよい。他の実施形態では、例えばリンクのようなオブジェクトに対するアクセス情報が返送されてもよく、システムがオブジェクトを取得するためにそのアクセス情報を使用する。
【００５０】
或る実施形態では、１又は２以上のタグは、それぞれエイリアスリスト(alias list)に関連づけられてもよい。例えば、タグは、目標の受信者（単数または複数）を記述する属性情報を含んでもよい。しかしながら、目標の或る受信者は別の様式で記述されてもよい。例えば、目標の受信者を記述する一つの方法はネームによる。しかし、単一の受信者は、別のコンテキストにおいては別のネームを使用してもよい。例えば、人物(person)は、joe.smith@domain1.com，jsmith@domain2.com，js@domain3.comのような複数の電子メールアドレスによって識別されてもよく、それらはすべて、同一の人物に対して有効な電子アドレスである。従って、エイリアスリストは、受信者（単数または複数）の複数の代替記述と共に追加の属性を含んでもよい。他の例としては、受信者のクラス、即ち、カリフォルニア州におけるＢＭＷの所有者を記述するために、“CA BMW OWNERS”、“CALIFORNIA BMW OWNERS”、“CA BMW”などがある。受信者の任意の記述が本発明の別の実施形態において使用され、このような受信者の任意の適切な代替記述が、エイリアスリストに含まれ、タグと関連づけられてもよいことが理解される。従って、もし６０９で一致しなければ、第２属性情報は、あるとすれば、各タグと関連するエイリアスリストと比較される。もしエイリアスリストにおける属性と一致すれば、６１２で、関連するデータオブジェクトが送信され、或いはアクセスされる。もし一致しなければ、データは返送されない。例えば、読み取りに使用可能なデータオブジェクトが存在しないことを示すメッセージが送信されてもよい。
【００５１】
本発明の実施形態は、デジタルオブジェクトウェアハウス（“ＯＷ”）において使用されることができる参加者(participants)についてのユニークな識別を用いた情報交換方法を含む。上述したように、参加者は、例えば、ソフトウェアアプリケーション、車両、移動体装置、他のＯＷを含む。一実施形態において、参加者は車両であり、ＯＷは、車両オブジェクトウェアハウス（“ＶＯＷ”）と称される。他の実施形態において、参加者は、他のタイプの移動体システム（例えば、携帯電話、ポータブルコンピュータ、ＰＤＡ(Personal digital assistants)、または、携帯ミュージックシステム、携帯ビデオシステム、または携帯ゲームシステムのような携帯娯楽システム）である。
【００５２】
ＯＷの一実施形態において、参加者は、オブジェクトを受信することが許容される参加者を部分的に指定する“プロクラメーション(proclamation)”と一緒にデータオブジェクトをデポジットする。その後、参加者は、ピックアップ参加者の“ネーム”を含む“デクラレーション(declaration)”を用いてＯＷと接続する。参加者は、携帯電話(mobile)であってもよく、役割の変更において作動することができる。或るアプリケーションにおいては、このことは、単一の参加者を記述するために使用されている複数の優れた“ネームフォーム”をもたらす。更に、異質(heterogeneous)の通信媒体は、無用でないにせよ、従来のネーム／アドレスバインディングを複雑にする。本発明の或る実施形態は、これらの複雑なネーミング条件に応答するユニークな方法を提供すると共に、持続的な“ネームフォーム”バリエーションだけでなく、全く新しいネームフォームの導入を可能にする。
【００５３】
一実施例において、ＯＷは、“プロクラメーション(proclamationa)”と“デクラレーション”における属性情報とのマッチングを行うと共にピックアップ可能なデータオブジェクトを決定する“ルックアップ”機能を提供する。一実施形態において、ＯＷは、単一のＱＳＬクエリーに基づくルックアップ機能を使用する。この実施は、デクラレーションとプロクラメーションが共通でシンプルなネームフォームを含む場合に有用である。他の実施例において、ルックアップ機能は、単一の参加者が有する多数の異なる“ネームフォーム”と多くの異なるネーム（例えば、上述したようなエイリアス）を取り扱うために必要とされる。従って、エイリアスリストを使用する拡張方法論は、ルックアップ機能の拡張性と複数のネームフォームを支援するために使用される。
【００５４】
ＯＷの実施形態は、広範な種々のアプリケーションと技術環境に適用可能である。従って、ＯＷ参加者についての広範な複数の“ネーム”と“ネーム空間”との結合を取り扱う方法の問題は、特定の例としてアドレス(address)である。上述したように、プロクラメーションとデクラレーションにおいて使用される参加者ネームは、異なるネームフォームを有し、異なるネーミングドメインに及んでもよい。しかしながら、このようなネーム及び／又はネームフォームは同一の参加者に関してもよい。例えば、ネームは、代表的には、フォームと定義を有する構文(syntax)で表現される。フォームは、標準団体あるいは通信コンプライアンス団体（例えば、ＷＷＷコンソーシアム、ＩＥＴＦ、ＮＡＮＤＣ、ＥＰＣグローバル、ＤＯＩ）によって提供されてもよい。いかなるフォームの定義も、通常、或る登録処理(registration process)またはドメイン登録(domain registry)によって割り当てられる。異なるシステムは、代表的には、互いに分離され、あるいは或るネーミング交換ファシリティを通じて連合(federate)される。しかしながら、たとえデジタルオブジェクトの分野における全てのオブジェクトがＤＯＩまたはＵＲＩのような共通ネームフォームを使用することに合意したとしても、ドメインオーソリティ間の配信ネーム定義の共通プラクティスは、依然として幾つかの問題を引き起こす。上述の例では、ユーザは、joe.smith@domain.com，jsmith@domain2.com，js@domain3.comのような異なるドメインにおいて異なるネームを有する。
【００５５】
再び図５を参照すると、一実施例において、ＯＷ５００は、参加者（例えば、車両、アプリケーション、または他のウェブサービス）からのトランスポートリクエストを処理するように設計されたウェブサービスのセットとして実施されてもよい。トランスポートリクエストは、ＯＷが実行すべきサービスを選択する命令を含んでもよい（例えば、デポジット５１０、ゲットリスト５１２、ピックアップ５１６）。データオブジェクトは、オブジェクトをピックアップするための基準を与える“プロクラメーション”と一緒に“デポジット”命令で参加者によってＯＷに配信されてもよい。プロクラメーションは、ウェブサービス（単数または複数）（例えば、ウェブサービスとして実施されるトランスポートハンドラ）によって処理され、そしてタグが形成されてタグデータベース５０３に格納される。しばらく後で、他の参加者または同一の参加者は、参加者の属性の識別を提供するデクラレーションと一緒にＯＷにトランスポートリクエスト５１２におけるゲットリスト(GetList)命令を配信する。ウェブサービスは、他のタグを生成するためにデクラレーションを処理する。ウェブサービスは、マッチングコンポーネントを使用して、参加者のタグと一致するタグＤＢ５０３における全てのタグについてルックアップ機能を実行する。そして、ＯＷは、一致するオブジェクト貯蔵部５０５におけるオブジェクトのリスト５１５を送信する。このリストは、例えば優先順位がつけられる。
【００５６】
図７は、本発明の他の実施形態による情報交換方法の例を示す。この例では、参加者によって提供されるデクラレーション７１０とプロクラメーション７００は、マルチ属性ｘｍｌデータ構造であってもよい。この例における属性情報は、“ネームフォーム”および“ネーム”属性を含む。この属性情報は、バージョン７０１，７１１属性を更に含み、データ構造を提供するアプリケーションの等級(vintage)と、有効期限(expiration)７０４，７１４と、種々の他の属性７０５，７１５を簡単に示す。ＯＷは、プロクラメーション７００の属性７０１−７０５を構文解析(parse)してタグ７２１を生成し、そしてタグ７２１をタグＤＢ７２０に格納する。同様に、ＯＷは、デクラレーション７１０の属性７１１−７１５を構文解析することによりゲットリスト(GetList)命令７４０を処理して他のタグ７４１を生成する。この例では、マッチングコンポーネントは、マッチングルールエンジン７６０として実施される。マッチングルールエンジン７６０は、マッチング基準の柔軟性と拡張性を維持するために異なるルールを用いて修正されてもよい。ＯＷは、マッチングルールエンジン７６０を用いてルックアップ機能を実施する。ルックアップ機能によって見つけられる全ての一致７５０は、リスト７４２を介してピックアップ参加者に戻されてもよい。
【００５７】
図８は、本発明の他の実施形態による属性情報の例を示す。一実施形態において、トランスポートリクエストにおける属性情報のフォーマットは、タグにおける他のフォーマットに変換されてもよい。例えば、ＯＷは、その提示されたネームフォームからの参加者ネームをタグにおける他のフォームに変換してもよい。一実施形態において、ネームおよびネームフォームのような属性情報は、例えばタグＩＤ(tag identity)にエンコードされてもよい。加えて、属性情報は、以下に更に詳細に説明するように、“クラス”または“グループ”を特定するために使用されてもよい。タグにおいて使用されるフォーマットは、ルックアップ機能（例えば、マッチングルールエンジンにおける機能）を促進するように設計されてもよい。もしネームについてエイリアスが存在すれば、そのエイリアスインデックスはタグに含まれてもよい。もしエイリアスマッチングが許容されれば（それはデフォルトであってもよい）、マッチングルールエンジンは、また、ルックアップについて一致を探しながら、エイリアスインデックスを検討する。図８に例示されているように、プロクラメーションとデクラレーションは、他の情報との間で、参加者を記述するネームフォーム８１１およびネーム８１２のフォームで参加者の識別８００を含んでもよい。８２０に示されるように、参加者ＩＤ８０１，８０２，８０３，８０４の多くの例が存在する。ネームフォームは、インターネットプロトコル（ＩＰ）アドレス、デジタルオブジェクトＩＤ（“ＤＯＩ”）、ユニバーサルリソースロケータ（“ＵＲＬ”）、および北アメリカナンバリングプラン（“ＮＡＮＰ”）のフォーマットでの電話番号を含む。これらは、参加者ＩＤにおいて使用される異なるネームフォームのわずかな例にすぎない。他のものは、例えば車両識別番号である。テーブル８４０は、トランスポートリクエストにおいて受信された一例の参加者ＩＤのそれぞれについて結果として得られるタグ８５０の例である。この例のタグ８５１，８５２，８５３，８５４は、それぞれ、アイデンティティインデックス８２１、クラスＩＤ８２２、エイリアスインデックス８２３、常駐ＯＷＩＤ８２４からなる。アイデンティティインデックスは、タグのアクセスを促進するのに有用な内部コードに結合(combine)されたネームフォームとネームの内部的表現であってもよい。加えて、クラスの例は、自動車、文書、音楽、ごくわずかのネームへの電話であってもよい。エイリアスインデックス８２３は、マッチング中にタグについて使用されるべきエイリアスリストを特定してもよい。最後に、ＯＷＩＤ８２４は、特定のＯＷが参加者についての駐在ＯＷであることを示してもよい。
【００５８】
図９は、本発明の他の実施形態による情報交換の一例を示す。この例は、デポジット９１１リクエストを介してＯＷ９００に配信されているプロクラメーション９０１の動作シーケンスを追跡する。この例では、ネームフォーム９０２とネーム９０３は、変換処理９１５を経由して、タグ９２０を生成する。そして、このタグはタグＤＢ９２５に格納される。その後、デクラレーション９３１は、ゲットリストトランスポートリクエスト９１２を介してＯＷに配信される。デクラレーションネームフォーム９３２とネーム９３３は、変換処理９１５を経由して処理されて、タグ９４０が生成される。マッチングルールエンジン９５１は、一致を見つけ出すために、タグＤＢにおけるエントリに対してリクエスト９１２からの属性情報を比較してもよい。この図解は、関連エイリアスリストを用いてタグ９２０とのマッチングを示す。そして、タグ９２０についてのタグＩＤは、全てのマッチングタグがタグＤＢ９２５において見つけられた後に、ゲットリストリクエストを行った者に戻されるべきメッセージリスト９５２に配置(put)される。
【００５９】
図１０は、本発明の他の実施形態によるマッチング技術の別の例を示す。この例は、マッチングの４つの異なる例を示す。タグ１０１１，１０１２，１０１３，１０１４は、全て、過去のプロクラメーションからのもののであり、タグＤＢに配置される。図１０の下の部分は、到来するデクラレーションからのタグ１０２１を示す。マッチングルールエンジン１０３１は、タグ１０２１についてのルックアップ手順を処理し、そして次のマッチングを見つける：（ｉ）タグ１０１１とのマッチング１０３１は、適格なアイデンティティマッチアップ(exact identity match up)であり、何故ならば、プロクラメーションにおけるエンコードされたネームフォームとネームとデクラレーションは同一であるからであり、（ｉｉ）タグ１０１２とのマッチング１０３２は、クラスマッチアップであり（アイデンティティが一致しなくても、タグは同一のクラスを有し、それは、或るマッチング或るマッチングアルゴリズムにより十分である（例えば、マッチングルールエンジンにおけるルール））、（ｉｉｉ）タグ１０１３とのマッチング１０３３は、エイリアスマッチングであり（アイデンティティが一致しなくても、タグ１０１３と関連するエイリアスリストは、一致する属性情報を含む）、（ｉｖ）マッチング１０３４はＯＷマッチングである（アイデンティティ、クラス、エイリアスが一致しなくても、例えば、マッチングアルゴリズムまたはルールは、プロクラメーションが配信された同一のＯＷに到来する任意のデクラレーションについて一致を受け入れてもよい）。
【００６０】
＜例３＞
参加者のグルーピング(PARTICIPANT GROUPING)
本発明の或る実施形態によるオブジェクトウェアハウスは、受信者のクラスまたはグループへのデータオブジェクトの送信を支援する。グループは、グループネームによってトランスポートリクエストにおいて参照される受信者の列挙(enumerated)されたセットである。例えば、グループネームがプロクラメーションにおいて提供される場合、グループの任意のメンバーは、ＯＷからオブジェクトをピックアップする権利が与えられる。クラスは、クラスネームによってトランスポートリクエストにおいて参照される受信者の非列挙(non-enumerated)のセットであり、ここで、クラスの任意のメンバーは、ＯＷからオブジェクトをピックアップする権利が与えられる。クラスを用いた情報交換は、上述の属性マッチング技術を用いて実施されてもよい。或る実施形態では、グループまたはクラスを構成する参加者のセットは、ＯＷの外部の登録処理(registration process)によって管理されてもよく、構成員(membership)はＯＷに伝達されてもよい（例えば、前述したように動的に）。
【００６１】
図１１は、本発明の他の実施形態によるグループに基づく情報交換の例を示す。図１１の例は、ＯＷの動作において使用されるグループの削除、維持、生成の方法を示す。上述したように、ＯＷの実施例は、オブジェクトの読み取りが許容される参加者（単数または複数）を部分的に指定するプロクラメーションと一緒に、参加者がオブジェクトをデポジットすることが許可される。その後、参加者は、ピックアップ参加者のネームを含むデクラレーションでＯＷと接続する。しかしながら、この例では、プロクラメーション１１００は、グループネーム１１０３（例えば、コミュータ）および“グループ”のネームフォーム１１０１を含む。従って、グループの任意のメンバー（例えば、コミュータ）は、オブジェクトをピックアップする権利が与えられる。グループは、多くの参加者が共通のグループネームの下で組織化(organize)されることを可能にする。以下に更に詳細に説明するように、グルーピングは静的または動的であることができる。
【００６２】
図１１を参照すると、データオブジェクトは、このオブジェクトをピックアップするための基準を提供するプロクラメーション１１００と一緒にデポジット命令１１３０でデポジット参加者によってＯＷに配信される。プロクラメーション１１００は、ウェブサービスによって処理されてもよく、タグ１１２１が生成されてタグデータベース１１２０に格納されてもよい。プロクラメーションにおける属性情報は、目標のグループを記述するネーム（またはグループネーム）とグループ（例えば静的グループ−“標準グループ”）としてデータオブジェクトの受信者を記述するネームフォーム１１０１を含んでもよい。ＯＷは、ネームがグループであることを示す属性を受信し、ネーミングされたグループについてのグループ情報をアクセスしてもよい。ネーミングされたグループについてのグループ情報は、そのグループの各受信者を記述する情報を含む。グループネームはＯＷによって処理され、タグはグループの各参加者メンバーについて生成される。グループ情報のアクセスと、グループ属性の受信に応答したタグの生成は、例えば、グループルールエンジン１１４１によって実施されてもよい。各参加者についての生成されたタグ１１２２は、タグデータベース１１２０に格納される。しばらくして、他の参加者が、ピックアップ参加者を記述する属性情報を提供するデクラレーション１１１０と一緒にＯＷにゲットリスト命令１１４０を配信する。ＯＷは、デクラレーション１１１０を処理して、タグ１１５０を生成する。そして、ＯＷは、マッチングルールエンジン１１６０を使用して、タグデータベース１１２０における全てのタグをタブ１１５０と比較する。そして、ＯＷは、マッチングタグ１１２２に関連する適格なオブジェクトのリスト１１４２をピックアップ参加者に送信する。
【００６３】
上述したように、他の実施形態ではグループは動的である。例えば、再び図１１を参照すると、データオブジェクトは、目標の動的グループを特定するネーム（またはグループ）と動的グループ（例えば“Ｄｙｎ−Ｇｒｏｕｐ”）を特定するネームフォーム１１０２を有するプロクラメーション１１００と一緒にデポジット命令１１３０でデポジット参加者によってＯＷに配信されてもよい。ＯＷは、例えば、ネームフォームが動的グループであることを特定する属性を受信し、タグ１１２１を生成してタグデータベース１１２０に格納してもよい。グループネームは、タグデータベースに格納されたタグに保存されてもよい。しばらくして、他の参加者が、ピックアップ参加者の属性の識別を提供するデクラレーション１１１０と一緒にＯＷにゲットリスト命令１１４０を配信する。ＯＷは、デクラレーション１１１０を処理してタグ１１５０を生成する。そして、ＯＷは、グループエンジン１１４１を使用して、タブデータベース１１２０における動的グループタグの全てについての機能を実行して、いまやピックアップ参加者が動的グループのうちの一つのメンバーであるかどうかを決定する。例えば、グループエンジンは、グループ構成員を動的に追跡するグループ制御コンポーネント１１９０をアクセスしてもよい。動的グルーピングの例は、加入(sabscriptions)を含む。加入において、参加者の一つのグループがサービスについてサインアップし、それは、ルールまたはイベントに基づき加入者からグループを生成してもよい。サービスは、グループの参加者を修正するためのグループ制御コンポーネント１１９０を含んでもよい。一実施形態において、グループ制御コンポーネント１１９０はＯＷの一部である。一実施形態において、グループ制御コンポーネント１１９０はＯＷの外部にある。例えば、或る実施形態において、グループ制御コンポーネントは、タグデータベース１１２０における動的グルーピングを有するタグにおいて特定される各グループにどの参加者が存在するかを決定するために、ＯＷによってアクセスされるウェブサービスの一部である。一旦、グループの参加者が決定されると、ＯＷは、もし参加者がグループのうちの一つに存在すれば、そのピックアップ参加者について適格なオブジェクトのリスト１１４２を送信してもよく、そのリストは優先順位がつけられる。
【００６４】
この動的グルーピング能力で、情報は、情報のデポジット者によって示された条件に基づき迅速に形成される受信者のセットにマルチキャストされることができる。適格に動的になるにつれて、ピックアップについてオブジェクトの適格性(eligibility)をダブルチェックすることが必要になる。適格性は、最初に、参加者についての適格なオブジェクトのリストの構成がチェックされる。そして、適格性は、例えば、参加者がオブジェクトをピックアップするために戻ると再びチェックされ、なぜならば、或るアプリケーションでは、参加者の適格性は、リストの取得とオブジェクトのピックアップとの間のこの期間において変更されているかもしれないからである。
【００６５】
＜例４＞
ロケーションベースの処理(LOCATION BASED PROCESSING)
図１２は、本発明の他の実施形態による地理空間情報(geospatial information)に基づく情報交換の例を示す。この例において、トランスポートリクエストにおける属性情報は地理空間情報を含み、それは、また、幾何学(geometric)またはロケーション(location)属性または情報と称される。地理空間属性は、例えば、経度および緯度、高度、ＧＰＳ座標、または、ＯＷとの間でデータオブジェクトを送受信する参加者の地理空間のロケーションに関する他の任意の情報を含んでもよい。例えば、データオブジェクトは、地理空間の属性１２０１を含むプロクラメーション１２００と一緒にデポジット命令１２３０でデポジット参加者１２５１によってＯＷ１２２２に配信されてもよい。地理空間属性は、オブジェクトをピックアップするための地理空間の基準を提供してもよい。例えば、地理空間属性は、特定地域内の誰もがデータオブジェクトの受信者であってもよいように地域を定義してもよい（例えば、データオブジェクトは地域についての天候レポートであってもよい）。地理空間属性は、或る高度よりも高い場所にいる任意の参加者がデータオブジェクトを受信するように高度を定義してもよい（例えば、もしデータオブジェクトが凍結道路注意であれば）。地理空間属性情報は、それ単体で使用されてもよく、或いは、ＯＷに格納されたデータオブジェクトの受信者を記述するための種々の他の属性と一緒に使用されてもよい。プロクラメーション１２００は、ＯＷにおけるウェブサービスハンドラー１２４１によって処理されてもよく、タグ１２２１が生成されてタグＤＢ１２２０に格納されてもよい。プロクラメーションは地理空間情報１２０１を含むので、このような情報は、地理空間のソフトウェアコンポーネント１２６２（例えば地理空間エンジン）によって処理されてもよく、その結果は、タグ１２２１と一緒にタグＤＢ１２２０に格納される。
【００６６】
後の時点で、ピックアップ参加者１２５２は、ピックアップ参加者の地理空間属性１２１１を含むデクラレーション１２１０と一緒にＯＷ１２２２にゲットリスト命令１２４０を配信してもよい。ウェブサービスハンドラー１２４１は、デクラレーション１２１０を処理してタグ１２５０を生成する。デクラレーションは地理空間情報を含むので、このような情報は、ジオマット（ＧｅｏＭａｔ）エンジン１２６２によって処理されてもよく、その結果は、ピックアップ参加者タグ１２５０と一緒にマッチングルールエンジン１２６０に送信される。そして、ＯＷは、そのマッチングルールエンジン１２６０を使用して、ピックアップ参加者のタグ１２５０と一致するタグＤＢ１２２２における全タグについてルックアップを実行する。例えば、ジオマットエンジンは、属性情報を受信し、各参加者についての結合された地理空間情報を表すエンコードされた地理空間値を生成してもよい。換言すると、ＧＰＳ情報または経度および緯度は、単一のエンコードされた値に結合されてもよい。参加者１２５２のエンコードされた地理空間の値は、参加者１２５２についての地理空間情報が、地理空間情報１２０１によって特定される基準を満足するかどうかを決定するため、地理空間属性１２０１によって特定される値の範囲と比較される。ジオマットエンジンの結果は、ピックアップ参加者１２５３の地理空間属性がタグＤＢ１２２０におけるタグ１２２１の要件と一致(match)するかどうかを決定するために使用されてもよい。マッチングは、エンコードされた地理空間の値が、データオブジェクトをアクセスするための基準を定義するエンコードされた地理空間属性において同様に特定される範囲内に含まれるかどうかを決定することを含んでもよい。マッチングは、地理空間情報が、他の基準（例えば、経度、緯度、高度、ＧＰＳ座標、または他の地理空間の基準に応じて）よりも大きいか或いは小さいかを決定することを含んでもよい。もし基準が満足されれば、ＯＷは、この参加者について適格なデータオブジェクトのリスト１２４２を返送してピックアップする。
【００６７】
そして、参加者１２５２は、ピックアップされるべきオブジェクトの識別（例えば、前のゲットリスト応答から得られる）と地理空間の属性を含むデクラレーションと一緒にＯＷ１２２２にピックアップ命令１２４２を配信してもよい。ＯＷのウェブサービスハンドラー１２４１は、このリクエストを処理すると共に他のタグ１２５０を生成する。そして、データオブジェクトの識別とタグ１２５０は、マッチングコンポーネント１２６０に送信される。地理空間属性は、ジオマットエンジン１２６２に送信されてもよい。ジオマットエンジン１２６２とマッチングコンポーネント１２６０は、オブジェクトがこの参加者によるピックアップについて依然として適格であることを検証してもよい。もし、参加者の地理空間属性が、参加者がもはや適格でないように変わっていれば（例えば、もし、自動車のドライバーが地理空間属性１２０１によって定義された領域外を運転していれば）、参加者は、オブジェクトをピックアップすることはできない。しかしながら、もし地理空間属性が再び検証されて、もし参加者が依然として適格であれば、データオブジェクト１２４４は、リクエストしているピックアップ参加者１２５２に返送される。
【００６８】
＜例５＞
トークン(TOKENS)
図１３は、本発明の他の実施形態によるトークンを用いた情報交換の例を示す。この例では、オブジェクトウェアハウス１３００はトランスポートコントローラ１３０１を備え、このトランスポートコントローラ１３０１は、トークンがデータオブジェクトを読み取る必要があることを示す属性情報１３１１Ａとデータオブジェクト１３１１Ｂからなるトランスポートリクエスト１３１０を受信する。従って、もしＯＷ１３００が適切なトークンを含むトランスポートリクエストを受信すれば、ＯＷは、そのトークンを提供するシステムにデータオブジェクトを返送してもよい。この例では、データオブジェクト１３１１Ｂは貯蔵部１３０５に格納される。後の時点で、トランスポートリクエスト１３１２が受信され、それはゲットリスト命令１３１３を含む。ゲットリスト命令に応答して、ＯＷ１３００は、読み取りに使用可能なデータオブジェクトを特定するリスト１３１５を含む応答１３１４を生成してもよい。もし、データオブジェクトを読み取るためにはトークンが必要とされることを示す属性が１又は２以上ののデータオブジェクトにデポジットされれば、リスト１３１５は、トークンがこのようなデータオブジェクトを読み取るために必要とされることを特定してもよい。次に、トランスポートリクエスト１３１６が読み取られてもよく、それは、ピックアップ命令１３１６Ａとトークン１３１６Ｂを含む。トークンを受信すると、ＯＷ１３００は、そのトークンを有効にすることを試みてもよい。有効化は、受信されたトークンが、特定のデータオブジェクトを読み取るために必要なトークンとしての資格を得るかどうかを決定することを含んでもよい。もし、有効なトークンが受信されれば、データオブジェクト１３１９を含む応答１３１８が生成されて、適切なロケーションに送信され、または、オブジェクトに対するアクセスがトークンの送信者に利用可能とされてもよい。
【００６９】
図１４は、本発明の他の実施形態による情報交換の方法を示す。１４０１では、データオブジェクトを読み取るためにはトークンが必要であることを示す属性とデータオブジェクトを有する第１トランスポートリクエストが受信される。別の実施形態によるトークンは、種々の方法で特定されてもよいことが理解される。例えば、トークンは、単一のコンピュータエレメント、または複数のコンピュータエレメントであってもよい。或る実施形態では、トークンの全てがトランスポートリクエストで提供されてもよい。他の実施形態では、例えば、トークンの一部のみ（例えばリンク）がトランスポートリクエストで提供されてもよく、トークンの他の部分が例えば有効化処理(validation process)の一部としてアクセスされてもよく、或いは、以下に説明する消費処理(consumption process)の一部としてアクセスされてもよい。１４０２では、トークンを有する第２トランスポートリクエストが受信される。この例では、利用可能なデータオブジェクトのリストをアクセスする中間ステップが省略され、第２トランスポートリクエストが、データオブジェクトを読み取るためのトークンを提供する。本明細書で述べた本発明のいくつかの実施形態、またはその種々の組合せは、読み取りに利用可能なオブジェクトのリストをアクセスすることを含んでもよいが、全ての実施形態がこのステップを実施するとは限らない。１４０３では、トークンが有効化される。１４０４でもしトークンが有効であれば、データオブジェクトは、１４０６で第２トランスポートリクエストの送信者に送信されてもよい。しかしながら、もしトークンが有効化されていなければ、本システムは、データオブジェクトを返送しなくてもよい（例えば、アクセスが拒否されてもよい）。
【００７０】
図１５は、本発明の他の実施形態によるトークンを用いた情報交換の例を示す。本発明の実施形態は、プロクラメーションが、データオブジェクトをピックアップすることをリクエストするときにピックアップ参加者にトークンを配信することを要求することを可能とするオブジェクトウェアハウスを含む。更に、或る実施形態は、ＯＷによって生成されて排他的に消費されるセキュアＯＷ(secure OW)トークンを含む。従って、このようなアプリケーションでは、参加者は、オブジェクトをピックアップするためにトークンを処理して譲り渡す(surrender)ことを要求されてもよい。加えて、或る実施形態では、ＯＷトークンは、ＯＷの外部のオーソリティ(authority)を制御することにより、一覧が作成(inventory)され、及び／又は配信されてもよい。或るトークンは、一回だけ使用されてもよく、他のものは特定回数または無制限に使用されてもよい。
【００７１】
以下は、データオブジェクトが、どのようにしてトークンピックアップ要件でオブジェクトウェアハウスにデポジットされるのかについての例である。データオブジェクト１５４４は、オブジェクトをピックアップするためにトークンが必要とされることを示す属性１５０１を含むプロクラメーションと一緒にデポジット命令１５３０でデポジット参加者１５５１によりＯＷ１５２２に配信される。プロクラメーション１５００は、ＯＷのウェブサービスハンドラ１５４１によって処理され、任意のエンジン（例えば、プラグイングルーピングエンジン１５６１及び／又は地理空間的エンジン１５６２）によって処理され、そしてタグ１５２１が形成されてタグＤＢ１５２０に格納される。この例では、プロクラメーションは、トークン要求属性(token required attributes)１５０１を含む。従って、この例は、プロクラメーション属性を処理するためにトークンエンジン１５６３を使用する。その結果として得られるトークン情報は、タグＤＢ１５２０にタグ１５２１と一緒に格納される。
【００７２】
しばらくして、ピックアップ参加者１５５２は、ピックアップ参加者の全ての適切なピックアップ属性１５１１（例えば、マッチング、幾何学、グルーピング、及び／又はエイリアシングのような属性）を含むデクラレーション１５１０と一緒にＯＷ１５２２にゲットリスト命令１５４０を配信する。ウェブサービスハンドラ１５４１および任意の関連エンジンは、デクラレーション１５１０を処理してタグ１５５０を生成してもよい。その結果物は、ピックアップ参加者タグ１５５０と一緒に、マッチングエンジン１５６０に送信される。そして、ＯＷは、マッチングエンジン１５６０を使用して、ピックアップ参加者のタグ１５５０と一致するタグＤＢ１５２２における全てのタグについてルックアップを実行する。そして、ＯＷは、この参加者が１５５２がピックアップするのに適格なオブジェクトのリスト１５４２を返送し、そのオブジェクトのリストには優先順位がつけられる。トークンがピックアップすることを要求するリスト１５４２におけるエントリーは、リストに挙げられていてもよい。一実施形態において、トークンオーソリティに対するポインタまたは他のアクセスメカニズムが提供されてもよい。例えば、一実施形態において、適格なオブジェクトのリストにおける各データオブジェクトは、必要とされれば、そのオブジェクトについてのトークンを配信することに関与する制御オーソリティに対するポインタと、そのトークン要件の指示を含んでもよい。以下で更に詳細に説明するトークンオーソリティは、トークンを発行するために使用されてもよい。或る実施例では、ピックアップ参加者は、ピックアップに先だってトークンを取得するためにトークンオーソリティをアクセスすることを要求されてもよい。例えば、参加者は、トークンをピックアップするためにリストに提供されたトークンオーソリティへのリンクに従ってもよい。そして、ピックアップ参加者は、オブジェクトのピックアップに戻るときにこのトークンを提示することができる。しかしながら、他の実施形態は、参加者にトークンを配信するための他の技法を有してもよい。
【００７３】
データオブジェクトを読み取る処理の例は、次のようである。参加者１５５２は、ピックアップ属性１５４６、トークン１５４７、およびインデックス、またはピックアップされるべきオブジェクト（以前のゲットリスト応答から得られる）についての他のロケータ(locator)を含むデクラレーション１５４５と一緒にＯＷ１５２２にピックアップ命令１５４３を配信してもよい。ＯＷのウェブサービスハンドラ１５４１、およびグルーピングエンジン１５６１、地理空間エンジン１５６２、またはトークンエンジン１５６３のようなシステムに備えられる任意のプラグインエンジンは、リクエストを処理し、他のタグ１５５０を生成する。ウェブサービスハンドラ１５４１は、タグ１５５０およびオブジェクトインデックスをマッチングエンジン１５６０に送信してもよい。マッチングエンジン２６０は、オブジェクトが、この参加者１５５２によるピックアップについて依然として適格であることを検証してもよい。もし適格であれば、そしてもしトークンが要求されれば、トークンエンジン１５６３は参加者のトークン１５４７を有効化してもよい。もしトークン１５４７が有効であれば、オブジェクト１５４２は、リクエストしているピックアップ参加者１５５２に返送される。或るアプリケーションでは、参加者のトークンは、データオブジェクトをピックアップする処理において消費されてもよい。このトランザクションのレコードは、さらに、後のレポート生成のためにログをトラッキングするＯＷに記録されてもよい。参加者１５５２は、このオブジェクトピックアップイベントの詳細を提供するＯＷ１５２２からのトランザクションレポートを要求することができる。
【００７４】
図１６は、本発明の他の実施形態によるトークンを用いたオブジェクトウェアハウスの例を示す。この例は、トークンをマッチングするための一つの技法を示す。例えば、トークンが生成されて、データオブジェクトの読み取りにおける参加者による使用のために配信されてもよい。トークンベースまたはトークンライクな交換に利用可能な種々のスキームが存在する。この例は、プライベートなＯＷトークンメカニズムを示す。例えば、ＯＷは、公開鍵基盤（“ＰＫＩ(Public Key Infrastructure)”）に基いてもよい。ここで、ＯＷは、ＯＷにデポジットされたデータオブジェクトに対してリンクされたトークンオーソリティのためのトークンを生成してもよい。トークンオーソリティは、例えば、トークンを所有し、それら自身の配信ポリシーに従ってそれらを配信してもよい。或るアプリケーションでは、同一のトークンオーソリティが多数のオブジェクトのために使用されてもよく、異なるトークンが、異なるオブジェクトをピックアップするために要求されてもよく又は同一のトークンが異なる多数のオブジェクトのうちの任意の一つをピックアップするために使用されてもよい。加えて、異なる実施形態では、トークンオーソリティは、無料でトークンを提供し、料金を請求し、長い時間をかけて又は参加者にゆっくりと配信し、または任意のアルゴリズム又は所望の処理に従ってトークンを配信する。或るアプリケーションでは、各トークンは、オブジェクトをピックアップするために１回だけ使用されてもよく、これにより使用されると消費される。消費されたトークンを再使用する任意の試みは無効(invalid)であってもよく、ピックアップリクエストは拒否される。或いは、マルチセッションピックアップが使用されてもよい。例えば、もしオブジェクトが大きく、または全オブジェクトがピックアップされる前にＯＷに対する接続が破綻すれば、オブジェクトのリマインダ(remainder)は、転送を開始するために使用される同一のトークンを用いてピックアップされることが許される。このような例では、トークンは、オブジェクトが首尾よく参加者に転送されるまで完全に消費されない。レポートは、ＯＷから、消費されるトークンと配信されるオブジェクトを詳述するトークンオーソリティに対して利用可能である。
【００７５】
以下はトークンを生成する例である。一実施形態において、トークンの生成は、多くのトークンを生成するためにＯＷにリクエストを送信することによって達成される。例えば、ＯＷは、リクエストごとに１ないし２５６のトークンを生成してもよい。この例では、もし２５６を超えるトークンが必要とされれば、トークンオーソリティは、複数のリクエストを送信することができる。ＯＷとトークンオーソリティとの間の通信は、参加者間で情報を交換することのようであってもよい。例えば、図１６に示されるように、ＯＷ１６２２は、参加者として同一または異なるＯＷからオブジェクトをピックアップ及び／又はデポジットする参加者であってもよい。一実施形態において、これは、例えばＯＷ参加者プロキシ１６５２を用いて達成される。例えば、参加者１６５１は、トークンオーソリティとして動作してもよく、ＯＷ１６２２にオブジェクトをデポジット１６３０するための命令を送信する。付随のプロクラメーション１６００は、ＯＷ１６２２がこのオブジェクトをピックアップするのに適格であることを示すピックアップ属性を含む。オブジェクトは、１又は２以上のトークンを生成するためのリクエストである。一実施形態において、ＯＷのウェブサービスハンドラ１６４１と任意のプラグインエンジンは、プロクラメーション１６００を処理してタグ１６２１を生成する。タグ１６２１とプラグインエンジンからの任意の出力はＤＢ１６２０に格納される。
【００７６】
定期的に、ＯＷ参加者プロキシ１６５２が起動して、ゲットリスト１６４０の命令をＯＷのウェブサービスハンドラー１６４１に送信する。プロキシ１６５２は、タグＤＢ１６２０に格納されている対応タグで１又は２以上のワークリクエストオブジェクトを探してもよい。ウェブサービスハンドラ１６４１とオプションのプラグインエンジン１６６１，１６６２，１６６３は、デクラレーション１６１０を処理して、ピックアップ参加者タグ１６５０を生成する。タグとプラグインエンジン出力は、タグＤＢ１６２０におけるマッチングタグを探し出すためにマッチングエンジン１６６０に送信される。適格なオブジェクトのリストはピックアップ参加者に返送され、それは、この例では、ＯＷプロキシ１６５２である。もし、オブジェクトがプロキシによるピックアップに利用可能であれば、ＯＷ参加者プロキシ１６５２は、非エンプティのリスト１６４２を受信し、そのリストをＯＷアドミニストレーション処理１６７０に送信する。アドミニストレーション処理１６７０は、例えば、トークン生成またはルールマネージメントを含むオブジェクトウェアハウスシステム機能を実施するための１又は２以上のソフトウェアコンポーネントであってもよい。ＯＷアドミニストレーション処理１６７０は、オブジェクトリスト１６４２を通じて動作し、ＯＷオブジェクト貯蔵部からアドミニストレーション処理に読み取られるべきオブジェクトについてのピックアップ命令を発行することをＯＷ参加者プロキシ１６５２に要請する。オブジェクトは、ピックアップされ、そして処理のためにＯＷアドミニストレーション処理１６７０に戻される。“トークン生成”コマンドについて、要求された数のトークンが生成される。トークンは、シリアル化されてもよく、例えば、それぞれＯＷの秘密鍵でサインされてもよい。従って、鍵を用いて、トークンは、ＯＷの公開鍵を用いることにより有効化されることができる。必要とされる数のトークンは、例えば、同様のデポジットおよびピックアップ技法を用いるＯＷを用いてリクエスト参加者１６５１に戻されてもよい。“トークン生成”コマンドは、また、トークンオーソリティＰＫＩ証明(Toke Authorities PKI Certificate)を含んでもよい。従って、配信されるトークンは、トークンオーソリティによって連帯保証(cosign)されてもよく、この証明は、提供されるトークンの信頼性を決定するために後でＯＷによって使用される。
【００７７】
トークンの使用と配信は次のように進められる。トークンオーソリティは、上述のピックアップ技法およびデポジットを用いて“トークン生成”リクエストに応答してＯＷから、必要な数と同じ数の多くのトークンをピックアップしてもよい。そして、トークンオーソリティは、任意の所望の基準で、任意のエンティティにこれらのトークンを配信することができる。そして、トークンは、使用されるときにＯＷによって有効化される。例えば、或る実施形態では、トークンが有効化されるために、それらは、ＯＷに提示されるときにトークンオーソリティによって連帯保証されなければならない。もしトークンがトークンオーソリティによって適切に連帯保証されず、またはトークンが既に消費されていれば、このようなトークンは無効である。或る実施形態において、トークンは長い時間をかけて失効しなくてもよい。他の実施形態では、トークンは、或る所定の期間の後に失効してもよい（例えば、プロモーション）。一旦、トークンがＯＷに提示されれと、それは有効化されてもよい。或る実施形態では、有効化は、ＯＷの署名が有効であることと、連帯保証のトークンオーソリティが有効であることを確かめるために使用されてもよい。他のアプリケーションでは、広範な種々の他の有効化技法が使用されてもよい。一旦、トークンが有効化され、オブジェクトをピックアップするために使用されると、トークンは、例えば、“使用中(in-use)”または“アクティブ(active)”としてマークされる。或る実施形態では、トークンは、トークンがピックアップの処理にあるときに“使用中”としてマークされるシリアル番号を含んでもよい。トークン“使用中”は、もし、このようなオブジェクトのピックアップがこのトークンを用いて開始されれば、単一のオブジェクトをピックアップすることを継続するために繰り返し使用されてもよい。一実施形態において、新たなピックアップは“使用中”のトークンと共には可能ではない。一旦、完全なオブジェクトがピックアップされると、このトークンは、“消費済(consumed)”または“無効(invalid)”としてマークされてもよい。このようなトークンは、もはや、ＯＷから何らオブジェクトをピックアップするために使用されず、ピックアップを継続しない。ＯＷは、例えば、決して再使用されることがないユニークなシリアル番号によって各トークンを追跡してもよい。ＯＷトークンの設計は、実際の貨幣等価額を含む商取引を支援するために使用されてもよい。従って、或るアプリケーションでは、商取引の要素の不正な再使用または配信を許容しないことが重要である。また、トークンは、インターネット課金ユニットまたは異なる国の通貨のような多数の貨幣本位(monetary standards)を具現するのに十分な柔軟性を有する。
【００７８】
＜例６＞
レポーティング(REPORTING)
或る実施形態において、ＯＷは、本明細書で述べられた他の情報交換の全てまたは幾つかと同様に、トークン交換動作の完全なログを保持してもよい。例えば、ＯＷの実施形態は、参加者が、長い期間にわたってＯＷからピックアップされデポジットされたオブジェクトのライフサイクルを詳述する個別のレポートをピックアップすることを可能とする管理およびレポーティングウェブサービスを支援してもよい。これらのレポートは、参加者によってピックアップされたオブジェクト及び／又はデポジットされたオブジェクトのブレークダウンを提供してもよい。それらは、また、例えば、参加者が、前の動作に従って未来の情報配信オプションを計画することができるように、時間、グループ、クラス、及び／又は幾何学情報を含んでもよい。これらのレポートは、また、活動を学習するビジネスワークフローを提供するために使用されることができる。この学習は、実際に、動的な形式でモデルドリブン処理(model driven process)に組み込まれることができる。例えば、モデルドリブンビジネスプロセスは、情報の交換とフローを含む定義を有してもよい。ＯＷからのレポートは、例えば、実際の情報フローに基づくビジネスモデルを動的に調整するために使用されてもよい。調整されたモデルは、ビジネスプロセスを稼動させるソフトウェアを調整するために使用されてもよく、それは、ビジネスプロセスの動的な変更をもたらす。加えて、レポーティングは、トークン動作(token activity)を追跡するために使用されてもよい。例えば、ＯＷのレポーティングコンポーネントは、必要ならば、各トークンまたは全てのトークンについてトークンライフサイクルレポートを構築するために使用されてもよい。また、いつでも全てのトークンのステータスを知ることも可能である。トークンオーソリティは、いつでもＯＷに対し配信されなかったトークンを戻すことができ、循環(circulation)からトークンシーケンス番号を効果的に取得する。
【００７９】
上述の説明は、本発明の態様がどのように実施されるかの例と共に、本発明の種々の実施形態を例示する。上述の例および実施形態は、唯一の実施例であると見なされるべきではなく、添付の請求項に定義されたような本発明の利点および柔軟性を示すために提示されたものである。例えば、上述の実施形態の幾つかの或る特徴は、少しばかり挙げれば、異なるネットワークを介してオブジェクトを送受信すること、異なるネットワークプロトコルでネットワークを介してオブジェクトを送受信すること、車両のようなインターネット接続を有するシステム間でオブジェクトを送受信すること、またはデータオブジェクトがどうのようにネームに処理されるかを特定するルールを動的に変更することのうちの１又は２以上を含むが、それに限定されるものではない。一実施形態において、上述したＯＷは、受信されてＯＷに格納されたデータオブジェクトのコンテンツをアクセスしない。従って、ＯＷの或る実施形態は、参加者間のデータオブジェクトを変更するために、デポジットおよびピックアップ通信のような各ＯＷトランザクションを伴うトランスポートリクエスト（例えば、プロクラメーションおよびデクラレーション）の属性のみを使用してもよい。同様に、或る実施形態では、トランスポートリクエストにおける属性情報は、データオブジェクトと共に参加者間を伝送されなくてもよい。従って、或る実施形態では、データオブジェクトは、関連する属性情報から完全に論理的に分離される。上述の開示内容と請求項の内容に基づき、当業者であれば、他の利益、構成、実施例、実施形態、および均等物は明らかであり、本願の請求項に定義される本発明の要旨および精神を逸脱することなく採用されてもよい。
【図面の簡単な説明】
【００８０】
【図１】本発明の一実施形態によるオブジェクトウェアハウスを例示する図である。
【図２Ａ】本発明の一実施形態によるオブジェクトウェアハウジングを例示する図である。
【図２Ｂ】本発明の他の実施形態によるオブジェクトウェアハウスを例示する図である。
【図３】本発明の一実施形態による情報交換方法を例示する図である。
【図４】本発明の一実施形態によるウェブサービスとして実施されるオブジェクトウェアハウスの一例を示す図である。
【図５】本発明の他の実施形態による情報交換システムを例示する図である。
【図６】本発明の他の実施形態による情報交換方法を例示する図である。
【図７】本発明の他の実施形態による情報交換方法の一例を示す図である。
【図８】本発明の他の実施形態による属性情報の一例を示す図である。
【図９】本発明の他の実施形態による情報交換の一例を示す図である。
【図１０】本発明の他の実施形態によるマッチング技術の別の例を示す図である。
【図１１】本発明の他の実施形態によるグループに基づく情報交換の一例を示す図である。
【図１２】本発明の他の実施形態による地理空間情報に基づく情報交換の一例を示す図である。
【図１３】本発明の他の実施形態によるトークンを用いた情報交換の一例を示す図である。
【図１４】本発明の他の実施形態による情報交換方法を例示する図である。
【図１５】本発明の他の実施形態によるトークンを用いた情報交換の一例を示す図である。
【図１６】本発明の他の実施形態によるトークンを用いたオブジェクトウェアハウスの一例を示す図である。
【符号の説明】
【００８１】
１００；オブジェクトウェアハウス
１０１；オブジェクト貯蔵庫
１０２；トランスポートコントローラ
１１０Ａ；データオブジェクト
１１０Ｂ；トランスポートリクエスト
１５０；ネットワーク
１５１；アプリケーション
１５２；移動体装置
１５３；オブジェクトウェアハウス
１５４；ウェブサービス
１５５；ネットワーク
【図１】
2008269595.tif 000003
【図２Ａ】
2008269595.tif 000004
【図２Ｂ】
2008269595.tif 000005
【図３】
2008269595.tif 000006
【図４】
2008269595.tif 000007
【図５】
2008269595.tif 000008
【図６】
2008269595.tif 000009
【図７】
2008269595.tif 000010
【図８】
2008269595.tif 000011
【図９】
2008269595.tif 000012
【図１０】
2008269595.tif 000013
【図１１】
2008269595.tif 000014
【図１２】
2008269595.tif 000015
【図１３】
2008269595.tif 000016
【図１４】
2008269595.tif 000017
【図１５】
2008269595.tif 000018
【図１６】
2008269595.tif 000019